[ARC] Add Support for cbETH

As a huge supporter of LSD diversity my concerns might be unexcepted but here’s my current position on cbETH

  • V3 mainnet is very near, onboarding cbETH on V2 will be nice in the short term but hurt in the long term (liquidity frag)
  • current onchain liquidity impose isolation mode for protocol safety, especially in a pre-shanghai upgrade world that’s a V3 feature.
  • main use case are usage as collateral → needs isolation mode to stay safu
    usage as part of leverage loop in increase staking yield → needs emode to be efficient
    that’s powered by V3.

thus my position is clear:

  • NAY on V2,
  • YAE on V3 with tight isolation mode (that can be pushed up via AIP as asset gain traction onchain) & emode support.

Hi @Doo_StableNode - thanks for your reply.

The goal of this asset listing is to onboard more users from Coinbase and centralized platforms to a decentralized protocol such as Aave. It additionally leads to greater staked asset diversity.

By doing so, we believe it grows the overall ecosystem - linking critical infrastructure from both worlds.

It seems you may mean “mass adoption” here?

If not, we are currently not pursuing it as collateral and liquidation is not a current concern.

This may change in the future with the introduction of V3 - cbETH is a better fit for it there.

Please standby for risk analysis and parameters in the future.

1 Like

MZ - wouldn’t be an Aave proposal with your reply - glad to see you here.

I am grateful for your candidness towards cbETH’s fit on Aave.

As mentioned in the original proposal, users have the agency to choose where this asset lives. This is mentioned in the Intro section:

As for our impetus for allowing the option of V2 - internal stakeholders conveyed an interest in listing on V2 to beat a listing elsewhere. A cToken model, there is value in the listing living on Aave first.

This may inspire other teams to focus borrow / supply liquidity on Aave vs. other platforms.

This is my opinion and not representative of Coinbase or its affiliates.

I mean you literally point it as a collateral.But please share more about it as I do want to learn more about AAVE governance and it could mean different meaning.

and the application also literally asks about it.

Doo - I would encourage you to revisit the intro section which I highlighted to Mark.

Our job is to present both cases and let the community decide - there is an option for it to be collateral on V3, with new isolated and eMode features.

There is also an option to have it listed on V2 as LTV of 0% - meaning not eligible as collateral - if users think V3 liquidity transition will not come soon enough.

To reiterate, formal parameters have not been decided. While the end goal is to list cbETH as collateral, this initial proposal for v2 would be to list it with an LTV of 0%

If this is the case, wouldn’t my concern for low onchain liquidity still apply? Sure, there are other ways for AAVE community to collaborate but that doesn’t change that it wouldn’t make ideal collaterals based on current numbers. Are you saying that I can’t point out such concerns?

@Doo_StableNode, your concern is valid, on-chain liquidity is paramount for any asset that’s listed as collateral.

However, as @fig mentioned, all that has been proposed is one of the following:

  • A v2 listing with an LTV of 0%, meaning it would not initially be listed as collateral (as Gauntlet has previously suggested for initial listings)
  • Or, upon contracts going live on mainnet, a v3 listing with parameters agreed upon by the community and risk advisors. As @MarcZeller suggested above, launching on v3 in isolation mode would help keep the protocol as a whole safe. Additionally, with supply caps in v3, the protocol can actively govern just how many deposits they’re willing to accept relative to liquidity.

As on-chain liquidity improves, the community (ourselves included) can help monitor and discuss adjusting these parameters to ensure the protocol is safe and any use as collateral is well managed.

Thanks for your engagement!

1 Like

Thanks for the response. Look forward to see how it progress :+1:

1 Like

If Aave lists cbETH before they list rETH which has many multiples of the liquidity of cbETH onchain then something is very wrong.

There are both philosophical and economic reasons not to move forward with this listing.

Further, there is an idea that withdrawals will make cbETH instantly liquid. This is false. The withdrawal queue will allow arbitragers to buy up depegged cbETH to burn, however, this will be a very minor incentive for users to provide liquidity. Overall volume will remain low and someone always has to foot the bill for liquidity. There is no one that will pay for cbETH liquidity and until that changes it will be a token that is unfit for use in DeFi.

Now, wen rETH?

1 Like

I don’t really understand the v2 option. What would be the value of listing a non collateral, non borrowable asset on v2 - why would anyone be interested in supplying this?

Waiting for V3 in this case makes far more sense imo.

I think rETH still has no chainlink price feed Price Feed Contract Addresses | Chainlink Documentation
Better to have rETH discussion in the rETH thread though.


Thank you @fig and @AndrewA for the proposal. Gauntlet is conducting analysis on the market risk side and will come back to the forums.

Given the imminence of V3 ETH and the meaningful risk control improvements that V3 has over V2, we recommend that the community consider waiting until V3 ETH.


Thanks to @fig and @AndrewA for the proposal.

I am not in favour of listening cbETH on V2 at all and am not in favour of statements such as:

The benefit of listening before another provider should at no point be a reason to list an asset.

I share @Doo_StableNode concern about low on-chain liquidity, however, with V3 features, this can be mitigated with isolation mode.

In general, I strongly believe that cbETH should wait for V3 Mainnet deployment and in the build-up to that try and build on-chain dex liquidity to make the listening more attractive.


Really excited to see so much community support.

Given the sentiment of the discussion here, I’d like to acknowledge that there’s a strong preference for waiting for Aave V3 to hit mainnet. This makes sense for many reasons and I personally agree that this is the most likely step forward.

To respect the process, I’d propose that we still include all options in a Snapshot vote. However, I want to make it clear that @Fig and I would expect a “V3 listing” to be the strong favorite in a poll over a V2 option. This expectation is based on the feedback received here–so thank you all :slightly_smiling_face:

With V3 being the expectation, I’d like to request feedback specific to an Aave V3 listing on Ethereum mainnet. How should a V3 market that includes cbETH be structured? These are the open question I have:

  • Isolation mode, how would it be structured?
  • Efficiency mode, should it be enabled? If so, what LTV threshold (EModeCategroy) should be used?
  • Supply caps, should cbETH have them? If so, what should they be as it relates to liquidity?
  • Borrow caps, should cbETH have them? If so, what should they be as it relates to liquidity?

^ Please add to this list above, it’s not comprehensive

cc @MarcZeller @sakulstra @Pauljlei @G-Blockchain as you had thoughts above

1 Like

Thanks for writing up the proposal! A few a points/concerns on my side:

First and foremost is the on-chain liquidity (conscious this was also discussed above). Liquidity in the Curve and Uni pools is not sufficient with respect to the supply of cbETH. As things currently stand, there will be too much reliance on centralised liquidity to facilitate liquidations. Aave cannot onboard an asset where liquidity depth is so opaque unless there are supply limits in place which are based off the measurable on-chain liquidity, imo. During events like we experienced earlier this year, centralised entities failed/halted trading and showed they cannot be relied upon. stETH was also listed on multiple centralised exchanges during this time and there was no indication that the CEX liquidity helped in any way. DeFi/DEX liquidity however proved its robustness/importance.

Second, can you shed more light on the node oeprators/decentralisation? Depegging from liquidations is one key risk, but the other is liquidations from slashing/penalties. I am concerned that a token like cbETH will increase systematic risk unless there is a sufficiently decentralised network of node operators.

1 Like

On liquidity, as I mentioned above, I agree that on-chain liquidity is paramount for any asset that’s listed as collateral. And given the preference for Aave V3, I’d expect that the community would vote to isolate and cap the supply in line with the on-chain liquidity.

To answer the second question, Coinbase leverages Coinbase Cloud and several external enterprise-grade infrastructure operators for ETH staking. Leveraging multiple providers reduces the risk of correlated downtime or slashing events that could be caused by any one operator. Beyond node operator diversity, these operators run multiple Ethereum clients, using multiple hosting environments, in multiple geographic regions, all in the same effort to reduce the risk of a correlated slashing event.

Hi all!

Quick update. @fig just posted a temperature check gauging the best path forward. Please vote within the next week!


As a part of Certora continuous formal verification activity, we have conducted a formal verification of cbETH token code using our generic ERC20 token specification.
It’s important to note that this is strictly a technical analysis of the smart contract code.

How to look at the dashboard
With Certora technology, we write rules that specify how a smart contract should behave and the tool either proves that the rule always holds or finds a counterexample. It’s impossible to specify general rules for all the ERC20 tokens, since they all have different features. We have chosen to specify a set of strict rules for tokens, for example “supply should always be fixed” and “transfer should always work”. As a result, a token with dynamic supply will obviously fail the fixed supply rule, and a token that has a pause and/or a blacklist function (like USDC) will fail the “transfer should always work”.

In the case of ERC20, the point of these rules is usually to present precise information about the token behavior to the community. This is how we should look at rule failures - usually not as bugs but as information about token features.

Having said that, here is our dashboard with the findings (cbETH is at the bottom of the list):

Here is the rule failures explanation:

  • transferCorrect and transferFromReverts rules fail because the token is pausable and transfers don’t work correctly in a paused state.
  • otherBalanceOnlyGoesUp rule fails because transferWithAuthorization() and receiveWithAuthorization() change “other’s” balance and they’re not accounted for by our standard spec.
  • isMintPrivileged fails because there multiple wallets can get the minter role and mint new tokens by design
  • ChangingAllowance rule fails because the permit() function can change allowance and is not part of our standard spec.

In summary, the cbETH token code complies with our generic ERC20 specification and all the rule violations are by design.

We support the listing of cbETH to the Aave V3 market. As many of the community suggested, the liquidity of cbETH in DEX is insufficient for the supply itself. The supply of cbETH can be increased as more people stake.

The liquidity in DEX such as the Uni V3 cbETH/WETH pool, the pool size sits around $6.5m which we think it is not enough for mass liquidation. Additionally, around 60-70% of the volume came from Coinbase.

For these reasons, we are not in support of listing cbETH to the V2 market. However, we are in support of listing cbETH to Aave V3 market in isolation mode with a very tight parameters. After that, the e-mode can be supported for looping between ETH correlated assets.


Onboarding additional centralized, low-quality credit risk is a surprising proposition at this time.

There are unquantifiable risks in onboarding a centralized staking derivative (for example, regulatory)
and I don’t see any benefit to the protocol.