Excessive rounding error in CL LP in pool's favor, consuming amounts more than specified by user by 1 unit

[p0mvn]

Background

Context in this thread: https://osmosis-network.slack.com/archives/C027ELA290B/p1699445946284559

We create a position with the following tokens,
MsgCreatePosition { pool_id: 1, sender: "osmo14hj2tavq8fpesdwxxcu44rty3hh90vhujrvcmstl4zr3txmfvw9sq2r9g9", lower_tick: -200000, upper_tick: 200000, tokens_provided: [Coin { denom: "ibc/27394FB092D2ECCD56123C74F36E4C1F926001CEADA9CA97EA622B25F41E5EB2", amount: "6000600052806000600892" }, Coin { denom: "uosmo", amount: "6000000000000" }], token_min_amount0: "0", token_min_amount1: "0" }
our response looks like this:
MsgCreatePositionResponse { position_id: 3, amount0: "6000000000001", amount1: "6000600052806000600892", liquidity_created: "56880086426956298610460832047547425567975", lower_tick: -200000, upper_tick: 200000 }
The atom amounts on both sides are the same
6000600052806000600892
6000600052806000600892
but the osmo amount increases between our sent funds
6000000000000 <- sent amount
6000000000001 <- amount used in the position
Our position here has gotten assigned 1 more uosmo than it actually supplied

Initial Investigation

I think we might have a small rounding issue where users can get uncharged by 1 unit in the worst case. What happens in LP logic is that: We compute liquidityDelta from desired amounts 0 and 1, position ticks and current ticks (here) Using the liquidityDelta we then recompute the actual amounts 0 and 1 (here) The amounts 0 and 1 are rounded up when providing liquidity in pool's favor. That is, as a user, for X liquidity that you get in return, you might have to provide one more unit than requested

This can be improved by defining better rounding properties in the first step to compute initiql liquidityDelta . In these methods. It should consistently round down

What they shared is that they give 6000000000000 in the request. This is the desired amount From response, they get charged 6000000000001 , this is the actual charged amount

Priority

From Dev: would put this as a bug we do need to solve, but not important relative to ~everything else were doing (unless easy to fix)

Acceptance Criteria

• fix bug
• cover with tests