Audit Comp | Firedancer V1

The firedancer binary and all linked, reachable code are in scope. The full codebase is~636,000 lines of C. Compiler-dependent bugs are in scope for GCC 8.5, 13, and 14 only. Clang is not in scope.

Key Areas of Concern

Runtime

Where to look: src/flamenco/runtime/ src/flamenco/vm/ Conformance mismatches with Agave leading to LOA or LOF. Largest new surface area.

Replay / Banks

Where to look: src/discof/replay/ Transaction dispatch, bank lifetime management, fork-aware state transitions. Banks accessed concurrently via shared memory — look for race conditions, refcounting bugs, and use-after-free on bank structures.

Accounts DB

Where to look: src/funk/ src/vinyl/ src/flamenco/accdb/ Funk is accessed concurrently via shared memory; vinyl is accessed client-server style via shared memory. Look for race conditions, memory corruption, attacker-reachable io_uring misuse, data corruption, and heap/workspace corruption.

Repair

Where to look: src/discof/repair/ Complex structures (forest, reassembly). DoS, overflows, UAF, wrong invariant assumptions.

Gossip

Where to look: src/discof/gossip/ Stateful structures, invariant mismatches causing bandwidth amplification.

Consensus / Tower

Where to look: src/choreo/ src/discof/tower/ Equivocation, liveness, fork choice bugs.

RPC

Where to look: src/discof/rpc/ New HTTP server, large attack surface.

GUI

Where to look: src/disco/gui/ Expanded HTTP-exposed interface.

Signing Tile

Where to look: src/disco/sign/ Private key leak

Sandbox

Where to look: src/util/sandbox/ Tile isolation, shared memory boundaries.

Snapshot Loader

Where to look: src/discof/restore/ Staging corrupt data for later exploitation.

Cryptography

Where to look: src/ballet/ Ed25519, SHA-256, AES, ChaCha20, BLS, secp256k1.

Networking

Where to look: src/waltz/ XDP, QUIC, HTTP, TLS. New QUIC client for vote transactions.

Feature Gates

Feature gates are only eligible for the bounty if they are activated on mainnet or present in this list: Feature Gates. Bugs related to feature gates that are not activated on mainnet and not on the list are out of scope.

Review tag

https://github.com/firedancer-io/firedancer/tree/v1.0 Mid-contest bug fixes are possible.

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 Audit Competition 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

TBD

Build Commands, Test Commands, and How to Run Them

Firedancer Localnet Setup Cluster Documentation

Asset Accuracy Assurance

Bugs found on assets incorrectly listed in-scope are valid.

Duplicate Rewarding

Duplicate submissions of bugs are valid under the following conditions:

• Duplicate reports for the same unfixed bug are valid
• Once a fix is merged to main, new reports for that bug are invalid
• Reports submitted before the fix are still eligible

Duplicate submissions of Insights are invalid.

The project commits to keeping private all info related to bug findings until this program is over. This means the project will not leak info about any bug findings or planned bug fixes, including bug findings found independently by the project or from concurrent private audits.

Attacker Position

Remote only: All attacks must be exploitable by a remote attacker with no pre-existing access on the validator. The compromised-tile model (assuming code execution on another tile within the sandbox) is out of scope for this contest.

Firedancer may be in majority, supermajority, or minority position. Attacker controls up to ~20% of stake.

Reference configuration

All attacks must be valid against this configuration TOML, section 8c. It defines which components are network-exposed, including enabled RPC methods, GUI, and telemetry endpoints.

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

Security researchers are required to submit KYC within 14 days of KYC being requested, else their rewards may be forfeited. Immunefi may make exceptions due to extenuating circumstances.

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

Insight Reporting

Insight reports may be reported to this program and do not require a PoC. Insights are rewarded according to Immunefi’s Standardized Competition Reward Terms.

Dispute Resolution

If there is any dispute over bug reports between projects and security researchers, Immunefi has final say on validity and severity based on the terms of this program.

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.