The main problem is that our G-Uni pools may shortly be out of range. Then, thinking long term, I find that our current incentive system for Uniswap V3 considerably reduce the flexibility and risk management possibilities for LPs, as well as the efficiency of the pool.
The issue for every DAO willing to incentivize Uni-V3 LPs is that it’d be to expensive to properly track on-chain different positions, so at first we’ve opted for incentivizing only a single range. But I propose a new incentive system that remedy this and would work as follow:
Anyone could provide liquidity to the Uni V3 pool, either directly, either through G-Uni, either through a management solution like Gamma
Each week, we’ll compute for each wallet the time-weighted amount of on-range agEUR provided and the fees earned (the exact formula would need to be discussed later)
From this we’ll split the ANGLE incentives of the week (with veANGLE boost) and upload a merkle root on chain
Any LP would be able to claim its ANGLE from the distribution contracts
The pros and cons I see would be:
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
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
Sounds good to me! Good think also is that G-UNI holders and stakers wouldn’t have anything to do if they want to keep receiving ANGLE rewards as well: no unstake or not getting rid of G-UNI tokens to LP again on Uniswap.
Other point is about the exact incentive formula based on your in-range liquidity + fees accumulated: should it be half/half or should we have something smarter to completely eliminate like LPs doing just-in-time-liquidity?
For the second we’d have to use a formula involving a product of time-weighted average liquidity and fees earned.
Yes agree for the APY part, this is going to be harder to predict since it’ll vary for everyone.
We’ll still support G-UNI positions so that if you want to do it passively and still get ANGLE rewards you’ll be able to do so.
Only thing is that it may no longer be the optimal behavior in this sense.
I have the feeling that the people that provide the current liquidity in the G-UNI (e.g. WETH/AgEUR) are not the kind of people with capacity to provide “changing UNI V3 ranges”. So I don’t know if someone will really switch (at least at this stage of the growth of the Angle protocol).
I have a similar suspicion. The minimalist approach is to push out the complexity and let individual LPs find and use solutions if they want to find an edge to earn slightly higher ANGLE rewards, particularly if it minimizes manual intervention on the ANGLE side. From the outset the GUNI vault perhaps should have been across the full range to allow this passivity.
Would you reallocate the existing dilution for the gauge to the new ranges or increase dilution to send tokens to the new ranges.
So I don’t expect a lot of people to change their range frequently, it’s more that I think this is the easiest and more efficient solution to be able to be flexible and support G-Uni / Gamma / direct LPing.
Like from a current user, it wouldn’t change much, the only difference would be the that the smart contract distribution the rewards changes. But for example to add Gamma it’d be way easier, as there would be no need for a new gauge.
Beyond the scope of this discussion, but I’ll have a think on what we could do to incentivize driving liquidity to these pairs beyond dilution. Reality is that we can tweak the ranges somewhat to increase localized efficiency gains but the effectiveness of this incentive in monetary terms is very much in a diminishing returns region.
I think this is a good idea. My only concern is making sure the formula we use is robust and correct, and also it does add a little bit of overhead for the team to do the calculation every week for distribution. If you guys want to move forward with this idea, go ahead and work out the formula and process, and we can review/discuss it here to make sure we aren’t missing anything.