Uniswap v3, rETH, and Incentivized Liquidity
I was tagged and now feel compelled to share opinions
So it appears xToken is trying to get involved in Uniswap v3 incentivized liquidity for rETH. I think this is a noble pursuit.
I’ve been doing some really cool work with FloorDAO I’ll eventually publish about. I have like 15 drafts on how we are approaching providing entry liquidity for bonds which targeting illiquid NFTs. I feel thinking about FloorDAO’s hurdles, paired with my longtime obsession with stablecoins gives me a strong base to approach handling rETH LP positions.
Background Stuffs
Understanding Uniswap v3 Basics
Positions set a Minimum and Maximum price range to provide liquidity.
Outside of this range, Positions are 100% exposed to the falling asset.
Does not support rebasing (or supply adjustments to user balances), so uses wrappers to combine interest and principal in fixed units.
As interest accumulates, the price per underlying unit drifts down
If a single LP dominates a pool (> 99%, then can withdraw liquidity and move the price before reentering a position at a new price.)
rETH Considerations
rETH is minted 1:1 w/ ETH does not want to sell at a loss
rETH purchased at less than 1 ETH per 1 rETH has captured profit given enough time for withdrawals from rETH to become enacted.
wrETH naturally incurs a discount without active rebalancing
rETH purchased at discount is profitable to sell at less of a discount
ETH cannot be withdrawn from rETH until an undetermined date in the future
The Limitations of Markets on One Directional Arbitrage
When providing liquidity of ETH vs rETH, this may buy rETH at a discount, however once a concentrated position is entirely rETH it cannot be unwound. This means that without selling rETH back onto the market at an attractive rate less than one ETH, the market is incentivized to simply mint more rETH when it wants.
However if more volume wants to exit rETH and the position has fallen below the minimum price, now containing entirely rETH, the price will tank quickly without buying support. The only way to help prop up the price at that point is to attract even more buyers.
Further, you have ETH which natively does not earn interest which you want to incentivize to support rETH which does natively support interest. You want this liquidity available for the duration in which rETH cannot be unwrapped to ETH. Swap fees are quite small. How then do you create enough of an incentive to pool ETH to support rETH over just buying and holding rETH?
We can see with recent stETH drama, holding up a peg of one directional assets can be tough particularly when leverage is applied as it adds the profit opportunity of crashing the price. Attackers don’t need to buy from limited on market liquidity, they can mint 1:1 without pushing up the price, then dump that on limited liquidity to trigger a cascade of liquidations which can also be purchased cheaply.
Isolating Ideal LP behavior
Uniswap v3 management is all about rebalancing.
LPs want to be able to purchase rETH cheaply, so that we can sell it for less than 1 ETH at a profit.
If an LP’s v3 Position buys rETH then sells rETH without rebalancing, they earn swap fees, where often the lower the swap fee the higher the volume. The more volume, the more revenue in many cases outside of very isolated pairs. (The current proposal suggests 0.05% fee tier. I think that is appropriate.)
A smart LP knows any rETH they buy, they may become forced holders of, so they should want to buy at a discount. They also know any discount they offer is better than a 1:1 mint. The more rETH they need to unload though, the higher discount they may need to use to attract new buyers.
Therefore LPs should not aim to provide the tightest range possible. Concentration is a high risk, as it limits the ability to offer a discount on rETH to prospective buyers. While an LP may not mind providing limited liquidity for small orders near 1:1, they certainly do not want a whale to exit into their position and deplete their available funds.
Perhaps, the best approach is to have three positions:
(Buffer) a small position which fields small orders in either direction
from 0.98-1 ETH per rETH
(Buy) a single sided ETH position
from 0.9 - 0.98 ETH per rETH
(Sell) a single sided rETH position
from 0.98 - 0.99 ETH per rETH.
(Note, while I refer to these as single sided these may have a mix of assets if the price is in range, but I feel the wording helps signal the intended direction of the liquidity.)
The Buffer should be very small, only to service the smaller fish who do not significantly impact liquidity available.
The Buy should contain the vast majority of liquidity. When rETH is dumped into the Buy position such that it moves the price more than a tick, liquidity should be rebalanced such that:
The position is exited with some amount of ETH and some amount of rETH (assuming its not sold through)
The ETH is then resupplied from the current tick down the same number of ticks, now extending further down (ex: 0.88-0.95 ETH per rETH)
The rETH is then added to the Sell position at a higher price than it was acquired.
Assuming there is eventual demand for rETH, the LP should turn a profit greater than swap fees alone, while still servicing sell pressure for ETH, and providing discount buy opportunities for attentive future holders. When Sell position gets sold out, it can rebalance the ETH its acquired back into the Buy position.
My thought is that this management style likely prices out many individual LPs due to associated gas costs, but if these actions could be pooled, may attract significantly more liquidity as may be more competitive in return to rETH itself, possibly outperforming it.
An Approach To Positioning Incentives
Uniswap v3 has a staking contract which allows incentive providers to set a minimum number of ticks. Normally this contract gets attacked by bigger players since they can better manage following the current tick. We’ve never seen this applied to a “pegged” asset before, though as we’ve seen with stETH the peg can be looser than typical pegged assets. I’d be curious about its performance here, where its harder to rebalance between the two sides.
For now, lets assume that staking contract is off the table, as its yet to prove itself, and we can’t afford to burn out our available liquidity. The next best option is to utilize an ERC20 wrapper which normalizes participation in providing liquidity, so that all LPs earn equally relative to the liquidity they provided.
xToken has had hiccups in the past, but they also pioneered Uniswap v3 management, as well as policy based governance tokens wrappers which allow for holders to express preference on future votes. I think they are a good candidate for managing wrapped rETH liquidity as they may be able to add ways to express preference on upcoming forks.
We can simplify management of liquidity by creating 5 baskets, where each basket contains 20 ticks which equates to a ~2% total price movement.
Basket 1 should not actively be rebalanced.
For every basket below (2 - 5), if the price falls into the range of a lower basket, it should rotate into the higher baskets range to sell. So if the price in in basket 3’s range, basket 2 has already sold all its ETH for wrETH, it should remove the wrETH and resupply in the basket 1 range (perhaps only 10 ticks from the bottom). When the price moves out of range above that basket, it should rotate the ETH its left with back into its original tick position.
In addition to these rotations, drift due to interest accrued in the wrapped version of rETH should be tracked with occasional bulk rebalances to accommodate for the drift. Given the native rate of yield, this need not be daily.
I think these five baskets could be wrapped in a single vault for users to enter/exit from. Ideally users, may enter in all ETH, where the vault may want to determines if swapping or minting is most ideal. For exits, I don’t believe it’s fair to exit in all ETH as that may create a race to exit in certain conditions.
Therefore, I think exits, may want to target the current ratio of holdings in ETH/rETH, and use buffers of ETH to purchase a proportional amount of rETH to be returned to users. I do worry this accounting might add unnecessary complexity, but I defer such decisions to the xToken team.