The current ETH+ backingBuffer is set at 0.25%, significantly higher than the suggested default value of 0.1%. This proposal suggests reducing the backingBuffer to 0.05% to align more closely with market conditions and optimize yield efficiency. The change is intended to further optimize ETH+’s performance by minimizing the impact of the backingBuffer on yield generation.
Abstract
The proposed change reduces the ETH+ backingBuffer from 0.25% to a 0.05%, to decrease the time required for the protocol to recover normal yields after significant market cap changes, thereby enhancing yield efficiency for ETH+ holders. The high liquidity of the collateral assets (wstETH, rETH, sfrxETH) on mainnet supports this reduction without significantly increasing risk to RSR stakers.
Problem Statement
The current 0.25% backing buffer for ETH+ is considerably higher than the recommended default of 0.1%. Given the low-yield nature of ETH+ collateral, this high backingBuffer results in prolonged recovery periods for yields when the market cap increases rapidly. Specifically, if the ETH+ market cap were to double, it would take approximately 15 days to return yields to normal levels. This delay is due to the need to replenish the backingBuffer from 0.25%, which represents around 30 days of revenue at current yields.
Rationale
Reducing the backingBuffer will optimize yield efficiency for ETH+ holders, aligning the protocol’s performance with the liquidity and stability of its collateral. The primary reason for maintaining a high backingBuffer is to prevent losses to RSR stakers during rebalances. However, given the high liquidity of ETH+ collateral assets, such as wstETH, rETH, and sfrxETH, on mainnet, the risk of significant losses during rebalances is minimal. Lowering the backingBuffer to 0.05% will mitigate the downside of prolonged yield recovery periods without materially increasing risk to RSR stakers.
Risks
The primary risk associated with reducing the backingBuffer is the potential for increased volatility in the protocol backing collateral which could expose RSR stakers to higher risks during rebalances. However, the high liquidity of ETH+ collateral assets mitigates this risk, making it unlikely that significant losses will occur. Additionally, careful monitoring and incremental adjustments can help manage this transition effectively. The probability of adverse outcomes is low given the market conditions and liquidity levels of the collateral assets.
I am in favor of changing the backingBuffer from 0.25% to 0.05%
I am not in favor of changing the backingBuffer from 0.25% to 0.05%
I am in support of this proposal, but would appreciate more information in this area. What exactly do you mean by “careful monitoring and incremental adjustments”?
A change from 0.25% to 0.05% is a significant adjustment.
If there is a concern that a significant change could put $RSR stakers at risk of receiving a loss during the backingBuffer rebalancing period, we could move it in more incremental steps, such as reducing by 0.05% until 0.05% is reached. We would continue to reduce the backingBuffer after each successful rebalancing period until 0.05% is reached.
That is only if there are any concerns with the liquidity of the underlying collateral.
I agree that ETH+ has particularly high liquidity collateral assets and therefore should encounter small slippage during rebalancing relative to other RTokens.
But I think 0.25% to 0.05% is too-significant an adjustment. I am in favor of moving to 0.1%.
$70 at 8 gwei is substantial. Depending on timing it could be higher. So I think it makes sense to be less drastic and pass through the 0.1% point first.
During rebalancing periods, how relevant has the backing buffer been? Do we have any historical data that could better inform our decision? ie ETH+ typically endures x% loss during rebalancing? I would imagine other RTokens and their individual assets have varying losses.
I think the backing buffer needs more details in the docs. For how much chatter and modifications are made to various RTokens, there should be more information and examples to better inform decisions.
Agreed, the backing buffer needs more documentation on the website. It’s quite important and there are many factors that inform that. Noted.
The gas level is relevant to consider because we should assume bidders pass on any costs they have to pay to the protocol. That is: bidders will only bid at prices that allow them to profit, given frictions such as swap slippage and gas costs.
Gas costs look like they range from ~0.01% loss at 5-10 gwei to ~0.05% loss at 50-100 gwei. So they can end up being relevant when the chain is congested, but generally we should expect the slippage from swaps to be larger. Total slippage in auctions is equal to the sum of these.
Liquidity for the 3 current backing collateral is varied. I’m seeing (at the time of posting) about ~0.1% slippage for wstETH and rETH, and ~0.5% slippage for sfrxETH.
Maybe ETH+ could accomplish a similar goal by reducing the rewardRatio. Right now it is set for a half-life of 2 weeks, and the suggested default is 1 week.
Following the governance process, this RFC will be pushed to IP next week for voting. After careful consideration, I do not believe it is the right time to make this adjustment.
The reason is that with the rapid growth of ETH+ over the last few months, the collateral basket may see quite a few changes to ensure ETH+ collateral basket is liquid enough to support mints and redemptions. This could mean, new collateral will be added, and underlying % exposure per LST will adjust as well.
With all this rebalancing happening it may be best to postpone a drastic change until the ETH+ basket has become more diversified and more testing on Backing_buffer has been done.
Up to now, ETH+ has come out as a huge win for the Reserve community and the vision is STILL to drive the market cap towards a unicorn level of success! Because of this, I am long term on its success and will be voting No on this IP.
If RSR stakers take a loss in the event of a collateral basket change due to insufficient backing_buffer, this would negatively impact ETH+'s brand as a safe yield index and break trust with the community. This could be detrimental to the longterm goals of ETH+.
Thank you for taking the time to read and see you all in the governance polls
Given the new information that was surfaced during the RFC process here, we recommend not pushing the RFC to an on-chain vote, but come back to it once the underlying issues have been resolved.
