- Symbol : stETH
- Address(es) :
- Deployment Date :
- Total supply : 538401629856492465802394 (538,401 units, as of June 25th, 2021, 18:38 UTC)
- Developers allotment : N/A
- Collateral Onboarding Application: [stETH] - MIP6 Collateral Onboarding
- Project website : https://lido.fi/
- Github repository : GitHub - lidofinance/lido-dao: Lido DAO smart contracts
Can use existing MCD collateral type adapter?
stETH as a rebalanced token can not, but a wrapping ERC20 contract with static balances can use the standard gemJoin adapter. The wstETH token is a current implementation of such wrapping contract.
Does the contract implement the ERC20 token standards?
Partially. The standard specifies that a ‘Transfer’ event must be emitted when tokens are transferred. stETH has periodic rebases where all balances change without such event emissions. For wstETH this discrepancy does not exist and it is ERC20 compliant.
- Risk analysis : HIGH.
- Compiler version : v0.4.24+commit.e67f0147
- Decimals : 18
- Overflow checks : Yes, the contract uses a SafeMath library.
Mitigation against allowance race-condition : Yes, the contract implements
decreaseAllowanceto get around this issue.
Upgradeable contract patterns :
Yes. A proxy contract is used. An upgrade will be needed to support withdrawals (when supported on ETH2).
Access control or restriction lists :
Yes. There is access control for pausing the token transfers, burning tokens, changing the token supply oracle and managing deposit fees. These capabilities are currently in the hands of the Lido DAO.
Non-standard features or behaviors :
- The contract supply is periodically rebased through an oracle (currently with 3/5 feed quorum). There are sanity thresholds to the periodic supply change (currently -5% daily or +10% annualy).
- The contract is pausable by a privileged actor (currently the Lido DAO).
- Tokens can be burned by a privileged actor (currently the Lido DAO).
- Ether submitted in exchange for minting stETH can not be withdrawn in the current contract version. The funds are protected by an m-of-n threshold scheme (currently 6-of-11).
- The token implementation is not in a standalone contract and instead inherited by the Lido staking and fee distribution contract.
- Does transfer have simple semantics? No. As this is a rebase token, storage changes are according to calculated shares amount and not the input token amount.
- Does transferFrom have simple semantics? No. As this is a rebase token, storage changes are according to calculated shares amount and not the input token amount.
- Can balances be arbitrarily modified by some actor? Yes, an oracle can change the total supply, which will change balances. Tokens of a can also be burned by a privileged actor.
- Are there any external calls? Yes. The contract stakes Ether on the ETH2 deposit contract. There is also support for recovering stuck Ether/tokens by sending them to a recovery address.
- AppProxyUpgradeable (Token Proxy): https://goerli.etherscan.io/address/0xA0cA1c13721BAB3371E0609FFBdB6A6B8e155CC0
- Lido (Implementation): https://goerli.etherscan.io/address/0x1d29643500b7fdb575c8f378cae13f614ed6956e
The Lido contract acts as a liquid ETH2 staking pool. The contract is responsible for Ether deposits, minting and burning liquid tokens, delegating funds to node operators and applying fees.
Lido inherits an ERC20 token contract which represents staked ether, stETH.
Tokens are minted upon deposit and can also be burned by a privileged actor.
stETH token’s balances are periodically updated when an oracle reports change in total stake (currently every day).
Upgrading the Contract
The contract uses an Aragon based proxy for upgradeability, utilizing the unstructured storage pattern.
Lido DAO contract has these privileged abilities:
- Stop/resume deposits and future withdrawal requests.
- Manage future withdrawal credentials.
- Burn tokens.
- Set addresses (oracle, treasury, insurance fund contract addresses).
- Set fees.
Overall we believe this is a high risk integration.
On a technical level the contract risk can be considered medium. It is implemented to the industry standards (SafeMath is used, ERC20 allowance race condition is mitigated), but has uncommonn logic:
- The vast staking and Aragon inherited logic, which might contain an undiscovered bug, and includes a non trivial upgrade process.
- The reliance on an off chain oracle for rebalancing.
- The need for a new Makerdao oracle implementation based on Curve as a sole liquidity source.
There are additional custodial risks which we believe that combined with the above elevate the overall risk to high:
- The token is fully controlled by a privileged actor (currently the Lido DAO) which has the power to upgrade implementation and change storage at will. In the current version that privileged actor can also change the withdrawal address, pause transfers or burn tokens.
- There is an additional custodial risk concerning the withdrawal multi-key scheme, which can lead to loss of funds.
Market liquidity risk is not evaluated in this scope.
|File Name||SHA-1 Hash|
|File Name||SHA-1 Hash|
|Lido||Implementation||ILido, IsContract, StETH, AragonApp|
|Function can modify state|
|Function is payable|