Lido is a liquid staking solution for Ethereum backed by industry-leading staking providers. Lido lets users stake their ETH - without locking assets or maintaining infrastructure - whilst participating in on-chain activities, e.g. lending.
Live
Triaged by Immunefi
PoC Required
Select the category you'd like to explore
Assets in Scope
Impacts in Scope
Build Commands, Test Commands, and How to Run Them
- See README section for full guide: https://github.com/lidofinance/dual-governance/tree/v1.0.1-hotfix?tab=readme-ov-file#setup
Is this an upgrade of an existing system? If so, which? And what are the main differences?
- Yes, this is an upgrade of the previously deployed Dual Governance version: https://github.com/lidofinance/dual-governance/releases/tag/v1.0.0. The primary change is a fix for a vulnerability in the Escrow.startRageQuitExtensionPeriod() method. Additional details are available in the release notes: https://github.com/lidofinance/dual-governance/releases/tag/v1.0.1-hotfix.
Where do you suspect there may be bugs and/or what attack vectors are you most concerned about?
- Attacks that result in indefinite blocking of governance decision execution.
- Attacks that prevent the successful completion of the RageQuit process, potentially leading to permanent or temporary locking of users’ stETH/wstETH/unstETH/ETH in Escrow contracts.
- Execution of proposals that bypass the enforced delays established by
DualGovernanceandEmergencyProtectedTimelock
What ERC20 / ERC721 / ERC777 / ERC1155 token standards are supported?
- Only stETH and wstETH (ERC20), and unstETH (ERC721) tokens are supported.
What emergency actions may you want to use as a reason to downgrade an otherwise valid bug report?
- Dual Governance is launched under a Protected Deployment Mode (https://github.com/lidofinance/dual-governance/blob/main/docs/specification.md#protected-deployment-mode), which allows the dynamic timelock system to be fully disabled in case of a critical bug in the Dual Governance logic.
- Additionally, the Tiebreaker mechanism (https://github.com/lidofinance/dual-governance/blob/main/docs/specification.md#tiebreaker-committee) can be activated to bypass the RageQuit timelock in the event of a system deadlock.
Which chains and/or networks will the code in scope be deployed to?
- hoodi/mainnet
What external dependencies are there?
- External dependencies can be found on https://github.com/OpenZeppelin/openzeppelin-contracts/releases/tag/v5.0.2
Manipulation of governance voting result deviating from voted outcome and resulting in a direct change from intended effect of original results
Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield
Permanent freezing of funds
Protocol insolvency
Incorrect calculation of multisig signers required for transaction processing
Theft of unclaimed yield
Permanent freezing of unclaimed yield
Temporary freezing of funds
Prevention of governance participation despite design parameters providing participation rights
Acquiring owner/admin rights or roles without contract’s owner/admin action
Impact caused by missing access controls allowing to execute privileged actions (e.g., changing protocol parameters or upgrading contracts) without required privileged roles
Impacts caused by griefing with no economic damage other than transaction fees where fix requires a change or a pause of a smart contract
Out of scope
All categories
- Impacts requiring attacks that the reporter has already exploited themselves, leading to damage
- Impacts caused by attacks requiring access to leaked keys/credentials
- Impacts caused by attacks requiring access to privileged addresses (including, but not limited to: governance and strategist contracts) without additional modifications to the privileges attributed
- Impacts relying on attacks involving the depegging of an external stablecoin where the attacker does not directly cause the depegging due to a bug in code
- Mentions of secrets, access tokens, API keys, private keys, etc. in Github will be considered out of scope without proof that they are in-use in production
- Best practice recommendations
- Feature requests
- Impacts on test files and configuration files unless stated otherwise in the bug bounty program
- Impacts requiring phishing or other social engineering attacks against project's employees and/or customers