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
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.
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.
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.
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:.
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
- Impacts requiring phishing or other social engineering attacks against project's employees and/or customers.
- 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
- Any affected code, from dependant Solana client implementations (eg. Agave) should be reported upstream.
Websites and Apps
All websites and applications are out of scope.
Blockchain/DLT & Smart Contract 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
- Example code (https://github.com/jito-foundation/jito-programs/tree/master/example-programs)
Prohibited Activities:
- Any testing on mainnet or public testnet deployed code; all testing should be done on local-forks of either public testnet or mainnet
- Any testing with pricing oracles or third-party smart contracts
- Attempting phishing or other social engineering attacks against our employees and/or customers
- Any testing with third-party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks)
- Any denial of service attacks that are executed against project assets
- Automated testing of services that generates significant amounts of traffic
- Public disclosure of an unpatched vulnerability in an embargoed bounty