What is Firedancer?
Jump Crypto - a trading company now serving the infrastructure field - created Firedancer, a new Solana validation client. Firedancer, which was constructed completely from the ground up utilizing C, does not include any code from the original Agave fork that makes Jito-Solana, which was made possible by Firedancer. While Agave can be brought down by a crash that has nothing to do with the bug, Firedancer can survive, and vice versa.
Firedancer’s networking and block production components are added to Agave’s runtime in Frankendancer, the transitional edition. You know what this means? It’s like putting a new kitchen in a house without having to move out completely while you live there. In other words, you don’t get rid of all of your furniture and move in a tent and then live with that for two years. First, you build a new kitchen, you then use the new kitchen while still living in your old bedrooms, and after that you replace them one by one, room by room. Instead of placing their stakes on a whole, as-yet untested rebuild, Frankendancer permitted validators to add new plumbing bit by bit.
How Firedancer Works and What It Has Shown
By creating independent CPU core-pinned tiles, Firedancer rethinks the validation as a set of loosely coupled components. While one tile is responsible for the reception of packets, one verifies the signatures and one builds blocks. The system can achieve a much higher level of processing capacity than a standard configuration. Firedancer has exceeded 600,000 transactions a second in live testing on small testnets. The aim of 1 million TPS will eventually be reached. Mainnet TPS is much lower than what the network could achieve because, in practice, the size of a block is constrained not by the speed of the client but by the number of computation units that can be included in a consensus slot. Currently, a 400ms slot can include only 100M CUs.
Firedancer v1.0.0, which is a complete Firedancer validator client and not the partial hybrid, will be ready around June 2026 after a few years of Frankendancer with real stake being run in production environments. Firedancer currently accounts for around 15-25% of mainnet stake as of the summer of 2026, with the goal of reaching 50% by the end of that same year. As of the time of this writing, the Solana Compass website is displaying the progress of Firedancer adoption, including an update on how many validators have adopted Firedancer.
How Firedancer Compares to Ethereum’s Client Landscape
Ethereum has successfully solved the problem of a single-client failure mode years ago by having many diverse, independently maintained clients: Geth, Nethermind, Besu and Erigon. The Ethereum community considers a client with more than 66% of the network stake as a systemic risk to Ethereum. If a supermajority of the clients on Ethereum contained an invalid state finalization bug, the community could be forced into a network restart.
For the first six years of its existence, the Solana network operated using a single lineage of code. Some outages in 2022 were a direct result of a single codebase bug. Firedancer is the first viable Solana alternative, a second implementation. Ethereum never had an equivalent performance problem with client implementations; its base chain throughput is only around 15-20 TPS, with scaling handled via L2 rollups. This is why none of the Ethereum teams is working to achieve hundreds of thousands of TPS on the L1. Firedancer is built by Jump, which is a high frequency-trading company, and thus employs kernel-bypass networking and memory layout techniques to get the most out of each CPU cache and memory load instruction. The tight deadlines of a 400ms slot on Solana make these kinds of techniques more valuable and applicable.
