Builds_Writing_The Pit_Firedancer_
  • Builds
  • Compositions
    • Research
    • Macro
    • Spotlights
    • News
    • Podcasts
    • Media
  • Chronicle
  • The Pit
  • Firedancer
  • Careers
  • Connect
  • Brand & Press
Terms of Use_Privacy Policy_Disclaimers_

Firedancer FAQs

We don't have all the answers. But we have most.


Jump Crypto is helping to build a second, fully independent consensus node implementation for the Solana network. A consensus node is the core piece of technology that validators use to agree on the chain’s state (blocks and transactions).

The Solana protocol’s primary goal is to achieve a leading degree of decentralization with performance close to what the hardware is physically capable of. Firedancer hopes to significantly improve both decentralization and performance.

It’s hard to understate the benefits a second consensus implementation — it removes a single point of failure, the Solana Labs client implementation. With 1/3+ of the stake running on Firedancer, no single client will have a supermajority on the network.

Right now, Solana’s throughput isn’t limited by hardware, but by software inefficiencies. As high-frequency trading engineers, Jump is used to operating at the very limits of what hardware is physically capable of. We will bring Jump’s performance engineering mindset to Solana’s scaling challenges.

Jump has always been a major contributor to, and validator and RPC node operator, in the Solana ecosystem. We had been helping with performance analysis and improvements for a long time. While the idea seemed daunting at first, by the time we proposed it to the Solana Foundation, we were already imagining all the ways we could optimize our own node implementation!

We hope to make significant progress on Firedancer over the next 12-24 months. All development is open source and happens in public—you can watch, discuss, and contribute to it. We’ll be seeking early input from the whole ecosystem in how to build a node implementation that best serves the community.

Firedancer’s core will be implemented in C/C++. Jump is built on C++, and the company has decades of experience in writing highly reliable and performant C++ code—including many proprietary libraries and concurrency primitives, some of which will be open sourced for the first time as part of the Firedancer project.

Today, C++ remains the language of choice for high-performance systems that require very low-level access to the underlying hardware. The amount of flexibility and tooling—especially for performance analysis—is unparalleled, and Jump has a long history of leveraging it to build some of the world’s fastest programs and supercomputers.

We love Rust, but since our goal is to bring the number of shared dependencies between both projects as close to zero as possible, it is not a sensible choice of implementation language. While initial releases will include Rust compatibility shims, our goal is to entirely remove any common supply chain risk between the Solana Labs implementation and ours.

We are evaluating a number of higher-level languages other than Rust for less performance-critical and auxiliary parts of the code base as well as formal verification approaches that compile down to C.

Solana is a complex piece of software. Some of the main components are:

  • • A core networking and concurrency layer which allows all the other components to efficiently talk to each other with as little overhead as possible.
  • • A storage layer that maintains and updates account state while minimizing the amount of disk utilization.
  • • Transaction replay engine for native and eBPF programs.
  • • Block generation and optimization on the leader and Turbine, Solana’s block propagation layer which broadcast proposed blocks in the network.
  • • Gossip and other auxiliary infrastructure that allows nodes to talk to each other.

Outcomes — for users

Firedancer will be designed to optimally use the hardware it runs on and avoid overheads such as copying data too many times, inefficient locking or NUMA-unaware memory allocation. These techniques come naturally in trading, but are seldom used in standard software engineering, with the current Solana Labs implementation being no exception. Among other things, Firedancer will use zero-copy networking to bypass most of the operating system’s kernel network stack and comes with its own queues and other concurrency primitives, but most importantly, it will be designed by a team with decades worth of experience writing highly efficient software.

“Mechanical sympathy” - understanding your platform’s constraints and using it to the fullest extent - becomes increasingly more important as throughput grows, various scaling limits are hit and the room for inefficiencies shrinks. In particular, Solana will eventually have to process 10 gigabit and beyond of network traffic, which becomes increasingly difficult.

Yes. Firedancer simply adds more resiliency to the ecosystem. Performance of the Solana Labs implementation is already continually improving, and we assume it will progress alongside the Firedancer implementation and benefit from architectural and design advances in Firedancer.

Outcomes — for developers

Yes. Firedancer will be implementing the Solana protocol piece by piece, and will have to rely on the existing implementation during the development effort. To facilitate this, the Solana Labs and Firedancer teams will agree upon a common interface that will allow both implementations to run side-by-side.

Yes. Performance improvements directly translate to being able to process more transactions with less hardware.

Firedancer will eventually be an entirely separate node implementation, with similar (likely lower) hardware requirements than the Solana Labs client.


Decentralization means increasing the number of people or nodes that need to misbehave (or be coerced to) in order to halt or compromise the network. Firedancer helps by making validation more accessible, by reducing implementation risks that would affect large portions of the stake at once and by adding a second independent core engineering team.

The Nakamoto Coefficient can never be high enough! But regardless: Decentralization isn’t just a validator numbers game, but more importantly, it is a question of network governance, independence of any centralized entity and the elimination of shared risks equally affecting all nodes.


Jump has deep experience with over 20 years of scaling networks and building highly performant software systems. We have the ability to apply our full research and development prowess to solve the issue of scale for the Solana blockchain.

As said best by Yakovenko, Co-Founder of Solana, “By adding more core contributors like Jump Crypto, the network can maintain its status as the best place to build in web3, while scaling to billions of users. I’m excited for Jump’s engineers to bring a new perspective to the network and help improve network resiliency and efficiency.”

Kevin Bowers has a background in computational physics and has worked with pushing supercomputers to the extremes of scale his entire career. While at Jump Trading, he has creatively dealt with interesting bottlenecks like the speed of light. This has allowed him and his team to create highly performant systems that focus on increasing robustness and resilience. His experience as a systems architect and scientist at places like Jump Trading, D.E. Shaw Research, Los Alamos National Lab, Bell Labs, and Berkeley has made him the perfect candidate to help strengthen Solana’s core infrastructure.

Terms of Use_Privacy Policy_Disclaimers_

© 2022 Jump Crypto. All Rights Reserved.