Bug Bounty Program
Stake DAO rewards original security vulnerabilities that cause concrete harm to users of in-scope production contracts. Reports are assessed under the policy published when they are received.
Scope
In Scope
- Stake DAO production contracts across all supported chains, including vaults, reward receivers and other instances created by production factories.
- Retired contracts where the issue affects remaining user funds or a required withdrawal or migration path.
Use Contract Addresses or a production factory's creation record to identify the deployment. The registry includes historical entries; we verify production status and explain any scope rejection. You do not need to audit the deployment registry before submitting.
Out of Scope
- Undeployed, testnet or obsolete code with no connection to an in-scope deployment. Re-deploying an old repository on a fork does not establish production exposure.
- Issues already established in audits, an earlier actionable report or internal records, including fixes awaiting deployment. When relying on internal knowledge, we provide evidence dated before submission, redacted where necessary.
- Compromised keys, malicious administrators, deliberate operator misconfiguration or roles exercising documented powers. An unprivileged path that bypasses those permissions can qualify.
- Intended fees, keeper incentives and reward collection without a violated user entitlement.
- Hardening suggestions, missing modifiers or accounting differences without demonstrated security impact.
- Self-inflicted losses or loss of tokens nobody is owed, such as unsolicited donations or airdrops, unless they cause separate harm to users.
- Frontend issues, social engineering and vulnerabilities solely in third-party contracts. Defects in Stake DAO's own integration code can qualify.
Required Evidence
Use these four fields in your email, with supporting files attached privately:
- Target: chain ID, deployed address, implementation address for proxies or clones, and source matching the deployed code.
- Issue: affected functions, expected versus actual behavior, caller permissions and assumptions. Show that the required conditions exist or can arise through normal protocol use.
- Evidence: a minimal reproducible test or transaction simulation against deployed code, with dependencies and run instructions. For forks, include a recent block number and date; historical evidence must explain why the issue still applies. Include a control showing normal behavior without the reported condition.
- Impact: affected users and assets, with expected versus actual balances, entitlements or state. Separate measured harm from estimated totals. A protocol-wide valuation and proposed fix are optional.
Disclose mocks, storage edits, injected balances and impersonated roles. Test setup cannot replace evidence that the required conditions and permissions are reachable in production.
Verify every claim before submitting, including claims produced by automated tools. Scanner output, code excerpts and passing test counts do not replace the evidence above.
If you claim funds are permanently lost or frozen, explain why existing claim, withdrawal, rescue, upgrade or governance paths cannot recover them. Otherwise, describe the recovery requirements, delay and any resulting harm.
Severity and Rewards
Stake DAO assesses severity from demonstrated harm, realistic preconditions, value at risk and recovery options. Reporter-assigned labels and CVSS scores do not determine rewards.
| Severity | Demonstrated impact | Maximum reward |
|---|---|---|
| Critical | Direct loss, unauthorized withdrawal or permanent freezing of user principal | Up to $100,000 |
| High | Theft of user yield, incorrect reward allocation or permission bypass causing material harm to users | Up to $25,000 |
| Medium | Incorrect calculations or griefing causing bounded, measurable harm to users | Up to $5,000 |
| Low | Other confirmed, in-scope security issues with limited impact | At Stake DAO's discretion |
These amounts are ceilings, not guaranteed payments. Rewards reflect impact, originality and remediation value.
Priority goes to the first eligible report with enough information to identify and reproduce the vulnerability. An incomplete or closed report that never established the issue does not pre-empt a later actionable report. Additional instances of the same root cause do not earn separate rewards.
Submission and Review
Email [email protected] with the subject [Bug Bounty] Contract — issue. Submit one report per root cause and keep follow-ups in the original thread.
We aim to provide an initial response within 5 business days. This may identify missing evidence or explain closure; full assessment depends on complexity and volume.
Reports missing required evidence or falling outside scope may be closed with a brief reason, without detailed technical review. Repeated submissions of the same claim without material new evidence may receive no further response.
Rules
- Test only in local environments or forks. Do not exploit production contracts, move other users' funds or disrupt live services.
- Keep reports and tests private and coordinate disclosure with the team. Publishing before the agreed disclosure date makes a report ineligible for a bounty.
- Stake DAO service providers and recent contributors are ineligible for rewards.
Stake DAO will not take legal action against researchers who investigate and report vulnerabilities in good faith and follow these rules, even if their report is ineligible for a reward. This commitment does not bind third parties.
Report suspected ongoing incidents affecting user funds immediately to [email protected], even without a complete report. Incident response is separate from bounty eligibility.