Wen Firedancer

The moment Solana enthusiasts have been waiting for has arrived quietly—exactly as planned. Jump Trading's Firedancer team revealed at Breakpoint 2025 that their completely independent Solana validator client is already live on mainnet, producing blocks, and has become the fastest voter on the entire network. Even more remarkably, they achieved this milestone with no one noticing—a deliberate strategy that chief scientist Kevin Bowers described as his dream scenario.

Summary

Firedancer represents years of intensive development by Jump Trading to create a completely independent second validator client for Solana—one written entirely in C with zero lines of Rust code. The project has reached a critical milestone: it's now live on mainnet, having accumulated over 100 days of runtime across three validators, produced more than 50,000 blocks, and landed over 20 million votes. This "boring" deployment was intentional, as the team believes that truly enterprise-grade blockchain infrastructure shouldn't create excitement—it should simply work reliably.

The presentation detailed remarkable performance optimizations across the validator stack. The team demonstrated how they've achieved sub-minute snapshot loading times (down from 20+ minutes), optimized transaction replay to near-theoretical limits, and created a validator that outperforms all others in voting speed. Frankendancer, the hybrid version combining Firedancer components with Agave, has already grown from zero mainnet stake at Breakpoint 2024 to 20-30% of mainnet stake across approximately 175 validators.

The technical achievements are substantial. Snapshot loading that previously took 20+ minutes for cryptographic verification alone now completes in under two minutes. Transaction replay has been optimized to the point where the replay dispatcher is mostly idle even during live mainnet operation. The team showed live demonstrations of booting a validator from scratch and producing mainnet blocks—all running the full Firedancer client without any Rust dependencies.

Key Points

The Firedancer Philosophy: Infrastructure Should Be Boring

Kevin Bowers opened the presentation by addressing the fundamental philosophy behind Firedancer's development approach. Unlike the typical "move fast and break things" mentality in tech, Jump Trading took a deliberately cautious path to mainnet deployment. Bowers explained that the only time users get excited about infrastructure is when it breaks, comparing their goal to upgrading a power grid—users shouldn't notice when a new generator comes online, they just want the lights to work reliably.

This philosophy stems from a deeper understanding of what blockchain needs to compete with traditional finance and big tech. To provide a credible alternative, blockchain infrastructure must be more reliable, more predictable, and more affordable than existing solutions. An exciting mainnet launch would have meant something went wrong, potentially devaluing not just Firedancer but the entire Solana ecosystem that needed a truly independent second validator.

Frankendancer's Mainnet Success Story

Frankendancer—the hybrid validator combining Firedancer components with Agave—has experienced remarkable growth since its quiet mainnet debut. At Breakpoint 2024, it had only a tiny amount of stake across a couple of validators. By May 2025, it had exceeded 5% of mainnet stake with around 30 validators. Currently, it fluctuates between 20-30% of mainnet stake across approximately 175 validators, running version 0806.

Interestingly, operators have been discouraged from migrating even more stake to Frankendancer. The current level provides adequate real-world production statistics necessary to tune the full Firedancer while minimizing ecosystem risk. This cautious approach demonstrates the team's commitment to responsible deployment over aggressive market capture.

Revolutionary Snapshot Loading Performance

Richard Patel presented the team's work on optimizing snapshot loading—a critical but often overlooked aspect of validator performance. Solana's state consists of approximately one billion small accounts totaling half a terabyte of data. The previous implementation took about 20 minutes just for cryptographic verification, with another 40 minutes for downloading on average cloud storage. Firedancer achieves this in under two minutes.

The optimizations span multiple areas: decompression was parallelized by switching to a multi-frame Z standard compression strategy that allows independent processing of different frames; the account index uses memory gather techniques to achieve 8x speedup through instruction-level parallelism; and the cryptographic verification leverages SIMD (Single Instruction Multiple Data) operations to hash different accounts simultaneously across multiple CPU lanes. Each optimization required understanding hardware limitations and finding clever ways to maximize throughput.

Streamlined Transaction Replay

Philip Taffet explained how Firedancer optimizes transaction replay—essential not just for startup but for ongoing validator operation. The replay dispatcher must decide how to execute transactions in parallel while respecting conflicts (transactions accessing the same accounts). The team applied lessons learned from building the block packer to create a replay dispatcher that approaches theoretical optimal performance.

Key innovations include careful data representation to minimize cache misses—storing transaction metadata in single cache lines where possible—and intelligent scheduling that prioritizes transactions on the critical path. The team uses historical data about account contention to predict which transactions are most likely to block others, allowing them to make smart scheduling decisions even before receiving the complete transaction graph.

Live Mainnet Demonstration

Michael McGee and Anway De demonstrated the full Firedancer client live on stage, booting a validator from scratch and producing mainnet blocks. The demonstration showed the complete pipeline: snapshot download from network peers, decompression, account database insertion, incremental snapshot loading, repair and catchup, and finally block production—all in approximately two minutes.

The validator produced live mainnet blocks that could be verified on block explorers. Perhaps most impressively, the team revealed that Firedancer is now the fastest voter on the Solana network, able to receive shreds, replay them, reach consensus, cast a vote, and send it out in approximately 25 milliseconds. Analysis showed their validator had the highest "vote right" percentage—the frequency of voting on the very next block—of any validator on the network.

Facts + Figures

• Firedancer has accumulated over 100 days of mainnet runtime across three validators
• The full Firedancer client has produced over 50,000 mainnet blocks
• Over 20 million mainnet votes have been landed by Firedancer validators
• Frankendancer now controls 20-30% of mainnet stake across approximately 175 validators
• Solana's state consists of approximately 1 billion accounts totaling half a terabyte of data
• Previous snapshot cryptographic verification took 20+ minutes; Firedancer achieves under 2 minutes
• Decompression throughput increased from 3.5 GB/s (single thread) to 35+ GB/s (parallelized)
• Memory gather techniques achieved 8x speedup for account indexing
• SIMD-optimized Blake3 hashing achieves approximately 8 GB/s throughput per CPU
• Firedancer vote latency is approximately 25 milliseconds from shred receipt to vote submission
• The validator GUI is publicly accessible at firedancer.node.io
• Firedancer is written entirely in C with zero lines of Rust code
• The account index spans approximately 100 GB of DRAM
• Point-to-point network transfers between validators can reach 50 Gbps
• The compression format change (parallel Z standard) adds only 0.2% to snapshot size

Top Quotes

"My dream was to go live on mainnet and nobody noticed." — Kevin Bowers

"Users do not and should not get excited when a generator comes online. They just don't want brownouts." — Kevin Bowers

"There is not a single line of Rust code running here." — Michael McGee

"Dreams do come true." — Kevin Bowers, on Firedancer's quiet mainnet deployment

"The best strategy I have found is you just run faster than everybody else." — Kevin Bowers

"People kind of think there's going to be this big bang moment with Firedancer where one day it's not deployed, the next day it is. And reality is kind of nuanced." — Michael McGee

"When Firedancer was three years ago—it's when we started contributing to the core protocol." — Michael McGee

"For maximum replay performance, the validator needs to find a way to dispatch the packed transactions in a way that exploits possible parallelism. And it needs to do it very quickly." — Philip Taffet

"Firedancer is massively over-provisioned. We've designed it to do a million TPS. And it would, if it could." — Michael McGee

"The chain is already in a lot of ways a product of Firedancer." — Michael McGee

Questions Answered

What is the difference between Firedancer and Frankendancer?

Frankendancer is a hybrid validator that combines Firedancer components with Agave (the existing Solana validator client written in Rust). This approach allows incremental replacement of components while staying in sync with protocol updates. The resulting validators use documented and standardized "tiles" that can be independently developed. Full Firedancer, by contrast, is a completely independent validator implementation written entirely in C with no Agave dependencies. The main remaining Agave components in Frankendancer are the bytecode interpreter and tower consensus.

Is Firedancer actually live on Solana mainnet?

Yes, full Firedancer started voting on mainnet in July 2025 and began producing full blocks on mainnet in October 2025. It's currently running on a handful of Jump Trading's validators with a small amount of stake, having accumulated over 100 days of mainnet runtime, produced more than 50,000 blocks, and landed over 20 million votes. The team expects the number of operators and validators using full Firedancer to grow as they complete external audits and encourage other operators to upgrade.

Why does snapshot loading speed matter for validators?

Snapshot loading is critical for validator recovery and startup. Every minute of downtime costs operators money and is bad for the network. Previous implementations took 20+ minutes just for cryptographic verification of the data. By optimizing decompression, indexing, and verification, Firedancer achieves sub-2-minute loading times. This makes cold starts practical and reduces the operational risk of running validators, as they can recover much faster from restarts.

How does Firedancer achieve such fast voting times?

Firedancer's 25-millisecond voting latency (from receiving shreds to casting a vote) results from optimizing every component in the chain: receiving network packets, replaying transactions, reaching consensus, and transmitting the vote. The replay dispatcher approaches theoretical optimal performance through careful cache optimization and intelligent scheduling that prioritizes transactions on the critical path. The team demonstrated their validator having the highest "vote right" percentage on mainnet.

What optimizations make Firedancer's snapshot loading so fast?

Multiple optimizations contribute to fast snapshot loading: parallel Z standard decompression that processes multiple frames simultaneously; memory gather techniques using instruction-level parallelism for 8x faster account indexing; SIMD-optimized cryptographic verification that hashes multiple accounts across CPU lanes simultaneously; and streamlined data flow that minimizes cache misses through careful data packing. The team requests operators enable parallel Z standard compression to fully benefit from these optimizations.

How does the replay dispatcher find parallelism in transactions?

The replay dispatcher uses directed acyclic graph (DAG) scheduling to identify which transactions can run in parallel without conflicts. It represents transactions as nodes with edges representing conflicts, then schedules transactions with no incoming edges for execution. Critical innovations include minimizing cache misses through compact data representation (fitting up to 13 edges per cache line) and using historical contention data to prioritize transactions on the critical path before the complete graph is received.

What happens when Firedancer officially ships to the broader community?

According to the team, there won't be a "big bang moment." The deployment trajectory will likely mirror Frankendancer's gradual adoption—starting with minimal stake, then growing as more operators gain confidence and migrate. Because the chain isn't currently at capacity, the team expects that "probably nobody will notice" when Firedancer adoption increases. External audits must be completed first, followed by encouraging other operators to upgrade.