Lido on Ethereum Scorecard

Lido on Ethereum Scorecard

Where we’re already succeeding

Lido on Ethereum Scorecard

Scorecard AttributeCategorySelf-AssessmentComment
Legally and physically unrelated
Validator set
Good
Operators run their own nodes (no white-labeling)
Validator set
Good
Good performance
Validator set
Good
Operators should earn well enough to build a profitable, dependable business on staking
Validator set
Good
Lido’s hostile takeover via a hard fork is possible
Security
Good
As discussed in our The Next Chapter for Lido article, as a very last resort (in the case of governance capture) we have made it trivial for Ethereum core developers to revoke Lido’s current permissions and transfer them to a community-owned contract.
Lido can’t change validator set at will
Governance
Good
Lido currently only has soft power over its Node Operators. Withdrawals and triggerable exits will change this balance, but at the same time permissionless elements will be added to the validator set.

Where we’re doing well, but can improve

Lido on Ethereum Scorecard

Scorecard AttributeCategorySelf-AssessmentComment
No operators with over 1% of total stake of Ethereum through Lido
Validator set
Okay
A few operators between 1% and 2%
Distributed geographically and jurisdictionally
Validator set
Okay
Overreliant on Europe and USA
Distributed variation of on-premise infra and different cloud providers
Validator set
Okay
Not enough on-premise infra setups
Best practices in security and key management
Validator set
Okay
Threshold based validation would be more robust
Client Diversity
Validator set
Okay
Prysm is not the dominant client in Lido (>58% minority client usage), but share of smaller clients could be higher. Additionally, more work to be done on Execution Layer client diversification
Lido’s smart contracts have the best security possible
Security
Okay
Thorough and multiple audits are undertaken on all smart contract upgrades, but no formal verification or symbolic execution based tests
Withdrawals are non-custodial and trustless
Security
Okay
Lido validators until July 2021 were created with threshold signature BLS withdrawal credentials; as of July 2021, Lido validators are on smart contract withdrawal credentials. The percentage of all Lido validators with threshold BLS withdrawal credentials is ~15% and steadily decreasing as new validators are added. Lido intends on rotating these validators to 0x01 (smart contract) withdrawal credentials as soon as possible, i.e. with the Capella Hardfork . The current Lido withdrawal smart contract is a stub, and will be upgraded to a fully-functioning withdrawal contract once the withdrawal specs are finalized.

Where our next priorities lie

Lido on Ethereum Scorecard

Scorecard AttributeCategorySelf-AssessmentComment
Lido governance has significant safeguards
Governance
Needs Improvement
Currently, there is no timelock between DAO vote finalization and execution. Lido is actively working on implementing more safeguards to the governance process.
There’s a robust set of Lido governance delegates
Governance
Needs Improvement
Lido DAO currently has vote delegation for Snapshot votes; however, the delegate set is limited and significant amount of voting power is undelegated and dormant. Lido is working on improving the delegate set and educating DAO members about vote delegation.
Delegation is enabled in onchain Lido governance
Governance
Needs Improvement
Currently, delegation is only enabled for Snapshot votes. Lido is actively researching possible mechanics for onchain delegation.
There's a way for new operators to enter the set and prove themselves
Validator market
Needs Improvement
Lido is actively researching ways to allow permissionless operators to join its validator set, including working with SSV Network and Obol on DVT, as well as exploring ways for solo stakers to participate in the protocol.
There's a way to reduce stake to operators who do not conform to Lido standards
Validator market
Needs Improvement
Lido is working on stake (re-)allocation mechanisms based on performance and off-chain attributes, as well as developing and lobbying for solutions to allow for penalizing malicious actors (e.g. triggerable exits).

Want to contribute to the discussion or workgroups related to the above priorities?