[RFC] Mandate Alignment for bsdETH

Based ETH (bsdETH)
1

Summary

This RFC proposes a clear mandate for Based ETH, bsdETH to guide future governance decisions. Despite reaching $12M in TVL, bsdETH launched without a formal introduction or defined mandate. The proposed mandate emphasises Ethereum-alignment, safety, and diversification, avoiding concentration in any single asset and revenue distributions. The goal is to offer safe ETH yield exposure to Base users. Community input is encouraged to ensure aligned decision-making and sustainable growth for bsdETH across Base’s DeFi ecosystem.

Introduction

Based ETH has enjoyed success since inception providing Base users with access to an over-collateralised index of ETH LSTs and TVL has rose to where it sits now at ~$12m. While divETH hasn’t been able to join the collateral basket this success has attracted the attention of other ETH LSTs like Origin’s OETH and more recently Rocket Pools rETH.

My pain point and reason for posting this RFC is that the unusual genesis of the Rtoken (see appendix for a summary of bsdETH’s history) has left bsdETH without a formal introduction or a clearly defined mandate.

Recently @signal posted a RFC to consider rETH for inclusion in the collateral basket. While this proposal seems rational I feel without community alignment around bsdETH’s mandate and it’s goals I feel any opinion given either in support or against it’s inclusion are half-baked.

Hence this proposal which seeks to align the community around the goals and aspirations of the RToken and it’s mandate, giving all future discussions a more solid base leading to more efficient and rational governance.

Proposed Alignment

RToken governance is still young but has been round long enough to see some patterns emerge around core RToken properties including chain alignment, positive impact on LST staking ecosystems, safety, and diversification, avoiding concentration in any single asset and revenue distributions and have outline these in more detail below.

I encourage anyone to comment either for or against my opinions of how bsdETH should operate under these properties especially since this RFC won’t graduate to an on-chain vote.

Mandate

  1. Maintain an Ethereum-aligned Liquid Staking Token basket compromised of LSTs available on Base which positively impacts the Ethereum staking distribution.

  2. Seek safety over maximised yield and diversification profiles.

  3. Optimise for diversification and yield where safety isn’t compromised.

  4. Desire for the collateral basket to not be too concentrated (>50%) in a single collateral asset.

  5. Maintain a diversification ratio >60% inline with other ETH aligned RTokens such as ETHplus.

  6. Ensure persistently strong over-collateralisation to mitigate from the loss that can occur during collateral asset depeg events.

Why this mandate?

The mandate above dovetails Larry’s previous RFCs with my experience participating in RToken governance and comments from other governors.

Revenue Distribution

90% passed through to the RToken holders.

10% distributed to the RSR stakers for providing governance and over-collateralized de-peg protection.

Why was this particular distribution chosen?

This ratio was chosen at inception and is still in play today to maintain bsdETH competitiveness in a growing LST market while also providing some over-collateralisation to RToken holders. This is a fine balance between yield for holders and yield for RSR stakers who provide the over-collaterisation and governance.

Interestingly this is not in-line with ETHplus which has a 95/5 split leading to an over-collateralisation of 7% compared to ETHplus 2%. At a later date we should consider bringing bsdETH ratio in-line with ETHplus or visa-versa but it out of the scope of this RFC.

Holder Profile

Based ETH is suitable for retail, institutions or DAO treasuries with a strong alignment to the Base L2. These participants want to get broad ETH exposure without taking undue risks, instead opting for safety and a reduced risk of loss from depeg events.

  • Passive yield exposure: Users can enjoy attractive yields on their ETH on Base through a diversified basket of liquid staking tokens.

  • Reduced counterparty risk: bsdETH offers exposure to a diverse basket of ETH LSTs with over-collateralized protection, the only one of it’s kind on Base.

  • Reputation neutrality: bsdETH allows for inclusion of any ETH LST that is available on Base providing it aligns with it’s mandate.

What does success look like for this RToken?

A highly liquid RToken whose growth at a minimum tracks the growth of the base ecosystem and it’s LST ecosystem, generating a safe and reliable yield for both RToken holders and stakers which doesn’t suffer from RSR slashing from collateral basket rebalances or depeg events. The RToken can also be easily minted, traded, and used in DeFi protocols across the Base L2.

Call To Action

What is expected from the RToken’s governors?

  • Advocates of bsdETH adoption, usage, and the values of the mandate.

  • Active participation in both forum discussions and governance proposal votes.

  • An interest in the Ethereum Staking ecosystem, keeping up-to-date on developing technologies and new LSD providers.

What can the community do to make this RToken a success?

  • Get involved! If you ever wanted to participate in the RToken governance flow and enjoy it’s success now is the time!

  • Please start by sharing any thoughts you have about this RToken in the comments below.

Poll

  • I am in favour of this mandate
  • I am not in favour of this mandate
  • I need more time / discussion to make up my mind
0 voters

Appendix

1. Based ETH History

Based ETH was first brought forward for consideration as a new yield RToken in 2023 when Larry The Cucumber post an RFC on the Diva Staking Forums.

The aim of this RFC was to see if there was appetite for collaboration between Diva and Reserve since there was considerable mission overlap. Reserve wanting to build on the success of it’s layer-one ETH LST index, ETHplus and Diva Staking to collect pre-launch TVL for it’s new LST powered by Distributed Validator Technology, DVT aiming to replicate the success of previous pre-launch Enzyme vaults.

The RFC proposed a frictionless user experience on Base providing an attractive asset for Ethereum-aligned depositors to hold on Base which prior to divETH’s launch will return yield from a basket of diversified blue-chip LSTs, the basket allocation chosen was comprised of equal parts CoinBase ETH, cbETH and Lido Staked ETH, wstETH. Upon divETH’s mainnet launch, bsdETH governors would be approached to add divETH to the basket. From a holders perspective, the resulting autonomous re-collateralization of bsdETH bestows benefits of increased diversification and exposure to divETH and the two protocols foster a close working relationship and benefit from TVL growth.

This RFC was met with a warm reception from the Diva Staking community and was swiftly followed up with another RFC authored by Larry to finalise the pre-launch campaign which also enjoyed support from Diva Staking governors, once finalised the complete proposal was pushed forward for IP and passed with a overwhelming majority with bsdETH going live shortly after.

Unfortunately we are yet to see divETH be pushed into production and as a result it is yet to be included into the collateral basket. However the success of bsdETH has not gone unnoticed, with interest being expressed from long tail of ETH LSTs, both Ethereum layer one products migrated to Base or new entrants into the ETH LST space express interest of being included in the collateral basket.

1 Like
2

I support this. On one hand, it helps clarify the vision of bsdETH, and on the other, it improves the transparency and efficiency of bsdETH basket governance.

Here are a few ideas for the basket that I’d like to propose for discussion and potential adoption:

General Principles for bsdETH:

  • The proportion of a single LST in the basket should not exceed 20%.
  • The amount of any LST held in the bsdETH basket should not exceed 10% of that LST’s total TVL.

ETH LST Temp Check:

  1. Safety Metrics – TVL, liquidity (on Base), 7-day APR, trading volume, whether unstaking is supported, holder count, and audit reports.
  2. Decentralization – The percentage of permissionless validators, to assess how decentralized the LST’s validator set is.

Integration Check:

  • Whether a plug-in can be developed by the team.
  • The amount and duration of incentive that can be offered.
1 Like
3

Thanks for your thoughts @signal

Definitely agree we should set a hard cap for the percentage of an LSTs total TVL we hold, 10% feels like a good starting point. We currently have 0.8% of wsuperOETHb, 1.2% of cbETH and 0.2% of wstETH so all good currently.

An allocation of 20% or less to a single asset is tricker. To have a max of 20% we’d have to have 5 assets minimum, which I think is unreasonable given the Base LST landscape. From discussions around the ETHplus basket general consensus has been 50% and given Lido ETH is over 50% of the LST market I don’t think this is unreasonable for LSTs of that size. Ofc we also have a mandate to positively impact the Ethereum staking distribution so a 50% allocation to Lido will be avoided when safe to do so and is unlikely for bsdETH unless we see it reach TVLs comparable to ETHplus.

I do like your ideas around asset temp checks, I’m sure this has been considered before but maybe Reserve governance isn’t mature enough to add it the additional vote at this stage. @rspa_StableLab what do you think about incorporating this into the governance flow for when we are considering a new asset?

Do you mean having an Integration Check as part of the Asset Temp Check? If so I agree, feels like this is the most obvious place for it. A template Temp Check RFC we can distribute to teams looking to integrate into Reserve to provide guidance of what’s need would work well!

4

Yeah, I think an Integration Check as part of the Asset Temp Check makes sense. However, when it comes to actually allocating basket share, I don’t yet have a complete framework. We might be able to reference some of the performance analysis you’ve done previously to help guide that decision. I’ll follow up later with a few more ideas on this.