[ARC] Add Support for cbETH

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?


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


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.


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.

1 Like

Hi all!

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


1 Like

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.

1 Like

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

1 Like

Hi all, with Aave V3’s launch on mainnet getting closer. I wanted to restart this thread and the discussion around what initial parameters should be.


Following are the initial analysis and risk parameters recommendations by Chaos Labs.

As of the day of this analysis (01/17/2022), cbETH has a market cap of ~$1B and daily trading volumes of $5M-$20M, with the two major liquidity venues being Coinbase and Uniswap V3.

Source: CoinGecko, 01/17/2022

-1% Depth in Uniswap V3 is approx. 30K-50K ETH.

In addition, the token has experienced cbETH/ETH ratio as low as 90% around two weeks after the launch.

While the counter-party risk is low with Coinbase as the issuing entity, cbETH is a new asset (launched on 09/22/2022) and a centralized token, requiring further and ongoing analysis to understand its complexity and usage before recommending increased caps and considering less conservative configurations.

Given the above, we recommend listing cbETH with borrowing disabled.

We recommend setting the LT at 74% and LTV at 71%. Since this is a new asset, we recommend not opening it in emode immediately but instead revisiting this option several weeks after the market is deployed and stable in production.

Initial risk parameter recommendations:

Symbol Isolation Mode Borrowable Collateral Enabled LTV LT LB RF LPF Debt Ceiling Supply Cap Borrow Cap
cbETH NO NO YES 71% 74% 10% N/A 0.10 N/A 15K N/A

After further analysis, we have updated our recommendation to allow the listing of cbETH outside isolation mode.
Generally, as recommended in the Aave docs and as mentioned by several community members on this thread, listing new assets in isolation mode is a conservative approach and good practice.
However, in this case, we think the supply cap recommended is conservative enough to allow listing cbETH outside of isolation mode and recommend the less prudent approach.

If the community desires, we can add both options (yes/no isolation mode) to the Snapshot vote to better understand the current community risk appetite.


Thanks for your analysis @ChaosLabs .

I see the risk params are conservative, but wanted to know if you took into account that the uniswap liquidity is not full range. This is key for oracles (not a concern atm because of great liquidity in Coinbase venue), but also for liquidations.

As far as I can see in the cbETH/ETH uniswap pair, these are the numbers:

  • Liquidity of ~10K worth of ETH in total
  • Range from 0.94 to 0.99 and from 1.01 to 1.04 with ~15 ETH locked per tick
  • Range from 0.99 to 1.01 with ~300 ETH locked per tick

Thanks for the comment @miguelmtz. The above was indeed taken into account in the analysis.

Updated Parameter Recommendations:

Gauntlet and Chaos Labs have collaborated and shared our independent analyses for the listing of cbETH and rETH (recommendations for rETH in a separate post).
Considering the similarities between the analyses and conclusions, we have aligned on a set of recommendations for the initial listing of cbETH on Ethereum V3.
The primary considerations were to allow full utility and usage of the assets by enabling them to be borrowed, starting with relatively conservative LT and Supply/Borrow Caps.

Symbol Isolation Mode Borrowable Collateral Enabled LTV LT LB RF LPF Debt Ceiling Supply Cap Borrow Cap
cbETH NO YES YES 67% 74% 7.5% 15% 0.10 N/A 10K 1200

Interest Rate Curve and Reserve Factor

The interest rate curve analyses and recommendations provided by Gauntlet:

cbETH is similar to stETH, which has been listed on Ethereum v2 since last Spring, but since borrowing has always been disabled for stETH, we have no data about how users respond to changes in interest rates. As such, we recommend starting with conservative parameters that can be tweaked later.


Under these parameters, the borrower interest rate increases linearly from 0% at 0% utilization to 7% at 45% utilization, and then linearly to 307% at 100% utilization. This interest rate curve matches that of the more volatile assets on Aave (1INCH, CRV, ENS, LINK, MKR, UNI). From a risk perspective, interest rate curves need to be designed to reduce the chances of utilization reaching 100% which would prevent suppliers from withdrawing cbETH and prevent liquidators from seizing cbETH collateral when performing liquidations. The proposed interest rate curve is thus desirable because it uses a low optimal utilization and has a high maximum interest rate.


Similar to our reply to the rETH thread, considering the conservative caps on cbETH,

the ACI is now supportive of onboarding cbETH into V3 emode even before shanghai to allow Aave to be competitive while maintaining risk into sustainable territories.


Emode - LT 91%, LTV 88%, LB 2%

As we’ve discussed before, cbETH shares many characteristics with wstETH, including the type of debt that it will support. Given that wstETH will be initialized with eMode params of LT 93%, LTV 90%, LB 1%, we recommend that cbETH be listed with lower LT and LTV and higher LB to account for the collateral difference.

1 Like

Really excited to see the ongoing discussion here :slight_smile:

Thank you to @ChaosLabs, @Pauljlei, and @MarcZeller for putting their recommendations forward.

Per the discussion, it looks like we’ve reached consensus on the following parameters. Please share if you disagree:

Market Risk Parameters

Symbol Isolation Mode Borrowable Collateral Enabled LTV LT LB RF LPF Debt Ceiling Supply Cap Borrow Cap
cbETH NO YES YES 67% 74% 7.5% 15% 0.10 N/A 10K 1200

Emode Eligible - NO

Interest Rate Curve and Reserve Factor

Parameter Recommendation
Base 0
Slope 1 0.07
Uoptimal 0.45
Slope 2 3.0
Reserve Factor 0.15
1 Like