[ARFC] Onboarding ETHx to Aave V3 Ethereum

Governance
9

Summary


This is a technical analysis of all the smart contracts of the ETHx asset and main dependencies.

Disclosure: This is not an exhaustive security review of the asset like the ones done by the StaderLabs team, but an analysis from an Aave technical service provider on different aspects we consider critical to review before a new type of listing. Consequently, like with any security review, this is not an absolute statement that the asset is flawless, only that, in our opinion, we don’t see significant problems with its integration with Aave, apart from different trust points.



Analysis

ETHx is a repricing Token that increases in value as staking rewards, MEV, and tips accrued to the user’s staked ETH. Rewards accrue from the consensus and execution layers, and the liquid rewards from the execution layer are restaked to keep auto-compounding.

For the context of this analysis, our focus has been on the following aspects, critical for the correct and secure integration with Aave:

  • Mechanism to update the exchange rate of the asset for the underlying ETH.
  • Access control (ownerships, admin roles) and nature of the entities involved.
  • Any miscellaneous aspect of the code we can consider of importance.

General points

  • The upgradeability admin of all systems is an OZ Timelock, which has a 7-day time lock and is controlled by a 6-of-9 Gnosis Safe.
  • For proxies, it uses an OZ transparent proxy pattern.

Economic Security

To ensure the health of the system, Stader has defined different aspects of protecting staker’s ETH. Stader requests 4 ETH and 0.4 ETH worth of SD tokens (Stader tokens) from node operators as collateral to borrow the staker’s ETH to run validators. The 4 ETH security collateral protects the staker ETH by absorbing all operational risks (slashing, MEV misappropriation, and any other ETH network-imposed penalties).


Contracts

The following is a non-exhaustive overview of the main smart contracts involved with ETHx.


ETHx

  • The so-called ETHx repricing token is an OZ Transparent Proxy contract with upgradeability by the general timelock.
  • ETHx also has an L2 contract with an extra PAUSER_ROLE role and without the staderConfig address present in the L1 contract. Currently, this contract is deployed at Arbitrum and Optimism.
  • The mint() and burnFrom() functions are controlled by the StakePoolManager and UserWithdrawalManager contracts, respectively.

Stader Stake Pool Manager

  • Contract where users deposit ETH and the only minter of ETHx.
  • OZ Transparent Proxy contract with upgradeability by the general timelock.
  • Users can stake ETH for ETHx by calling the deposit() function.
  • The exchange rate is obtained from the Oracle contract.

User Withdrawal Manager

  • Contract where users withdraw and redeem ETH and the only burner of ETHx.
  • OZ Transparent Proxy contract with upgradeability by the general timelock.
  • The redemption consists of a 3-step process: request by calling requestWithdraw(), finalize by calling finalizeUserWithdrawalRequest(), and claim by calling the claim() function.
  • In the request step, the staker transfers ETHx, and the amount of ETH to be claimed is calculated based on the current exchange rate.

ETHx Oracle

A contract that receives the exchange rate data from the Oracle operators through the majority consensus mechanism for appropriate blocks.

  • OZ Transparent Proxy contract with upgradeability by the general timelock.
  • Node operators submit the exchange rate by calling the submitExchangeRateData() function with the total ETH staked and total ETHx supply at an x block. The exchange rate formula is defined by total ETH staked / total ETHx Supply.
  • Each node operator submits new data to update the exchange rate; when the minimum number of submissions is reached (submissionCount >= trustedNodesCount / 2 + 1) and the data is from a block greater than the last block updated, an internal function updateWithInLimitER() is called and the exchange rate is updated. The trustedNodesCount is set to 5 trusted nodes.
  • Exchange rate updates must be submitted at precise intervals of 7200 blocks (approximately 24 hours). The exchange rate update frequency (updateFrequencyMap[ETHX_ER_UF]) was set in the initialize() function.
  • An Inspection mode is enabled when the new exchange rate deviates more than 1% from the current rate. When enabled, the Stader manager needs to verify the validity of the new exchange rate. The Inspection mode can be turned off by calling the closeERInspectionMode() function after 7200 blocks from the block where it was activated.
  • The deviation ( erChangeLimit) was set in the initialize() function to 5%, but after, it was set to 1% here.
  • The Oracle also has a function updateERFromPORFeed() to update the exchange rate from Chainlink Proof of Reserve data feeds for ETHX and ETH supply as an alternative to the above, but it’s currently deactivated. The Stader manager can turn it on by calling the togglePORFeedBasedERData() function. The Stader Manager role is given by the general timelock.
  • Each Oracle operator provides security collateral to back their Oracle performance. The list of Oracle operators is here.

Miscellaneous

  • The system has multiple audits by SigmaPrime, Halborn, and Code4rena. Given its layered nature, we still recommend adding some extra.
  • The minimum proposal delay of 7 days for upgradability in the timelock contract gives an acceptable time to verify the proposed changes.
  • There is visible work on monitoring the system’s health across several metrics. An important mention is the Oracle, which plays a crucial role in the system and is run by well-known node operators who have demonstrated technical proficiency in it. We still recommend adding some extra operators to maintain the system’s integrity, but the current configuration is already quite solid.

Conclusion

We think ETHx doesn’t have any problem in terms of integration with Aave, and there is no major blocker for listing.

5 Likes