__Proof of Concept (PoC) Requirements__
A PoC, demonstrating the bug's impact, is required for this program and has to comply with the [Immunefi PoC Guidelines and Rules](https://immunefisupport.zendesk.com/hc/en-us/articles/9946217628561-Proof-of-Concept-PoC-Guidelines-and-Rules)

__Asset Accuracy Assurance__

- Bugs found on assets incorrectly listed in-scope will be considered valid and be rewarded.

__Private Known Issues Rewards Policy__

- Private known issues, meaning known issues that were not publicly disclosed, are valid for a reward.

__Primacy of Impact vs Primacy of Rules__

- Lido adheres to the Primacy of Rules, which means that the whole program is run strictly under the terms and conditions stated within this page.

__KYC Requirement__

- No KYC is required for the Lido Bug Bounty Competition

__Eligibility Criteria__

- Security researchers who wish to participate must adhere to the rules of engagement set forth in this program and cannot be:
   - On OFACs SDN list 
   - Official contributor, both past or present
   - Employees and/or individuals closely associated with the project 
   - Security auditors that directly or indirectly participated in the audit review

__Responsible Publication__

- Whitehats may publish their bug reports after they have been fixed & paid, or closed as invalid, with the following exceptions:
   - Bug reports in mediation may not be published until mediation has concluded and the bug report is resolved.

- Immunefi may publish bug reports submitted to this Bug Bounty Competition and a leaderboard of the participants and their earnings.

__Proof of Concept (PoC) Requirements__
- A PoC, demonstrating the bug's impact, is required for this program and has to comply with the [Immunefi PoC Guidelines and Rules](https://immunefisupport.zendesk.com/hc/en-us/articles/9946217628561-Proof-of-Concept-PoC-Guidelines-and-Rules).

__Feasibility Limitations__

- The project may be receiving reports that are valid (the bug and attack vector are real) and cite assets and impacts that are in scope, but there may be obstacles or barriers to executing the attack in the real world. In other words, there is a question about how feasible the attack really is. Conversely, there may also be mitigation measures that projects can take to prevent the impact of the bug, which are not feasible or would require unconventional action and hence, should not be used as reasons for downgrading a bug's severity.

Therefore, Immunefi has developed a set of [feasibility limitation standards](https://immunefisupport.zendesk.com/hc/en-us/articles/16913132495377-Feasibility-Limitation-Standards) which by default states what security researchers, as well as projects, can or cannot cite when reviewing a bug report.

__Immunefi Standard Badge__

- By adhering to Immunefi’s best practice recommendations, Lido has satisfied the requirements for the [Immunefi Standard Badge](https://immunefisupport.zendesk.com/hc/en-us/articles/15006865432209-The-Immunefi-Standard-Badge).

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.

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

Theft of unclaimed yield

Permanent freezing of unclaimed yield

Temporary freezing of funds

Contract fails to deliver promised returns, but doesn't lose value

Incorrect calculation of multisig signers required for transaction processing

Prevention of governance participation despite design parameters providing participation rights

Impacts caused by griefing with no economic damage other than transaction fees where fix requires a change or a pause of a smart contract

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

**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 `DualGovernance` and `EmergencyProtectedTimelock`


**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

Dual Governance: Known Risks & Limitations

Dual Governance

Dual Governance Resources

Dual Governance Specification

Dual Governance Mechanism Design

Rewards are distributed according to the impact of the vulnerability based on the [Immunefi Vulnerability Severity Classification System V2.3](https://immunefi.com/immunefi-vulnerability-severity-classification-system-v2-3/) 

In addition to the regular [Lido Bug Bounty Competition](https://immunefi.com/bug-bounty/lido/information/) rewards per severity, this competition offers a **$100,000 bonus rewards pool **for valid, non-duplicate reports on the assets in scope on this program.

This **$100,000 bonus pool** will be distributed among researchers based on the severity of their valid, unique submissions, as determined at the end of the competition.

Bonus rewards are paid out in the following **priority order**:

1. Critical vulnerabilities
2. High vulnerabilities
3. Medium vulnerabilities
4. Low vulnerabilities

The **pool is allocated top-down**, meaning bonuses are paid to higher severity submissions first. If sufficient funds remain after paying critical submissions, bonuses will be issued to high severity findings, and so on.

**If fewer vulnerabilities are found than the total size of the pool, the full pool will not be spent.**

For example, if only a single valid Critical is found, the bonus paid will be **$50,000**, and the remaining **$50,000 will go unused**.

Bonus amounts for each unique, valid report are:

- Critical: $50,000
- High: $10,000
- Medium: $2,000
- Low: $1,000


If the number of valid submissions in a given severity exceeds the available bonus pool for that severity category, then the funds will be **evenly split among all eligible submissions** in that category. For example, if 4 criticals are found, each critical severity report will be rewarded $25,000. 

##### *Note:

1. The **bonus rewards pool is limited to $100,000**.
2. If the bonus rewards pool is exhausted, **reports will still be rewarded** under the regular Bug Bounty Program reward terms.
3. Bug reports will be paid after the Bug Bounty Competition ends and rewards are calculated. 
4.** Insights are out of scope** for this Bug Bounty Competition.
5. Any reports on Lido assets that are NOT in scope for this Bug Bounty Competition should be submitted to [Lido Bug Bounty Program](https://immunefi.com/bug-bounty/lido/information/).
6. **Duplicate** submissions of bugs are **not valid**. 
7. Rewards are denominated in USD and distributed in USDC on Ethereum.
8. Reports submitted via the regular Bug Bounty Program page will not be eligible for bonus rewards.
9. If the same bug is submitted separately to both the Bug Bounty Program and the Bug Bounty Competition, the report will be eligible for rewards only under the program where it was submitted first. For example:
- If Security Researcher A submits a valid bug to the Bug Bounty Program, and Security Researcher B submits the same bug to the Bug Bounty Competition, then only Security Researcher A is eligible, under Bug Bounty Program terms.
- If the reverse happens, only Security Researcher B qualifies, under Bug Bounty Competition terms.

__Repeatable Attack Limitations__
If the smart contract where the vulnerability exists can be upgraded or paused, only the initial attack will be considered for a reward. 
The amount of funds at risk will be calculated with the impact of the first attack being at 100% and then a reduction of 25% from the amount of the first attack for every [300 blocks] the attack needs for subsequent attacks from the first attack, rounded down

Bug Bounty Comp | Lido: Dual Governance

Status

Status

Leaderboard is Empty