Summary
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 StakeWise team, but an analysis from an Aave technical service provider on different aspects we consider critical to review. 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
osETH is an overcollateralized token that represents ETH staked in so-called Vaults (isolated staking pools) and earns ETH rewards that accrue from their validators. osETH can be minted against staked ETH on any Ethereum node and has in-built slashing protection.
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 owner role of the main contracts is given to the StakeWise DAO address, which is a Gnosis Safe controlled by a SafeSnap plugin. All transactions executed must pass a Snapshot vote and the Reality.eth escalation game with SWISE. The 4-of-7 committee acts as a safeguard and is responsible for rejecting malicious transactions. Just one of the seven signers is from the StakeWise team.
- The main contracts are non-upgradable, except for the Vaults created by VaultFactory, which are proxies and can be updated if the DAO proposes and the VaultAdmin accepts.
How osETH overcollateralized system works?
The maximum LTV for any StakeWise Vault V3 is 90%, meaning you can mint osETH up to 90% of your staked ETH to make it liquid. The limit is set to ensure that any penalties or slashing from the Vault validator do not affect the osETH holders and preserve the peg stability.
The user’s osETH position is considered healthy if it does not exceed the 90% limit. This limit can be exceeded if the Vault APY differs from the osETH APY. Depending on the level above the limit, the user position is subject to the so-called redemption or liquidation mechanisms.
At a 91.5 % limit, the user position is considered risky and subject to the redemption mechanism. This means anyone can redeem osETH acquired from exchanges for ETH locked in the Vault. The limit amount of osETH that can be redeemed for ETH is defined by the amount needed to bring the user position back to a healthy level (the formula is defined below). Redemptions don’t incur any fees, so the stakers in the Vault don’t actually lose capital. To redeem osETH, the function redeemOsToken() must be called on the Vault where the staker has a risky position level.
The redeem-amount formula:
Amount of osETH to be redeemed = 10 * amount of osETH currently minted - 9 * amount of ETH staked / osETH exchange rate
At a 92% limit, the user position is considered unhealthy and subject to the liquidation mechanism. This means that anyone can liquidate the entire osETH position of the staker previously minted for ETH + 1% reward on the value of ETH redeemed taken from the user’s stake. The oracles will exit enough validators in the Vault, so the liquidators can liquidate a position as soon as there is the so-called unbonded ETH (amounts less than 32 ETH accumulated from new deposits or exit from validators) in the Vault. If a slashing event triggers the liquidation, it will take 36 days from the initial violation to exit the slashed validators, and the liquidators can do the liquidation. To liquidate a staker position, the function liquidateOsToken() must be called on the Vault where the staker has an unhealthy position level.
The LTV, redemption, and liquidation limits are defined in a contract called OsTokenConfig and can be fetched by the getConfig() function.
List of contracts
The following is a non-exhaustive overview of the main smart contracts involved with osETH.
- The so-called overcollateralized staked ETH token is a non-upgradable contract that accrues staking rewards.
- The osETH token is a repricing token that continually increases the exchange rate as more staking rewards are earned.
- The OsTokenVaultController contract controls the minting of new osETH tokens by calling the
mint function.
- The StakeWise DAO multi-sig can add more controllers to mint new osETH tokens by calling the
setController function.
- The exchange rate is queried from the OsTokenVaultController Contract.
- It’s a non-upgradable contract that controls the emission/burn of osETH tokens.
- The mint/burn functionalities are called by Vaults duly registered in the VaultRegistry Contract.
- The Keeper Contract updates the new average rewards per second by calling the
setAvgRewardPerSecond() function.
- The StakeWise DAO multi-sig can set up a new Keeper Contract.
- It’s a non-upgradable contract that provides the configuration for minting and liquidating osETH tokens.
- This contract defines the configuration of minting and liquidating osETH stakers positions by setting the LTV and Liquidation Threshold percentages. Vaults query these values when Staker’s mint tokens or liquidators liquidate unhealthy Staker positions. The percentages can be fetched by calling the
getConfig() function.
- The StakeWise DAO multi-sig can set up new LTV and Liquidation Threshold percentages by ca.
Vaults
- Vaults are created permissionless through the VaultFactory Contract.
- It’s an OZ ERC1967Proxy Contract with a UUPS pattern. The implementation can be found here.
- The Vaults are independent and cannot be unilaterally upgraded by the StakeWise DAO. However, if the StakeWise DAO implements changes to the Vault Contract, the Vaults can choose to upgrade to the new version.
- Once oracles submit a new Merkle tree root to the Keeper contract, every Vault can pull these updates by calling the
updateState() function.
- Stakers can mint osETH tokens through Vaults, which calculate and validate the LTV using the OsTokenConfig Contract and then call the OsTokenVaultController Contract to mint new osETH tokens.
- Vault Admin cannot change the Vault’s core parameters (vault type and fee) once deployed.
Oracle
- Oracles fetches the reward data from the Beacon Chain validators and triggers validator registration and exit processes. The new reward data is submitted to the Keeper Contract by the
updateRewards() function, which sets an average reward per second to accrue in the OsTokenVaultController.
- The
updateRewards() function checks if the new average reward per second value exceeds the maximum average reward per second limit (around 22.14% APR) set in the Keeper contract constructor. The maxAvgRewardPerSecond defines the hard limit on the maximum exchange rate possible.
- To update the rewards, there is a voting mechanism that the Oracles periodically participate in every 12 hours set in the Keeper contract constructor.
- The Oracles use validator balances in the Beacon Chain and execution rewards/penalties for all the Vaults connected to the smoothing pool (a staking rewards pool) to calculate the consensus rewards/penalties for each Vault. These calculations are used to create a Merkle tree, which is then uploaded to IPFS. The vote is saved to a database and can be accessed through public Oracles endpoints.
- Anyone can call the
updateRewards() function by fetching votes from Oracles endpoints, concatenating them, and sending them to the Keeper Contract.
- The Oracle network has 11 participants, and 6 out of 11 votes are needed to update the rewards and process validator registration/exits.
- The Keeper Contract is a non-upgradable contract controlled by the StakeWise DAO multi-sig.
- The StakeWise DAO multi-sig can update the number of participants, the threshold to update the rewards, and the threshold to approve new validator registration/exists.
- Currently, the Oracle Network consists of 11 commercial operators all acting under SLA agreements: StakeWise Labs, P2P, Gnosis, DSRV, Chorus one, Bitfly, Finoa, T-Systems, Gateway.fm, Stake.Fish, and Senseinode.
Miscellaneous
- The system has multiple audits by Halborn and Sigma Prime. Given its layered nature, we still recommend adding some extra.
- The team has put effort into both security and decentralization, making the control of the major contracts by the DAO, building a robust Oracle network, and not allowing Vault Admins to make changes in the core logic.
- Given the nature of osETH to be overcollateralized and for providing in-built slashing protection, we believe that peg stability can be reinforced with its listing on AAVE V3.
Conclusion
We think osETH doesn’t have any problem in terms of integration with Aave, and there is no major blocker for listing.