Lido Community Staking Module (CSM) is a permissionless module allowing community stakers to operate Ethereum validators with lower entry costs. Stakers provide stETH bonds, serving as security collateral, and receive rewards in the form of bond rebase and staking rewards (including execution layer rewards), which are socialized across Lido’s staking modules. Lido Staking Router (SR) V2 is a component that utilizes a modular design with support for staking modules like CSM.
Ackee Blockchain Security assigned two specialized teams to audit the Lido CSM update, with one focusing on the Community Staking Module (CSM) and the other on the Staking Router (SR). The Lido CSM update itself is divided into two parts: new contracts for the CSM codebase in a separate repository and changes to existing core contracts, such as the SR. To ensure a thorough and efficient review, the respective teams audited these two parts in parallel, each addressing the security aspects of both CSM and SR.
Across both reports, Ackee Blockchain Security discovered 46 issues which resulted in 32 fixes by Lido Finance.
Lido Finance engaged Ackee Blockchain Security to perform a security review of the Lido Finance Community Staking Module for a total of 74 engineering days in a period between July 16 and September 6, 2024.
Lido Finance also engaged Ackee Blockchain Security to perform a security review of the Lido Finance Staking Router for a total of 26 engineering days in a period between July 22 and August 23, 2024.
Both time donations included Fuzzing with Wake Framework. The audit resulted in 7831 lines of fuzz tests, 58 execution flows, and 36 stateful invariants. All tests have been pushed public to the awesome-wake-tests repo. The audit of CSM and SR contained 5256 and 3434 lines of code, respectively.
METHODOLOGY
The CSM methodology includes the review, implementation and execution of manually-guided differential stateful fuzz tests in Wake testing framework to verify the correctness of the system. Ackee performed a thorough manual review of the code, focusing on the following aspects:
- bond supplied by node operators is correctly accounted and cannot be stolen by any account,
- the system contains no underflow/overflow issues that could lead to invalid state updates,
- permissionless functions cannot be abused to bring node operators into unintended states and prevent them from performing actions on the contracts,
- node operators are unable to deposit invalid keys and break the system functionality,
- CSM cannot cause denial of service to other staking modules and to the logic responsible for depositing keys,
- node operators are able to withdraw their rewards and unbonded funds without any issues,
- it is not possible to forge proofs of validator slashing or withdrawal that are not true but accepted by the smart contracts,
- the system cannot suffer from denial of service attacks by node operators spamming transactions,
- access controls are properly enforced in all critical functions without being overly restrictive or loose,
- node operators are unable to gain more rewards than stated in the rewards distribution report,
- rewards distribution report cannot be accepted if there is not enough votes to reach the configured quorum,
- node operators cannot bring validators into unexpected states, breaking the module’s logic.
The manual review was performed in parallel and in sync with the Staking Router audit performed by Ackee Blockchain Security. All issues of possibly medium severity or higher were immediately reported to the Lido team. These issues include the report date in their descriptions in this document. The review was concluded using static analysis tools, including Wake.
The SR methodology includes the creation of a Python model of the Lido protocol with the new Curated Staking Module (NodeOperatorsRegistry) and Community Staking Module (CSM) as modules. All the in-scope contracts were deployed, including the CSM codebase, the remaining protocol architecture was forked from the mainnet. On the Python model, Ackee has built a manually guided fuzzing campaign, with flows implemented for each function in the contracts. Finally, we’ve defined several stateful invariants where most notable ones are:
- the Python state is the same as in the contracts (differential testing approach),
- invariants on key counts (e.g. deposited keys count is always less or equal to the vetted keys count),
- correct incrementation of nonces,and more stateless checks, such as correct event emission.
During the Staking Router review, Ackee paid special attention to:
- exploring a potential attack surface of the core contracts because of introducing permissionless staking modules,
- new unvetting and pausing mechanism in DepositSecurityModule,
- possible guardians misbehaving, including signature replays and correct nonces usage,
- multi-transactional third-phase reports from accounting oracle,
- permissionless reward distribution in NodeOperatorsRegistry,
- ensuring overall access controls are not too relaxed or too strict,
- and looking for common issues such as data validation.
SCOPE
The CSM audit report has been performed on the commits 8ce944 and 13f78f in the community-staking-module and easy-track repositories, respectively.
- all files in src directory, excluding src/interfaces, in the community-staking-module repository,
- contracts/EVMScriptFactories/CSMSettleELStealingPenalty.sol in the easy-track repository.
The SR audit report further specifies the scope on the commit fafa23 and includes the following:
- contracts/0.4.24/nos/NodeOperatorsRegistry.sol
- contracts/0.8.9/DepositSecurityModule.sol
- contracts/0.8.9/StakingRouter.sol
- contracts/common/lib/MinFirstAllocationStrategy.sol
- contracts/0.8.9/oracle/AccountingOracle.sol
- contracts/0.8.9/sanity_checks/OracleReportSanityChecker.sol
FINDINGS
The classification of a security finding is determined by two sub-ratings: Impact and Likelihood. This two-dimensional rating makes the severity of issues more noise-free, without losing any information. The likelihood factor usually decreases severity of medium issues that would be just acknowledged by the team to infos and warning
The Lido CSM+SR findings total 46 issues out of which 32 issues were fixed by Lido Finance.
| Critical | High | Medium | Low | Info | Warning | Total |
| 0 | 0 | 1 | 11 | 18 | 16 | 46 |
CONCLUSION
Our review resulted in 46 findings, ranging from Info to Medium severity, out of the 46 findings 32 were fixed by Lido Finance. The most severe one M1 results in valid keys covered bond not being deposited, incorrectly preventing node operators from creating new validators under certain circumstances.
Ackee Blockchain Security recommends Lido Finance:
- ensure the off-chain services are working as expected to achieve the security guarantees of the system,
- be cautious when using unsafe functions and functions that do not properly update all internal state, such as CSAccounting.updateBondCurve or CSAccounting.setBondCurve,
- avoid using unchecked blocks that heavily rely on correctness of external contracts, where breaking the assumptions may lead to critical vulnerabilities,
- ensure the contracts are deployed and initialized atomically so no front-running of initialization functions is possible,
- address all the reported issues.
Ackee Blockchain Security’s full Lido Finance CSM audit report can be found here. The Lido Finance SR report can be found here.
We were delighted to audit Lido Finance and look forward to working with them again.
