LIP-25: Staking Router 2.0

The proposal for Lido Staking Router 2.0 (SR) upgrade includes improvements to both on- and off-chain parts of the following components:

• the Deposit Security Module (DSM)
• the Validator Exit Bus Oracle (VEBO)
• the Accounting Oracle (AO)
• and reward distribution mechanisms in curated-based staking router modules.

If the DAO approves it, the new SR upgrade will be included in the further on-chain vote to be applied to the Lido protocol. Off-chain parts needed to support on-chain changes will be deployed just before the on-chain vote.

TL;DR

Lido ValSet stream contributors propose to improve the Staking Router in multiple ways:

• automate key vetting and unvetting (the process of ensuring only safely depositable keys are under limit) and handling of cases such as incorrect signatures, duplicate keys, and deposits front-run within Deposit Security Module;
• allow staking router modules to signal Validator Exit Bus Oracle to exit validators independently of withdrawal requests using a new boosted exit mode;
• adjust validator exit prioritization to account for each module’s target share for Validator Exit Bus Oracle;
• and scale reporting and decouple reward distribution for Accounting Oracle 3rd phase report.

It is proposed to change on-chain contracts and off-chain parts of the Staking Router.

Motivation

1. In the current implementation of the curated Staking Router modules, key vetting (the process of validating keys before making them depositable) occurs through DAO actions, and in particular Easy Track motions, which operators may initiate after submitting keys or via full on-chain DAO votes. The proposed DSM changes aim to improve the process of key vetting to be able to work without requiring governance approval and to accommodate future permissionless modules
2. The current VEBO mechanism only processes validator exits in response to user withdrawal requests. This limitation hinders the protocol’s ability to manage validator exits proactively, especially for future permissionless modules (like Community Staking Module), and thus an improvement is proposed to allow for exits for reasons other than withdrawal requests. From the Staking Router side, it is also proposed to consider a module’s share exceeding some threshold when prioritizing (ordering) validators for exit.
3. The introduction of the Community Staking Module, which does not limit the number of node operators, necessitates a scalable solution for the Accounting Oracle’s third phase report.
4. Current reward distribution mechanisms, tied to the third phase Accounting Oracle finalization hook, risk exceeding block gas limits and complicate the reporting process, so an improvement is proposed to add permissionless on-chain method to handle reward distribution independently of Accounting Oracle’s third-phase report.

Research forum post with more details can be found here

The contract specification details can be found in the LIP-25.

Next steps

• MixBytes and Ackee teams are conducting the smart contract audits and deploy verification for the upgrade. Also MixBytes will be auditing the off-chain Oracle code. Once finalized, the reports will be published on the Research forum.
• If this snapshot vote is approved, the on-chain voting will occur after all audits and security checks successfully completed. An improved Staking Router 2.0 will be applied to the protocol with all the proposed changes.