[ARFC] Onboard rsETH to Arbitrum and Base V3 Instances

[ARFC] Onboard rsETH to Arbitrum and Base V3 Instances

Author: ACI

Date: 2025-01-21


ARFC updated with Risk Params 2025-01-30

Summary

This is an ARFC to onboard rsETH to the Aave V3 Arbitrum and Base Instances allowing Aave users to supply rsETH as collateral. This proposal will be under Direct to AIP, as rsETH is already listed on other Aave instances.

Motivation

rsETH has seen continued growth across networks, and is currently the only of the onboarded LRT not available on Arbitrum or Base. We expect further growth of this asset with onboarding to these networks. Arbitrum has one of the largest wstETH reserves of any Aave instance and Base activity has continued to increase. We suggest to onboard rsETH with similar parameters to ezETH and corresponding E-Modes for rsETH / wstETH and rsETH / stablecoins.

Specification

Contract addresses:

rsETH arbitrum: 0x4186BFC76E2E237523CBC30FD220FE055156b41F

wrsETH base: 0xEDfa23602D0EC14714057867A78d01e94176BEA0

Risk Parameters:

Risk Parameters have been provided by Risk service providers during the ARFC phase and this ARFC has been updated accordingly. 2025-01-30

Parameter Value Value
Asset rsETH wrsETH
Market Arbitrum Base
Isolation Mode No No
Borrowable No No
Collateral Enabled Yes Yes
Supply Cap 900 400
Borrow Cap - -
Debt Ceiling - -
LTV 0.05% 0.05%
LT 0.10% 0.10%
Liquidation Bonus 7.50% 7.50%
Liquidation Protocol Fee 10.00% 10.00%
Variable Base - -
Variable Slope1 - -
Variable Slope2 - -
Uoptimal - -
Reserve Factor - -
Stable Borrowing Disabled Disabled
Flashloanable Yes Yes
Siloed Borrowing Disabled Disabled
Borrowable in Isolation No No
E-Mode Category rsETH/wstETH rsETH/wstETH

rsETH/wstETH E-Mode on Arbitrum & Base

Parameter Value Value
Asset rsETH wstETH
Collateral Yes No
Borrowable No Yes
LTV 92.50% -
LT 94.50% -
Liquidation Penalty 1.00% -

Useful Links

rsETH:

Disclaimer

ACI is not directly affiliated with the issuers of the assets mentioned in this proposal and did not receive compensation for creating this proposal.

Next Step

  1. Publish a standard ARFC, collect community & service provider feedback before escalating proposal to AIP.
  2. Publish an AIP vote for final confirmation and enforcement of the proposal.

Copyright

Copyright and related rights waived under CC0.

2 Likes

Summary

LlamaRisk recommends onboarding rsETH on the Arbitrum and Base V3 instances. We previously conducted a full review of rsETH on Ethereum mainnet, and our positive outlook remains. We agreed on the parameters with ChaosLabs, who will share them shortly. Since the main use case is to leveraged-loop rsETH with wstETH, an rsETH-wstETH E-mode makes sense for Arbitrum and Base. The demand for a rsETH-stablecoin E-mode is expected to be low, so it is not recommended.

Although the liquidity for rsETH on those chains is not very high, it is mitigated by the fact that rsETH will be correlated against its debt asset wstETH. We note that no Timelock is slowing down contract upgrades or parameter updates, which could increase users’ safety.

rsETH on Arbitrum

Liquidity


Source: Kyberswap, January 27th, 2025

rsETH has meaningful liquidity on Arbitrum, with 462 rsETH ($1.49m) available to be sold at a 7.5% price impact.

Access control

Kelp is using LayerZero for bridging the assets deposited on Arbitrum to the Ethereum mainnet, where it is restaked. Three assets can be deposited: ETH, ETHx, and wstETH. A LayerZero endpoint is used to receive the rsETH/ETH exchange rate. The Kelp’s architecture on Arbitrum is made of the two following contracts:

  • RSETH_OFT: LayerZero ERC20 contract representing rsETH on Arbitrum.
  • RSETHPool: deployed behind a TransparentUpgradeableProxy contract from OpenZeppelin. It allows for the minting of rsETH on Arbitrum by depositing ETH, ETHx, or wstETH. The deposited assets are bridged to Ethereum mainnet for restaking within EigenLayer.

Here are the controlling wallets:

The RSETH_OFT contract is owned by the 2/6 Multisig directly. The RSETHPool contract is controlled by the two following roles, which are all assigned to the ProxyAdmin:

  • DEFAULT_ADMIN_ROLE: can set the fee, pause/unpause deposits, update the oracle for rsETH, update the L1 vault address, update the Startgate pool, add/remove accepted tokens, and update the LayerZero destination chain.
  • BRIDGER_ROLE: can withdraw the accumulated fees from the pool and move assets for bridging.

rsETH on Base

The main token for rsETH on Base is wrsETH, a thin wrapper around the underlying rsETH that is being bridged. Since they are atomically redeemable 1-1 for each other, we refer to them interchangeably.

Liquidity


Source: Kyberswap, January 27th, 2025

Base has less liquidity than Arbitrum, with only 342 rsETH ($1.02m) available within a 7.5% price impact.

Access control

Like on Arbitrum, LayerZero is also used on Base, but only ETH can be deposited in exchange for rsETH. The Kelp architecture on Base is made of the following three contracts:

  • RSETHPoolV2ExternalBridge: deployed behind a TransparentUpgradeableProxy contract from OpenZeppelin. Allows for the minting of rsETH on Arbitrum by depositing ETH, which is then bridged to Ethereum mainnet for restaking within EigenLayer.
  • RSETH_OFT: LayerZero ERC20 contract representing rsETH on Arbitrum.
  • RsETHTokenWrapper: a wrapper for rsETH that can be redeemed for it on a 1-1 basis.

The RSETHPoolV2ExternalBridge contract has two roles, which are both assigned to a 3/6 Safe multisig:

  • BRIDGER_ROLE: can withdraw fees and bridge the ETH deposited.
  • DEFAULT_ADMIN_ROLE: can set the fee, change the rsETH oracle, change the L1 vault, change the stargate pool, change the destination chain, and pause the contract.

The RSETH_OFT contract is owned by the 3/6 Safe multisig.

The RsETHTokenWrapper contract has the following roles:

Price Feeds

Although Chainlink price feeds are available for Arbitrum and Base, we recommend using the internal exchange rate of rsETH together with CAPO. The internal exchange rate for rsETH on Arbitrum and Base is pushed through LayerZero, whose risk is already borne by Aave since the minting and burning of rsETH on those chains also happens through LayerZero. This will also depend on BDG’s preference and technical appreciation.

Disclaimer

This review was independently prepared by LlamaRisk, a community-led non-profit decentralized organization funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.

The information provided should not be construed as legal, financial, tax, or professional advice.

Overview

Chaos Labs supports listing rsETH/wrsETH on Aave’s Arbitrum and Base instances. Below, we provide an analysis and recommendation.

Analysis

Chaos Labs has previously provided a risk assessment for rsETH on Ethereum, finding that it was suitable for listing. rsETH on Arbitrum uses the OFT standard to facilitate transfer across chains, while wrsETH is a wrapped version of OFT rsETH that is used on some networks to facilitate integrations in DeFi.

rsETH’s popularity on Aave has grown rapidly, almost entirely driven by its E-Mode with wstETH, allowing users to leverage rsETH against the previously little-borrowed wstETH.

Following this demonstrated demand on Ethereum, we propose a listing that allows users to leverage the asset on Arbitrum and Base.

Market Cap and Liquidity on Arbitrum and Base

rsETH currently has a supply of 6,149 on Arbitrum, having decreased significantly since its peak in April, though this can be expected to increase when it is listed on Aave. The asset’s liquidity has been somewhat volatile, with a large spike from June to September; it has deteriorated since.

wrsETH’s total supply on Base is 5,160 and its liquidity is concentrated in two pools on Aerodrome. Its liquidity has been volatile, though it has maintained a consistent floor of ETH liquidity since October.

The proposed listing parameters will limit the assets’ reliance on on-chain DEX liquidity.

LTV, Liquidation Threshold, and Liquidation Bonus

We recommend setting the assets’ non-E-Mode LTV and LT to 0.05% and 0.10%, respectively, aligning the values with those in the Prime instance. This will prioritize leveraged strategies while effectively eliminating uncorrelated borrowing that could strain the assets’ DEX liquidity in the event of liquidations.

E-Mode

We recommend aligning the assets’ E-Modes with that on Ethereum.

Supply Cap and Borrow Cap

We recommend setting the assets’ supply cap to 2x the liquidity available at a price impact equivalent to the asset’s Liquidation Penalty. This leads to a recommendation of 900 rsETH on Arbitrum and 400 wrsETH on Base. We do not recommend allowing borrowing given limited use cases and demand.

Specification

Following the above analysis, we recommend the following parameter settings:

Parameter Value Value
Asset rsETH wrsETH
Market Arbitrum Base
Isolation Mode No No
Borrowable No No
Collateral Enabled Yes Yes
Supply Cap 900 400
Borrow Cap - -
Debt Ceiling - -
LTV 0.05% 0.05%
LT 0.10% 0.10%
Liquidation Bonus 7.50% 7.50%
Liquidation Protocol Fee 10.00% 10.00%
Variable Base - -
Variable Slope1 - -
Variable Slope2 - -
Uoptimal - -
Reserve Factor - -
Stable Borrowing Disabled Disabled
Flashloanable Yes Yes
Siloed Borrowing Disabled Disabled
Borrowable in Isolation No No
E-Mode Category rsETH/wstETH rsETH/wstETH

rsETH/wstETH E-Mode on Arbitrum & Base

Parameter Value Value
Asset rsETH wstETH
Collateral Yes No
Borrowable No Yes
LTV 92.50% -
LT 94.50% -
Liquidation Penalty 1.00% -

Disclaimer

Chaos Labs has not been compensated by any third party for publishing this recommendation.

Copyright

Copyright and related rights waived via CC0

1 Like

Update: A legacy function in the RSETHPool contract previously allowed the BRIDGER_ROLE to send all funds in the contract to itself and bridge the asset to L1. This resulted in a significant risk for users and the Aave DAO, as a malicious takeover of the wallet with that role could have rendered rsETH undercollateralized.

Following our communication with the Kelp DAO team, they have successfully addressed the identified concern by deploying a contract upgrade which deprecated the vulnerable function. We appreciate their swift response and commitment to protocol security.