Boost | Firedancer v0.1

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.

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.

Mid-Contest Code Updates

In this contest bug fixes may be applied mid-contest.

The project is to keep changes private as far as possible. When changes need to be made public, then the changelog will be updated here & in the Firedancer Boost Discord channel. Publicly fixed bugs are invalid and the scope is updated to the new code.

All bug reports before the fix was public will earn a reward. All bug reports after are invalid. If a new bug is introduced by their fix then it is valid for a reward.

Mid-Contest Changelog

• July 16 :: improve balance between votes and non-votes https://github.com/firedancer-io/firedancer/pull/2404

Asset in scope link updated from https://github.com/firedancer-io/firedancer/tree/v0.106.11814 to https://github.com/firedancer-io/firedancer/tree/e60d9a6206efaceac65a5a2c3a9e387a79d1d096

Asset Accuracy Assurance

Bugs found on assets incorrectly listed in-scope will be considered valid and be rewarded.

Private Known Issues Reward Policy

Private known issues, meaning known issues that were not publicly disclosed, are not valid for a reward.

Primacy of Impact vs Primacy of Rules

Firedancer adheres to the Primacy of Rules, meaning the whole bug bounty program is run strictly under the terms and conditions stated on this page.

KYC Requirement

Immunefi will be requesting KYC information to pay for successful bug submissions. The following information will be required:

• Full name
• Date of birth
• Proof of address (either a redacted bank statement with the address or a recent utility bill)
• Copy of Passport or other Government ID

Eligibility Criteria

Security researchers who wish to participate must adhere to the rules of engagement outlined in this program and cannot be:

• On OFAC SDN list
• Official contributor, both past or present
• Employees and/or individuals closely associated with the project
• Employees of Solana Foundation or any other Solana client project
• Security auditors who directly or indirectly participated in the audit review

Responsible Publication

Whitehats may publish their bug reports after they have been fixed & paid or closed as invalid, with the following exceptions:

• Bug reports in mediation may not be published until mediation has concluded and the bug report is resolved.

Immunefi may publish bug reports submitted to this program and a leaderboard of the participants and their earnings.

Feasibility Limitations

The project may receive valid reports (the bug and attack vector are real) and cite assets and impacts that are in scope, but there may be obstacles or barriers to executing the attack in the real world. In other words, there is a question about how feasible the attack really is. Conversely, there may also be mitigation measures that projects can take to prevent the bug's impact, which are not feasible or would require unconventional action and, hence, should not be used as reasons for downgrading a bug's severity.

Therefore, Immunefi has developed a set of feasibility limitation standards that, by default, state what security researchers and projects can or cannot cite when reviewing a bug report.

Immunefi Standard Badge

By adhering to Immunefi’s best practice recommendations, Firedancer has satisfied the requirements for the Immunefi Standard Badge.