Audit Comp | Firedancer V1

Proof of Concept (PoC) Requirements

Proof of Concept (PoC) Requirements A runnable PoC, demonstrating the bug's impact, is required for this program and has to comply with the Immunefi PoC Guidelines and Rules.

A valid PoC should:

• Build and run against the in-scope branch with clear setup instructions
• Demonstrate the impact - show the actual outcome (crash, corruption, Bank Hash Mismatch, etc.), not just a hypothesis
• Be self-contained - a reviewer should be able to reproduce the issue by following the steps in the report without additional guesswork
• Include the attacker model - specify what position the attacker is in (Current leader, staked validator, gossip participant, etc.) and what inputs they control.

Examples of what qualifies:

• A crafted network packet or sequence of packets that crashes the validator or leads to a bank hash mismatch in a local cluster
• A solfuzz-agave harness input (protobuf) that triggers a crash or bank hash mismatch between Firedancer and Agave. Accepted harness targets: instr_execute, txn_execute, elf_loader, vm_interp, vm_syscall_execute, shred_parse, pack_compute_budget. Inputs must include the harness target name. As a counterexample, an error code mismatch will crash the harness but does not result in a validator crash/bank hash mismatch and would not be eligible for submission.
• A minimally modified validator or client that exploits a consensus or replay bug WITH CLEAR EXPLANATION AND JUSTIFICATION of why the modification is necessary and how it’s still possible on mainnet.
• A PoC that demonstrates sandbox escape.

Examples of what does not qualify:

• A report describing a potential issue with no reproduction steps
• Static analysis output or code snippets without demonstrated impact
• Reports that only show a code path is reachable without showing it is exploitable

Whitehat Educational Resources & Technical Info

• Documentation: firedancer-io.github.io/firedancer/
• Repository: https://github.com/firedancer-io/firedancer

Optional Project Info

Where might Security Researchers confuse out-of-scope code to be in-scope?

Out of Scope:

• firedancer-dev development binary and tool
• Frankendancer codebase (code that is ONLY reachable from fdctl/fddev) - not the focus of this contest, please report issues via the standing bug bounty.
• Development scripts, tools, CI environment
• Solana protocol bugs (report to Anza/Jito)
• Social engineering or phishing attacks
• Test files and test-only code (unless they reveal a production vulnerability)
• Tile-to-tile attacks (compromised-tile attacker model).

Directory Structure Reference

src/
├── app/firedancer/ - Binary entry point, topology, CLI
├── ballet/         - Cryptography
├── choreo/         - Consensus (tower, ghost, equivocation)
├── disco/          - Shared tiles (net, pack, verify, dedup, GUI, shred)
├── discof/         - Full Firedancer tiles (replay, repair, gossip, tower, RPC, snapshots)
├── flamenco/       - Runtime, accounts DB API, sBPF VM, bank, program cache
├── funk/           - In-memory fork-aware database
├── vinyl/          - Persistent storage database
├── tango/          - IPC, shared memory messaging
├── util/           - Core utilities, sandbox, tile runtime
└── waltz/          - Networking (XDP, QUIC, HTTP, TLS)

Is this an upgrade of an existing system? If so, which? And what are the main differences?

Firedancer v1.0 is the successor to Frankendancer, the hybrid validator client that combines Firedancer's networking stack with the Agave runtime. In v1.0, all Agave dependencies have been replaced with native C implementations — making it the first fully independent Solana validator client. Key new components include the runtime, accounts database (funk + vinyl), replay system, repair, gossip, consensus, RPC server, and snapshot loader.

Which chains and/or networks will the code in scope be deployed to?

Solana mainnet.

Public Disclosure of Known Issues

Bug reports covering previously discovered bugs (listed below) are not eligible for a reward within this program. This includes known issues that the project is aware of but has consciously decided not to “fix,” necessary code changes, or any implemented operational mitigating procedures that can lessen potential risk.

• bundle: known issues in bundle client
• consensus: known issues in tower, ghost, choreo
• eqvoc: known issues in equivocation detection
• gossip: known issues in gossip subsystem
• pack/bank: known issues in pack, bank, and execle
• poh: known issues in proof of history
• progcache: known issues in program cache
• quic/net: known issues in QUIC and networking
• repair: known issues in repair, forest, blockstore
• restore: known issues in snapshot, vinyl, and restore subsystem
• rpc: known issues in RPC and HTTP/2
• runtime: known issues in execution and runtime
• runtime: known issues in VM, SBPF, and ELF loader
• sandboxing: known issues in seccomp filters
• shred: known issues in shred processing
• sign: known issues in sign tile
• util: known issues in utilities and infrastructure
• verify/dedup/resolv: known issues in verify, dedup, resolv

Previous Audits

Firedancer V1’s haven’t completed any audits yet.