[ARFC] Onboard rsETH to Arbitrum and Base V3 Instances

Governance
1

[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
2

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

image
image824Ă—732 39.7 KB

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

image
image812Ă—730 40.5 KB

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.

3

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.

image
image1620Ă—704 60.4 KB

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.

image (1)
image (1)1586Ă—1090 74.3 KB

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.

image (2)
image (2)1588Ă—1090 67.9 KB

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
4

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.

5

rsETH (Arbitrum and Base) technical analysis


Summary

Following the new proposal for listing it on Base and Arbitrum, we have checked how the KelpDAO Team had implemented the rsETH bridge mainnet <> L2s and native restaking.
This is a technical analysis of all the smart contracts of the asset and main bridge dependencies.

Disclosure: This is not an exhaustive security review of the asset like the ones done by the KelpDAO team, but an analysis from an Aave technical service provider on different aspects we consider critical to review before a new type of listing, in this case of a cross-chain asset.


Analysis

The Kelp Team has added support for its cross-chain asset via two different layers:

  • A native L2 minting system, where users can deposit ETH and LSTs for rsETH, which later on gets bridged to mainnet.
  • A cross-chain bridge via LayerZero infrastructure, where tokens are locked in an OFT adapter contract on mainnet and minted on the respective L2.

Bridge

The main cross-chain rsETH bridge to L2s (Base and Arbitrum in this case) relies on the Layer Zero infrastructure. The bridge flow between chains consists of a few steps:

  • L1 → L2s:

    1. Users send the rsETH to the rsETH OFT adapter via the send() function.
    2. Internally, the lz endpoint contract is called to send a cross-chain message.
    3. On the L2, the lz endpoint receives the message and calls the lzReceive() function in the rsETH OFT contract, which mints the rsETH to the user.

  • L2s → L1:

    1. Users call the send() function in the OFT rsETH.
    2. Internally, the token amount is burned, and the lz endpoint is called to send a cross-chain message.
    3. On the L1, the lz endpoint receives the message and calls the rsETH OFT adapter, which transfers the rsETH.

  • L2 → L2:

    1. Users call the send() function in the OFT rsETH.

      Obs.: On Arbitrum, this can be done directly, while on Base, users need first to unwrap wrsETH to rsETH.

    2. Internally, the token amount is burned, and the lz endpoint is called to send a cross-chain message.

    3. On the L2, the lz endpoint receives the message and calls the lzReceive() function in the rsETH OFT contract, which mints the rsETH to the user.


L2 Native Minting

The Kelp Team enables minting rsETH on both chains via the deposit pool contract. Later, the assets in the deposit pool are bridged back to the mainnet to be restaked via the bridgeAssets() function.

  • Users can mint wrsETH on Base by depositing ETH via the deposit(msg.value) function.
  • On Arbitrum, the Kelp treasury provides rsETH already bridged, so it is not a native minting, but users can swap ETH, ETHx, and stETH for rsETH via the deposit(token, amount) function.
  • The exchange rate is calculated internally using the current exchange rate from the rsETH oracle, which is fetched using the rsETHOracle.getRate() function.
  • The rsETHOracle contract receives the rate via a cross-chain rate provider deployed on Ethereum. This provider contract broadcasts the current rate to the respective chains via LayerZero cross-chain messages.

It’s important to mention that the deposit pool contract imposes a 500 rsETH/day limit on Base.


Contracts


Access Control:

The system has role-based access control, which we described below.

  • DEFAULT_ADMIN_ROLE: Is responsible for configuring the important addresses (oracle, layerZero endpoint, assets being deposited) and the general fees, as well as other roles.
  • BRIDGER_ROLE: It manages the deposited assets on the L2 by sending them to the L1VaultETH contract on mainnet to mint rsETH, which is bridged to the L2 (see L1 → L2s bridge section for a detailed flow of the assets).
  • MANAGER_ROLE: This is not used in other contracts where it is present, but it is used in L1VaultETH contract to mint rsETH and send it back to L2 (see L1 → L2s bridge section for a detailed flow of the assets).
  • LEGACY_MANAGER_ROLE: deprecated.

Ethereum Mainnet

Contract Role Admin Upgradable
RSETH_OFTadapter OFT adapter for bridge rsETH via LayerZero Safe 3-of-6 No
RSETHMultiChainRateProvider Exchange rate provider for L2s using LayerZero infrastructure Timelock (3 days) No
L1VaultETH the receiver of ETH bridged from L2, which mints rsETH on L1 and send it back to the L2 Safe 3-of-6 (DEFAULT_ADMIN_ROLE,MANAGER_ROLE); EOA (MANAGER_ROLE) ProxyAdmin → Timelock (3 days)

Arbitrum

Contract Role Admin Upgradable
Deposit Pool The main entrance for users who want to swap rsETH Safe 3-of-6 (DEFAULT_ADMIN_ROLE, BRIDGER_ROLE) ProxyAdmin → Timelock (3 days)
rsETH OFT adapter representing rsETH bridged Safe 3-of-6 No
rsETHOracle cross chain rsETH exchange rate receiver Timelock (3 days) No

Base

Contract Role Admin Upgradable
Deposit Pool The main entrance for users who want to mint rsETH Safe 3-of-6 (DEFAULT_ADMIN_ROLE, BRIDGER_ROLE) ProxyAdmin → Timelock (10 days)
rsETH OFT adapter representing rsETH bridged Safe 3-of-6 No
wrsETH Wrapper for OFT rsETH Safe 3-of-6 (DEFAULT_ADMIN_ROLE); EOA (BRIDGER_ROLE) ProxyAdmin → Timelock (10 days)
rsETHOracle Cross-chain rsETH exchange rate receiver Timelock (10 days) No

Price strategy

The Kelp team has not only bridged the rsETH token itself but also added the rsETH Oracle to support the native L2 minting, which receives the rate via LayerZero cross-chain messages from a rate provider on mainnet. Apart from this, Chainlink also has rate feeds on both chains, which pulls the exchange rate from the mainnet oracle.

Given that we don’t see any issue with synchronization of the rate update between Chainlink feeds and the rsETH Oracle (depending on LayerZero), we think it makes sense to use the Chainlink feeds in order to be consistent with other Aave approaches on cross-chain pricing.


Miscellaneous aspects

  • The system has security review by Mixbytes, and can be found here.
  • Currently, Kelp is using LayerZero’s DVN for the verifications. We suggest that this can be expanded to other DVNs.

Conclusion

We think rsETH has no problem integrating with Aave on Base and Arbitrum.
The Kelp Team has already addressed our recommendations for time-locking the sensitive contracts for the L2 bridging and minting system, and there is no major blocker for listing.

2 Likes
6

The current proposal has been escalated to ARFC Snapshot.

Vote will start tomorrow, we encourage everyone to participate.

1 Like
7

As Michigan Blockchain, we support onboarding rsETH to Arbitrum and Base V3 Instances. rsETH is an ETH Liquid Restaked Token (LRT) issued by Kelp DAO. After ether.fi, Kelp DAO offers the second largest ETH LRT in terms of market cap, which is rsETH.

Total market cap of rsETH is 576787 ETH ($1.5b) and that number has been growing steadily for the past several months. In this case, supporting the expansion to Aave’s biggest L2 markets which are the Arbitrum and Base Instances makes a lot of sense.

Currently, nearly $1.1b of the $1.5b market cap is deposited into two Aave v3 Instance: Ethereum and Lido, with Ethereum taking most of the share.


rsETH exposure distribution across Aave Instances

The LRT with the highest market cap, weETH is available for supply/borrow on 7 Aave v3 Instances and we can analyze the percentage of the TVL deposited into Base and Arbitrum Instances to see how this proposal will increase Arbitrum and Base TVL. This comparison is fair because if rsETH is onboarded to Base and Arbitrum instances, rsETH will coexist with weETH as rivals as they do currently in the Ethereum Instance, so that is a controlled variable.


weETH exposure distribution across Aave Instances

Total supply of weETH on Aave is $3.97B, and Arbitrum Instance makes up 7.23% of it while Base Instance makes up 3.91%. Other chains have negligible weETH TVL so we don’t have to take those into consideration for now. If we consider that rsETH TVL is $1.1b on Aave, and if we assume a similar exposure distribution, Arbitrum Instance will get $79.5m and Base instance will get $43m of the TVL (considering total TVL stays $1.1b, but it will probably continue to grow given the current trend). Therefore, Arbitrum TVL will increase by 8.75% (current TVL is $909.17m) and Base TVL will increase by 9.74% (current TVL is $441.3m). Both of these increases are massive, so given there are no threats in implementing rsETH to these markets, the positives outweigh other considerations.

We support onboarding rsETH with similar parameters to ezETH and corresponding E-Modes for rsETH / wstETH and rsETH / stablecoins as the “[ARFC] Onboard ezETH to Arbitrum and Base Instances” has just passed in December 2024 and we think that the risk profiles of these assets are similar.

-Kerem Dillice

8

After Snapshot monitoring, the current ARFC Snapshot ended recently, reaching out both Quorum and YAE as winning option with 812.5K votes.

Therefore [ARFC] Onboard rsETH to Arbitrum and Base V3 Instances has PASSED.

Next step will be the publication of an AIP for final confirmation and enforcement of the proposal.

9

Just after listing, a misconfiguration involving the new eMode including wrsETH and another involving LBTC has been detected, with a race condition between two proposals running in parallel causing the rsETH eMode to have too conservative risk parameters but including on the same eMode both ETH assets (rsETH collateral, wstETH borrowable) and BTC assets (LBTC collateral, cbBTC borrowable).

Even if this doesn’t create any immediate risk to the protocol or these assets, this is a highly unexpected configuration, and we have recommended the Aave Protocol Guardian to freeze the assets affected (wrsETH and LBTC), as there were no user supplies yet.

A follow-up governance proposal will be submitted fixing the eMode configuration, and making both LBTC and wrsETH fully operative again.

4 Likes
10

We have created the governance proposal to correct the configuration of wrsETH and LBTC on Base and unfreeze both assets.

Voting will start in approximately 24 hours, and if the governance approves this proposal, both assets will be fully operative in approximately 5 days.

https://vote.onaave.com/proposal/?proposalId=268

4 Likes