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 v0.1 Frankendancer 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.
The sandbox and security model are in scope. You may assume an existing RCE breach and findings downstream of that, for example a sandbox escape, or gaining RCE in the sandbox of a different tile. Tiles in the Agave address space (bank, poh, store) are not considered sandboxed, and for example going from a pack RCE to bank RCE is not a sandbox escape.
The primary concern of the validator is defending against untrusted and malicious behavior from the network, and containing damage in the case of RCE. Issues local to the validator that cannot be exploited remotely, for example, command line argument or environment variable handling issues will be out of scope or informational.
For cluster impacts, a theoretical Firedancer-only chain is in scope. For example, a chain halt would not be possible currently on mainnet with a Firedancer exploit, since it would only halt Firedancer nodes, which the cluster can survive without. But you may assume 100% Firedancer nodes and demonstrate a chain split.
The Firedancer v0.1 sandbox (and machine model) are explicitly in-scope. This means that a researcher could assume a tile’s already been breached, and any findings downstream of that “contrived” tile breach are valid. As an example: Assume the “Net” tile has been breached, such that the researcher has full RCE within the sandbox of the Net tile. If the attacker is able to cause malicious effects in any of the “downstream” tiles or on the system itself, these findings would also be in scope. However, this assumption does not hold for boundaries with the Agave validator, such as the link between pack and bank tiles.
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 sandbox escape
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)*
Liveness issues that cause Firedancer v0.1 validators to crash or be unavailable*
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
Process to process RCE between sandboxed tiles
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