Firedancer v0.1 Latest Mainnet (Pre-)Release

Firedancer codebase can be found at https://github.com/firedancer-io/firedancer/tree/main. Documentation and further resources can be found on:

- Documentation: [https://firedancer-io.github.io/firedancer/](https://firedancer-io.github.io/firedancer/)
- Technical education: Technical articles, ReadMe's, whitepaper, etc.
- [https://github.com/firedancer-io/firedancer/blob/main/README.md](https://github.com/firedancer-io/firedancer/blob/main/README.md)
- [https://github.com/firedancer-io/firedancer/blob/main/src/disco/README.md](https://github.com/firedancer-io/firedancer/blob/main/src/disco/README.md)
- All header files contain sufficient documentation about each component's function
- Developer codebase walkthrough
- Non-technical education: introductory videos, protocol summaries, FAQs, etc
- Solana Docs: https://solana.com/docs
- How to build and run a Node [https://firedancer-io.github.io/firedancer/guide/getting-started.html](https://firedancer-io.github.io/firedancer/guide/getting-started.html)

The Firedancer validator builds as a single binary: `fdctl`.  All code and functionality linked and reachable by the main function of this binary is in scope, including from the primary `run` command, but also `configure`, `monitor`, and others. Bugs in linked but unreachable code (for example: cryptography implementations that are behind a development flag or library utility code that is never called) are in scope but are not exploitable and will be considered informational (aka insight reports).


The Firedancer repository contains code for two validators:

- Firedancer v0.1, lovingly nicknamed “Frankendancer”, a split between Firedancer and the existing Agave validator written in Rust
- A full C-only Firedancer, completely replacing the existing Agave validator.


The full Firedancer code is behind a development flag, and findings in code that is only reachable in full Firedancer will be considered informational (aka insight reports).


The Firedancer v0.1 validator interfaces with the existing Agave validator written in Rust via an FFI interface. This FFI interface and the modifications to Agave to support such FFI are in scope, but bugs in the Agave validator itself that would impact existing Solana validators should be reported to the Agave bug bounty and are not considered in scope for the contest.


The directory and file listing are provided to help navigate the codebase and determine what is in scope. The ground truth for scope and impact will follow the production binary.

Firedancer is a new validator client for Solana.

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*

Process to process RCE between sandboxed tiles

Any bug leading Firedancer v0.1 to produce an invalid block or skip its leader slot

Consensus issues causing Firedancer v0.1 validators to fork

Increasing network processing node resource consumption by at least 30% without brute force actions, compared to the preceding 24 hours*

Shutdown of greater than or equal to 30% of network processing nodes without brute force actions, but does not shut down the network*

A bug in the respective layer 0/1/2 network code that results in unintended smart contract behavior with no concrete funds at direct risk*

Modification of transaction fees outside of design parameters*

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.

Rewards are distributed according to the impact of the vulnerability based on the [Immunefi Vulnerability Severity Classification System V2.3](https://immunefi.com/immunefi-vulnerability-severity-classification-system-v2-3/). 


__Reward Payment Terms__

Payouts are handled by the Firedancer team directly and are denominated in USD. However, payments are made in USDC.