Solana Firedancer: What 17% of Mainnet Stake Actually Shows (2026)

Solana Firedancer is live on mainnet-beta and it runs 16.94% of active stake — 74,080,306 SOL across 69 voting validators, measured at epoch 1065, slot 460,489,190, on 23 October 2026. That is the number almost nobody publishes, and it is the only number that answers the question people are actually asking.

Page one for this keyword is a wall of explainers that describe what Firedancer will do, news posts about what it might do next, and a Reddit thread asking what it is. Several still say the goal is "to deliver a fully independent validator by the end of 2024". None of them tell you how much of the network is running it today, whether it performs better than Agave in practice, or whether the client-diversity problem it was built to solve has actually been solved.

So this article measures it. Two RPC calls give you the stake split by client. A public validator dataset gives you per-validator skip rates, so the performance claim can be tested rather than repeated. Every figure below is dated, and the commands are in the article so you can re-run them and get your own numbers tomorrow.

Yes. Firedancer has been running on mainnet-beta for months, and at epoch 1065 it is the second-largest validator client by stake. Here is the full split across the 666 validators that were voting and not delinquent when we measured.

Client	Validators	Active stake (SOL)	Share of stake
Agave (Anza)	597	363,234,399	83.06%
Firedancer	69	74,080,306	16.94%
Frankendancer	0 active (2 delinquent)	1,796 (delinquent)	0.000%

Two details in that table matter more than the headline. The first is that Firedancer holds 10.36% of the validators but 16.94% of the stake — the average Firedancer operator runs 1.64 times the stake of the average validator. Adoption is concentrated among large operators, not spread evenly. Four of the ten largest validators on the network run it, including the one operated by Jupiter, which at 9,726,420 SOL is the single biggest Firedancer node and the fifth biggest validator overall.

The second is that Frankendancer — the hybrid that put Firedancer's networking layer in front of Agave's runtime — is finished. Two validators still broadcast a Frankendancer version string and both are delinquent, holding 1,796 SOL between them. Every explainer that describes Firedancer as "currently a hybrid called Frankendancer" is describing software that no longer carries meaningful stake.

Solana does not expose a "client" field, which is why so few pages publish this split. You have to infer the client from the version string, then weight it by stake. Two unauthenticated calls do it:

# 1. version per gossip node, keyed by identity pubkey
curl -s https://api.mainnet-beta.solana.com -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getClusterNodes"}'

# 2. activated stake per validator, keyed by nodePubkey
curl -s https://api.mainnet-beta.solana.com -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getVoteAccounts"}'

Join the two on nodePubkey and read the client off the version number. The scheme is documented in Firedancer's own release guide, and it is unambiguous once you know it:

• vYY.MM.PATCH — full Firedancer. A new release line every month, patches for bug fixes. Everything numbered 26.* today is Firedancer.
• v0.xxx.yyyyy — legacy Frankendancer, for example 0.1105.40200.
• 4.x.y (and older 1.x, 2.x, 3.x) — Agave, maintained by Anza.

Across the whole gossip network, not just voting validators, there are 138 Firedancer nodes: 124 on v26.10.4, 9 on v26.10.3, 5 on v26.10.2. The spread between 138 gossip nodes and 69 staked validators is RPC and unstaked infrastructure, which is worth remembering if you see a raw node count quoted as an adoption figure. Stake is the measure that decides what the network does; node counts are not.

Firedancer's own FAQ states it plainly: "Frankendancer was a hybrid of the Agave validator and Firedancer's network components. Support for Frankendancer ended when the Alpenglow cluster upgrade is activated on mainnet."

That condition has now been met, and it happened recently enough that most coverage has not caught up. When we published our Solana Alpenglow upgrade status check on 5 October 2026, the SIMD-0326 feature gate account did not exist on mainnet. It does now:

curl -s https://api.mainnet-beta.solana.com -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getAccountInfo",
       "params":["A1pengvuM6JEcyNuTnMqepBKhwHE3N6PmUrdATGawhJS",
                 {"encoding":"base64"}]}'

# -> data "AQCsZRsAAAAA" = Some(459648000)

A feature account holds an Option<u64>: one tag byte then the activation slot, little-endian. Decoded, the tag is 1 and the slot is 459,648,000, which is exactly 1064 × 432,000 — the first slot of epoch 1064. getBlockTime on that slot returns 1792589765, or 21 October 2026 at 13:36:05 UTC. Alpenglow went live on mainnet two days before this article was measured, and that is what ended Frankendancer.

Firedancer's release notes line up with the same timeline. v26.10.2, the first mainnet-ready build with Alpenglow support, warns that "migration from Tower to Alpenglow will not be supported" — operators had to cut over cleanly rather than upgrade in place. v26.10.1 added a safety rail: the validator "will now abort if running in Alpenglow mode on a non-Alpenglow cluster or vice-versa, or at the epoch boundary where Alpenglow activates". Deliberately halting at the boundary is the correct behaviour, and it is a reasonable explanation for the four Firedancer validators that are currently delinquent.

Skip rate is the honest performance test for a validator client. It measures the share of slots a validator was assigned as leader but failed to produce a block for. A skipped slot is a block that never existed, so for anyone sending transactions it is pure added latency. Stake-weighted across the active set at epoch 1065:

Measure	Firedancer	Agave
Stake-weighted skip rate	0.0863%	0.4664%
Median validator skip rate	0.000%	1.339%
Validators with a zero skip rate	58 of 69 (84%)	188 of 597 (31%)
Stake-weighted uptime	99.974%	99.815%
Delinquent share of client	4 of 73 (5.5%)	64 of 665 (9.6%)

Taken at face value that is a 5.4-times lower skip rate, and it is the kind of number a marketing page would stop at. It should not be taken at face value, because of the concentration we already found: Firedancer operators are larger than average, and larger operators run better infrastructure regardless of which software they run.

The way to separate the client from the operator is to compare Firedancer and Agave validators of similar size, so the hardware and staffing budgets are roughly matched. Bucketed by activated stake:

Stake bucket	Firedancer skip rate (n)	Agave skip rate (n)	Ratio
Over 1M SOL	0.0463% (14)	0.0705% (94)	1.5x
300k to 1M SOL	0.1318% (22)	0.5037% (78)	3.8x
100k to 300k SOL	0.4671% (27)	1.7621% (252)	3.8x
Under 100k SOL	0.0000% (6)	5.0085% (173)	sample too small

Firedancer is ahead in every bucket where there is enough of it to measure, so the client itself is doing something real. But the margin collapses at the top: among validators over a million SOL, where 78% of Firedancer's stake sits, the gap is 1.5 times rather than 5.4 times, and both clients are already under 0.08%. The honest reading is that most of the headline difference is selection — the operators who adopted Firedancer first were already the ones with near-zero skip rates — and that the remaining advantage is real but small where it matters most.

The mid-size buckets are where the client difference is clearest, and they are also where there is the most room to improve: a 1.76% skip rate on an Agave validator holding 100,000 to 300,000 SOL is nearly 18 missed blocks in every thousand leader slots. The bottom bucket, where Agave averages 5.01%, is dominated by small operators on thin hardware, and there are only six Firedancer validators down there to compare against — which is itself part of the story in the hardware section below.

The strongest argument for Firedancer was never throughput. It was that Solana ran on one codebase, so one bug could stop the chain. Firedancer's own documentation makes exactly this case: "As a second validator codebase, Firedancer removes the risk of a single point of failure."

Removing that risk has a measurable threshold. Solana needs two-thirds of stake to agree before anything is finalised, so a client holding more than 33.34% of stake can stall the network by failing all at once, and a client holding more than 66.67% could in principle finalise a bad fork on its own. Against those two lines, at epoch 1065:

• Firedancer at 16.94% is below both thresholds. If every Firedancer validator went offline simultaneously today, the remaining 83% would keep producing and finalising blocks. That is a genuine improvement and it is new.
• Agave at 83.06% is above both. A consensus bug that only affects Agave still stops Solana. The single point of failure has not been removed; it has been reduced from 100% of stake to 83%.

For Agave to fall to 33.34%, Firedancer would need to roughly double: +71,982,806 SOL has to move, on top of the 74 million it already has. For context on how concentrated the decision is, we walked the validator list from largest to smallest and found that 18 validators reach the 33.4% mark, and six of those eighteen already run Firedancer. Client diversity on Solana is not a grassroots outcome; it is a decision made by a few dozen large operators and the stake pools that delegate to them, which is also why where you stake your SOL is a governance choice and not only a yield choice.

One more concentration figure worth knowing: Firedancer's five largest validators hold 51.5% of all Firedancer stake. The client's footprint is not just small relative to Agave, it is itself top-heavy.

Running two independent codebases only removes correlated failure if the machines are independent too. They are substantially not. Grouping the active set by the network each validator is hosted on:

• TeraSwitch hosts 20 of 69 Firedancer validators (29%), carrying 18,188,808 SOL, or 24.6% of all Firedancer stake. The same provider also hosts 69 Agave validators carrying 99,402,385 SOL — 27.4% of Agave's stake.
• Allnodes hosts 10 Firedancer validators and 69 Agave validators. Cherry Servers hosts 4 and 44.
• Germany is the most common country for both clients — 29 of 69 Firedancer validators and 164 of 597 Agave validators.

So a datacentre-level or jurisdiction-level event hits both clients at once, and the three largest hosting providers carry a share of stake comparable to the entire Firedancer client. Software diversity is only one of the independence axes, and it is the one that gets measured because it is the one that is easy to measure. This is the same reasoning that applies when you pick an RPC provider or compare QuickNode and Triton for order flow: a second vendor is not redundancy if it sits in the same rack.

A smaller but cleaner contrast from the same data: Firedancer's stake-weighted commission is 11.95% against Agave's 29.83%. Both have a median of 5%, so the gap is driven entirely by the tail of validators charging 100% commission — 57 Agave validators holding 97.8 million SOL do, against 6 Firedancer validators holding 6.7 million. If you stake through a liquid staking protocol or a validator basket, that tail is the thing those products are filtering out on your behalf.

Here is the part that affects anyone sending transactions rather than running a validator, and it is a direct consequence of the Alpenglow activation that retired Frankendancer. Alpenglow moves consensus votes off the ledger into aggregated BLS certificates. Measured over 30 minutes of getRecentPerformanceSamples on 23 October 2026:

• 4,181,171 transactions, of which 5 were vote transactions. Votes used to be the majority of everything in a Solana block. They are now effectively absent from the ledger.
• 493.5 transactions per slot, 2,323 transactions per second, essentially all of it real user activity rather than consensus overhead.
• 212.5 ms per slot, measured as 8,472 slots over 1,800 seconds — not the 400 ms figure that most documentation and most articles still quote.

Both of those shifts matter for execution. Block space that used to be consumed by votes is now available for swaps, and the interval in which your transaction has to reach the leader has roughly halved. That tightens every latency budget in the stack: a bot that was comfortably inside one 400 ms slot may now be arriving a slot or two late, which shows up to the user as slippage rather than as a latency metric. It is also why priority fee behaviour and MEV and block packing deserve a fresh look rather than a 2024 mental model.

Firedancer is relevant to that stack in one more specific way: it implements Jito-style bundles natively. Its glossary defines a bundle as "a sequence of transactions packed atomically without reordering or interleaving other transactions", delivered "via Jito gRPC protocol via the bundle tile". In practice 68 of 69 Firedancer validators have Jito MEV enabled, against 563 of 597 on Agave — so moving to a reimplemented client has not changed how bundles reach leaders, which is the mechanism sniper bots and copy trading systems depend on to land in a specific block.

Firedancer's rationale page argues that "improved performance also means current performance needs can be achieved with lower cost hardware", which "should encourage additional validator operators to join the network who were otherwise prohibited by current hardware requirements". Its own hardware page asks for more than Agave does:

Requirement	Firedancer minimum	Agave recommendation
CPU	24 cores at over 2.8 GHz	12 cores / 24 threads
RAM	256 GB (512 GB ECC recommended)	256 GB or more
Disk	2 TB PCIe Gen3 NVMe, high TBW	1 TB accounts + 1 TB ledger + 500 GB snapshots
Binaries	None published — build from source	Prebuilt x86_64 AVX2 builds (being retired)

The core count is the one to notice: Firedancer's stated minimum is double Agave's recommendation. That does not make the performance claim false — the client is doing more work per core and the release notes report real gains, including mainnet memory use cut "from 183 to 159 GiB" and snapshot loading "down to 40 seconds for mainnet" in v26.10.2. But the documented entry ticket is higher, not lower, and our own measurement agrees: the median Firedancer validator holds 303,765 SOL against the median Agave validator's 167,952, and only six Firedancer validators run under 100,000 SOL. If the goal was to widen the operator base, that has not happened yet.

The operational details are also heavier than a one-line install, and they are worth knowing before anyone treats Firedancer as a drop-in:

• There are no prebuilt binaries. The FAQ is explicit: "Firedancer does not provide pre-built binaries. Run make -j to build the validator," and you need roughly 32 GiB of memory available just to compile it.
• Builds are not portable. Firedancer detects the host and emits architecture-specific instructions, so "binaries built on one machine may not be able to run on another" unless you set a MACHINE target explicitly.
• It needs privileged setup on every boot. firedancer configure init all must run as root to set up kernel-bypass networking, carries a documented warning that it "may make permanent changes to your system", and has to be re-run after each reboot.
• There is a documented failover path back to Agave. Since v26.10.2 the validator can write an Agave-compatible tower or Alpenglow vote history file as it runs, and firedancer wait blocks until the node reaches a safe state to fail away from. That is a sign of a team that expects operators to need an exit.

Firedancer ships on calendar versioning: a new release line every month, patch releases for fixes, and a main branch the docs say "should not be used". What the mainnet data shows is how fast that cadence actually propagates.

v26.10.4 was published on 21 October 2026 at 15:46 UTC — about two hours after Alpenglow activated — to fix "an issue where Firedancer gossip table disagrees with Agave causing high traffic and busyness". Within roughly 48 hours, 65 of 69 staked Firedancer validators were on it, holding 96.7% of all Firedancer stake. Agave's distribution is similar at the top, with 568 of 597 on 4.3.2, but it carries a tail that Firedancer does not have yet: seven validators still voting on version 1.9.20 and three on 1.13.5, release lines years behind the current one.

The repository itself is unusually active for a project with this few maintainers. As of 23 October 2026: 1,559 commits in the last 90 days, 1,534 stars, 541 forks, 154 all-time contributors but only 13 distinct authors across the most recent 100 commits, 314 open issues and 213 open pull requests, written in C, licensed Apache-2.0, with the latest commit landing the same day we measured. A 17%-of-stake validator client being carried by roughly a dozen active committers is worth stating plainly — it is a thin bus factor by the standards of the stake it secures, and it is the same pattern we found across the open-source trading bot landscape.

Firedancer runs a bug bounty and publishes its third-party audits, which is more than most infrastructure does. The gap is which version those audits cover.

The firedancer-io/audits repository contains five reports: Atredis Partners and Neodyme on Firedancer v0.1, Neodyme on v0.4, and two Cure53 audits of the GUI/HTTP layer and the metrics component. Its most recent commit is dated 7 May 2025, and the newest report in it is the v0.4 audit. There was also an Immunefi audit contest, held 10 July to 21 August 2024, ahead of the v0.1 mainnet launch.

Every one of those covers the Frankendancer line. No public audit report exists for the v26.x full-Firedancer releases that now carry 74 million SOL. The security policy is candid about the boundary — "code outside the scope of the bug bounty program is still in development. It has yet to go through more rigorous security testing and auditing" — and a query of GitHub's global advisory database returns zero advisories affecting Firedancer. The accurate statement is that nothing has been published, not that something was found; it is the same distinction we drew when checking whether a bridge program had a reproducible build.

Credit where it is due on one point competitors never check: Firedancer publishes a software supply chain document listing every vendored dependency — nanopb, picohttpparser, Fiat-Crypto, musl libc, bzip2, s2n-bignum, blst and Zstandard, nine items in total, all C or assembly. The same document omits Frankendancer "because of Agave's extremely large and rapidly changing set of dependencies", which "would therefore be impractical to adequately document". That is Firedancer's own doc making the supply-chain argument for a from-scratch C client better than any blog post could.

Has Firedancer been released?

Yes. Firedancer is released and running on Solana mainnet-beta. At epoch 1065 on 23 October 2026 it held 74,080,306 SOL, or 16.94% of active stake, across 69 voting validators. The current mainnet release is v26.10.4, published 21 October 2026.

What is the difference between Firedancer and Frankendancer?

Frankendancer was a hybrid that ran Firedancer's networking layer in front of Agave's runtime and consensus code. Full Firedancer replaces all of it with a from-scratch C implementation. Firedancer's FAQ says Frankendancer support ended when Alpenglow activated on mainnet, which happened at slot 459,648,000 on 21 October 2026. Only two delinquent validators holding 1,796 SOL still broadcast a Frankendancer version.

What is the Solana Firedancer release date?

There is no single date, which is why the question keeps getting re-asked. Firedancer ships monthly release lines named vYY.MM.PATCH, and the version running on most of its mainnet stake today is v26.10.4. Rather than looking for a launch date, read the current share directly with a getClusterNodes plus getVoteAccounts pair and count the stake on 26.* versions.

Does Firedancer increase Solana TPS?

Not by itself, and not in the way the headline claims suggest. Measured over 30 minutes on 23 October 2026, mainnet ran 2,323 transactions per second at 493.5 transactions per slot and 212.5 ms per slot. Throughput on Solana is set by what users actually send and by protocol-level limits, not by how much headroom one client has. What Firedancer changes is the ceiling and the skip rate, not today's load.

Does Firedancer fix Solana client diversity?

Partly. Firedancer at 16.94% is below the roughly 33.34% threshold at which a single client failing could stall the network, so a total Firedancer outage would no longer stop Solana. Agave at 83.06% is still above that threshold, so an Agave-only consensus bug still would. Firedancer would need to roughly double, about 72 million SOL more, to push Agave under the line.

Can I run a Firedancer validator?

Technically yes, but the bar is high. The documented minimum is a 24-core CPU, 256 GB of RAM and a 2 TB NVMe drive, there are no prebuilt binaries so you compile from source with around 32 GiB of memory available, and a privileged configure step has to run at every boot. The measured adoption reflects that: the median Firedancer validator holds 303,765 SOL and only six run under 100,000 SOL.

Do I need to care about Firedancer if I just trade on Solana?

Only for one reason, and it is not the client itself. The same upgrade that retired Frankendancer took consensus votes off the ledger and brought slot times to 212.5 ms, so blocks now carry close to 100% real transactions and the window to reach a leader is about half what most documentation still describes. If your execution path was tuned against a 400 ms slot, it is worth re-checking.

The useful habit here is not following client-adoption numbers — it is refusing to accept a performance claim without a measurement. Every figure in this article came from two public RPC calls, one public validator dataset and a GitHub repository, and the most interesting findings were the ones that contradicted the marketing: a 5.4-times skip-rate advantage that shrinks to 1.5 times once you control for operator size, and a hardware bar that doubled while the stated goal was to lower it. The same standard is why uwuu publishes a trader leaderboard you can audit on-chain instead of a screenshot, and why the fee is performance-based — you pay only when a copied trade actually makes you money.