Firedancer: What Developers Need to Know

Firedancer is an independent Solana validator client written in C by Jump Crypto’s engineering team. It is a ground-up reimplementation of the Solana validator, not a fork of the existing Agave (formerly Solana Labs) client. The goal is significantly higher transaction throughput and lower latency through hardware-aware design.

What Firedancer changes

Firedancer reimplements the validator’s networking, block production, and consensus layers. For developers, the key changes are:

Higher throughput capacity

Firedancer’s architecture is designed to process more transactions per second than Agave. The networking stack uses kernel-bypass techniques (DPDK, io_uring) and the transaction pipeline is parallelized across CPU cores with zero-copy message passing. In testing, Firedancer has demonstrated throughputs far exceeding Agave’s capacity.

Different leader behavior

When a Firedancer validator is the slot leader, block production characteristics may differ:

• Transaction ordering within a block may follow different heuristics.
• Block packing efficiency may change — Firedancer may fit more transactions per block.
• Timing of block propagation may differ, affecting perceived confirmation times.

Same runtime semantics

The Solana runtime (the BPF/SBF virtual machine that executes programs) is spec-compatible across clients. Your programs, transactions, and RPC calls work identically whether the validator runs Agave or Firedancer:

• Smart contracts execute the same way.
• Transaction format is unchanged.
• Account model is unchanged.
• RPC API is compatible.

Frankendancer: the transitional release

Frankendancer is a hybrid build that uses Firedancer’s networking and block production components with Agave’s runtime and consensus components. It allows validators to adopt Firedancer’s performance improvements incrementally while the full Firedancer runtime is finalized.

Developers interacting with Frankendancer validators see the same RPC interface. The differences are in internal validator performance characteristics, not in the API surface.

What developers should prepare for

1. Test against multiple clients

As Firedancer adoption grows, the network becomes a multi-client environment. Behavior that depends on implementation-specific quirks of Agave (transaction ordering within a slot, exact timing of state transitions) may not hold under Firedancer.

2. Expect higher TPS

More transactions per second means:

• Higher data volumes for indexers and archivers.
• More frequent account state changes.
• WebSocket subscriptions may deliver more events per second.
• getBlock responses may contain more transactions.

3. Review timing assumptions

If your application assumes specific block production timing (slot duration, propagation delay), verify those assumptions hold across both clients. The 400ms slot time is a protocol parameter, but the actual distribution of transactions within a slot may vary.

4. Monitor transaction landing rates

A multi-client network may change the dynamics of transaction landing. Firedancer leaders may process the TPU queue differently, potentially affecting which transactions get included during congestion.

Multi-client benefits

A multi-client network is healthier:

• Resilience: a bug in one client does not halt the network.
• Correctness: two independent implementations catch spec ambiguities.
• Performance: competition drives optimization.

Ethereum’s multi-client ecosystem (Geth, Nethermind, Besu, Erigon) has demonstrated these benefits. Solana is moving in the same direction with Agave and Firedancer.

Timeline

Check the Firedancer GitHub repository and Jump Crypto announcements for current status.

FAQ

Do I need to change my programs for Firedancer? No. Firedancer executes the same SBF bytecode with the same runtime semantics. Your deployed programs work without changes.

Will RPC methods work the same? Yes. Firedancer implements the same JSON-RPC API. Your existing RPC calls, including sendTransaction, getAccountInfo, and WebSocket subscriptions, work as before.

Does Firedancer affect priority fee behavior? The priority fee mechanism is part of the runtime spec and works the same. However, Firedancer’s higher throughput may reduce congestion pressure, potentially changing the effective priority fee market.

Should I use a Firedancer RPC node? You can. Firedancer nodes expose the same RPC API. The choice between Agave and Firedancer RPC nodes is primarily about the provider’s infrastructure, not API compatibility.

Updated: 2026-10-21