weETH technical/security analysis
Summary
Given this is the first time an asset with LRT (Liquid Restaking Token) characteristics is listed into Aave, this is a technical analysis of all the smart contracts of the asset and main dependencies.
Disclosure: this is not an exhaustive security review of the asset like the ones done by the Ether.fi 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, same as with any security review, this is not a absolute statement that the asset is flawless, only that in our opinion, we don’t see major problems for its integration with Aave, apart from different trust points.
Analysis
weETH (and its underlying eETH) is technical a Liquid Staking Token similar to stETH, but integrated natively with Eigenlayer, and so its nature of LRT (Liquid Restaking Token).
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. This is specially important because the asset should be price based on “primary market”, given its thin secondary liquidity and risks associated.
- Access control (ownerships, admin roles) and nature of the entities involved.
- Any miscellaneous aspect of the code we can consider of importance.
The following is a summary of the main contracts involved in the chain of dependencies of weETH, including weETH itself.
General points
- The upgradeability admin of all systems is an OZ Timelock, with 3 days time lock (last changed here) and controlled by a 4-of-7 Gnosis Safe. Roles were granted on constructor to the Gnosis Safe.
- For proxies, it uses an OZ proxy contract, with beacon pattern, industry standard.
Contracts
The following is a non-exhaustive overview of the main smart contracts involved with weETH
High-level, weETH is a so-called wrapper for eETH, in order to hide rebasing dynamics and be more compatible with systems like Aave.
- Proxy with upgradeability by the general timelock.
- The exchange rate is queried from the Liquidity Pool contract (more later).
Underlying of weETH.
- Proxy with upgradeability by the general timelock.
- eETH is controlled in terms of minting/burning by the Liquidity Pool contract.
Entry point for deposits/withdrawals, in some cases by using the an NFT ownership system, and others for the Membership manager contract.
- Proxy with upgradeability by the general timelock.
- A
rebase()function injecting rewards can only be called by the Membership Manager contract
Smart contract for deposits into eETH and misc other actions, like some migration features from previous versions or claiming of rewards.
- Proxy with upgradeability by the general timelock.
- The Etherfi Admin contract is the one in charge of calling
rebase()here, which in turn calls the Liquidity Pool and eETH.
Contract in charge of validators management features and rewards accrual.
- Proxy with upgradeability by the general timelock.
- Has the function
_handleAccruedRewards(), called by the Timelock to initiate the chain of calls for changes on the exchange rate of eETH. It contains validations on maximum absolute numbers, capping by time and update how much the exchange rate can change on both the positive and negative sides.
Contract receiving information about validators and rewards accrued. It acts as reporting and validation layer for different parts of the system.
- Proxy with upgradeability by the general timelock.
- Controlled by non-multisig address, but for our understanding, no critical action can be performed superseding the limitations of the Timelock on other layers.
Miscellaneous
- The connection with Eigenlayer doesn’t seem to cause any major security concern. With upgradeable systems on both sides, this could change in the future, so should be taken into account by the community.
- After this analysis, we can say that the team has put effort on both security and decentralisation, including taken immediate measures when requesting on behalf of Aave. We think that given the criticality of the system, the 4-of-7 timelock could be extended, but we believe currently is acceptable.
- The current architecture is highly layered, both architectural and flow-wise. This is not a problem per-se, just a design approach, but it makes more difficult to reason about the system.
- The system has multiple audits, with some well-known entities involved, like Zellic or Nethermind. We still recommend to add some extra, given the layered nature of the system.
Conclusion
We think weETH doesn’t have any problem in terms of integration with Aave, and there is no major blocker for listing.
However, the community should be mindful of the upgradeable nature of the system and its relatively complex access control and layers, which means certain level of trust is expected. In addition, the asset is pretty new in the market, but that should be more of a consideration for risk contributors.