Firedancer
Firedancer is a new validator client for Solana.
PoC Required
KYC required
Select the category you'd like to explore
Assets in Scope
Impacts in Scope
Firedancer builds as a single production binary, fdctl. Code linked into and reachable from this binary in the latest Frankendancer release build and branch is in scope, including the primary fdctl run command. Code from the consensus, runtime, and other components of the full future Firedancer validator are not in scope. The FFI interface between Frankendancer and Agave is in scope, but bugs in Agave code that exist in the standalone Anza Agave validator are not in scope, and should be reported to Anza. Protocol bugs or design flaws in Solana are not in scope, and are reportable to Anza.
For cluster-level impact, a theoretical Firedancer-only chain is in scope. For example, while a chain halt is not currently possible on mainnet via a Firedancer-only exploit (since the network includes other validator clients), you may assume a 100% Firedancer validator set and demonstrate impacts such as a chain halt or chain split under those conditions.
The sandbox and security model are in scope. You may assume an existing RCE within a specific tile, and any findings downstream of that breach—such as a sandbox escape or gaining RCE in the sandbox of a different tile—are considered valid.
However, tiles in the Agave address space (e.g., bank, poh, store) are not considered tightly sandboxed. As such, transitions from a tile in the Agave to any other tile are not in-scope. Additionally, the link between pack and bank is trusted and out-of-scope. Regarding severity of inter-tile RCE, we are most interested in starting in a complex tile that is close to input from the network. (e.g. net or quic).
The primary security concern of the validator is defending against untrusted or malicious behavior originating from the network, and limiting damage in the event of RCE. Issues that are purely local to the validator and not remotely exploitable—such as command-line argument or environment variable handling—will be considered out of scope or informational.
The GUI is in scope. You may assume the GUI’s HTTP port is exposed to the public internet. Vulnerabilities that involve, are triggered by, or relate to the block engine functionality may be considered valid. However, such findings will typically be assessed at a lower severity level.
Special Note: Severities noted by the “*” are those that we don’t believe are currently realizable risks with the amount of stake applied to Firedancer when authoring these terms.
However, We believe these risks could be realized with more stake applied to Firedancer. If you find something that realizes these risks, you are encouraged to submit it, and they will be rewarded according to their impact.
Any bug leading to loss of funds or acceptance of forged / invalid signatures
Key compromise/exfiltration exploit chain
Network not being able to confirm new transactions (total network shutdown)*
Unintended permanent chain split requiring hard fork (network partition requiring hard fork)*
Direct loss of funds*
Permanent freezing of funds (fix requires hard fork)*
Infinite Mint
Unintended chain split (network partition)*
Temporary freezing of network transactions by delaying one block by 500% or more of the average block time of the preceding 24 hours beyond standard difficulty adjustments*
Elevate privileges in the Firedancer GitHub repository to cut releases or commit to protected branches
Liveness issues that cause Firedancer validators to crash or be unavailable*
Any sandbox escape
Out of scope
Additional Rules/Information:
For exploits denoted as RCE, we expect an actual proof of RCE. Memory corruptions that are merely building blocks in a full RCE exploit chain will be rewarded less than full RCE exploits.
Please keep validator code patches in PoCs to a minimum, and thoroughly explain for each change why the bug can still be exploited on an unpatched validator, and under what conditions.
These impacts are out of scope for this bug bounty program:.
- Impacts requiring phishing or other social engineering attacks against project's employees and/or customers.
- Any affected code, from dependent Solana client implementations (e.g. Agave) should be reported upstream.
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