Overview
Since the launch of Lido protocol in December 2020, the protocol has seen exceptional growth and cemented itself as the leading liquid staking protocol, amassing over 8M ETH staked, equivalent to 32% market share.
In recent times, Lido has made significant strides with the launch of V2, introducing new functionalities such as withdrawals and the innovative Staking Router concept. Whilst V1 was grounded in a Curated Operator set, the Lido V2 iteration transforms the platform into a modular stake allocation marketplace, backed by the DAO’s governance.
At its very core, the Staking Router consolidates Lido’s vision, unifying stakers, developers and node operators to foster a decentralised Ethereum ecosystem. In addition to simplifying stake management, Lido V2 has adopted Distributed Validator Technology (DVT) to distribute validators across multiple machines, enhancing resilience and reducing single points of failure.This is done by fragmenting the validator's private key and distributing it across a network of computers; this setup complicates attacks and provides fault tolerance, ensuring the network remains robust even if some nodes go offline. The evolution highlights Lido’s commitment to achieving a robust Ethereum validator set without compromising on quality, security and decentralisation.
Since the launch of Lido protocol in December 2020, the protocol has seen exceptional growth and cemented itself as the leading liquid staking protocol, amassing over 8M ETH staked, equivalent to 32% market share.
In recent times, Lido has made significant strides with the launch of V2, introducing new functionalities such as withdrawals and the innovative Staking Router concept. Whilst V1 was grounded in a Curated Operator set, the Lido V2 iteration transforms the platform into a modular stake allocation marketplace, backed by the DAO’s governance.
At its very core, the Staking Router consolidates Lido’s vision, unifying stakers, developers and node operators to foster a decentralised Ethereum ecosystem. In addition to simplifying stake management, Lido V2 has adopted Distributed Validator Technology (DVT) to distribute validators across multiple machines, enhancing resilience and reducing single points of failure.This is done by fragmenting the validator's private key and distributing it across a network of computers; this setup complicates attacks and provides fault tolerance, ensuring the network remains robust even if some nodes go offline. The evolution highlights Lido’s commitment to achieving a robust Ethereum validator set without compromising on quality, security and decentralisation.
Diagram from Lido
Lido v1
Before delving into V2 we will take a closer look at the functionalities of v1
Ethereum’s Path
When a user deposits ETH into Lido's contract, they receive a proportional portion of Lido's total stETH pool. The stETH pool's size can increase from consensus and execution layer rewards or decrease due to slashing penalties. Consequently, the value of a user's stETH share can either rise or fall. Before staking, the deposited Ether is stored in the Lido contract's balance, commonly referred to as "buffered" or in the "deposit buffer", it awaits transfer to the deposit contract.
Providing ETH from the user’s point of view;
Before delving into V2 we will take a closer look at the functionalities of v1
Ethereum’s Path
When a user deposits ETH into Lido's contract, they receive a proportional portion of Lido's total stETH pool. The stETH pool's size can increase from consensus and execution layer rewards or decrease due to slashing penalties. Consequently, the value of a user's stETH share can either rise or fall. Before staking, the deposited Ether is stored in the Lido contract's balance, commonly referred to as "buffered" or in the "deposit buffer", it awaits transfer to the deposit contract.
Providing ETH from the user’s point of view;
Balance Synchronisation and Oracles
One of Lido's key functions is to keep the total validator balances aligned with the stETH supply, this way 1 stETH = 1 ETH. To do this, it uses oracles that update the Lido contract to reflect changes in validator balances. Oracles are used due to the fact that the consensus and execution layers are separate. These updates usually occur daily.
Reward Distribution
Users get 90% of all rewards earned by validators. The remaining 10% is a protocol fee, half of which goes to the treasury and the other 5% to node operators.
One of Lido's key functions is to keep the total validator balances aligned with the stETH supply, this way 1 stETH = 1 ETH. To do this, it uses oracles that update the Lido contract to reflect changes in validator balances. Oracles are used due to the fact that the consensus and execution layers are separate. These updates usually occur daily.
Reward Distribution
Users get 90% of all rewards earned by validators. The remaining 10% is a protocol fee, half of which goes to the treasury and the other 5% to node operators.
Key management and Validator Activation
After approval, the node operator is included in NodeOperatorsRegistry and can add their signing keys to this contract. These keys, once sent to the DepositContract, place the corresponding validators in an activation queue. After activation, these validators join the consensus process.
Staking Limits
While there isn’t a cap on the number of keys a node operator can submit, Lido sets staking limits for each one. This means each operator can only have a certain number of approved keys and is restricted to initiating a limited number of validators. These limits can be changed through Aragon Voting or EasyTrack mechanisms.
Evolution of Deposit Security Overview
Deposits to the DepositContract require withdrawal credentials (WC) so that only authorised parties can withdraw funds in the future. All Lido deposits use Lido-approved WC to make sure only Lido can access user funds.
During Oct 2021, a vulnerability was discovered that allowed a bad acting Node Operator to intercept user funds on deposits to the Beacon Chain. This vulnerability was achieved by the malicious Node Operator front running the Lido.depositBufferedEther function by directly depositing at least 1 ETH to the deposit contract using the same validator key but different withdrawal credentials to Lido subsequently allowing them to gain control of the 32 ETH from Lido. Thereafter the LIP-5 was raised to fix this deposit front-running vulnerability in which we saw the advent of the Guardian Committee.
Guardian Committee's Role:
Before making a batch deposit, a guardian committee checks for any malicious pre-deposits. They sign a message containing:
- The Merkle root of all deposits, depositRoot from DepositContract
- A nonce of key operations; keyOpsIndex from NodeOperatorsRegistry
- Block number
- Block hash
The depositor bot then proceeds to submit these messages to DepsoitSecurityContract. Here, the guardian signatures are verified and confirm the block with the specified number contains the specified hash.
After approval, the node operator is included in NodeOperatorsRegistry and can add their signing keys to this contract. These keys, once sent to the DepositContract, place the corresponding validators in an activation queue. After activation, these validators join the consensus process.
Staking Limits
While there isn’t a cap on the number of keys a node operator can submit, Lido sets staking limits for each one. This means each operator can only have a certain number of approved keys and is restricted to initiating a limited number of validators. These limits can be changed through Aragon Voting or EasyTrack mechanisms.
Evolution of Deposit Security Overview
Deposits to the DepositContract require withdrawal credentials (WC) so that only authorised parties can withdraw funds in the future. All Lido deposits use Lido-approved WC to make sure only Lido can access user funds.
During Oct 2021, a vulnerability was discovered that allowed a bad acting Node Operator to intercept user funds on deposits to the Beacon Chain. This vulnerability was achieved by the malicious Node Operator front running the Lido.depositBufferedEther function by directly depositing at least 1 ETH to the deposit contract using the same validator key but different withdrawal credentials to Lido subsequently allowing them to gain control of the 32 ETH from Lido. Thereafter the LIP-5 was raised to fix this deposit front-running vulnerability in which we saw the advent of the Guardian Committee.
Guardian Committee's Role:
Before making a batch deposit, a guardian committee checks for any malicious pre-deposits. They sign a message containing:
- The Merkle root of all deposits, depositRoot from DepositContract
- A nonce of key operations; keyOpsIndex from NodeOperatorsRegistry
- Block number
- Block hash
The depositor bot then proceeds to submit these messages to DepsoitSecurityContract. Here, the guardian signatures are verified and confirm the block with the specified number contains the specified hash.
Lido V2 Overview
Lido V2 introduces enhanced features, including a user withdrawal option. Building on V1's Curated Node Operator Registry, it now incorporates a StakingRouter, transforming Lido into a stake allocation marketplace with diverse staking modules.
Withdrawal Option: Lido V2 introduced the capability for users to withdraw.
StakingRouter Introduction: The previous Curated Node Operator Registry in V1 will now be encapsulated into a modular system via the StakingRouter.
Modular Transformation: Lido now functions more akin to a stake allocation marketplace, granting users a variety of staking choices or modules.
Module Management: The DAO oversees the stake allocations to newer modules as they are incorporated.
Default delegation Layer on top of Ethereum: Lido v2 provides a marketplace for delegation across several profiles of validators instead of just pro validators.
Providing ETH from the user’s point of view;
Lido V2 introduces enhanced features, including a user withdrawal option. Building on V1's Curated Node Operator Registry, it now incorporates a StakingRouter, transforming Lido into a stake allocation marketplace with diverse staking modules.
Withdrawal Option: Lido V2 introduced the capability for users to withdraw.
StakingRouter Introduction: The previous Curated Node Operator Registry in V1 will now be encapsulated into a modular system via the StakingRouter.
Modular Transformation: Lido now functions more akin to a stake allocation marketplace, granting users a variety of staking choices or modules.
Module Management: The DAO oversees the stake allocations to newer modules as they are incorporated.
Default delegation Layer on top of Ethereum: Lido v2 provides a marketplace for delegation across several profiles of validators instead of just pro validators.
Providing ETH from the user’s point of view;
Staking Router Introduction:
The Staking Router is a smart contract that serves as the central manager for different groups of validators. It organises these groups into separate contracts called modules. Each module is responsible for its own set of tasks like managing node operators, storing their digital keys, and allocating stakes and rewards among them.
Although the internal workings of each module may vary widely due to different technologies, they all need to follow a common set of rules, known as an "interface," to interact with the Staking Router. This means that every module must have a standardised way to provide certain types of information, like the digital keys of its validators, so that the Staking Router can coordinate everything smoothly.
When the development team were creating specifications for Staking Router, they considered different kinds of validator groups that could work with it. Amongst these are the following:
1. Curated: These are node operators chosen and managed by a DAO. This is similar to the existing NodeOperatorsRegistry system.
2. Community: These are node operators that anyone can join if they put down a financial bond. The bond amount can be reduced if the operator has a good reputation.
3. DVT: These are special validators that use DVT technology. They might also require a bond. Examples include Obol's Distributed Validator Clusters or SSV nodes.Blockchains disperse responsibility to validators across the globe, DVT provides the opportunity to logically break 1 validator into multiple parties to enhance resilience and minimise single points of failure.
This is achieved by fragmenting the private key securing a validator and distributing it across a network of computers, known as a "cluster". This setup not only complicates the task for attackers trying to access the complete key, as it's not fully stored on any single machine, but also allows for a degree of fault tolerance. If some nodes in the cluster go offline, the remaining nodes can still carry out the necessary signing, thereby bolstering the overall robustness of the validator network.
The Staking Router is a smart contract that serves as the central manager for different groups of validators. It organises these groups into separate contracts called modules. Each module is responsible for its own set of tasks like managing node operators, storing their digital keys, and allocating stakes and rewards among them.
Although the internal workings of each module may vary widely due to different technologies, they all need to follow a common set of rules, known as an "interface," to interact with the Staking Router. This means that every module must have a standardised way to provide certain types of information, like the digital keys of its validators, so that the Staking Router can coordinate everything smoothly.
When the development team were creating specifications for Staking Router, they considered different kinds of validator groups that could work with it. Amongst these are the following:
1. Curated: These are node operators chosen and managed by a DAO. This is similar to the existing NodeOperatorsRegistry system.
2. Community: These are node operators that anyone can join if they put down a financial bond. The bond amount can be reduced if the operator has a good reputation.
3. DVT: These are special validators that use DVT technology. They might also require a bond. Examples include Obol's Distributed Validator Clusters or SSV nodes.Blockchains disperse responsibility to validators across the globe, DVT provides the opportunity to logically break 1 validator into multiple parties to enhance resilience and minimise single points of failure.
This is achieved by fragmenting the private key securing a validator and distributing it across a network of computers, known as a "cluster". This setup not only complicates the task for attackers trying to access the complete key, as it's not fully stored on any single machine, but also allows for a degree of fault tolerance. If some nodes in the cluster go offline, the remaining nodes can still carry out the necessary signing, thereby bolstering the overall robustness of the validator network.
Diagram from
ethereum.org
Key Features of DVT:
- Fault Tolerance: Ensures the validator remains online even if one machine goes offline.
- Enhanced Uptime: With distributed validators, there's the potential to achieve up to 99.9% uptime.
- Beneficial for Solo Stakers: Solo stakers or small-scale operators can benefit as their nodes remain online, even if individual nodes go offline.
- Geographical diversity: Geographic diversity within the validator, comprising clients from different locations, enhances its resilience to various forms of stress.
- Client Diversity: Each validator using DVT could consist of various client implementations to prevent specific bugs from impacting the validator's overall performance. If numerous validators adopt DVT, the network would feature validators composed of diverse clients, which are more resilient, varied, and distributed across different regions of the world.
- Offchain or L2: This is an improved version of the Curated group. It saves money on transaction fees by storing validator keys somewhere other than the main blockchain, like a separate layer or an off-chain database.
Each of these groups has different rules and features, but they're all designed to work with the Staking Router.
The Staking Router is a manager for deposits and future withdrawals across multiple modules, aligned with the objectives set by Lido DAO. Initially, Lido DAO specifies the maximum percentage of active validators each module can have. If a module performs well, its validator capacity can be increased. The overarching goal is to achieve capital efficiency while maintaining both safety and diversity in blockchain validation.
Analogical Explanation (Using Financial Statements):
Pre-Staking Router:
Lido primarily possessed assets in the form of Ethereum staked within a curated validator group. On the liabilities side, there was stETH in a validator set eligible for withdrawal and a surplus. (stETH is a future obligation that the DAO must give back to the user).
Post-Staking Router:
With the advent of the Staking Router, Lido V2 presents a varied asset portfolio featuring assorted validator sets.
- Fault Tolerance: Ensures the validator remains online even if one machine goes offline.
- Enhanced Uptime: With distributed validators, there's the potential to achieve up to 99.9% uptime.
- Beneficial for Solo Stakers: Solo stakers or small-scale operators can benefit as their nodes remain online, even if individual nodes go offline.
- Geographical diversity: Geographic diversity within the validator, comprising clients from different locations, enhances its resilience to various forms of stress.
- Client Diversity: Each validator using DVT could consist of various client implementations to prevent specific bugs from impacting the validator's overall performance. If numerous validators adopt DVT, the network would feature validators composed of diverse clients, which are more resilient, varied, and distributed across different regions of the world.
- Offchain or L2: This is an improved version of the Curated group. It saves money on transaction fees by storing validator keys somewhere other than the main blockchain, like a separate layer or an off-chain database.
Each of these groups has different rules and features, but they're all designed to work with the Staking Router.
The Staking Router is a manager for deposits and future withdrawals across multiple modules, aligned with the objectives set by Lido DAO. Initially, Lido DAO specifies the maximum percentage of active validators each module can have. If a module performs well, its validator capacity can be increased. The overarching goal is to achieve capital efficiency while maintaining both safety and diversity in blockchain validation.
Analogical Explanation (Using Financial Statements):
Pre-Staking Router:
Lido primarily possessed assets in the form of Ethereum staked within a curated validator group. On the liabilities side, there was stETH in a validator set eligible for withdrawal and a surplus. (stETH is a future obligation that the DAO must give back to the user).
Post-Staking Router:
With the advent of the Staking Router, Lido V2 presents a varied asset portfolio featuring assorted validator sets.
Diagram from
adcv
Stake Allocation Algorithm
A new feature is the introduction of a stake allocation algorithm, which determines how to distribute incoming Ether among various modules.This is the main difference in the deposit process. It optimises the use of deposited capital. The Lido contract continues to serve as a deposit buffer, but some of the ether is now transferred to the Staking Router during the deposit process. The Staking Router calculates the ether amount to be allocated to each module and executes the deposits. This is referred to as the stake allocation.
Managing Relative Module Sizing via the Staking Router
To control the proportional sizes of individual modules, the DAO sets a target share for each module that joins, calculated as the percentage of its active validators relative to the overall number across all modules. Concurrently, this target serves as the module's quota, tilting stake allocation towards modules that have fewer deposits. Below we will go through an example of how this operates:
Example:
Modules at the beginning of an allocation round
A new feature is the introduction of a stake allocation algorithm, which determines how to distribute incoming Ether among various modules.This is the main difference in the deposit process. It optimises the use of deposited capital. The Lido contract continues to serve as a deposit buffer, but some of the ether is now transferred to the Staking Router during the deposit process. The Staking Router calculates the ether amount to be allocated to each module and executes the deposits. This is referred to as the stake allocation.
Managing Relative Module Sizing via the Staking Router
To control the proportional sizes of individual modules, the DAO sets a target share for each module that joins, calculated as the percentage of its active validators relative to the overall number across all modules. Concurrently, this target serves as the module's quota, tilting stake allocation towards modules that have fewer deposits. Below we will go through an example of how this operates:
Example:
Modules at the beginning of an allocation round
The above visualisations capture the dynamics of stake allocation in Lido's upgraded architecture. Managed by the Staking Router, the deposit procedure aims to align the current share of each module's active validators with a DAO-imposed target share.
The first chart, "Target vs Current Shares by Module," reveals the initial state of this mechanism. It shows that while the "Community" and "DVT" modules were below their target shares, the "Curated" module was already above its target.
The second chart, "Active Validators and Ready-to-Deposit Keys by Module," further highlights each module's readiness to onboard new validators. Notably, the "Curated" module has a significant number of validators ready for deposit, which as shown below will influence the next allocation round. These charts offer a snapshot of the stake allocation process, showing how the DAO's target shares guide the distribution of ether among the modules.
Target Share: This is a predetermined percentage set by the DAO that dictates how many active validators a particular module should aim to have relative to the total number of active validators across all modules. Essentially, it's a quota or goal for each module to reach and is used to guide the allocation of new validators. The target share is a way to control the proportionate size of each module within the overall system.
Ready-to-Deposit Keys: These are keys that are ready to be activated as validators but have not yet been allocated Ether. They are essentially "waiting in line" to become active validators. These keys can quickly become active validators during the next allocation round, provided enough ether is available in the deposit buffer.
To further understand the entire process, we will go through a specific example below detailing the state of modules after an allocation round.
Modules after the allocation round
Assume there's 32,000 Ether available for adding 1000 new validators. The algorithm begins by allocating Ether to the smallest module first, stopping when one of the following conditions is met:
- The module's size equals the next larger module
- All available validators in the module have been funded
- The module's predefined quota is fulfilled (target share)
If multiple modules are of the same size, have validators ready, and haven't yet met their predefined quotas, the remaining ether is evenly distributed among them until either they reach their capacity or the ether runs out.
Step 1: Calculate Flat Caps
The first step is to calculate the maximum number of validators for each module, known as the "flat caps," based on their target shares.
Flat Cap of a Module = Target Share of the Module × Total Active Validators
Community: Flat Cap = 0.1 x 11000 = 1100 validators
DVT: Flat Cap = 0.2 x 11000 = 2200 validators
Curated: Flat Cap = 0.7 x 11000 = 7700
Validators Step 2: Allocation to Modules
The algorithm then starts by allocating Ether to the smallest module first. It stops when either the module reaches its flat cap, all ready validators are covered, or the target share is reached.
Community Module
- Flat Cap: 1100 validators
- Already Active Validators: 700
- Ready Validators: 300Ether
- Required: 300 × Ether per Validator = 9600
Initial State: At the start of the allocation process, the Community module had 700 active validators and 300 ready-to-deposit keys.
Ether Requirement: To convert these 300 ready-to-deposit keys into active validators, the Community module required 300×32 = 9,600 ether.
Allocation Outcome: The algorithm allocated the required 9,600 ether to the Community module, allowing all 300 ready-to-deposit keys to become active validators.Final State: With this allocation, the Community module ended up with a total of 1,000 active validators, which is within its flat cap of 1,100 validators.
This means the Community module successfully onboarded all its ready validators without exceeding its target share.
DVT Module
- Flat Cap: 2200 validators
- Already Active Validators: 1800
- Ready Validators: 500Ether
- Required: 400 × Ether per Validator = 12800
In this instance we have a flat cap of 2200 validators with 1800 already active and 500 ready. 2200-1800 = 400 ready to deposit keys that can be onboarded as active validators without exceeding the Flat Cap. Therefore, 100 ready validators will be left for the next allocation.
Curated Module
- Flat Cap: 7700 validators
- Already Active Validators: 7500
- Ready Validators: 2000Ether
- Required: 400 × Ether per Validator = 9600
In this final instance we have a flat cap of 7700 validators with 7500 already active and 2000 ready.7700-7500 = 200 ready to deposit keys that can be onboarded as active validators without exceeding the Flat Cap. Therefore, 1800 ready validators will be left for future allocations
Step 3: Spill Over
Spill Over = Initial Deposit Buffer - Total Allocated Ether
For example, the spill over would be 32000 - (9600 + 12800 + 9600) = 0
There is no spill over into the next round
Modules Post Allocation Round:
The first chart, "Target vs Current Shares by Module," reveals the initial state of this mechanism. It shows that while the "Community" and "DVT" modules were below their target shares, the "Curated" module was already above its target.
The second chart, "Active Validators and Ready-to-Deposit Keys by Module," further highlights each module's readiness to onboard new validators. Notably, the "Curated" module has a significant number of validators ready for deposit, which as shown below will influence the next allocation round. These charts offer a snapshot of the stake allocation process, showing how the DAO's target shares guide the distribution of ether among the modules.
Target Share: This is a predetermined percentage set by the DAO that dictates how many active validators a particular module should aim to have relative to the total number of active validators across all modules. Essentially, it's a quota or goal for each module to reach and is used to guide the allocation of new validators. The target share is a way to control the proportionate size of each module within the overall system.
Ready-to-Deposit Keys: These are keys that are ready to be activated as validators but have not yet been allocated Ether. They are essentially "waiting in line" to become active validators. These keys can quickly become active validators during the next allocation round, provided enough ether is available in the deposit buffer.
To further understand the entire process, we will go through a specific example below detailing the state of modules after an allocation round.
Modules after the allocation round
Assume there's 32,000 Ether available for adding 1000 new validators. The algorithm begins by allocating Ether to the smallest module first, stopping when one of the following conditions is met:
- The module's size equals the next larger module
- All available validators in the module have been funded
- The module's predefined quota is fulfilled (target share)
If multiple modules are of the same size, have validators ready, and haven't yet met their predefined quotas, the remaining ether is evenly distributed among them until either they reach their capacity or the ether runs out.
Step 1: Calculate Flat Caps
The first step is to calculate the maximum number of validators for each module, known as the "flat caps," based on their target shares.
Flat Cap of a Module = Target Share of the Module × Total Active Validators
Community: Flat Cap = 0.1 x 11000 = 1100 validators
DVT: Flat Cap = 0.2 x 11000 = 2200 validators
Curated: Flat Cap = 0.7 x 11000 = 7700
Validators Step 2: Allocation to Modules
The algorithm then starts by allocating Ether to the smallest module first. It stops when either the module reaches its flat cap, all ready validators are covered, or the target share is reached.
Community Module
- Flat Cap: 1100 validators
- Already Active Validators: 700
- Ready Validators: 300Ether
- Required: 300 × Ether per Validator = 9600
Initial State: At the start of the allocation process, the Community module had 700 active validators and 300 ready-to-deposit keys.
Ether Requirement: To convert these 300 ready-to-deposit keys into active validators, the Community module required 300×32 = 9,600 ether.
Allocation Outcome: The algorithm allocated the required 9,600 ether to the Community module, allowing all 300 ready-to-deposit keys to become active validators.Final State: With this allocation, the Community module ended up with a total of 1,000 active validators, which is within its flat cap of 1,100 validators.
This means the Community module successfully onboarded all its ready validators without exceeding its target share.
DVT Module
- Flat Cap: 2200 validators
- Already Active Validators: 1800
- Ready Validators: 500Ether
- Required: 400 × Ether per Validator = 12800
In this instance we have a flat cap of 2200 validators with 1800 already active and 500 ready. 2200-1800 = 400 ready to deposit keys that can be onboarded as active validators without exceeding the Flat Cap. Therefore, 100 ready validators will be left for the next allocation.
Curated Module
- Flat Cap: 7700 validators
- Already Active Validators: 7500
- Ready Validators: 2000Ether
- Required: 400 × Ether per Validator = 9600
In this final instance we have a flat cap of 7700 validators with 7500 already active and 2000 ready.7700-7500 = 200 ready to deposit keys that can be onboarded as active validators without exceeding the Flat Cap. Therefore, 1800 ready validators will be left for future allocations
Step 3: Spill Over
Spill Over = Initial Deposit Buffer - Total Allocated Ether
For example, the spill over would be 32000 - (9600 + 12800 + 9600) = 0
There is no spill over into the next round
Modules Post Allocation Round:
The first chart, "Target vs Current Shares by Module (After Allocation)," showcases the algorithm's success in aligning each module's share of active validators with its DAO-imposed target. This alignment is a cornerstone in maximising capital efficiency and ensuring a balanced flow of ether across modules.
The second chart, "Active Validators and Ready-to-Deposit Keys by Module (After Allocation)," provides insights into each module's capacity post-allocation. Here, we observe that the "Community" and "DVT" modules have nearly reached their flat caps, while the "Curated" module retains room for growth.
These visualisations collectively validate the algorithm's ability to adapt in real-time, ensuring minimal idle ether and facilitating a move toward target shares.
Curated module
The existing "NodeOperatorsRegistry" becomes the "Curated module." This means it needs to fit into a new format, called the "module interface." However, the basic design of this registry won't change.
Fee Distribution
Rewards are distributed evenly across all modules based on the number of active validators and fee settings. Lido DAO has the flexibility to set different treasury fees for each module, which can enable some new and innovative strategies for Lido to gain stake.
Each module has its own way of setting fees, which consist of two parts:
1. Fee for the module
2. Separate fee for the treasury.
As an illustration, the module might charge a 5% fee that is divided among the node operators in that module, and another 5% fee that goes directly to the treasury.
The system uses a high-precision factor (multiplier of 100 × 10^8) when calculating fees. This is done to ensure that the fees for smaller modules aren't rounded down.
The system does not look at individual validator performance for distributing fees. Instead, it divides the fees among modules based on the number of active validators and the fee rate set by each module. This also has the effect of making stETH fully fungible, despite having the ETH backing deposited in different modules.
Example: A Module with 75% of all active validators and a 5% fee;
The second chart, "Active Validators and Ready-to-Deposit Keys by Module (After Allocation)," provides insights into each module's capacity post-allocation. Here, we observe that the "Community" and "DVT" modules have nearly reached their flat caps, while the "Curated" module retains room for growth.
These visualisations collectively validate the algorithm's ability to adapt in real-time, ensuring minimal idle ether and facilitating a move toward target shares.
Curated module
The existing "NodeOperatorsRegistry" becomes the "Curated module." This means it needs to fit into a new format, called the "module interface." However, the basic design of this registry won't change.
Fee Distribution
Rewards are distributed evenly across all modules based on the number of active validators and fee settings. Lido DAO has the flexibility to set different treasury fees for each module, which can enable some new and innovative strategies for Lido to gain stake.
Each module has its own way of setting fees, which consist of two parts:
1. Fee for the module
2. Separate fee for the treasury.
As an illustration, the module might charge a 5% fee that is divided among the node operators in that module, and another 5% fee that goes directly to the treasury.
The system uses a high-precision factor (multiplier of 100 × 10^8) when calculating fees. This is done to ensure that the fees for smaller modules aren't rounded down.
The system does not look at individual validator performance for distributing fees. Instead, it divides the fees among modules based on the number of active validators and the fee rate set by each module. This also has the effect of making stETH fully fungible, despite having the ETH backing deposited in different modules.
Example: A Module with 75% of all active validators and a 5% fee;
Provided the combined module and treasury fees are below 10%, the total fee taken by the protocol will not exceed 10%, irrespective of the number of modules.
There's a special scenario where a module might be paused due to some emergency, even though its validators are still active. In this case, the module's fees are sent to the treasury.
Once the module is operational again, these fees are returned to it from the treasury.
Below details a more granular view of the fee distribution function and includes a flow chart of the process.
The distribution function does the following:
1. Initial Setup: It loads data about the current staking modules and counts them.
2. Empty Case: If there are no staking modules or no one is actively validating transactions, the function simply returns an empty response
3. Initialize Variables: If there are active modules and validators, it sets up arrays to keep track of module IDs, who gets rewards, and how much those rewards are. It also sets a constant to measure fee precision called FEE_PRECISION_POINTS.
4. Loop through Modules: For each active staking module, the function does several things:
- Saves its ID and the address of who gets the rewards.
- Figures out what percentage of total active validators are in this module.
- Calculates the module's fee based on its share of active validators. If the module is running, this fee is stored.
- Adds the module's fee plus a treasury fee to a running total.
5. Check Total Fee: After going through all modules, it checks that the total fee isn't more than 100%.
6. Clean Up: If some modules had zero active validators, their data is removed from the arrays.
Return Values: Finally, it returns data structures of who gets rewards; module IDs, the fees, the total fee, and the fee precision constant.
It gives a snapshot of how rewards are divided among participants.
There's a special scenario where a module might be paused due to some emergency, even though its validators are still active. In this case, the module's fees are sent to the treasury.
Once the module is operational again, these fees are returned to it from the treasury.
Below details a more granular view of the fee distribution function and includes a flow chart of the process.
The distribution function does the following:
1. Initial Setup: It loads data about the current staking modules and counts them.
2. Empty Case: If there are no staking modules or no one is actively validating transactions, the function simply returns an empty response
3. Initialize Variables: If there are active modules and validators, it sets up arrays to keep track of module IDs, who gets rewards, and how much those rewards are. It also sets a constant to measure fee precision called FEE_PRECISION_POINTS.
4. Loop through Modules: For each active staking module, the function does several things:
- Saves its ID and the address of who gets the rewards.
- Figures out what percentage of total active validators are in this module.
- Calculates the module's fee based on its share of active validators. If the module is running, this fee is stored.
- Adds the module's fee plus a treasury fee to a running total.
5. Check Total Fee: After going through all modules, it checks that the total fee isn't more than 100%.
6. Clean Up: If some modules had zero active validators, their data is removed from the arrays.
Return Values: Finally, it returns data structures of who gets rewards; module IDs, the fees, the total fee, and the fee precision constant.
It gives a snapshot of how rewards are divided among participants.
Future Modules Direction
The team has focused on immediate design decisions until now. In the next version of Staking Router, they plan to prioritise three key features:
1. Support for bonds;
Modules like Community and DVT need operators to provide bonds as collateral, partly funded by Lido's pool. Until a complete bond system is ready, these bonds can be turned into stETH. This interim solution has risks during mass-slashing events but can be managed off-chain through an insurance fund. Two temporary options exist for handling stETH-based bonds: either distribute slashing penalties across the protocol or have an insurance fund cover them. Plans are in progress to create a true bond system that adjusts rewards and penalties based on individual performance.
2. Integration of withdrawals into the stake-balancing algorithm;
In addition to the balancing algorithms discussed earlier, the Staking Router can use a strategy to remove active validators and align modules with the DAO's target shares. This will aid each module in achieving its target share of stake
3. Compatibility with L2 and off-chain modules.
Despite anticipated interoperability challenges the Staking Router will accommodate L2 modules. Minimal interface needs will allow ease of integration for these modules. As a result of the design process the only required information for each module consists of: total, active, stopped and exited keys. It is also expected that there will be future feature requests from contributors and stakeholders.
Conclusion
Lido V2 represents a significant upgrade, incorporating a variety of features aimed at enhancing user experience, capital efficiency, and security. The introduction of the StakingRouter transforms Lido into a modular stake allocation marketplace, allowing for more diversified staking options. This is complemented by a new stake allocation algorithm designed to optimise the distribution of incoming deposits across different modules. DVT technology and new fee distribution mechanisms add layers of resilience and financial incentive to the system. With future updates focused on bond support, withdrawal integrations, and Layer 2 compatibility, Lido is well-positioned to continue positively shaping Ethereum staking by emphasising decentralisation, performance, and broader participation.
References & Further Reading:
ADR: Staking Router, Lido
Contracts: Staking Router, Lido
Distributed validator technology, ethereum.org.
How DVT Helps: Liquid Staking Protocols, Obol
Lido V2 — What’s the difference?, Blockworks
The Staking Router + DVT: A Seismic Change for LSTs, Blockworks
stETH is the decentralized reserve currency for the sovereign internet, adcv
The team has focused on immediate design decisions until now. In the next version of Staking Router, they plan to prioritise three key features:
1. Support for bonds;
Modules like Community and DVT need operators to provide bonds as collateral, partly funded by Lido's pool. Until a complete bond system is ready, these bonds can be turned into stETH. This interim solution has risks during mass-slashing events but can be managed off-chain through an insurance fund. Two temporary options exist for handling stETH-based bonds: either distribute slashing penalties across the protocol or have an insurance fund cover them. Plans are in progress to create a true bond system that adjusts rewards and penalties based on individual performance.
2. Integration of withdrawals into the stake-balancing algorithm;
In addition to the balancing algorithms discussed earlier, the Staking Router can use a strategy to remove active validators and align modules with the DAO's target shares. This will aid each module in achieving its target share of stake
3. Compatibility with L2 and off-chain modules.
Despite anticipated interoperability challenges the Staking Router will accommodate L2 modules. Minimal interface needs will allow ease of integration for these modules. As a result of the design process the only required information for each module consists of: total, active, stopped and exited keys. It is also expected that there will be future feature requests from contributors and stakeholders.
Conclusion
Lido V2 represents a significant upgrade, incorporating a variety of features aimed at enhancing user experience, capital efficiency, and security. The introduction of the StakingRouter transforms Lido into a modular stake allocation marketplace, allowing for more diversified staking options. This is complemented by a new stake allocation algorithm designed to optimise the distribution of incoming deposits across different modules. DVT technology and new fee distribution mechanisms add layers of resilience and financial incentive to the system. With future updates focused on bond support, withdrawal integrations, and Layer 2 compatibility, Lido is well-positioned to continue positively shaping Ethereum staking by emphasising decentralisation, performance, and broader participation.
References & Further Reading:
ADR: Staking Router, Lido
Contracts: Staking Router, Lido
Distributed validator technology, ethereum.org.
How DVT Helps: Liquid Staking Protocols, Obol
Lido V2 — What’s the difference?, Blockworks
The Staking Router + DVT: A Seismic Change for LSTs, Blockworks
stETH is the decentralized reserve currency for the sovereign internet, adcv
Disclaimer:
The information and services above are not intended to and shall not be used as investment advice.You should consult with financial advisors before acting on any of the information and services. ASXN and ASXN staff are not investment advisors, do not represent or advise clients in any matter and are not bound by the professional responsibilities and duties of a financial advisor.Nothing in the information and service, nor any receipt or use of such information or services, shall be construed or relied on as advertising or soliciting to provide any financial services.
The information and services above are not intended to and shall not be used as investment advice.You should consult with financial advisors before acting on any of the information and services. ASXN and ASXN staff are not investment advisors, do not represent or advise clients in any matter and are not bound by the professional responsibilities and duties of a financial advisor.Nothing in the information and service, nor any receipt or use of such information or services, shall be construed or relied on as advertising or soliciting to provide any financial services.