Applying the x/farm logic to x/gamm module

[Thunnini]

I was hoping to apply the x/farm module to the x/gamm module as well. Currently, the x/gamm fee distribution mechanism accumulates the swap fees then gives the fee to the user upon claiming in proportion to the shares owned, so technically an LP who deposited later has some advantages if other users don’t claim their portion of the rewards as often. Therefore, I believe the F1 fee distribution mechanism is more reasonable so we should apply to the x/gamm module as well. Also, since there is no way to distribute the exit fee and the F1 distribution module will allow this as well.

However, this brings up another issue since each LP tokens have a different amount of fee reward accumulated, so unlocked LP tokens are technically not fungible with each other unless there is additional logic to stake the shares. Perhaps staking the share token upon minting by default could solve this. But the bigger issue that I see is that when the pool’s share tokens are staked to the pool, the lockup module isn’t able to be used. One option is to change the lockup module’s architecture, as going with the current implementation will force users to choose whether to receive the pool rewards or the Osmo farming rewards.

Pros:

• Fee distribution is more equitable
• Exit fee distribution can happen

Cons:

• Requires a stake/unstake feature to be added to the pool shares
• Need to come up with a different mechanism to distribute the exit fee
• Not compatible with the current lockup module

[sunnya97]

Question: Why not just add SwapFees into the pool, rather than distributed as rewards? This way we don't need F1 or anything like that. Just need to keep track of LP tokens and total shares.

This works as long as the token being distributed is part of the pool (which SwapFee tokens should be).

The place where this is a problem is when the token to be distributed (such as OSM liquidity rewards) is different to what's in the pools. But I think for this, we don't need to have a continuous distribution. That can be done in an epochized way, where it iterates over all recipients, but only like once a day or week or something.

I think this will remove a lot of this complexity

[Thunnini]

Currently Balancer & Uniswap only calculate and distribute the fee upon withdrawal according to the portion of shares owned. The issue I see is that if I had 100 ATOM worth of fees to receive, and if someone deposits the same amount of liquidity right before I withdraw my swap fee gets cut in half even though I have been providing liquidity for longer.

However, I guess since this isn’t seen as a major issue on the Ethereum AMMs this may not be as big of an issue as I am thinking.

And like you’ve mentioned, the exit fee is paid in the share tokens which isn’t supported in the current implementation. However, since it seems like Balancer, even though has the exit fee but is fixed to a 0% value–so I’m okay with not prioritizing implementation for the exit fee.

[sunnya97]

and if someone deposits the same amount of liquidity right before I withdraw my swap fee gets cut in half even though I have been providing liquidity for longer.

But they would be getting less share tokens. Because as fees accumulate in the pool, then the ratio between liquidity:shares is increasing. They'd have to add more liquidity to get the same amount shares tokens as you.

And like you’ve mentioned, the exit fee is paid in the share tokens which isn’t supported in the current implementation.

So it seems the simplest solution would be to fix this, right?

[sunnya97]

Closing this due to switch to using x/incentives module.