Runnable PoC Required
Select the category you'd like to explore
Assets in Scope
Impacts in Scope
We prioritize soundness vulnerabilities affecting Groth16 and Plonk proof types.
Soundness bug where a malicious prover can forge a false proof for all 4 proof types (core, compressed, Plonk, Groth16) for a general class of programs.
Soundness bug where a malicious prover can forge a false Compressed proof for a general class of programs.
Soundness bug where a malicious prover can forge a false Groth16 and a Plonk proof for a general class of programs.
Completeness bug affecting all proof types and a general class of programs.
Soundness bug that allows forging a false core proof but not compressed or SNARK proofs.
Out of scope
All reports must be valid on SP1's latest release commit, which can be found here. The findings must be reproduced with production circuits and verification keys, with default production security checks. Findings that require Cargo features or paths intended solely for experimental, mprotect, debug, profiling, dummy, testing, benchmarking, or in-development circuits are out of scope. Findings on the usage of proof_nonce are also considered out of scope.
More precisely, the findings should use the compiler feature-set used to build the Docker images here; in particular, sp1-prover/experimental and sp1-prover/mprotect are off, sp1-prover/native-gnark is turned on, and they should demonstrate a completeness or soundness vulnerability in sp1_sdk::prover::Prover::verify.
Proofs of concept should be able to run on an Apple M3 chip or similar hardware in ten minutes or less.
The whir, veil, spartan, pgspcs crates within slop are out of scope. Findings that affect slop only as a standalone library and do not affect the in-scope proving and verification in SP1 are considered out of scope.
A bug bounty submission for a completeness vulnerability should demonstrate an inherent and deterministic incorrectness inside an AIR constraint, recursive circuit, or production verifier that makes a valid execution unprovable, or makes its correctly generated proof unverifiable. Failures that are specific to a prover backend or prover implementation, hardware, insufficient resources, concurrency, timeouts, environment variables, or user misconfiguration are out of scope.
All reports must be valid under the SP1 security model
- https://docs.succinct.xyz/docs/sp1/security/security-model
- https://docs.succinct.xyz/docs/sp1/security/safe-precompile-usage
This means that all eligible proofs of concept must use
- A memory-safe, non-malicious program.
- An ELF produced by the provided SP1 toolchain.
- Safe usage of precompiles and patched crates as explained in the documentation.
- Must not request a
Coreproof for an ELF that invokes theVERIFY_SP1_PROOFsyscall.
Only production soundness failures and protocol-level completeness failures as defined above are eligible for the bounty. Findings on DoS of prover and the verifier, as well as service availability, are considered out of scope.
Source: SP1
Blockchain/DLT specific
- Incorrect data supplied by third party oracles
- Not to exclude oracle manipulation/flash loan attacks
- Impacts requiring basic economic and governance attacks (e.g. 51% attack)
- Lack of liquidity impacts
- Impacts from Sybil attacks
- Impacts involving centralization risks
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