You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am not sure this can be called bug or a design decision, but imagine the following scenario:
January 1st userA addLiquidity and gets 100 shares minted
Between January 1 - June 30th lots of swaps are happening, but no one removes liquidity
On June 30th the pool price is the same as it was on January 1st, and userB adds the same liquidity as userA and gets the same 100 shares minted
Now if userB redeems, he can run away with all the fees generated between January 1st - June 30th
The problem is that 'rebalancing' is only called during removing liquidity from the pool, so the fees are not accounted for unless someone withdraws liquidity. So the fairness of the fee distribution depends on how often the withdrawLiquidity method is called.
Expected Behavior
easiest fix would be to call rebalance before depositing too, then mint: userSuppliedLiquidity*totalAmountOfTokensMinted/allLiquidityHeldByThePool
To Reproduce
No response
Additional context
No response
The text was updated successfully, but these errors were encountered:
Describe the bug
v4-periphery/contracts/hooks/examples/FullRange.sol
Line 152 in 581d96d
I am not sure this can be called bug or a design decision, but imagine the following scenario:
The problem is that 'rebalancing' is only called during removing liquidity from the pool, so the fees are not accounted for unless someone withdraws liquidity. So the fairness of the fee distribution depends on how often the withdrawLiquidity method is called.
Expected Behavior
easiest fix would be to call rebalance before depositing too, then mint: userSuppliedLiquidity*totalAmountOfTokensMinted/allLiquidityHeldByThePool
To Reproduce
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: