Firedancer: what changes for RPC, landing, and CU on mainnet

Firedancer: what changes for RPC, landing, and CU on mainnet. Jump Crypto’s C/C++ client has been producing real blocks since December 2025. This is not a recap of who migrated which box. It is what that share of stake does to the assumptions in your send path.

The short version

You do not get a Firedancer SDK. You do not get a new CU opcode. The cluster still agrees on one block, one account model, one cost formula. If your integration already talks JSON-RPC and signs versioned transactions, you keep that.

What moved is the leader. For some slots the packer is Jump’s tile, not Agave’s scheduler. That changes how greedy the block fills, how bundles land, and whether the node you happen to be talking to will answer historical RPC at all.

Client census and the five-client map live in Firedancer and the Solana validator client landscape. CU caps live in 100M CU blocks and the 12M account cap. Bundles live in Jito Bundles. This piece is the overlap: app code meeting a mixed-client cluster.

Two binaries, one gossip identity

Jump ships two shapes from the same repo. Frankendancer is Firedancer’s networking, signature verify, and pack glued onto Agave’s runtime and consensus. Firedancer is the full rewrite. Operators pick one. Gossip still shows a version string; it does not hand your dapp a feature flag.

Live count, 27 Aug 2026, from wenfiredancer.com: about 10.7% of stake, 45 of 697 validators, versions in the 0.x line the tracker treats as Firedancer family. That number moves daily. Do not hard-code “40% Jump” from a mid-year blog into a runbook. Re-read the tracker when you care.

Solana Beach said in late August they are running full Firedancer v1.1.4 on the live box with Agave as a hot spare in another data center. That is the operator pattern that matters for you: the slot you are trying to enter might be packed by either client, even for the same staker, across failovers.

RPC: same JSON, different machine

Public RPC providers still speak Agave-shaped JSON-RPC. Your wallet adapter, Metis router, and Yellowstone subscriber do not switch dialects when Firedancer stake ticks up. For most product work, Firedancer is invisible.

It stops being invisible if you pointed reads or sendTransaction at a validator RPC. Firedancer docs are blunt here:

• The rpc tile implements a subset of the Solana RPC API. Frankendancer’s JSON-RPC is still Agave’s, with Firedancer flags passed through (port, full_api, private).
• Production tuning turns transaction_history and extended_tx_metadata_storage off. History is expensive. A node optimized to lead will not keep your signature-status archive.
• Private RPC is the default posture: bind localhost or do not publish the port in gossip. Firewall it. That node is not your product RPC.
• Sending QUIC transactions to Firedancer over loopback needs accept_local=1 or the kernel drops the response. This is an operator footgun, not an app API change.

Practical rule: keep using a dedicated RPC (Helius, FluxRPC, PublicNode, your own Agave/Yellowstone box). See FluxRPC and RPC providers compared. Do not scrape getProgramAccounts off a leader.

Landing: who is leader this slot

Landing is still “did this leader include my bytes.” Firedancer’s pack tile is the scheduler when that validator is leader. Official websocket docs expose three schedule strategies:

• perf - fill the block as fast as possible.
• balanced - middle.
• revenue - wait as long as possible before filling. More time for better-paying traffic.

You cannot ask the cluster which strategy the next leader is on. You can assume a mix. A revenue leader will look “slower” to a low-fee swap and “correct” to a tipped bundle. That is economics, not a consensus bug.

Pack skip reasons in the Firedancer API are worth knowing by name, because they show up as “didn’t land” in your sender:

• fail_cu_limit - this tx would blow the block compute budget.
• fail_write_cost - account write cost (the hot-account cap, not the global 100M).
• fail_fast_path / fail_slow_path - account conflicts.
• Scheduled but not landed: failed bundle, duplicate, bad fee payer.

Bundles still exist. Firedancer records txn_from_bundle per tx. Jito-compatible engines still feed 1-5 transaction microblocks that fail or succeed together. If you need atomicity, keep the bundle path. If you only need inclusion, priority fees plus a sane CU price still work. Dual-route. Do not drop Jito because “Firedancer is faster.” Faster ingress is not a landing SLA.

CU: the protocol did not move with the client

SIMD-0286 raised the block compute limit to 100M CUs. The writable account cap is still 12M. Those numbers are cluster rules. Firedancer executes them. It does not raise them because the networking tile is in C.

Two traps in RPC responses, called out in Firedancer’s own API docs:

1. getBlock’s computeUnitsConsumed is execution CUs only. It does not include signature cost, data cost, or the rest of the consensus cost formula. Do not budget a program from that field alone.
2. Firedancer’s websocket cost numbers include the full consensus-relevant cost unless they say otherwise. If you mix the two without reading the label, your CU math will disagree with pack.

Simulation still lies about congestion. Simulate, then send with a CU limit you measured on a similar mainnet tx, then bump on fail_cu_limit / exceeded-limit logs. Same playbook as 2024. Client diversity did not retire it.

One million TPS was a hardware demo. Live cluster throughput is still in the low thousands of real user TPS, protocol-capped. Do not size retries, timeouts, or UX copy as if Firedancer stake share equals 1M TPS in your slot.

What not to change

• Transaction encoding, ALTs, address lookup tables, compute budget ix, versioned txs.
• Program IDs. Firedancer is not a new SVM with new builtins for app authors.
• Blockhash / last-valid-block-height windows. Same cluster clock.
• Alpenglow. That is a consensus change from Anza, still on its own calendar. Alpenglow is not Firedancer.

What you should change if you have not already: treat “which client is leader” as weather. Log land/fail by slot. Keep a second RPC. Keep a bundle path for the txs that cannot partial-fail. Re-read wenfiredancer.com when someone on the team quotes a stake share from memory.

// Still the app loop. Client diversity does not replace this.
const bh = await rpc.getLatestBlockhash()
const sim = await rpc.simulateTransaction(tx, { replaceRecentBlockhash: true })
if (sim.value.err) throw sim.value.err
const cu = Number(sim.value.unitsConsumed ?? 200_000)
tx.add(ComputeBudgetProgram.setComputeUnitLimit({ units: Math.ceil(cu * 1.15) }))
// Then: send + (optional) Jito bundle. Dual-route. Do not aim at validator RPC.

People and links

Resources

• Jito Bundles: atomic execution on Solana
• 100M CU blocks and the 12M account cap
• Agave / Anza
• Firedancer websocket API (pack stats, CU labels)