This proposal follows the discussion we had here. To sum it up:
I propose to switch for Uniswap V3 from a staking system to a system were rewards are computed on chain.
There are 4 ways to be eligible for the rewards:
- LP directly on Uniswap through the
NonfungiblePositionManager
- LP through Arrakis and hold Arrakis LP token
- LP through Arrakis and stake the Arrakis LP token on the Angle gauge (for backward compatibility)
- LP through Gamma once they’ve deployed the pool
Then the computation would be as follow:
- The weekly distribution is split against every swap that happened during the week proportionally to their volume.
- For each swap, the rewards are split between all LPs position in range, proportionally to:
(0.4 * (fees earned by the position)/(fees of the swap) + 0.4 * (agEUR in the position)/(agEUR in the pool)+ 0.2 * (other token in the position)/(other token in the pool)) * veANGLE boost
The first factor is in favor of more concentrated positions as they’ll earn more fees, but less risky positions still get a decent share of rewards.
The script I’ve made to compute rewards is here: Uniswap V3 Reward Computation · GitHub
Finally the reward amounts would be brought on-chain using a merkle root.
The smart contract code would be this one: Reward Distributor · GitHub. I don’t think it needs to be audited as it’s quite standard, won’t manage funds outside from the weekly distribution and has been tested on our side.
As a reminder, the pros and cons of this new system are the following:
Pros:
- Maximal flexibility on the DAO side: the distribution rules could be changed anytime
- Maximal flexibility on the LP side: they can choose their range or their management solution
- Optimized UX: as there would be no need to stake the Uni V3 position, it minimizes the number of on-chain txs
- Minimal Composability risk: as we don’t rely on any external party to stake the position, there is no risk of smart contract failure
- Current LPs would not have to do anything: we’ll include them in the computations so they don’t even have to unstake their position
Cons:
- It requires trust in a centralized party to compute and upload the merkle root. However this trust is relative as the party would only be able to steal one week distribution of ANGLE
The goal would be to move this to voting in the coming days to eventually switch before the next epoch.