[ARFC] Onboard rsETH to Arbitrum and Base V3 Instances

Governance
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