Uniswap V3 rETH Incentives

Intro
This proposal outlines a path forward for rETH liquidity on Uniswap V3. This is both a governance proposal and a partnership proposal. We are putting forward our capital markets platform, xToken Terminal, as the service provider for rETH liquidity incentivization. Terminal allows projects to deploy a highly configurable Uni V3 LM program in a matter of minutes, no dev work or technical expertise required. Terminal is permissionless and rigorously tested, providing an out-of-the-box solution that saves projects time and money.

Back to rETH. Currently, rETH liquidity on Curve is fairly strong with 22k rETH paired against 6.5k wstETH, facilitated by Convex-routed incentives. Balancer liquidity is solid as well, with 3.2k rETH paired against 3.5k ETH. (All values as of May 9th.)

While there is a nontrivial amount of rETH liquidity on Uniswap (1.3k rETH paired against 550 ETH), there is room for improvement. In order for rETH to compete against other ETH liquid staking providers, we should maintain a substantial amount of liquidity on Uniswap V3, the highest volume and most capital efficient DEX.

Designing an LM Program
While Uniswap V3 offers major advantages for traders and LPs, it comes with give and takes that are important to understand in designing the best liquidity incentivization strategy for rETH. Additionally, there are considerations that come with any liquidity mining program that are worth discussing.

In designing an LM program, we first need to understand what we’re optimizing for. After a few weeks gauging community sentiment, we believe these are the community’s top priorities:

  • #1: Maximizing capital efficiency
  • #2: Limiting opportunity cost
  • #3: Minimizing gas costs

With these priorities in mind, we can establish the key decision points for the program:

  • #1: Asset pair
  • #2: Range concentration
  • #3: Rebalance/migration frequency

Interestingly enough, the decision on point #1 drives the logic on points #2 and #3.

Asset Pair
So, what asset should rETH be paired with? The Curve pool is paired with wstETH - a wrapper for Lido’s liquid staking asset - and the Balancer pool is paired with vanilla WETH. These are likely our two best options for the Uni pool.

The arguments for vanilla WETH are:

  • Highly liquid and accessible with negligible smart contract risk
  • Doesn’t force LPs to have exposure to a competitor’s asset

The arguments for wstETH are:

  • No opportunity cost as both sides of pair are earning staking returns
  • No rebalance or pool migration requirements as wstETH and rETH should not diverge materially in price ratio

Range Concentration
No matter if we choose WETH or wstETH, the price range we choose on the rETH pair will be highly concentrated. However, due to the fact that wstETH and rETH are unlikely to deviate in price, we can comfortably set a more concentrated range than on a WETH pair.

In the case of the WETH pair, rETH slowly gains in price on WETH, meaning that our price range will likely want to consider some slack to the upside. But because rebalancing liquidity requires some technical expertise, the initial version of Terminal does not allow pool sponsors to “reposition” their price range (more on this later!), as this can be complex and inadvisable depending on liquidity conditions. This means that LPs would need to migrate their liquidity to a new pool with a new price every so often, depending on the concentration of the range. LPs may not be happy about needing to spend gas to migrate liquidity every so often.

Rebalance/Migration Frequency
As mentioned above, a wstETH pairing would be unlikely to require any rebalances or pool migrations, because wstETH and rETH should move roughly in line with each other.

On a WETH pair, the frequency of pool migrations would depend on how concentrated the price range is. The more concentrated the range, the more frequent the requirement for migration.

This is a bit of a quagmire, because we don’t want to require that LPs manually migrate their liquidity every so often. Additionally, we want liquidity to be as concentrated as reasonably possible.

This challenge is exactly why we have begun development on the Rebalance CLI - a new feature that we’re announcing here publicly for the first time. We realized that for xToken Terminal to reach its full potential, we needed to empower projects with the ability to reposition liquidity without requiring their LPs to manually migrate. The CLI is best-suited for pools with concentrated price ranges on asset pairs with sufficient external liquidity (outside of Uniswap). A rETH<>WETH pool fits the use case perfectly.

For reference, management of Terminal pools is entirely non-custodial. We (xToken) do not have any control or influence over deployed pools. We’ve implemented a number of careful safeguards into the CLI in order to ensure an effective rebalance. However, this feature would need to be operated by the Rocket Pool team and/or community.

Incentives Program Proposal
In light of this analysis, we’re proposing a highly concentrated rETH<>WETH pool (0.05% fee tier), with the benefit of the Rebalance CLI for seamless liquidity repositioning. For the initial trial period, we’d like to propose 400 RPL in rewards over 10 weeks. This should provide an opportunity for the community to get comfortable with the program as well as attract sufficient liquidity to effectively demonstrate the Rebalance CLI. Towards the end of the program, we will do an analysis of the program and open a discussion on whether to extend it. If the community is in favor, Terminal allows sponsors to renew rewards on a pool in just a few clicks.

On Security
Those who are familiar with the previous version of our project know that at our peak we managed over $100m in assets, specializing in native staking strategies and later getting into liquidity strategies. In fact, for several months after Uniswap V3 launch, we were the largest provider of Uni V3 managed liquidity (peaking at $25m). Those who are familiar with our project also know that we had security incidents in spring/summer 2021, related to our deprecated asset management product line. Since then, we’ve bolstered our security practices and have developed a rigorous and intentional process. Additionally, the Terminal liquidity mining contracts have been audited by ABDK, have been the subject of an Immunefi bounty program for several months and have undergone several months of internal review.

Appendix: Some Basic Math on Uniswap V3
It’s well understood that incentivizing a rETH pool on Uniswap V3 would be much more capital efficient than a similar incentive on Uniswap V2. But how much more?

Let’s start with some assumptions:

  • Rocket Pool pays out $1000 in incentives per week on a rETH<>WETH pool
  • LPs demand an APR of 10%
  • There is no other liquidity in the Uniswap pool besides for the incentivized liquidity
  • For simplicity, 1 rETH = 1 WETH = $2500
  • Our Uni V3 range will allow for 0.25% price deviation in either direction (tick range of [-30, 20])

Under these assumptions, both a Uni V2 and a Uni V3 pool would accumulate slightly more than $500k in TVL (~104 rETH + 104 WETH).

Now to test the gains in capital efficiency from V3. Say you wanted to exchange 40 WETH for rETH:

  • On V2, you’d receive 28.83 rETH
  • On V3, you’d receive 39.96 rETH

Even on a small scale, you can see the massive gains that come with concentrated liquidity. V3 yielded 39% more rETH in this case!

8 Likes

Thanks for thinking of us! So in the example given, a $1000/week incentive, and liquidity to command a 10% LP reward would result in 40 ETH trade having a slippage reduction of 11.17 ETH => 0.04 ETH?

280x more capital efficiency? Just want to make sure I’m understanding the math right.

4 Likes

Yup, that’s right. I tried to steer clear of any exact promises of capital efficiency given that there are some moving pieces and this is just a demonstration, but you’re understanding the math correctly

2 Likes

This proposal makes so much sense. Love the real world example at the end!

@mjc716 - I love the steer clear concept and an excellent explanation of the mechanics of what you are proposing. Nice reference to current data, with absolutely no “advice” on the “financial” outcome. The only sentence I see that might need a second look. Look at the snippet below. “comes with give” There is a plural error there; entirely up to your thinking and mindset on this one. I just thought of an option. Does this edit fit into your perspective?

(ORIGINAL)
… it comes with give and takes that are important to understand in designing the best liquidity incentivization strategy for…

(EDIT)
… it comes with giving and takes some understanding of designing when incentivizing for the best liquidity strategies.

1 Like

yes i meant “gives and takes” - good catch

Thanks for the proposal. Wondering if there is any consideration of the UNI v3 pools on Arbi and Opti for this propospal? I mean these pools are probably a drop in the ocean in TVL now … but I assume these pools to get bigger incrementally as L2#22 plays out in full force. It would be also good to think about incentivising the L2s even if that little extra … so that the low to mid sized whales and much smaller players can actually gain from moving to the L2s

@mjc716 thank you for your well thought out proposal.

This isn’t necessarily about Token Terminal but the core team have always been concerned about the effect of liquidity incentives, in general:

  • Liquidity incentives deepen liquidity, without a matching rise in trade volume, and so makes LPs dependant on incentives to be profitable
  • Liquidity incentives attract mercenary capital if incentives are removed, reduced, or they find a better offer they will shift to the other opportunity removing rETH liquidity
  • RPL has a fixed inflation, giving liquidity incentives means Rocket Pool are locked into a war against other protocols to attract liquidity - potentially causing more and more of its treasury to be allocated to liquidity incentives and not on developing our ecosystem
  • Increasing demand for rETH without significant increase in supply will cause UX issues
  • rETH needs both depth on L1 and distribution on L2, so we would have to provide incentives across the board otherwise only the incentivised pool would attract liquidity

Additionally we are concerned about the following:

  • Liquidity distribution rights (such as Curve bribes and Tokemak) leave our liquidity up to political winds
  • Relying on one platform to deliver our liquidity is a single point of failure

The community-run Curve initiative was very successful in many ways, but it also proved our concerns were real.

1 Like

Yes, I 100% agree that L2s will be essential for rETH liquidity going forward. We thought of this proposal as more of a “trial” which, if deemed successful by the community and team, could lead to more L1 incentives and also L2 incentives in the future.

Luckily, Terminal makes it really easy to create Uni incentive programs so if the community wanted to move forward with an L2 program at any point, it could come together very quickly (assuming governance approves of course)

2 Likes

Hey @langers - thanks for the thoughtful reply from you and team! I don’t necessarily disagree directionally with any of this but I think we can assuage most of your concerns. Some thoughts:

  • Being prudent about long term positioning at this stage shows that RPL are a really long term oriented team. That said, I don’t think the trial program we’re proposing will come close to a scale where we’d be forced to contend with most of these issues. The liquidity generated should be relatively small compared to the current liquidity in the curve pool for example. We tried to frame the proposal as a trial where we’ll take our learnings into any future program. Or if the community doesn’t deem it successful, the program would of course not be extended

  • In terms of creating a dependency where LPs need to rely on incentives, I think this is something that we should be vigilant about. On the other hand, facilitating liquidity is a pretty natural cost of doing business for most projects, including liquid staking protocols. I think people are coming around to the fact that liquidity is crucial for most web3 projects and liquidity incentives are sort of just another line item cost, similar to paying salaries or server costs (I’m currently writing a blog post on exactly this)

  • If the trial program is successful, I think the path would be figuring out how much of a budget for incentives the community is comfortable with and working backwards from there on how much should be allocated to L1, L2, Uni, Curve, etc., however folks think is the best way to slice it

  • On the two additional points at the bottom of your message - it would seem to me that incentivizing Uni v3 liquidity would be a step in the right direction towards relieving those concerns, no?

3 Likes

I like the team’s stance on this. It gives slower but more organic growth over time.

But as I write this, there is a minipool queue forming and some are upset there is not enough liquidity to burn their rETH.

Maybe it doesn’t have to be all or nothing. There could be a policy that the protocol will spend less and less on liquidity incentives over time as trade volume increases. Similar to how the bug bounty program gets increased over time.

1 Like

I had been thinking about this, and largely feel that the number 1 concern for LPs entering a position which may leave them holding rETH without additional exit liquidity is outperforming rETH.

The risk faced when posing a very concentrated range, while capitally efficient has been designed to rebalance. This means if the total rETH sold into the pool uses up the available ETH, it would then sell its newly acquired rETH into outside liquidity pools (which are less concentrated) to rebalance.

This provides a great service to rETH holders, and perhaps that is the number one priority, but I feel it would need very high incentives to cover the IL faced by rebalances, and the lost opportunity to earn interest on its ETH portion of liquidity.

In order to make this more attractive to LP’s I think its important to provide less concentrated service to rETH holders in order to stimulate a robust arbitrage market, and provide an opportunity to LPs which can outperform the lost interest earning opportunity.

Here is an article I wrote on the subject

It boils down to capturing profit by selling at a higher price than the rETH was acquired. I believe this approach would make any additional incentives a bonus rather than a hinge.

Below are rough numbers of how I’d aim to set it up, but if there is interest I can assemble some stronger models.

By managing the ranges in such a fashion more profit can be extracted by LPs at slightly degraded service to rETH holders looking to exit. This can help address dependence on incentives/bribes.

By only holding liquidity below peg and not selling rETH above 1:1, this approach while taking up more range, packs more buy pressure below the peg. So while 40 ETH in the above example sold into 104 ETH over 30 ticks, this would have 208 ETH in 100 ticks using these rough numbers.

I share this concern.

The suggested solution is interesting as a strategy for people looking to invest. I’m not sure that it is something the protocol should want to pay for through incentives.

1 Like

I think some of the points you bring up 1) make me think that our approach of starting small with incentives is the right move and 2) make me think that starting with a slightly less concentrated range makes sense as well. On #2, we can still get really strong capital efficiency even if we give up a little bit of the price concentration. The difference to traders will be relatively small and it will allow us to ease in to the process and experiment a bit

1 Like

At what liquidity concentration level is a uni v3 pool equivalent to a curve or balancer pool with A=50?

This is the approximate difference in discounts

Curve

I took this desmos and made some adjustments to set it to 104 on each side like that proposed, and set the steps to x += 10.

A = 50
104 rETH, 104 ETH supplied

rETH in ETH out rETH / ETH Discount
10 9.99 0.9986405895 0.14%
20 19.95 0.9976291965 0.24%
30 29.90 0.9965022563 0.35%
40 39.81 0.9951721283 0.48%
50 49.68 0.9935014011 0.65%
60 59.47 0.9912485538 0.88%
70 69.16 0.9879362821 1.21%
80 78.60 0.9824853525 1.75%
90 87.49 0.972070417 2.79%
100 94.91 0.949103107 5.09%

1% discount achieved after 60%+ buy pressure spent

A = 15
104 rETH, 104 ETH supplied

rETH in ETH out rETH / ETH Discount
10 9.96 0.9964822706 0.35%
20 19.86 0.9932192661 0.68%
30 29.69 0.989623812 1.04%
40 39.42 0.9854512779 1.45%
50 49.02 0.9803445778 1.97%
60 58.42 0.9737368968 2.63%
70 67.53 0.9646717476 3.53%
80 76.12 0.9514905038 4.85%
90 83.83 0.9314807542 6.85%
100 90.14 0.9013730756 9.86%

1% discount achieved with 25%+ buy pressure spent


Uniswap
I don’t have a fancy desmos link for Uniswap, but I mapped a few ticks in excel and used a sample of those to extrapolate further ticks, so might not be a perfect mapping. Because this is a quick w.i.p. i only provided enough ETH per tick to buy 1 or 2 rETH respectively in the below two tables.

Uniswap 100 ticks
1 rETH worth of ETH per tick supplied

rETH in ETH out rETH / ETH Discount Price at tick
1 0.9990214785 0.9990214785 0.10% 1.00
10 9.945158765 0.9945158765 0.55% 0.99
20 19.79050345 0.9895251725 1.05% 0.98
30 29.53603895 0.9845346315 1.55% 0.97
40 39.18176525 0.9795441313 2.05% 0.96
50 48.72768237 0.9745536474 2.54% 0.95
60 58.1737903 0.9695631717 3.04% 0.94
70 67.52008905 0.9645727006 3.54% 0.93
80 76.7665786 0.9595822325 4.04% 0.92
90 85.91325897 0.9545917663 4.54% 0.91
100 94.96013014 0.9496013014 5.04% 0.90

1% discount achieved after 20% of buy pressure spent

Uniswap 100 ticks
2 rETH worth of ETH per tick supplied

rETH in ETH out rETH / ETH Discount Price at tick
2 1.998042957 0.9990214785 0.10% 1.00
10 9.970115955 0.9970115955 0.30% 1.00
20 19.89031753 0.9945158765 0.55% 0.99
30 29.76061451 0.9920204837 0.80% 0.99
40 39.5810069 0.9895251725 1.05% 0.98
50 49.35149469 0.9870298938 1.30% 0.98
60 59.07207789 0.9845346315 1.55% 0.97
70 68.74275649 0.9820393785 1.80% 0.97
80 78.36353051 0.9795441313 2.05% 0.96
90 87.93439992 0.977048888 2.30% 0.96
100 97.45536474 0.9745536474 2.54% 0.95
110 106.926425 0.9720584088 2.79% 0.95
120 116.3475806 0.9695631717 3.04% 0.94
130 125.7188316 0.9670679357 3.29% 0.94
140 135.0401781 0.9645727006 3.54% 0.93
150 144.3116199 0.9620774663 3.79% 0.93
160 153.5331572 0.9595822325 4.04% 0.92
170 162.7047899 0.9570869992 4.29% 0.92
180 171.8265179 0.9545917663 4.54% 0.91
190 180.8983414 0.9520965337 4.79% 0.91
200 189.9202603 0.9496013014 5.04% 0.90

1% discount achieved after 20% of buy pressure spent w/ double the buy pressure as other tables.

note I included this with ~200 ETH with assumption no rETH liquidity provided vs the same total ETH provided in Curve


Some thoughts on the above

I feel I’m heavily influenced by the fact the arb cannot be completed. When an arb can be completed, Curve feels like the no brainier solution, set and forget, with less bias against smaller divergences.

However, given the arb cannot be completed, I feel the Curve stableswap approach is not necessarily the best due to how the A factor suppresses the rate of change.
With an Amplification Coefficient of 50, the pool takes significant time to reach a 1% price difference, and that may impact demand to correct the peg, as well as the remaining serviceable sell pressure.

With Curve, there is a potential for additional incentives from the Curve ecosystem which derive from holding CRV or its derrivative meta gov tokens, bribes, or goodwill from benevolent holders of CRV/metagov.

With Uniswap there are no additional incentives.

Ultimately the goal here would be to provide the most robust exit liquidity for anyone in the Rocket Pool ecosystem to give confidence to investors they can exit early if they need to. This means attracting liquidity which is not yet rETH but is open to being rETH. This should target outperforming the yield rETH will earn on its own else these long term commitments should just mint rETH. Reserving this liquidity for the ecosystem’s benefit has costs.

Curve can help cover some costs, but suppresses arbitrage and so may maintain less available liquidity to exit.

Uniswap doesn’t cover any costs, but distributes buy pressure more evenly which may normalize at a better serviceable area for holders.

While going with a singular Uniswap position, auto managed would maximize service, it may come at additional incentive costs.

My above plan would help maximize service while minimizing costs to RocketPool to cover the gap between earnings and rETH yield directly with maybe some more fixed duration additional dev costs

1 Like

Thanks for sharing this data. The flip side of that is lower slippage in normal operation and resistance against oracle manipulation.

Ultimately I think it makes sense to diversify incentives across a few different platforms anyway. Uni v3 can play a role, but isn’t necessarily the most capital efficient.

I would respectfully disagree with that assessment though big picture can appreciate it achieves the goals laid out in a low complexity manner.

  1. Lower slippage in normal operation.
  • While this chart demonstrates evenly spread ticks, they do not have to be evenly spread and could have greater concentration at earlier ticks.
  • Ranges in general can be adjusted, here I wanted the slippage because to me that’s how you ensure the peg actually gets corrected instead of left to hang open, but even spread tighter range could also provide lower slippage in normal operation.
  1. Oracle manipulation
  • generally agree that someone can move the price out of range and once there can provide a small amount of liquidity too little for MEV bots to spend the gas to arb.
  • Would point out that 200 rETH sold into Curve with A = 50 sends the price to ~ 0.52 ETH per rETH.
    which if we assume you could incentivize the same amount of liquidity (2/tick) that 200 ETH would still have the price ~.90 ETH per rETH
  • (I wonder if using Uniswap as a buffer against oracle manipulation is useful. Can have small amount at say 0.9 which could provide a buffer for any MEV bot correcting a Curve Oracle Attack by giving an outlet to offload the rETH they buy there. Though perhaps aggregators would run right through it. Its possible you can use MEV bots as Keepers which could both activate providing liquidity and then arb it themselves such that the buy pressure is only on the market if Curve price is below that line… Need to think on this more…)
  1. Capital Efficient.
  • Note the 1/tick line is for half the total value as the Curve pool.
  • The 2/tick would have the same total value and could service the same 80 rETH at ~ 2% difference, but then still has another 120 rETH it can still service before reaching the the 5% difference of the Curve pool at 100 rETH in total serviced.
2 Likes

totally agree here, would not make sense to try to close the Curve pool, and while open makes sense to play the game.

2 Likes