The document describes the principles and algorithm for calculating the amount of Ether for stETH withdrawal requests finalization. A high-level description of the Lido on Ethereum protocol logic with withdrawals enabled is provided in the Withdrawals Landscape post. stETH and shares mechanics Lido on Ethereum protocol is a staking pool which anyone can submit their Ether and gets stETH in return. stETH is a ERC20 token that represents a holders' share in the staking pool, but the share mechanics is hidden underneath, while the balance of the token are dynamic and reflects the amount of Ether of the corresponding share at the moment. If the staking pool earns rewards or suffers losses, each holder's balance changes accordingly. As you can see on the picture, shares aren't normalized, so the contract also stores the sum of all shares to be able to calculate each account's balance. When a new holder submits their ETH, the new shares get minted to reflect what share of the protocol controlled ether has been added to the pool. Normally share rate changes after the consensus layer oracle report comes in and total pooled ether has been rewrited by the up to date value. You can see that holders who entered the pool with same Ether at different share prices gets minted different amounts of shares:

Abstract On Tuesday, Oct 5, the vulnerability allowing the malicious Node Operator to intercept the user funds on deposits to the Beacon chain in the Lido protocol was reported to Immunefi. On Wednesday, Oct 6, the short-term fix was implemented. Currently, no user funds are at risk, but the deposits to the Beacon chain are paused. This document outlines the long-term mitigation allowing deposits in the Lido protocol. The vulnerability could only be exploited by the Node Operator front-running the Lido.depositBufferedEther transaction with direct deposit to the DepositContract of no less than 1 ETH with the same validator public key & withdrawal credentials different from the Lido's ones, effectively getting control over 32 ETH from Lido. To mitigate the vulnerability, Lido contracts should be able to check that Node Operators' keys hadn't been used for malicious pre-deposits. DepositContract provides the Merkle root encoding of all the keys used in staking deposits. We propose to establish the Deposit Security Committee checking all deposits made and approving the current deposit_data_root for Lido deposits. The idea was outlined on research forum post as the option d).

You need to replace the offchain message passing entity from Shuttle to Wormhole, keeping deployed bETH contracts on both Terra and Ethereum sides at the same addresses. bETH is a derivative token which make possible to add stETH as a collateral into the Anchor protocol. The native side of bETH is Ethereum, which means, when someone wants to send some bETH tokens from Ethereum to Terra, the tokens are locked in a contract on the Ethereum side (the contract is called ShuttleVault). Then, the bridge passes the message "mint N bETH tokens on the Terra side to address A" When user wants to pass their tokens back to Ethereum, they burn this amount of Terra-side bETH, and the bridge passes the message "unlock the given amount of bETH tokens on the Etereum side and send them to address B" To upgrade the message forwarding entity (bridge) from Shuttle to Wormhole:

Blockchain operations require real tokens with real value for any operations: coin & token transfers, deploying & interacting with smart contracts. To ease up development & testing, large blockchains support test networks, where tokens are still required, but are free. Those tokens are often distributed through token faucets like these: https://goerli-faucet.slock.it/ https://faucet.goerli.mudit.blog/ https://faucet.terra.money/ Public faucets are a bad fit for us: they often don't work and provide far too few tokens. We have our own stash of test tokens we're distributing upon team member's request. The task is to automate the process.

Incorrect burning of shares https://hackmd.io/@mixbytes/Hyx8pX5lt#1-Incorrect-burning-of-shares Any burning of the stETH token is an emergency that Lido DAO reserves to use against protocol hack or to recover from a failure mode. The burning of tokens for an arbitrary address shouldn’t happen during normal protocol operations. We acknowledge, that burning any number of stETHs on the wstETH contract balance will violate the wrapping/unwrapping mechanics, but this shouldn’t happen in a normal mode. However this opportunity is very important for failure recovery: if there is an error in the current implementation of the wstETH token, then the DAO will be able to pause stETH, burn stETH from the wstETH contract’s balance, redeploy a new token, and recover balances by minting after that. Possible incorrect initialization https://hackmd.io/@mixbytes/Hyx8pX5lt#1-Possible-incorrect-initialization

The Lido DAO is an Aragon organization. Since Aragon provides a full end-to-end framework to build DAOs, we use its standard tools. We use standard aragon Voting contract that has been initialized with voteTime 24 hours. As the the number of LDO token holders grows, 24 hours is no longer the optimal value for voting time, neither from voting organization point of view, nor from the security point of view. In the future, we plan to increase the voting period again, for example, to one week. Aragon voting not allow to change this parameter trough the setter, so we’ve forked the app and add a setter, a role and coressponed event for voteTime variable. This change will require upgrade the voting contract, adding of a new role and republish the UI. The current mechanics When someone starts a vote, the Voting contract stores the time of the vote start: Vote storage vote_ = votes[voteId];

Preamble MIP10c3-SP#: 36 Author(s): Contributors: Type: Process Component Oracle Team Name: Status: Date Proposed: <yyyy-mm-dd> Date Ratified: <yyyy-mm-dd>