Inside Firedancer: Jump Crypto's Ambitious Rewrite of Solana's Validator Client

The Solana ecosystem has long spoken of Firedancer in almost mythical terms—a new validator client that promises to push the network's performance to unprecedented heights. Built by Chicago-based trading firm Jump Crypto, Firedancer represents one of the most ambitious undertakings in blockchain infrastructure: a complete ground-up rewrite of Solana's validator software. In a revealing conversation on the Lightspeed podcast, Michael McGee, a software engineer working on Firedancer, pulled back the curtain on the project's current state, the enormous challenges his team has faced, and what the future holds for Solana's performance capabilities.

Top Projects

Lulo

Score: 7,586.13

Bonk

Score: 4,806.12

Sphere

Score: 2,544.42

Moonwalk

Score: 2,026.11

The discussion covered everything from the technical intricacies of achieving bit-for-bit conformance with the existing Agave client to the philosophical questions of what blockchain architecture might look like in the future. McGee's candid assessment of both the successes and struggles of the Firedancer project offers a rare window into the engineering realities behind one of crypto's most anticipated infrastructure upgrades.

The Two-Pronged Firedancer Project

Firedancer is not a single monolithic release but rather two distinct components that have followed different development trajectories. Frankendancer, the hybrid version that combines Jump's optimized components with existing Solana Labs code, has been live for over a year and now commands approximately 10% of the network's stake. This incremental approach has allowed the team to ship early and iterate based on real-world feedback while the more comprehensive full Firedancer continues development.

The full Firedancer, which would represent a complete replacement of the Agave client, remains in development and has only been deployed in non-voting mode. McGee explained that the vast majority of the team's engineering effort over the past three years has been dedicated to solving what they internally call the "conformance problem"—the challenge of ensuring that Firedancer's execution matches Agave's results bit-for-bit across every possible scenario.

The team of 20 engineers has been split between these two efforts, with only three or four people working on Frankendancer while the bulk of the team tackles conformance. This allocation reflects the enormous complexity of replicating a live, constantly evolving codebase without introducing any divergence that could cause consensus failures on the network.

The Conformance Challenge: Harder Than Anyone Expected

The conformance problem has proven far more difficult than the Firedancer team initially anticipated. McGee described it as the central challenge that has consumed three years of intensive engineering effort. At its core, conformance requires that both validator clients produce identical outputs for any given input—a requirement that becomes extraordinarily complex when dealing with a protocol as feature-rich as Solana.

"Solana is a pretty complex protocol, a lot of moving pieces, a lot of parts of the protocol, you have to be bit for bit identical," McGee explained. "So there's this really kind of big problem, which is you have this huge code base and we're trying to do a rewrite, but we have to get it to match perfectly."

The challenge is compounded by the fact that Solana has no formal specification. While a brief white paper exists, the actual specification consists of hundreds of thousands of lines of code that serve as the de facto documentation. The Firedancer team has essentially been reverse-engineering the protocol's behavior by examining Agave's source code, often having to dig through multiple layers of implementation to understand why their system disagrees on seemingly minor points.

McGee offered a telling example of the granular level at which conformance must be achieved: "Sometimes the code relies on undocumented features of Rust where it rounds in a certain way when you multiply two floats. We have to replicate like some parts of the Rust language—how does Rust do saturating floating point operations?"

Chasing a Moving Target

Perhaps the most significant factor making conformance difficult is that Solana never stops evolving. The Anza team, to their credit, ships new features at a remarkable pace—a velocity that creates constant challenges for a team trying to build a conformant implementation from scratch.

Solana operates on a two-day epoch cycle, with feature activations possible at the start of each epoch. There is an entire queue of features scheduled for activation, meaning the Firedancer team must constantly adapt their implementation to match new protocol behavior. McGee described this as "building to a moving target," noting that the team has invested significant engineering effort into features that were subsequently deprecated or replaced before Firedancer could ship.

"People always point to Bitcoin or Ethereum and say these guys have seven clients and you can write a new one in a weekend," McGee observed. "Bitcoin hasn't changed since it was developed. Solana is a huge ecosystem with a ton of stakeholders with a constantly iterating code base with new features coming online week by week."

The team has learned to avoid over-anticipating future changes. While they support Solana's evolution, attempting to build toward projected future states has repeatedly burned them when designs changed or features were canceled. This creates a delicate balance between implementing current protocol behavior and not falling too far behind the network's progression.

Alpenglow: A Perfect Example of Development Challenges

Alpenglow, Anza's ambitious redesign of Solana's consensus mechanism, perfectly illustrates the challenges the Firedancer team faces. This fundamental rewiring eliminates proof of history—a component McGee personally implemented over months of painstaking work to create what he believes is the best possible proof of history implementation, fully pipelined with multiple cores feeding into the sequencing process. That work will be discarded when Alpenglow ships.

"We're fully supportive of Alpenglow—it's going to be awesome. It is a perfect example of something that makes our life very, very difficult," McGee acknowledged. Beyond proof of history, Alpenglow replaces the entire Tower BFT consensus algorithm that Firedancer has spent years implementing. Multiple engineers have worked on Tower BFT conformance for years, and all of that code will be deprecated.

The Firedancer team faces an impossible choice: they can either implement current protocol behavior and risk having to redo work when changes ship, or they can build toward future designs and risk being unable to run against current mainnet while waiting for those designs to materialize. As McGee noted, Alpenglow depends on several other changes, has no firm timeline, requires ecosystem-wide agreement, and must pass governance votes before it can be implemented.

Frankendancer's Success Story

Despite the challenges facing full Firedancer, Frankendancer has emerged as a genuine success story. The hybrid client has grown to approximately 10% of network stake and, according to McGee, now performs comparably or better than Agave across virtually all tracked metrics.

"We shipped the initial version probably more than a year ago and kind of been slowly acquiring stake in a pretty cautious way," McGee explained. The team tracks extensive performance data on Frankendancer deployments in production and has worked through the inevitable issues that accompany any initial software release.

The cautious approach to stake acquisition reflects awareness of the risks involved. With the current consensus mechanism, if any client exceeds 20% of stake, an outage in that client could potentially halt the network. The Firedancer team is deliberately growing stake slowly while building confidence in the software's stability and accumulating operational experience.

The Compute Unit Constraint

A central theme throughout the discussion was the compute unit limit that effectively caps Solana's transaction throughput regardless of how performant individual validator clients become. The current limit of 50 million compute units per block translates to approximately 1,000-2,000 transactions per second in practice—far below what Firedancer is capable of processing.

"We've built this incredibly fast validator and we go out and run it on the real network and okay, it does 1,000 TPS the same as all the other software," McGee said. "But it has to. We can't go and stuff a million TPS down everybody's throat."

The constraint exists for good reason: the entire Solana ecosystem must be able to keep pace with whatever throughput the chain produces. This includes RPCs that serve data to applications, exchanges like Coinbase that index blockchain activity, and the Agave client itself. McGee noted that Coinbase struggled when Solana was doing just 1,000 TPS—at a million TPS, they would be offline for years.

The compute unit limit is being raised gradually through a coordinated effort across the ecosystem. Anza's performance team works to make Agave faster, enabling higher limits that the ecosystem slowly adapts to. This measured approach prevents the sudden shock that would occur if throughput jumped dramatically overnight.

Why TPS Matters More Than Block Fullness

When asked whether Firedancer's team primarily measures performance through TPS or block fullness, McGee was unequivocal: TPS is the ultimate goal. The economic value of a blockchain correlates most directly with the volume of transactions it can process, and fees serve as the best proxy for actual economic utility.

"If you're a capitalist, you want to say what is maximizing fees," McGee explained. "That's the most value being created, people willing to pay the most to use it. So ultimately that looks like increasing TPS."

The million TPS prototype that Firedancer demonstrated was "pathfinding"—proving that such throughput is technically achievable with Solana technology and showing the way forward for the ecosystem. A distributed cluster running simulated transactions achieved the milestone, establishing that the target is realistic rather than theoretical.

Block fullness becomes relevant as a secondary optimization while the compute unit constraint remains in place. Since blocks are limited to a certain size, the Firedancer team can differentiate by ensuring blocks are always maximally full and filled as quickly as possible. They've built a scheduler prototype that fills blocks to 100% capacity in just 130 milliseconds when sufficient transactions are available, and this scheduler is already live on the network.

The Scheduling Bottleneck

McGee identified the transaction scheduler as one of the most critical bottlenecks in validator performance. While many operations in block production are parallelizable—like signature verification, which can scale across multiple CPU cores—scheduling inherently requires single-core processing. A single component must maintain a view of all pending transactions and their potential conflicts to determine which can be executed simultaneously.

"You have a list of transactions and they may conflict with each other—they're trying to send funds from the same account. You need a single place that has a view of all of this and really quickly schedules those transactions for execution without trying to send funds from the same account twice," McGee explained.

The Firedancer team built a specialized greedy scheduler that processes transactions from highest to lowest value, attempting to schedule each in turn. Counterintuitively, simpler algorithms outperform more sophisticated approaches that try to analyze transaction dependencies and optimize placement—the overhead of complex analysis stalls the scheduling process itself.

Anza recognized this same limitation and has been working on their own greedy scheduler redesign. This kind of targeted optimization represents the "bugs, not architecture" philosophy that Alessandro from Anza advocates—the performance issues aren't fundamental but rather addressable through focused engineering effort.

Validator Timing Games

The current validator environment creates incentives for timing games that work against user interests. With 400 milliseconds to produce a block and a capped compute unit limit, validators can often maximize profits by waiting until the end of their slot and then selecting the highest-value transactions for inclusion.

"What you kind of want to do is wait until the end of your block and then look at what's the best stuff I received and pack it in really quickly," McGee described. "But this isn't really particularly good for the network. You've now had a 400 millisecond period where you were basically doing nothing."

The result is a network pattern where each leader does nothing for 390 milliseconds and then does work for 10, effectively wasting capacity and increasing latency for users. Transactions submitted early in a slot may not be executed until near the end of the 400-millisecond window.

Raising the compute unit limit would naturally address this behavior. With more work to accomplish, validators couldn't afford to wait as long before starting block production. At sufficiently high throughput, the games become impractical because there's simply too much legitimate work to complete.

The Protocol Solution Philosophy

The Solana development community strongly favors solving problems at the protocol level rather than relying on social consensus or external enforcement. Alpenglow exemplifies this approach to block timing: validators vote on how long blocks take, and if consensus indicates a block took too long, the leader loses their fees. This replaces the honor system with cryptoeconomic incentives.

Sandwiching represents a more challenging problem without obvious protocol-level solutions. While multiple concurrent leaders has been proposed as a potential fix, it requires an extensive development timeline and ecosystem-wide agreement that hasn't materialized. In the meantime, social pressure through transparency tools like Sammy.me—which publicly identifies validators engaged in sandwiching—provides some deterrent.

"If possible, we're looking for protocol ways to solve problems," McGee noted. "At the same time, people complain about sandwiching, but it has been much decreased through other mechanisms."

Supporting Modifications and Block Engine Integration

Firedancer takes a neutral stance on modifications, aiming to support anyone who wants to build on top of the validator software. The team views a diverse ecosystem of mods as preferable to either a single dominant mod controlled by one entity or no mods at all—evolution requires experimentation with different approaches.

The Jito integration served as an initial case study for how to support third-party modifications cleanly. The Firedancer architecture, built on messaging primitives from trading infrastructure, naturally accommodates extensions. Different components communicate through message buses, allowing mod developers to subscribe to internal messages and inject transactions without compromising the core system's performance or security guarantees.

McGee indicated that formal modding documentation and support would be publicized within the next year or two, enabling the broader community to build on Firedancer's foundation.

Private Transaction Ports and Order Flow

The discussion touched on alternative TPU ports and private transaction routing—a topic that arose prominently around SIMD96 debates. McGee drew parallels to US equities market structure, where payment for order flow routes retail trades through market makers like Citadel rather than public exchanges.

This structure, despite criticism, delivers remarkably attractive execution for retail users. Market makers can offer better prices than public order books because they're confident they're not trading against informed participants like Warren Buffett. The spread they must price in is smaller, benefiting the end user.

McGee suggested similar dynamics could benefit Solana users. "If a user wants to buy a token and they go to the lit public market—the order book on chain—they're not going to get a good price. That order book has to account for the fact that Warren Buffett might be the guy coming in to take the bid or the ask."

Private flow routing enables participants to build reputations for fair dealing. Repeated interactions create accountability—a market maker that front-runs customers will lose flow to competitors. On Ethereum, services like the Flashbots Protect guarantee transactions won't be seen or front-run, and similar credibility systems are emerging on Solana.

The Adoption Challenge

Building superior software isn't sufficient for adoption. McGee acknowledged that validators have legitimate costs and concerns that prevent switching from familiar systems. They've purchased hardware optimized for Agave, invested time in operational procedures, and built their businesses around proven technology.

"If you're trying to build a competitor to something that's in the marketplace, you have to do much better. It has to be a step change for people to switch," McGee observed.

The Firedancer team has responded with extensive operator-friendly features. Configuration files are thoroughly documented. Standardized metrics and monitoring tools provide operators with detailed performance reports. Most notably, the team built a visualization GUI for validators—something no other blockchain project has attempted—that has become a significant draw for operators.

The team goes beyond just building software, actively monitoring Frankendancer deployments and proactively reaching out to operators with configuration recommendations or hardware suggestions. This white-glove approach recognizes that superior technology alone won't drive adoption.

The Stake Delegation Program

The Firedancer delegation program emerged from recognition that operators need material incentives to make the switch. Rather than just hoping validators would adopt new software on its merits, the program provides stake to operators running Frankendancer, creating immediate economic benefit that offsets transition costs.

The program serves a crucial secondary purpose: generating the feedback loop necessary for software improvement. Without operators running the software in production and reporting issues, the development team would be working in a vacuum. Early shipping and iterative improvement requires real-world deployment.

"We need to make sure this thing is stable. The whole point of having Frankendancer is we're trying to rebuild this huge code base," McGee explained. "If we went and just did it in a vacuum, drinking Diet Coke in a basement, and came back three years later, we would never actually ship anything."

The 20% Threshold and Liveness Risks

The conversation delved into the nuanced relationship between client diversity and network resilience. The 20% stake threshold is critical because current consensus requires 80% agreement for block finalization. A client with more than 20% stake that experiences an outage could halt the entire network.

This creates two distinct risk categories. The catastrophic scenario involves a security vulnerability like an infinite mint bug that allows an attacker to create unlimited tokens. If all validators run the same client with the same bug, the fraudulent transactions would be validated and the attacker could bridge out billions before anyone noticed—effectively killing the chain.

With 20% or more stake on Firedancer, however, an infinite mint attack would cause the clients to disagree rather than unanimously approve fraudulent transactions. The network would halt rather than process the exploit—a far preferable outcome that preserves the option to restart without stolen funds.

The second, more common scenario involves routine bugs that don't affect security but cause divergence between clients. A minor discrepancy in timestamp calculation, for instance, would cause clients to disagree and potentially halt the network even though the underlying issue is inconsequential. Until there are three or four clients with evenly distributed stake, any single client failure can bring down the network.

McGee emphasized that extensive tooling and test vectors have been developed specifically to minimize divergence risks, and the team has processes to quickly realign Firedancer with Agave if discrepancies occur in production.

Removing the Compute Unit Limit Entirely

When asked what compute unit limit he would set if given the choice, McGee's answer was surprising: remove it entirely. The Solana protocol was designed to let leaders produce blocks that they believe the network can handle, with network consensus providing natural feedback through skipped blocks.

"If I produce this block and everybody's chugging away taking 10 seconds, 20 seconds, 30 trying to replay what I've produced, they should just time out after 400 or 450 milliseconds and say that block was too expensive. Then throw it away."

Under this model, validators would naturally find the optimal block size through empirical observation. They would edge their blocks up toward the limit where they're still accepted, creating organic pressure on slower validators to upgrade hardware or risk falling behind. The network would constantly push toward maximum achievable throughput without requiring development teams to manually adjust parameters.

The current model forces development teams to continuously recalibrate a compute model that imperfectly estimates actual replay time. Different hardware configurations, new instruction patterns, and evolving network conditions create constant drift between modeled and actual costs. Removing the limit in favor of empirical consensus sidesteps this complexity entirely.

The Vision for Solana's Future Performance

McGee's vision centers on creating the infrastructure that enables competition and evolution. Current constraints eliminate meaningful differentiation between validator clients—with capped block sizes and 400-millisecond vote windows, virtually any software can meet the requirements.

"There is nothing driving development teams to go and build a really, really good system for these because it's not going to translate economically. And the same is true of validator operators—they're not fully incentivized today to buy better hardware and move the network forward productively."

Removing artificial constraints would create market forces that reward innovation. Operators with faster hardware and more efficient software could produce larger blocks and earn greater rewards. Those who fall behind would face economic pressure to upgrade. The entire ecosystem would continuously optimize toward maximum performance.

Is Solana the Final Form of Blockchain Design?

When posed the philosophical question of whether Solana represents the platonic ideal of blockchain architecture, McGee's immediate response was no—but with important caveats. Solana in 2020 looks nothing like Solana today, and the network will likely be unrecognizable again in another four or five years. That constant evolution is precisely why Solana succeeds.

"What other blockchain would go and redesign their entire consensus mechanism from scratch and try to ship it in six months?" McGee asked rhetorically about Alpenglow. This willingness to make fundamental changes distinguishes Solana from more ossified networks.

At the same time, certain Solana components represent near-optimal solutions that would persist in any ideal blockchain design. Turbine, the block propagation mechanism, has held up remarkably well and will remain in Alpenglow. Other components, like the stake program with its tens of thousands of lines of complexity, probably fall far short of any platonic ideal.

The key is whether a project can continue adjusting toward better designs or becomes trapped by legacy decisions. Solana's track record suggests continued evolution rather than stagnation.

A Call for Sympathy

McGee closed with a request for understanding from the engineering community about the scale of what Firedancer is attempting. Rewriting a two-million-line codebase is the kind of project that typically fails. Doing it with a new team that must learn the problem space from scratch, while the original team continues developing the target codebase, approaches the impossible.

"In the history of engineering, no one has really been able to rewrite code bases like that," McGee observed. "The fact that we're doing it and we've shipped, and the product is alive and is going to deliver is pretty impressive. It's not something that people recognize—the amount of difficulty and engineering investment and challenge that is involved."

Frankendancer's success and full Firedancer's progress represent remarkable achievements given these constraints. The team has built comprehensive testing infrastructure, shipped working software that outperforms the original client on key metrics, and maintained conformance with a constantly moving target. When full Firedancer finally ships with voting capability, it will stand as one of the most ambitious successful rewrites in blockchain history.

The Path Forward

The Solana ecosystem stands at an interesting inflection point. Frankendancer has proven that Jump's engineering approach delivers real improvements, even within current constraints. The tooling and processes developed for conformance testing provide a foundation for safely shipping full Firedancer. Meanwhile, Anza's aggressive development pace continues pushing the protocol forward with initiatives like Alpenglow.

The combination of a more performant validator client and protocol-level improvements like Alpenglow could unlock significant throughput increases in the coming years. McGee's description of the current state—where obvious optimizations like greedy schedulers and basic bug fixes deliver major performance wins—suggests substantial low-hanging fruit remains to be picked before hitting fundamental limitations.

Perhaps most importantly, the discussion revealed a Solana ecosystem that embraces change rather than resisting it. From proof of history to Tower BFT to compute unit models, nothing is sacred if something better can be built. That willingness to discard even significant engineering investments in pursuit of improvement bodes well for Solana's long-term competitiveness in an evolving blockchain landscape.

Facts + Figures

• Firedancer development has been ongoing since 2022, with a team of approximately 20 engineers working on the project at Jump Crypto.

• Frankendancer currently commands approximately 10% of Solana network stake after shipping initial versions more than a year ago.

• The current Solana compute unit limit is 50 million CUs per block, translating to approximately 1,000-2,000 transactions per second in practice.

• Anza aims to double block space in 2025, potentially raising the limit from 48 million to 96 million compute units.

• Firedancer demonstrated a million TPS prototype on a distributed cluster, establishing the technical feasibility of dramatic throughput increases.

• A new Firedancer scheduler prototype fills blocks to 100% capacity in just 130 milliseconds when sufficient transactions are available, and is already live on the network.

• The 20% stake threshold is critical because current consensus requires 80% agreement—any client above this threshold that fails could halt the network.

• Only 3-4 engineers from the 20-person Firedancer team have worked on Frankendancer; the majority has focused on solving the conformance problem.

• Solana operates on a two-day epoch cycle, with feature activations possible at the start of each epoch, creating a constantly moving target for Firedancer development.

• Visa and MasterCard process approximately 60,000-70,000 transactions per second, representing retail commerce volume that Solana aims to match or exceed.

• Michael McGee personally implemented Firedancer's proof of history system over months of work—code that will be discarded when Alpenglow ships.

• The Firedancer team has invested engineering effort in features that were subsequently deprecated before they could ship, demonstrating the challenge of building against a moving target.

• Sammy.me is identified as a transparency tool for exposing validator sandwiching behavior, reducing the practice through social pressure.

• McGee advocates for removing the compute unit limit entirely, allowing market forces to determine optimal block sizes through empirical network feedback.

• US equities markets are cited as a model for potential order flow arrangements on Solana, where retail users receive better pricing through informed routing.

Questions Answered

What is the difference between Frankendancer and full Firedancer?

Frankendancer is a hybrid validator client that combines Jump Crypto's optimized components with existing Solana Labs code, allowing the team to ship incrementally and gather real-world feedback. It has been live for over a year and currently runs on approximately 10% of network stake, performing comparably or better than Agave across most tracked metrics.

Full Firedancer represents a complete ground-up rewrite of the entire validator software, replacing all Agave code with Jump's implementation. This version has only been deployed in non-voting mode while the team continues solving the conformance problem—ensuring bit-for-bit identical execution with the existing client.

Why has Firedancer taken so long to ship?

The primary challenge is achieving perfect conformance with the Agave client across every possible scenario, which has consumed three years of intensive engineering effort from most of the 20-person team. Complicating matters, Solana has no formal specification, so the Firedancer team must reverse-engineer protocol behavior from source code while simultaneously tracking a constantly evolving codebase that adds new features every few days.

The team has also invested significant effort in features that were subsequently deprecated or replaced before Firedancer could ship. Additionally, fundamental protocol changes like Alpenglow require discarding completed work—including McGee's personally implemented proof of history system—and rebuilding to match new designs.

What is the conformance problem?

Conformance requires that Firedancer produce identical outputs to Agave for any possible input, down to the bit level. This is necessary because validators must agree on blockchain state, and even minor discrepancies—like a nanosecond difference in timestamp calculation—would cause consensus failures.

The challenge extends to replicating undocumented behaviors of the Rust language and understanding implementation details buried deep in Agave's codebase. With no formal specification, the code itself serves as documentation, requiring extensive reverse engineering to achieve perfect matching.

Why doesn't Firedancer's superior performance translate to higher network throughput?

Solana enforces a compute unit limit that caps block size to ensure all ecosystem participants can keep pace—including RPCs, exchanges, other validator clients, and applications that index blockchain data. Even though Firedancer can process far higher throughput in private clusters, it must produce blocks that the rest of the network can replay within the 400-millisecond window.

This limit is being raised gradually through coordinated ecosystem effort, with Anza working to improve Agave performance and allow higher limits. Until the constraint is lifted, Firedancer's performance advantage manifests in how efficiently it fills blocks rather than how many transactions it can theoretically process.

How does Alpenglow affect Firedancer development?

Alpenglow requires discarding significant Firedancer engineering work, including the proof of history implementation that took months to perfect and the Tower BFT consensus code that multiple engineers worked on for years. These components will be replaced by Alpenglow's new consensus mechanism, essentially wasting the investment in recreating them.

The Firedancer team cannot simply build toward Alpenglow early because the timeline is uncertain, designs may change, and building for a future that doesn't materialize would prevent them from running against current mainnet. They must implement current protocol behavior even knowing it will soon be deprecated.

What risks does client diversity create for Solana?

While multiple clients protect against catastrophic security vulnerabilities like infinite mint bugs, they introduce risk of network halts from routine bugs. If Firedancer and Agave disagree on anything—even inconsequential details like timestamp rounding—the network will halt because neither client can achieve the 80% consensus required for progress.

This risk persists until three or four clients exist with evenly distributed stake, at which point a single client's failure could be isolated while others continue operating. Currently, any divergence between clients above the 20% threshold could bring down the entire network.

What would happen if the compute unit limit were removed?

Validators would naturally find optimal block sizes through empirical observation, producing blocks as large as they believe the network can handle. Blocks that take too long to replay would be skipped and leaders would lose fees, creating natural incentives to find the sustainable maximum.

This approach would create market pressure for operators to upgrade hardware and improve software, as falling behind would mean inability to replay blocks and loss of voting rewards. The network would continuously optimize toward maximum achievable throughput without requiring manual parameter adjustments from development teams.

How is Firedancer driving adoption among validators?

Beyond superior performance, the Firedancer team emphasizes operator-friendly features including thoroughly documented configuration files, standardized metrics and monitoring tools, and a unique visualization GUI for validators that no other blockchain project has built. The team actively monitors Frankendancer deployments and proactively contacts operators with optimization recommendations.

The stake delegation program provides material incentives for operators to switch by delegating stake to Frankendancer operators, offsetting the costs of transitioning from familiar Agave setups. This generates the feedback loop necessary for software improvement while gradually building network adoption.

How does Firedancer approach third-party modifications?

Firedancer takes a neutral stance, aiming to support any modifications developers want to build while maintaining core properties of performance and security. The architecture uses messaging buses between components, allowing mod developers to subscribe to internal messages and inject transactions through a clean sandbox interface.

The Jito integration served as an initial case study for this approach. Within the next one to two years, the team plans to publicize formal modding documentation and support, enabling a diverse ecosystem of modifications rather than having a single dominant mod controlled by one entity.