Decred Bug Bounty

Rules

We ask that you respect the following rules and guidelines. Repeated violations will lead to disqualification from the bounty program.

• All vulnerability reports need to have clear reproduction steps and/or proof of concept.

• Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.

• Any type of public disclosure of the vulnerability without prior approval from the bug bounty program will make it ineligible for payout.

• Please inform us if you have your own timeline for full disclosure (90 days minimum). Unless specified we will release the information at our own pace.

• All current/past (for up to 6 months) Decred contractors are barred from participating.

• You must not leverage the existence of a vulnerability or access to sensitive or confidential data to make threats, extortionate demands, or ransom requests.

• Hazardous testing without explicit authorization will lead to disqualification. This includes:

  1. Issues relating to excessive traffic/requests (e.g. DoS, DDoS)
  2. Attacks which may affect the availability of systems
  3. Social engineering attacks (e.g. phishing, opening support requests)
  4. Attacks that are noisy to users or admins (e.g. spamming notifications or forms)
  5. Attacks against physical facilities

• Content generated by LLMs must be meaningfully edited, validated, or supported by original analysis. Reports consisting primarily of low-effort, irrelevant, or excessively verbose content will be rejected.

Reminders

• Almost all of Decred’s projects can be run locally and reproduction instructions are available on GitHub. We strongly recommend doing this.

• There is a completely separate Decred testnet which is specifically created for software testing. Testing on the public testnet will prevent impact on mainnet and removes the risk of causing real financial damage. It is also possible to create your own personal simnet, running on your own local system with low enough difficulty to mine blocks using only a CPU.

• Always check the “issues” in GitHub of a project to avoid a duplicate report.

• The Decred project is not responsible for any loss of DCR due to vulnerability testing.

Payout

The OWASP Risk Rating Methodology will be used for assessing vulnerabilities and determining payout amount.

The impact on the Decred ecosystem will also be taken into consideration. An RCE in dcrwebapi (low impact) is not the same as an RCE in dcrd or Decrediton (higher impact). Once the payout amount is decided there will be no changes to the payout amount unless the vulnerability impact changes.

The following are also factors in the payout:

• Quality of the initial writeup.
• Quality of vulnerability reproduction steps and/or proof of concept.

The bounty program is funded by the Decred Treasury, therefore all payments are in DCR only. Recipients are required to create a Decred wallet and provide a payment address. Payouts are sent at the beginning of each month using the average DCR/USDT rate of the previous month.

For vulnerabilities that require a patch rollout and pose a risk to other network participants, we might choose to only release 60% of the payout amount first and hold the 40% until a patch has been released and distributed.

The maximum approved budget for payouts is capped at 100,000 USD. Please be aware of this when you are submitting multiple critical vulnerabilities. If the limit is reached then a new proposal will have to be submitted and get stakeholder approval before you can be paid in full.

Successful bounty hunters will be given one month to claim due rewards, after which they will be considered forfeit.

Indicative payout amounts

Note: up to 500 USD

Low: up to 1,500 USD

Medium: up to 5,000 USD

High: up to 15,000 USD

Critical: up to 30,000 USD

In Scope

To be eligible for the bounty program, reports must be reproducible security vulnerabilities in the latest production release or the master branch of the following repositories.

* Private RPCs which by default listen on localhost only are out of scope.

** Only the csppsolver command and the solver and solverrpc packages are in scope.

*** Assets other than Bitcoin and Decred are out of scope. Companion app and dexadm are out of scope.

**** Scope has some limitations, please read the linked GitHub page before testing.

Ineligible Findings

• Bugs which do not lead to security vulnerabilities.

• Misconfiguration or vulnerabilities in chat and communication platforms including email, Element/Matrix, Discord, and the Decred forum.

• Vulnerabilities in old releases, proof-of-concept code, feature branches, or projects still under development.

• Duplicate reports or reports of vulnerabilities which are already known (note that some of our issue tracking is private).

• Vulnerabilities which only exist on testing or staging sites.

• Vulnerabilities requiring extensive access to the host system (eg. physical access, root login) are only accepted if said access may be gained via a flaw in our source code.

• Typical resource exhaustion attacks involving normal network operation are already well-known limitations of peer-to-peer networks and generally are not covered. They will be considered on a case by case basis.

• The following issues will be closed as invalid except in rare circumstances demonstrating clear security impact:

  1. Theoretical vulnerabilities that require unlikely user interaction or circumstances. For example:

     1. Vulnerabilities only affecting users of unsupported or end-of-life browsers or operating systems.
     2. Broken link hijacking.
     3. Tabnabbing.
     4. Content spoofing and text injection issues.
     5. Self-exploitation, such as self-XSS or self-DoS (unless it can be used to attack a different account).

  2. Theoretical vulnerabilities that do not demonstrate real-world security impact. For example:

     1. Clickjacking on pages with no sensitive actions.
     2. Cross-Site Request Forgery (CSRF) on forms with no sensitive actions (e.g. Logout).
     3. Permissive CORS configurations without demonstrated security impact.
     4. Software version disclosure/banner identification issues/descriptive error messages or headers (e.g. stack traces, application or server errors).
     5. Comma Separated Values (CSV) injection.
     6. Open redirects (unless you can demonstrate additional security impact).
     7. Outdated software/library versions.

  3. Optional security hardening steps/missing best practices. For example:

     1. SSL/TLS Configurations.
     2. Lack of SSL Pinning.
     3. Insecure settings in non-sensitive cookies (e.g. missing HttpOnly/Secure flags).
     4. Content-Security-Policy configuration opinions.
     5. DMARC, SPF, or other email server or DNS configuration settings and policies.
     6. Most issues related to rate limiting.

Submit Vulnerability

Please follow a standard format when submitting vulnerabilities.

Title

Affected website or repository

Vulnerability Type

Details

Impact of Vulnerability

Reproduction or POC details

Fix