Right now the IMC supports a little bit of rETH/RPL incentives, which stretch the charter a bit. Folks (internal and external) have brought up a desire for some RPL support.
Yeah, “MAY” seems like the better word to me, especially if it is directed towards a narrow goal. Something like: "The IMC MAY support RPL liquidity for the limited purposes of supporting RPL/ETH oracle safety or … ". Leaving it open ended doesn’t feel like the best idea.
This is “MAY” and “SHOULD” from RFC2119, which we use for RPIPs. MAY means it’s entirely optional - no bias either way. SHOULD means there needs to be a good reason to not do the thing.
With respect to “support RPL liquidity” being too open ended, I think I agree and would instead propose stealing building off of the current wording from the rETH bullet (I’ll use MAY, but could be SHOULD).
I’m currently at 4 options based on MAY/SHOULD and oracle safety or broader:
The IMC SHOULD support lowering slippage when exchanging between ETH and RPL and/or rETH and RPL on major platforms where this trading occurs.
The IMC MAY support lowering slippage when exchanging between ETH and RPL and/or rETH and RPL on major platforms where this trading occurs.
The IMC SHOULD support RPL/ETH TWAP oracle safety.
Im not happy with the options. I think I’d like to see some ordering in it. Like first and foremost rETH/ETH liquidity is important and if that’s sufficiently fulfilled providing RPL/ETH/rETH is the secondary option.
Im esp in favor of making the idle sitting $2M of RPL on the IMCs treasury work. And since the IMC is paid in RPL, it includes interaction with rpl/xxx markets
So I go with may in second order to rETH/eth.
On the other hand I’d like to see some more freely choosen possibilities to incentivize engagement with the RP protocol. Kind of like Rabbitholes Rocketpool pool quest (rocketscan link). We could support such things with RPL payments.
This is my preferred option, since it implies a limited scope.
I do not like the “lowering slippage when exchanging between ETH and RPL” options, because it leaves a lot of room for interpretation how to allocate between rETH liquidity and RPL liquidity.
With two competing liquidity goals, there would be a clear trade-off. I’m not sure that lowering rETH liquidity to increase RPL liquidity is what we want to do and I would like to see a bit more reasoning if we go that direction.
I’m not in favor of adding any RPL liquidity bullet to the charter without discussing what goals we want for RPL liquidity long term. With rETH it was obvious we need liquidity supported by the protocol, however, it is less clear that we need it for RPL.
Beyond oracle safety, RPL/ETH full-range POL would likely only marginally reduce slippage at our size. It would take a large commitment of resources to meaningfully change things.
Are there any estimations what ‘supporting RPL/ETH TWAP oracle safety’ would cost and if the budget can sustain this? (In current and foreseeable market conditions.)
I’m generally in favor of some support for RPL, as long as it does not endanger the IMC’s primary support for rETH. Investing in oracle safety sounds like a sensible, small scope expansion to start with.
I’m not directly opposed against RPL liquidity vs slippage either, as a later step, to support node operators. However I do think that may quickly cross into trade-off territory, so we’d have to explicitly define it as secondary and perhaps even impose hard (percentage) budget limits to prevent ambiguity in decision making. And then it may not be enough to move the needle, given budget constraints.
Agree with other suggestions to preface RPL additions with ‘As a Secondary goal’.
Of the listed options, I prefer
The IMC MAY support RPL/ETH TWAP oracle safety.
In the long-term, with an actively used RPL penalty system it would be beneficial to have reduced slippage for RPL/ETH, however at this point a ‘SHOULD lower slippage’ mandate is too strong and would likely detract from the rETH focus.
I would however suggest a softer
The IMC MAY act to improve accessibility of RPL.
With the intention of allowing the potential bootstrapping of RPL pools on L2s, matched but not ongoing incentives with protocols that may wish to have an RPL pool and potentially lending protocols supporting RPL to enable borrowed RPL as a collateral option for node operators.
@Pieter A relatively small amount of liquidity with a wide (full) range significantly improves TWAP safety and increases the cost of attacks, as this can be owned by the protocol it is an upfront rather than an ongoing cost apart from any divergent loss incurred due to RPL/ETH ratio changing and the liquidity can be later redeployed elsewhere if desired.
There is a good explanation here: https://www.euler.finance/blog/euler-protocols-oracle-risk-grading-system
and more in depth here: https://blog.uniswap.org/uniswap-v3-oracles
Thanks everyone for the insights, thought I’d voice our support here. I’m Tenzent and I lead BD at Silo Finance. We currently enable RPL lending markets and this proposal would help us immensely at growing them. The RPL oracle is currently strong but with UniV3 there is always the risk of all LPs withdrawing liquidity and the oracle becoming less secure, having some baseline liquidity in the pool provided by team members greatly increases the reliability of the oracles. Much more, on Univ3 there tends to be a lot of concentrated liquidity positions but these actually do not provide much security to the oracle - the way to create an extremely safe oracle is to have liquidity deposited full-range (spread 0 to infinity across all ticks). This does not have to be a huge sum, even a small of full-range deposits can increase the security of the price feed greatly.
If anyone is interested in the costs of manipulation around the RPL oracle, we maintain analytics on it showing you PnD costs, Oracle vs Market price, and position stats: RPL/WETH/XAI of Silo Finance
I’ve voted for B and C as increasing the overall liquidity and oracle safety for RPL seems like a positive for outside integrators like ourselves. If this change is enacted, we will also be helping to increase the overall liquidity available to borrow for RPL.
I would recommend 100K~ of RPL/ETH liquidity to be seeded full range.
As a lesser goal, the IMC SHOULD support RPL/ETH TWAP oracle safety
should not be a lesser goal since oracle safety is at least as important for the protocol as rETH liquidity. I don’t think changing this wording would change much, I would vote yes for this proposal as is.
To be honest, I am happy with a broad interpretation for promoting RPL liquidity. I have always liked the fact that the best place for RPL (in terms of yield) is in the protocol. But many people cannot put it to use in the protocol and so, from a protocol perspective, where is the next best place?
I am in favor of this, although I don’t follow the majority of it. I do believe that depositing into the reth pool should be prioritized over incentivizing people to trade on DEXs and in defi