Scale or Die at Accelerate 2025: Dropped Transactions & Empty Blocks (Michael & Philip | Firedancer)

Firedancer, the highly anticipated Solana client, is now live on mainnet and capturing significant stake. Developers Michael McGee and Philip Taffet reveal impressive performance metrics and innovative strategies for maximizing block efficiency under current compute unit (CU) limits.

Summary

Top Projects

Lulo

Score: 7,586.13

Bonk

Score: 4,806.12

Sphere

Score: 2,544.42

Moonwalk

Score: 2,026.11

The Firedancer team has announced that their Solana client is now live on mainnet, having acquired over 5% of network stake. Performance data shows Firedancer outperforming other clients, particularly during high-stress events like the Trump token launch. The client demonstrated superior block production and transaction processing capabilities, even under extreme network conditions.

However, the developers highlighted a critical issue: despite Firedancer's advanced capabilities, Solana's overall transaction throughput remains constrained due to CU limits imposed on blocks. This revelation led the team to shift focus from raw speed to intelligent block production strategies.

The presentation detailed the evolution of Firedancer's architecture, from its initial design to current optimizations. A key focus was on developing "Goldilocks rules" for optimal block packing, balancing speed, parallelism, and prioritization of high-fee transactions. These strategies aim to maximize validator revenue and network efficiency within existing constraints.

Lastly, the team unveiled new tools for transaction analysis and validator performance tracking, along with a delegation program to incentivize adoption of Firedancer validators.

Key Points:

Firedancer Mainnet Performance

Firedancer has successfully launched on Solana's mainnet, securing over 5% of network stake. Performance metrics demonstrate the client's superior capabilities, particularly in handling high-stress scenarios. During the Trump token launch, widely considered one of the most challenging events for the network, Firedancer nodes did not drop a single transaction during TPU ingress and maintained excellent scheduling efficiency.

Comparative data shows Firedancer consistently outperforming other clients in block production quality, even under extreme network loads. This performance translates to increased fee capture and revenue generation for the Solana network, highlighting the potential impact of widespread Firedancer adoption.

Compute Unit Limit Challenges

Despite Firedancer's impressive performance, the team identified a significant bottleneck in Solana's overall transaction throughput. The compute unit (CU) limit imposed on blocks restricts the network's ability to fully leverage Firedancer's capabilities. This constraint has forced the development team to shift their focus from raw speed to intelligent block production strategies.

The CU limit has emerged as a recurring theme in Solana's scaling challenges, affecting various aspects of network performance from dropped transactions to unfilled blocks. The Firedancer team emphasized the need for the broader Solana ecosystem to address this limitation to unlock the full potential of high-performance clients like Firedancer.

Evolution of Firedancer Architecture

The presentation provided insight into Firedancer's architectural evolution. Initially, the system used a high-speed transaction ingestion front-end coupled with Solana Labs code for execution. However, this design was bottlenecked by limitations in the Solana Labs codebase.

Subsequent iterations placed Firedancer's parallel account checker (PAC) in control, allowing for better scaling and parallelism. Optimizations like fast bitsets for conflict detection significantly improved performance. However, the team discovered that raw speed alone was not the optimal strategy under CU limits, leading to the development of more nuanced packing strategies.

Goldilocks Rules for Optimal Block Packing

To address the challenges posed by CU limits, the Firedancer team developed a set of "Goldilocks rules" for optimal block packing:

1. Don't pack too fast: Slowing down transaction execution allows for better sampling of incoming transactions and potentially higher fee capture.
2. Don't pack too slowly: Starting execution too late risks underfilling blocks.
3. Use appropriate parallelism: Balancing between sequential and parallel execution to maximize high-priority fee capture while ensuring blocks are filled.

These rules led to the development of a dynamic execution strategy that adjusts the number of execution threads based on the current position within the block time and the remaining CU budget. This approach aims to maximize fee capture and block efficiency within the constraints of the CU limit.

New Tools and Visualizations

The Firedancer team unveiled a suite of new tools and visualizations to aid in understanding and optimizing validator performance. These include:

1. A detailed block visualization showing CU usage and bank utilization over time.
2. Transaction-level analysis tools allowing for filtering and examination of individual transactions within a block.
3. Comprehensive fee and CU consumption metrics for both included and excluded transactions.

These tools are designed to provide validators, developers, and users with unprecedented insight into block composition and transaction processing. The team emphasized their commitment to making these tools publicly accessible to foster greater understanding and innovation within the Solana ecosystem.

Delegation Program and Community Engagement

Recognizing the challenges validators face in adopting new clients, the Firedancer team announced a delegation program. This initiative aims to incentivize validators to run Firedancer by offering SOL matching and staking support. The program, accessible at delegation.firedancer.io, represents a significant effort to accelerate Firedancer adoption across the Solana network.

The team also highlighted their commitment to community engagement and transparency. By making performance data and analysis tools publicly available, they aim to foster a collaborative approach to network optimization and encourage broader participation in Solana's technical development.

Facts + Figures

• Firedancer has acquired over 5% stake on Solana's mainnet
• During the Trump token launch, Firedancer nodes did not drop a single transaction during TPU ingress
• Firedancer can execute between 60 and 45 million CUs in 400 milliseconds with a single execution thread
• The client uses fast bitsets for conflict detection, significantly improving transaction scheduling efficiency
• Firedancer's block visualization tool provides insights into CU usage and bank utilization over 400-millisecond intervals
• The new transaction analysis tool allows filtering and examination of individual transactions within a block
• Firedancer's performance tracking includes metrics such as block size, speed, CU utilization, and fee capture
• The delegation program is launched at delegation.firedancer.io to incentivize validator adoption
• Firedancer's GUI shows near-zero CPU utilization during idle periods, demonstrating efficiency
• The client can lazily execute entire mainnet blocks on a single CPU core

Top quotes

1. "Firedancer is alive. We're running on Mainnet. We have been for a while. We're slowly acquiring stake. We now have a little bit over 5%."
2. "Even under incredible stress, Firedancer is still cruising, still able to produce really good blocks."
3. "Turns out there is a CU limit that you've heard a lot about. It's placed on blocks. It restricts what you can do."
4. "We realized that with one execution thread, we could often capture, with one executing only with one execution thread was always safe."
5. "We may not be out of pack bigger blocks right now, but we'll certainly pack better ones."
6. "It's kind of like every problem on this chain somehow ends up being the CU limit, whether it's a drop transaction, it's a bug, an unfilled block, that's a mistake."
7. "We decided why not build this visualization. Here it is, live a block we produced."
8. "We collect a bunch of data internally to track the performance of the validator. We want to make sure it's doing well. That's how we showed you those charts earlier. We track everything."

Questions Answered

What is Firedancer and how is it performing on Solana's mainnet?

Firedancer is a new client for the Solana blockchain that has recently gone live on mainnet. It has acquired over 5% of network stake and is showing impressive performance metrics, particularly during high-stress events. Firedancer nodes have demonstrated superior block production and transaction processing capabilities, outperforming other clients in terms of block quality and efficiency, especially under extreme network loads.

How does Firedancer handle high-stress network events?

During high-stress events, such as the Trump token launch, Firedancer has shown exceptional resilience and efficiency. The client did not drop a single transaction during TPU ingress and maintained excellent scheduling efficiency. This performance translates to increased fee capture and revenue generation for the Solana network, highlighting Firedancer's ability to handle peak network activity without compromising on transaction processing.

What is the main challenge facing Solana's transaction throughput, according to the Firedancer team?

The main challenge identified by the Firedancer team is the compute unit (CU) limit imposed on blocks in the Solana network. Despite Firedancer's advanced capabilities and speed, this CU limit restricts the overall transaction throughput of the network. The team emphasized that this constraint has become a recurring theme in Solana's scaling challenges, affecting various aspects of network performance from dropped transactions to unfilled blocks.

How has Firedancer's architecture evolved to address performance challenges?

Firedancer's architecture has undergone significant evolution. Initially, it used a high-speed transaction ingestion front-end coupled with Solana Labs code for execution. Later iterations placed Firedancer's parallel account checker (PAC) in control, allowing for better scaling and parallelism. The team also implemented optimizations like fast bitsets for conflict detection. Most recently, they've developed intelligent block packing strategies to maximize efficiency within the constraints of the CU limit.

What are the "Goldilocks rules" for optimal block packing in Firedancer?

The Firedancer team developed three "Goldilocks rules" for optimal block packing:

1. Don't pack too fast: Slowing down allows for better sampling of incoming transactions.
2. Don't pack too slowly: Starting execution too late risks underfilling blocks.
3. Use appropriate parallelism: Balance between sequential and parallel execution to maximize high-priority fee capture while ensuring blocks are filled. These rules guide a dynamic execution strategy that adjusts based on the current position within the block time and remaining CU budget.

What new tools has the Firedancer team developed for transaction analysis?

The Firedancer team has unveiled several new tools for transaction analysis and validator performance tracking. These include a detailed block visualization showing CU usage and bank utilization over time, transaction-level analysis tools for filtering and examining individual transactions within a block, and comprehensive fee and CU consumption metrics. These tools aim to provide unprecedented insight into block composition and transaction processing for validators, developers, and users.

How is the Firedancer team encouraging adoption of their client?

To encourage adoption of Firedancer, the team has launched a delegation program accessible at delegation.firedancer.io. This program offers SOL matching and staking support to validators who run Firedancer. Additionally, the team is making their performance data and analysis tools publicly available to foster transparency and collaboration within the Solana ecosystem. These efforts aim to accelerate Firedancer adoption and encourage broader participation in Solana's technical development.