Stacks

Rewards are distributed according to the impact of the vulnerability based on the Immunefi Vulnerability Severity Classification System V2.2. This is a simplified 5-level scale, with separate scales for each category, encompassing everything from consequence of exploitation to privilege required to likelihood of a successful exploit.

Stacks DoS Severity Classification

For Blockchain/DLT reports, the denial-of-service (DoS) severity classification combines blast radius (B) and recovery needed to restore chain progression or valid confirmations (R). The matrix determines the final severity.

Blast Radius

• B1 (Local or short-lived DoS): One miner or signer fails without preventing other honest participants from confirming proposals, or the disruption is resolved with a new bitcoin-anchored tenure won by a different miner.
• B2 (Partial confirmation failure): The attack prevents some valid transactions or honest proposals from reaching the canonical chain while other transactions confirm and the chain progresses. The inclusion of the affected transactions or proposals is not restored after a different miner wins a new Bitcoin-anchored tenure.
• B3 (Network shutdown): The attack prevents the network from confirming new valid transactions. The network’s ability to confirm transactions is not restored after a different miner wins a new Bitcoin-anchored tenure.

An issue with no material effect on a supported production service is Informational or out of scope.

Recovery

• R1 (Automatic recovery): Default automation restores chain progress and confirmations without operator action. It remains effective if the attacker repeats the attack.
• R2 (Existing-software recovery): Miners, signers, or nodes restore confirmations by restarting, reconfiguring, or activating a prepared backup. Recovery requires no new software or consensus change. To cause another incident, the attacker must re-establish the attack's preconditions.
• R3 (Non-consensus-changing software recovery): Confirmations cannot resume until the mining or signing set deploys a new build, patch, or other artifact that does not change consensus.
• R4 (Consensus-changing recovery): Confirmations cannot resume without a consensus change.

Severity

Notes on DoS Vectors Classification

• A coordinated restart is R2 when it clears the attack state and another incident requires a new attacker action, such as resubmitting the trigger or winning another sortition (meaning it has to rebuild the attack preconditions). A patch installed after confirmations resume is remediation and does not change that recovery grade.
• To demonstrate a partial confirmation failure (B2), a valid transaction or honest proposal that the attack is claimed to block must reach the canonical chain in a test without the attack and fail to reach it in an otherwise equivalent test with the attack. An unrelated valid transaction must continue to confirm while the attack is active, showing that the chain continues to progress.
• A network shutdown (B3) must be demonstrated across the independent production roles required to stop confirmations. A test node hosting both miner and signer roles represents one failure domain unless the supported production deployment uses the same topology. A malicious miner can always withhold blocks during its own tenure, so that behavior alone does not demonstrate a DoS vulnerability.
• To demonstrate a network shutdown (B3), the proof of concept must reproduce the halt with miner and signer roles running separately.
• A malicious miner can always withhold blocks during its own tenure, so that behavior alone does not demonstrate a DoS vulnerability.
• Default timeouts and resource guards must remain enabled because they determine the effect of the attack. An underpriced transaction that reaches a default timeout and is rejected while other transactions continue to confirm does not establish B2 or B3. Reserving virtual address space alone does not demonstrate memory exhaustion; the proof of concept must produce an out-of-memory (OOM) condition or process termination under the recommended configuration https://docs.stacks.co/operate/run-a-node.
• A report may describe multiple distinct attack vectors. Each vector will be graded using its own demonstrated impact and recovery; evidence from separate vectors will not be combined. Multiple steps required to execute one attack form a single vector will be assessed together. The report is classified at the highest severity established by any eligible vector.

Critical Finding Limits

Please note that Critical finding bounties are capped at 10% of the damage resulting from the finding. This mostly takes into account technical and financial damage but also includes the “human” impact, including reputational risk.

We guarantee a minimum payout of $15,000 USD for all valid Critical findings.

We Will

• Respond meaningfully to all reported issues in a timely manner.
• Not pursue legal action against or “counter-hack” any researchers acting in good faith and abiding by this program’s rules.
• Consider theoretical attacks and findings without proof-of-concept code as long as technically meaningful, evidence-based arguments are provided.

You Must

• Undergo full KYC. We are based in the Cayman Islands and abide by strict AML law, including OFAC controls/sanctions and onchain wallet address screening.
• Not be based or test from an OFAC-sanctioned country or region or (be a sanctioned individual or organization) as defined here: https://ofac.treasury.gov/sanctions-programs-and-country-information
• Report all bugs using this template. All fields are required unless otherwise marked.
  • Executive summary of issue:
  • Finding details:
  • Repository, file, and line of code where finding is found:
  • Steps to replicate:
  • Impact of finding (short term):
  • Impact of finding (long term):
  • Mitigation suggestions (short term):
  • Mitigation suggestions (long term):
  • (Optional) Suggested patch:
  • (Optional) Any useful links or resources:
  • (Optional) Do you want a shout-out on our Security Wall of Fame?
  • (Optional, if approved) Do you want a cybersecurity-themed NFT sent to your Stacks wallet?
• Use a private testnet. Testing on mainnet or public testnets is forbidden.

A proof-of-concept is required for all submissions. Please include it in the corresponding form field.

Payments

Payouts are handled by the Stacks Endowment team directly and are denominated in USD. However, payments will be made in the USD equivalent in the Stacks token (STX).