Lido Staking Vaults (stVaults): Technical Design and Architecture TL;DR It's an evolving (Work-In-Progress) draft of the Lido stVaults tech design document, which covers a high-level technical description of stVaults' design principles, architecture, and mechanics. It's not a product or goals doc, although they are briefly mentioned to give context. More detailed tech reference follow-up docs and materials will be presented later. 1. Abstract Lido Staking Vaults (stVaults) are modular primitives that seamlessly connect stakers, node operators, and protocols, settle fee structure, validation setup, and optimize risk/reward. All this is done while preserving decentralization, security, and access to stETH liquidity. 2. Goals

Repository: Lido Oracle Directory to audit: src/ Approximate lines of code: ~ 6400 (tool: pygount) Update details For the upcoming hard fork, the off-chain Oracle will require certain mandatory changes that must be released prior to the fork to avoid accounting issues (Oracle V5). Simultaneously, we are preparing the implementation of Triggerable Withdrawals, which will also require audit (Oracle V6). In case if Triggerable Withdrawals feature is ready in time the V5 release will be skipped. The Lido Oracle is optimistically scheduled for a single audit in February, covering both Scope V5 and V6. However, in the worst-case scenario, scope V6 may be delayed and require a separate audit in April. Changes V5

Abstract Improve the safety check for the accounting report in the case of a negative rebase, reducing the possible impact size, but with the requirement for a second opinion for extreme cases. As a result impact size of current sanity check reduced by 26 times to 0.19% per day. Motivation The AccountingOracle contract is a fundamental component of the Lido protocol that delivers, amongst other data, the aggregate of all Lido validators' Beacon Chain balances (clBalance in the report) to the protocol, thereby facilitating the daily rebase of the stETH token. The accuracy of this value is critical to the integrity of the protocol, and it relies on a committee of independently operated Oracle daemons in a 5-of-9 configuration. The protocol could be harmed if this committee is compromised, malfunctions, or colludes. This risk is acknowledged and constrained by a sanity check that restricts the possible discrepancy in balance that Oracle can report. The current approach to sanity checking allows the Oracle committee to bring up to a 5% reduction of TVL in each report. Given that the governance reaction time has a lower bound of 72 hours, the malicious or compromised Oracles could reduce reported TVL by 15-20%, invoking mass liquidations on lending markets and dropping the price of stETH. However, a real negative rebase has very distinct features that we can take into account to reduce the impact and attack surface while allowing frictionless operation of the protocol even during a mass slashing event. While a high-precision check is possible using zero-knowledge technologies and EIP-4788, we decided to start with the simplier solution. It limits the impact in a simple but effective way. It provides an easy way to improve the robustness of the solution later.

Overview With the increase in the share of the SimpleDVT module and the demand for more targeted allocation of stake into the module, the question arises about the existence of a mechanism ensuring the deposit of user ETH into a specific staking module of the protocol. However, the current protocol lacks a mechanism to facilitate this because all incoming stake is automatically allocated across modules according to the MinFirstAllocationStrategy. This means that new stake will be directed to the module with the smallest share of allocated stake until a certain module has the smallest share. Additionally, it's important to note that ETH from the buffer can be used to fulfill withdrawal requests (also check the code of Lido.getDepositableEther()) One possible solution to the problem at hand, without making changes to the Lido core protocol smart contracts, is simply to wait for an opportune moment when there are no outstanding withdrawals in the protocol. Subsequently, one can sequentially call the submit method (to place ETH in the buffer) and the deposit method (to allocate stake to the module). Thus, as long as the module's share of allocated stake remains minimal, it can be asserted that newly staked Ether will be allocated to this module. The technical implementation of this approach involves using an external smart contract, capable of submitting Ether and simultaneously depositing it within a single transaction. However, this approach will also require adjustments to off-chain tooling, particularly minor changes to the logic of the depositor bot to ensure conditions for optimal timing and the invocation of methods on the external contract. On-chain implemenatation's interface

🚧 WORK IN PROGRESS 🚧 Abstract The proposal to integrate external trustless ZK-based Beacon Chain oracles as extra safety measures for the stETH token rebase within the Lido protocol. It includes: Required changes for the protocol to add these new checks on rebase 2-of-3 Multiprover to improve security and reliability Tiebraker quasi-oracle to speed up the start Emergency lever to prevent DoS for the integration period (1st year)

Scope of note This note is a supplementary document for DSM 2.0 exploring the risk and possible limitations on executing fron-run deposit attack within guardian collusion. Original attack Front-run An operator might attempt to front-run the deposit transaction with their own deposit transaction but with different withdrawal credentials. In this case, the deposit transaction through DSM will be reverted due to a mismatch of deposit_root on the Deposit Contract, after which the Council Daemon will report the front-run key to the module, and it will be excluded Guardian Collusion With the emergence of permissionless modules, it is necessary to reconsider the collusion scenario, as the ability to introduce permissionless modules and modules with FIFO can alter the attack patterns.

The current doc describes the implementation details of EasyTrack EVM factories to manage an instance of the Simple DVT NodeOperatorsRegistry. The rights to manage node operators (clusters) in the Simple DVT will be granted to the Simple DVT committee represented by the gnosis multisig. The high-view overview of the management flow is presented in the below diagram. Before reading the current document, please check out the high-level Simple DVT module management flow. For consistency, throughout the document, the term node operator(s) is used, but by this, we also mean cluster(s). Validator Keys Management The management of the validator keys in the instance of the NodeOperatorsRegistry used as a curated staking module happens from the reward address. To add or remove the validator's keys, the node operator sends the transaction from the reward address. image

Anchor Sunset. Review Scope. Simple summary The anchor-collateral-steth contains Ethereum contracts for integrating stETH as a collateral into the Anchor protocol in the form of bETH token. Context In June 2022, we created a post on the research forum in which we published a proposals to stop supporting Anchor integration. A snapshot was published too, that passed the vote. The procedure is as follows: upgrade contracts to prevent bETH from minting;

GateSeal. Audit scope A GateSeal is a contract that allows the designated account to instantly put a set of contracts on pause (i.e. seal) for a limited duration. GateSeals are meant to be used as a panic button for crucial contracts in case of an emergency. Each GateSeal is one-time use only and immediately becomes unusable once activated. If the seal is never triggered, the GateSeal will still eventually expire after a set period. Quick summary Project repo Written in Vyper 0.3.7 Developed in Ape 0.6.2 Python 3.10.6 Scope

Cross-chain governance executor For the governance representation, the token and the bridge admin has been set to the Lido DAO agent contract as a final result of deployment The governance executor has been deployed from the following repo: https://github.com/lidofinance/governance-crosschain-bridges/tree/master, the contracts correspond to master branch. Deployment instructions: https://github.com/lidofinance/governance-crosschain-bridges#deploying-the-optimismbridgeexecutor, deployment script: https://github.com/lidofinance/governance-crosschain-bridges/blob/master/deploy/gov-bridge-optimism.ts Cross-chain governance executor actions log on OP Mainnet Deployment (01.08.22) The expected final audit report commit: https://github.com/aave/governance-crosschain-bridges/commit/8fa25b0080dd3dcc2390313631aea6796a12c9d8 [x] The commit to deploy from: https://github.com/lidofinance/governance-crosschain-bridges/commit/a47c99b53175c3309165cafdd35c654e6c4e519d

Part of withdrawal credentials rotation plan At this stage of the ceremony, all participants have installed the necessary software, and have already set up communication [exchanged public communication keys] of workstations. Cold machinedc4bc_airgapped qr-tool Hot machine qr-tool

Summary Aragon UI, the Lido DAO's web interface, was originally designed as an accessible tool to discern the protocol's state. Over its operational lifespan, the complex nature of its development environment and maintenance have led us to reassess its value proposition. This proposal outlines these issues with an aim to deprecate Aragon UI in favor of a more simple and efficient solution. Disclaimer. It's essential to clarify that our proposal pertains solely to the Aragon UI, the web dashboard interface including Aragon Client, standard Aragon apps and Lido Aragon apps. This proposal does not encompass or impact the Aragon contracts currently embedded within our protocol. Those remain integral to the protocol architecture and are not part of this re-evaluation. About Aragon UI Aragon UI has been our immediate touchpoint for decoding the state of the protocol. Previously, it was also used as a DAO voting interface. Since then, we have developed our custom DAO Voting UI which offer a much smoother user experience, rendering the Aragon Voting app inferior and redundant. Additionally, in its earlier versions, Aragon UI also incorporated state-changing levers but these were used only occasionally for testnet purposes. For mainnet operations, state changes are handled through omnibus voting scripts, eliminating the need for these management functions in the Aragon UI. Issues with Aragon UI 1. Intricate Development Environment Setup

Both Hardhat and Ape are popular frameworks within the Ethereum development community. They provide tools and features that facilitate smart contract development, deployment, and interaction. This report aims to present an in-depth comparison of these two frameworks to help Lido-on-Ethereum engineering teams make an informed choice. Background While working on Lido V2, Lido-on-Ethereum team recognized a series of pain points that need urgent attention. Our existing infrastructure, namely lido-dao and scripts, while functional, has revealed some clear areas for improvement. Addressing these will not only boost our productivity but also enhance the quality of our deployments and voting process. This necessitates evaluating tools and frameworks that can alleviate these issues. Among the potential candidates are Hardhat and Ape Ethereum development frameworks. Before diving into the comparative analysis of these two platforms, let's shed light on the specific challenges we currently face: For Contract Development: Deploy Whack-a-mole: We're constantly troubleshooting deployment issues, making the process unpredictable and time-consuming. Lack of Conventions or Style Guide: The absence of a unified style guide or convention has led to inconsistencies in code, making collaboration and review processes more challenging. Poor Test Structure: Our current test structure lacks organization and clarity, which affects maintainability and comprehension.

wstETH bridging questionnaire Purpose The following questionnaire is provided to evaluate wstETH bridges designs and security surfaces on L2s and other chains to provide a technical background for "blessings and co-marketing" governance proposals towards the Lido DAO. Suggested outputs The desired outcome is: to have the statements and answers listed inside README.md for every wstETH bridge design repo to have the audit report with an explicit confirmation of the statements

Lido, as part of the community, thinks of Ethereum as a credibly neutral home for applications and their users. The mission of Lido on Ethereum is to provide a secure and accessible staking platform and contribute to Ethereum's decentralization. Lido is firmly committed to diversifying the validator set, which should reduce the risk of downtime or censorship while retaining network performance. With this goal, we, the dev team, present Staking Router, a major protocol update, moving the operator registry to a modular architecture. This design would allow for experiments with different approaches and principles for building validator sets, including solo and DVT validators, without significant changes to the underlying protocol. The Staking Router brings Lido's vision of creating a platform for stakers, developers, and node operators to collaborate and advance the future of decentralized staking to reality. We invite teams and individual contributors to build with us. Glossary Aragon is a DAO framework used by Lido on Ethereum; AragonApp is a base utility contract from Aragon; Aragon Voting is a DAO voting application;

After a major upgrade, the Lido V2 protocol now spans 50+ contracts: some updated implementations, others are completely new. This means that many of the labels and tags on Etherscan are now outdated or absent. We, Lido-on-Ethereum contributors, kindly request to update the labels and tags according to the table provided below in order to increase transparency and accessibility of the protocol, as well as to improve Etherscan user experience. Please let us know if the preferred labels and tags do not comply with Etherscan's conventions. Contract Address Type Current label Preferred label Preferred tags

Lido Oracle Specification (Outdated) Oracle daemon (further Oracle) for Lido stacking protocol collects, make some decisions and reports Consensus and Execution Layer data to Lido Oracle smart contract. Depends in which mode Oracle is running it reports validator's balances on Consensus Layer, skimmed rewards, withdrawal requests and validators to eject. Validators ejection works separately from main oracle report. It could happen more often, depends on Oracle contract setup and withdrawals activity. New Oracle will contain 3 modules: Accounting - Makes decisions about protocol day-to-day operations.How much balance on Consensus Layer. How much Lido validators running and exited. How much ETH do we have to fulfill withdrawal requests. How much ETH we should block on deposit contract for withdrawals.

Lido on Ethereum V2 upgrade template. Audit scope Created: 2022-03-10 Updated: 2023-04-12 Simple summary A single contract to be used for the Lido DAO Aragon vote that performs on-chain actions for the Lido V1→V2 upgrade on behalf of the Lido DAO. Context Lido V2 upgrade changes almost every previously deployed contract and adds new ones. From the prospects of the governance process, an on-chain vote for the upgrade should perform an atomic (all or nothing) transition. The upgrade template encompasses migrations, permissions granting procedures, and overall protocol integrity checks.

This guide describes how to migrate from Council daemon v1 to Council daemon v2. This guide is for the Goerli test network. Table of contents Changelog Overview Step by step guide Changelog Staking Router support

On March 24, Lido protocol on Goerli testnet has been successfully upgraded to V2. This document is intended for Lido's existing partners and developers looking to understand the scope of the upgrade in terms of how their product interacts with Lido protocol. A high-level upgrade overview can be found in the blog post. The code of the upgrade is open and available on Lido's GitHub. You can find all the changes in this PR. The addresses of all the contracts deployed on Goerli are listed on the Lido's docs hub. Lido UI has also been upgraded to V2 and is now being tested at https://stake.testnet.fi/ Deposit flow No changes has been done to the deposit flow. All the addresses, calls, methods and events remain the same as before the protocol upgrade.