Jump Crypto: How To Improve Solana?

The pursuit of blockchain performance has long been characterized by grand proclamations about fundamental architectural overhauls, revolutionary consensus mechanisms, and the need for massive infrastructure investments. Yet according to Jump Crypto's engineering leadership, the reality of improving Solana is far more pragmatic—and perhaps more exciting for that very reason. In a recent episode of Lightspeed, Michael McGee from Jump Crypto offered a refreshingly candid assessment of where Solana stands today, where the most significant performance improvements lie, and how the Firedancer client is positioning the network for a future of hundreds of thousands of transactions per second.

Top Projects

Lulo

Score: 7,586.13

Bonk

Score: 4,806.12

Sphere

Score: 2,544.42

Moonwalk

Score: 2,026.11

The conversation revealed a perspective that challenges conventional wisdom about blockchain scaling: the biggest wins aren't hiding behind complex research problems or requiring massive capital expenditure on data centers. Instead, they're found in methodical engineering work, bug fixes, and careful optimization of existing systems. This philosophy has guided Jump Crypto's development of Firedancer and shapes their vision for Solana's continued evolution.

The Sliding Scale of Pain: Prioritizing Problems in Protocol Development

Understanding where to focus engineering resources in blockchain development requires a clear framework for prioritization. According to McGee, the Solana ecosystem operates on what he describes as a "sliding scale of pain" that dictates which problems deserve the most urgent attention. This hierarchy places user experience at the absolute pinnacle of concern, with decreasing urgency as you move further from the end user.

At the top of this hierarchy sits user pain. When a user experiences friction—whether that's a transaction failing to land, excessive wait times, or dropped transactions—it represents the most severe category of problem that demands immediate attention. The reasoning is straightforward: users are the ultimate arbiter of a network's success, and their willingness to continue using Solana depends directly on the quality of their experience.

Developer pain occupies the second tier of this framework. While not as immediately critical as user-facing issues, problems that make life difficult for developers—whether related to SDKs, tooling, or writing secure programs—have downstream effects on the entire ecosystem. Developers build the applications that attract users, so their productivity and satisfaction directly impact the network's growth trajectory.

Validator operator pain comes next in the hierarchy. Issues affecting those who run the infrastructure that powers the network are certainly worth addressing, but they don't carry the same urgency as user or developer problems. These operators have chosen to participate in the network and have typically developed expertise in working around various challenges.

Finally, at the bottom of the priority list, sits core protocol developer pain. McGee noted with characteristic humor that this tier barely registers on the concern scale. If a core protocol developer experiences difficulty, the expectation is simply that they'll figure it out—that's their job, after all. There was even a tongue-in-cheek suggestion that if someone like Anatoly Yakovenko experiences pain, the community might take some satisfaction in it.

This framework isn't merely philosophical; it directly shapes where Jump Crypto and other teams focus their engineering resources. The current emphasis on transaction landing speed and network capacity stems directly from this prioritization—these are the issues that create user pain today.

The Bug Fix Philosophy: Why Solana's Problems Aren't Fundamental

One of the most striking assertions from the discussion was the characterization of Solana's performance challenges not as fundamental architectural limitations, but simply as bugs waiting to be fixed. McGee cited Alessandro from Anza, who advocates for this perspective: the issues preventing Solana from achieving dramatically higher throughput aren't the result of flawed design choices that require massive re-engineering efforts.

"People think these performance problems are like, you know, that they're like foundational engineering challenges. And we need to go and re-architect this and build data centers and route damn water into that. And it's like, no, like the software mostly has bugs. And you can fix them and realize like pretty significant performance wins."

This framing carries significant implications for Solana's development trajectory. Rather than facing years of fundamental research and development before seeing meaningful improvements, the network can achieve substantial gains through systematic identification and elimination of performance bottlenecks. The compute unit increases that have been rolling out represent exactly this kind of methodical improvement.

The candid acknowledgment here is that current throughput numbers—roughly a thousand transactions per second in production—don't reflect the theoretical capabilities of the underlying technology. Private clusters running Firedancer have demonstrated performance far beyond what the mainnet currently achieves. The gap between theoretical capability and production reality represents the aggregate effect of various inefficiencies, bugs, and conservative parameter choices.

McGee suggested that this bug-fixing approach can carry Solana to 200,000 to 300,000 TPS before the network might need to undertake more fundamental re-architecting efforts. The path from current production numbers to that threshold is paved with engineering work that, while not necessarily glamorous, can deliver real results in relatively short timeframes.

The Leader Pipeline: Where Performance Bottlenecks Live

When pressed on specifically where the most significant performance improvements can be found, McGee pointed to the leader pipeline as the primary area of focus. This is the set of processes a validator executes when it's their turn to produce blocks, and it encompasses everything from receiving transactions to packing them into blocks and executing them.

The leader pipeline involves several distinct operations that must occur within tight time constraints. Validators must receive incoming transactions from across the network, verify that these transactions are valid (including cryptographic signature verification), rank transactions by various criteria including fee priority, decide which transactions to include in the block, and execute those transactions to update network state.

Some of these operations, like signature verification, are computationally expensive but parallelizable. This means that regardless of how many transactions are incoming, the validator can simply allocate more CPU cores to handle the load. These operations don't represent fundamental bottlenecks because capacity can scale with available hardware resources.

The critical bottleneck, as McGee explained, lies in the scheduling problem—deciding which transactions to include in a block and in what order. This operation is inherently difficult to parallelize because it requires a unified view of all pending transactions and their potential conflicts. Two transactions attempting to modify the same account state cannot be executed simultaneously without risking consistency issues.

"The problem of scheduling, like deciding what goes into a block basically has to be done on a single CPU core, like absent some incredibly novel, like groundbreaking engineering. You pretty much have a list of transactions and they make conflict with each other, right?"

This single-threaded nature of the scheduling problem means that scheduler performance directly caps the network's throughput. No matter how fast other parts of the system operate, the scheduler's limitations determine the ceiling for block production speed.

The Greedy Scheduler Revolution

Understanding that the scheduler represented the key bottleneck, both Jump Crypto's Firedancer team and Anza's Agave team have invested heavily in scheduler optimization. The solution that emerged from both teams' work converges on a common principle: simplicity beats sophistication.

The natural instinct when approaching a scheduling problem might be to develop complex algorithms that analyze transaction dependencies, optimize ordering for maximum parallelism, and make intelligent predictions about which transactions are most valuable. However, this complexity introduces its own performance costs. Every cycle spent analyzing and optimizing is a cycle not spent actually scheduling transactions.

The greedy scheduler approach that both teams adopted takes a radically simpler approach. Transactions are simply processed in order of value (typically measured by fees), with each transaction scheduled for execution as soon as it's determined not to conflict with already-scheduled transactions. There's no complex dependency analysis, no sophisticated optimization—just a straightforward pass through the transaction queue.

"It turns out if you try and do too much complicated work in there, figure out what transactions are dependent on which and do some smart analysis of who can, then you end up just stalling your scheduling."

This insight—that simpler algorithms can dramatically outperform more sophisticated ones in this specific context—represents the kind of practical engineering wisdom that separates production systems from academic exercises. The scheduler doesn't need to find the theoretically optimal ordering; it needs to find a good-enough ordering as quickly as possible.

The convergent evolution of both major Solana clients toward greedy scheduling demonstrates how the competitive dynamic between Firedancer and Agave benefits the entire ecosystem. Lessons learned in one codebase inform improvements in the other, and the network as a whole benefits from having multiple teams attacking the same problems from different angles.

Firedancer's Architecture: Message Buses and Trading System Heritage

Jump Crypto's background as a trading firm significantly influenced Firedancer's architectural choices. The high-frequency trading world has spent decades optimizing for exactly the kind of performance characteristics that blockchain validators need: low latency, high throughput, and deterministic behavior under load.

Central to Firedancer's design is the use of message buses—a pattern borrowed directly from trading systems. Rather than components calling functions on each other directly, different parts of the validator communicate by passing messages through shared channels. This architecture offers several advantages that prove particularly valuable in the blockchain context.

Message-passing architectures naturally support parallelism. Different components can process their respective workloads simultaneously, with the message bus handling coordination. This allows Firedancer to take full advantage of modern multi-core processors without the complexity of managing shared state across threads.

The message bus approach also provides natural extension points for modifications and integrations. External systems can subscribe to message streams to receive real-time data about validator operations, and they can inject messages to influence behavior. This flexibility has proven particularly valuable for supporting the modding ecosystem that has emerged around Solana validators.

The architecture also facilitates isolation. If an external integration or mod has a bug, the message bus provides a natural boundary that can prevent that bug from corrupting the core validator's state or behavior. This isolation is crucial for maintaining both security and performance guarantees even when running third-party code.

Firedancer's Current Capabilities and Future Potential

The performance numbers McGee shared paint an encouraging picture of Solana's near-term trajectory. Even before the compute unit limit increases that are currently in progress, Firedancer demonstrates capabilities far beyond current production requirements.

"In Firedancer, we can already probably do a few hundred thousand TPS if the compute unit limit was raised. I mean, we've run, you know, we run private clusters that can do far beyond that."

This revelation suggests that the software infrastructure is substantially ahead of what the network's current parameterization allows. The compute unit limit—which caps the total computational work that can be included in a single block—represents a deliberate constraint that's being incrementally relaxed as confidence in network stability grows.

The gap between demonstrated capability and production deployment reflects the prudent approach Solana's maintainers take toward network upgrades. Even when the technology is ready, gradual rollouts allow for observation of real-world behavior and quick rollback if unexpected issues emerge. The compute unit increases that have been rolling out follow exactly this pattern.

The engineering work that enabled Firedancer's performance wasn't about fundamental breakthroughs in computer science. Rather, it involved meticulous attention to detail across every component of the validator: custom memory allocators optimized for validator workloads, carefully tuned data structures, elimination of unnecessary copying and allocation, and relentless profiling to identify and eliminate hotspots.

Alpenglow and the Future of Solana's Consensus

While much of the discussion focused on the execution layer improvements that Firedancer delivers, McGee also touched on Alpenglow—the forthcoming consensus protocol upgrade for Solana. Alpenglow introduces several changes to how the network reaches agreement on block validity, though its impact on raw performance differs from the execution layer improvements.

One concrete benefit McGee highlighted relates to how validator votes are handled. In current Solana, votes—the mechanism by which validators signal their agreement that a block is valid—are themselves transactions that must be included in subsequent blocks. This means the leader must receive these vote transactions, schedule them, and execute them just like any other transaction.

Alpenglow changes this model by distributing votes through a separate, out-of-band system rather than including them in blocks as transactions. While McGee characterized this as a "minor improvement" in the context of the broader performance picture, it does reduce the scheduling burden on leaders and frees up block space for user transactions.

The scheduler optimizations discussed earlier remain separate from Alpenglow's changes. The greedy scheduling approach applies regardless of consensus protocol, and the benefits of improved scheduling would accrue whether the network is running current consensus or Alpenglow.

The Modding Ecosystem: Two Possible Futures

One of the more nuanced topics addressed was the role of validator modifications—commonly called "mods"—in Solana's ecosystem. Mods allow validators to customize their behavior beyond what the base client provides, and they've become a significant factor in how the network operates in practice.

McGee outlined two potential futures for the modding ecosystem, one desirable and one concerning. The concerning scenario involves centralization: a single team develops a dominant mod that captures all order flow and determines block construction, with every validator essentially running the same modified code. This outcome would undermine the decentralization that makes blockchain networks valuable.

"A bad future with modding is that one team writes a big mod that kind of says, oh, we're gonna be the team that receives all the order flow and decides how to create blocks and we're gonna win and no one else will be able to compete."

The preferable future involves a vibrant ecosystem of diverse mods, with different validators running different modifications, numerous teams experimenting with different approaches, and good ideas surfacing through competition and adoption. This scenario preserves the evolutionary dynamics that allow blockchain networks to improve over time.

Jump Crypto's position is firmly in support of the latter outcome. They want to enable a thriving mod ecosystem where experimentation is easy and the best ideas can eventually be adopted into the core protocol itself. The architectural choices in Firedancer—particularly the message bus design—specifically support this goal by making it straightforward to build integrations that can observe and influence validator behavior.

The Jito Integration as a Template

The integration with Jito—the leading MEV infrastructure provider on Solana—served as Jump Crypto's initial test case for supporting mods on Firedancer. Jito has achieved significant adoption in the Solana validator set, making it an essential integration for Firedancer to support.

Approaching the Jito integration, the team had to balance several considerations. They wanted to support the integration fully, enabling validators to participate in Jito's block auction system if they chose. At the same time, they needed to maintain Firedancer's core properties: the performance characteristics that enable high throughput and the security properties that protect against various attack vectors.

The solution leverages Firedancer's message bus architecture. The Jito integration can subscribe to relevant message streams to receive information about incoming transactions and pending block contents. It can inject messages to influence which transactions get included. But it operates in what McGee described as a "sandbox"—isolated from the core validator in ways that prevent bugs in the integration from compromising the validator itself.

The experience with Jito is informing Jump Crypto's broader approach to mod support. Within approximately one to two years, they plan to release formal documentation and tooling for building Firedancer mods, creating what McGee described as a "really messy, formally supported way for people to have mods."

Performance Properties and Security Guarantees

The sandbox approach to mod support reflects a broader principle in Firedancer's design: modifications shouldn't compromise the core properties that make the validator valuable. These properties fall into two main categories.

Performance guarantees ensure that the validator can achieve its theoretical throughput capabilities regardless of what integrations are running. A buggy mod shouldn't be able to starve the core validator of CPU time or memory resources. The isolation provided by the message bus architecture helps maintain these guarantees.

Security guarantees protect against various attack vectors that might be introduced through third-party code. The validator handles valuable assets and has significant privileges within the network; a compromised validator could potentially steal funds or disrupt network operations. Proper isolation ensures that mod code can't access sensitive state or interfere with critical operations.

These guarantees are particularly important given that validators have economic incentives to run various optimizations and integrations. If running mods significantly degraded security or performance, the ecosystem would face a difficult choice between optimization and safety. By making mods safe by design, Firedancer allows validators to experiment freely.

The Path to Higher Throughput

The discussion painted a clear picture of Solana's path toward dramatically higher transaction throughput. The network isn't waiting for fundamental breakthroughs; it's executing on a series of incremental improvements that compound to deliver major gains.

The immediate focus is on compute unit limit increases, which are already in progress. These parameter changes allow more computation per block, directly increasing the number of transactions that can be processed. Firedancer's demonstrated ability to handle much higher compute limits than currently deployed means the software is ready for these increases.

In parallel, scheduler improvements across both Firedancer and Agave clients continue to push out the throughput ceiling. The shift to greedy scheduling algorithms has already delivered significant gains, and continued optimization of these critical code paths will yield further improvements.

Network-level improvements, including the changes that Alpenglow introduces, will contribute their own gains. Moving votes out of band, optimizing block propagation, and reducing consensus overhead all increase the network's effective capacity.

The cumulative effect of these improvements, according to McGee's estimates, should take Solana to 200,000 to 300,000 TPS before any fundamental re-architecting becomes necessary. This represents a two-orders-of-magnitude improvement from current production throughput, achieved through engineering execution rather than research breakthroughs.

Competition and Collaboration Between Clients

The presence of multiple validator clients—Firedancer from Jump Crypto, Agave from Anza, and potentially others—creates a dynamic that benefits the entire ecosystem. Teams working on different implementations can learn from each other's approaches while maintaining healthy competition.

The convergence on greedy scheduling illustrates this dynamic. Firedancer's approach to scheduling inspired examination of Agave's scheduler, leading the Anza team to develop their own improvements based on similar principles. Neither team is working in isolation; they're part of a broader community that shares insights and pushes each other toward better solutions.

This multi-client approach also provides resilience against bugs and security vulnerabilities. A bug that affects one implementation is unlikely to affect others, so the network can continue operating even if one client experiences issues. This diversity is a significant advantage over networks that depend on a single implementation.

The relationship between teams involves both competition and collaboration. They compete to build the best validator client, which pushes both teams toward excellence. They collaborate on protocol changes, sharing insights about what works and what doesn't. This balance has proven productive for Solana's development.

Developer Experience and Ecosystem Growth

While much of the discussion focused on validator-level performance, McGee acknowledged that developer experience represents another important area for improvement. The developer pain tier in his hierarchy may not be as urgent as user pain, but it still demands attention.

SDKs, tooling, and documentation all influence how easily developers can build on Solana. Friction in the development process slows ecosystem growth and may push developers toward other platforms. Improving these aspects of the developer experience doesn't grab headlines like TPS improvements, but it's essential work for long-term ecosystem health.

Secure program development is particularly challenging in blockchain contexts. Smart contracts handle real value and can't be easily upgraded once deployed, making bugs especially costly. Tools that help developers write secure code, catch common mistakes, and verify correctness provide significant value to the ecosystem.

The modding infrastructure that Firedancer is developing will also benefit developers building infrastructure and tooling. The ability to observe validator behavior and integrate custom logic opens up possibilities for monitoring tools, analytics systems, and novel services that haven't yet been imagined.

Looking Ahead: The Next Two Years

The conversation provided a glimpse into Solana's likely evolution over the next couple of years. The major themes are clear: continued performance improvements through both client optimization and parameter changes, maturation of the modding ecosystem with formal support and documentation, and gradual rollout of Alpenglow's consensus improvements.

Firedancer's trajectory involves continued performance work alongside the development of formal mod support. The team's goal is to provide a platform that validators can customize confidently, knowing that their modifications won't compromise performance or security. The one-to-two year timeline for formal mod documentation suggests this will be a significant focus.

The compute unit increases will continue rolling out, with each increase taking the network closer to the demonstrated capabilities of optimized clients. This gradual approach allows for careful observation and quick response to any issues that emerge, trading off speed of rollout for safety.

The ecosystem as a whole will benefit from these improvements. Higher throughput enables new applications and use cases that aren't viable at current capacity levels. Better developer tools attract more builders to the ecosystem. A healthy modding community fosters innovation and experimentation.

The Philosophy of Pragmatic Engineering

Throughout the discussion, a consistent philosophy emerged: pragmatic engineering beats grand vision. The teams building Solana's infrastructure aren't chasing theoretical perfection or novel research contributions. They're identifying bottlenecks, measuring performance, and systematically eliminating inefficiencies.

This approach may lack the excitement of announcing revolutionary new architectures or claiming breakthrough capabilities. But it delivers results. The path from a thousand TPS to hundreds of thousands of TPS is paved with countless small improvements, each contributing its part to the cumulative gain.

The "it's just bugs" framing captures this philosophy perfectly. Problems that seem fundamental often turn out to be implementation details that yield to careful engineering. The sophistication isn't in the grand design; it's in the execution.

This mindset extends to how the teams approach new features and capabilities. Rather than building elaborate systems to support theoretical future needs, they focus on solving today's problems well. Features like mod support evolved from specific real-world requirements—supporting Jito integration—rather than abstract architectural ambitions.

Implications for the Broader Blockchain Space

The insights from this discussion have implications beyond Solana. Other blockchain projects face similar performance challenges, and the lessons learned here may prove valuable across the industry.

The emphasis on scheduler performance as the critical bottleneck applies to any blockchain that processes transactions with potential conflicts. The greedy scheduling approach and its success suggest that simple algorithms may outperform sophisticated ones in high-throughput scenarios more broadly.

The multi-client approach, with its combination of competition and collaboration, offers a model for how blockchain ecosystems can organize development. Having multiple teams working on implementations creates resilience and drives innovation, benefits that accrue regardless of the specific protocol.

The pragmatic engineering philosophy—focusing on bug fixes and optimizations rather than revolutionary redesigns—may offer the fastest path to improved performance for many projects. The tendency to attribute performance limitations to fundamental design choices may obscure opportunities for significant gains through straightforward engineering work.

The User-Centric Vision

Ultimately, all of this technical work serves a single goal: improving the experience for users of the Solana network. Every millisecond shaved from transaction latency, every increase in throughput capacity, every improvement in reliability directly benefits the people using Solana-based applications.

The sliding scale of pain keeps this user focus front and center. It's easy for infrastructure projects to become enamored with technical challenges and lose sight of why those challenges matter. The explicit prioritization of user experience over developer convenience, operator needs, and internal engineering considerations keeps the teams aligned on what actually matters.

This user-centric focus also shapes how improvements are rolled out. The gradual approach to compute unit increases, the careful testing of new scheduler implementations, the sandbox approach to mod support—all reflect a commitment to not disrupting users even while pursuing aggressive performance improvements.

The vision of Solana handling hundreds of thousands of transactions per second isn't about impressive benchmarks. It's about enabling applications and use cases that require that capacity, serving users at scale without degrading experience. The technical work is in service of this broader goal.

Conclusion

The conversation with Jump Crypto's Michael McGee reveals a Solana ecosystem that's neither complacent about current capabilities nor paralyzed by the scale of remaining challenges. The path forward is clear: systematic engineering work to eliminate bugs and bottlenecks, careful optimization of critical code paths like the scheduler, gradual parameter increases as confidence grows, and infrastructure support for a healthy modding ecosystem.

The gap between demonstrated capabilities and production deployment represents opportunity. Firedancer can already handle loads far beyond what the network currently processes, and continued improvements from both Firedancer and Agave teams will push those capabilities further. The limiting factor isn't what the technology can do; it's the prudent pace of rollout that ensures stability.

For users and developers building on Solana, this should be encouraging news. The performance improvements they need aren't blocked by unsolved research problems or massive capital requirements. They're coming through sustained engineering effort, and the teams building Solana's infrastructure have both the capability and the philosophy to deliver them.

Facts + Figures

• Solana currently processes approximately 1,000 transactions per second in production, significantly below the theoretical capabilities of optimized validator clients.

• Firedancer can already achieve several hundred thousand TPS if the compute unit limit were raised, with private clusters demonstrating performance far beyond that threshold.

• The scheduler—the component that decides which transactions to include in blocks—operates on a single CPU core and represents the primary bottleneck in the leader pipeline.

• Both Firedancer (Jump Crypto) and Agave (Anza) teams have converged on greedy scheduling algorithms, which simply process transactions highest-value to lowest without complex dependency analysis.

• Signature verification, while computationally expensive, is parallelizable and therefore doesn't represent a fundamental throughput bottleneck.

• Jump Crypto expects Solana can reach 200,000 to 300,000 TPS before requiring fundamental architectural changes, achievable through bug fixes and optimization alone.

• Alpenglow will move validator votes out of band through a separate system, removing them from blocks and freeing up capacity for user transactions.

• Firedancer's architecture uses message buses—a pattern borrowed from high-frequency trading systems—to enable component communication and mod support.

• Jump Crypto plans to release formal documentation and tooling for Firedancer mods within approximately one to two years.

• The Jito integration served as the initial test case for Firedancer's mod support architecture, operating in a sandbox that maintains performance and security guarantees.

• Jump Crypto identifies two possible futures for validator modding: concerning centralization around a single dominant mod, or a healthy ecosystem of diverse mods with many teams experimenting.

• The "sliding scale of pain" prioritization framework places user pain as most urgent, followed by developer pain, validator operator pain, and finally core protocol developer pain at lowest priority.

• Compute unit increases are currently rolling out incrementally, allowing the network to gradually approach the demonstrated capabilities of optimized clients.

• Alessandro from Anza characterizes most performance problems as "just bugs" rather than fundamental engineering challenges requiring massive re-architecting.

Questions Answered

How much can Solana's TPS improve without fundamental changes?

According to Jump Crypto's assessment, Solana can achieve 200,000 to 300,000 TPS through systematic bug fixes and optimization work alone, without requiring fundamental re-architecting of the system. This represents a two-orders-of-magnitude improvement from current production throughput of approximately 1,000 TPS. Firedancer has already demonstrated the ability to handle several hundred thousand TPS in private clusters, with the current limitations being primarily parameter choices like the compute unit limit rather than software constraints. Only beyond this threshold would more fundamental engineering changes potentially become necessary.

Where is the biggest performance bottleneck in Solana validators?

The scheduler, which decides what transactions go into each block, represents the primary performance bottleneck in Solana's leader pipeline. Unlike operations like signature verification that can be parallelized across many CPU cores, the scheduler must maintain a unified view of all pending transactions and their potential conflicts, effectively requiring it to run on a single CPU core. This single-threaded nature makes scheduler performance the ceiling for block production speed. Both Firedancer and Agave teams have invested heavily in optimizing their schedulers, converging on greedy algorithms that prioritize speed over sophisticated optimization.

How does Firedancer achieve its high performance?

Firedancer achieves its performance through meticulous engineering across every component of the validator, drawing on Jump Crypto's background in high-frequency trading systems. The architecture uses message buses for component communication, enabling parallelism and clean extension points. A custom greedy scheduler processes transactions by value without complex dependency analysis, avoiding the performance cost of sophisticated optimization. The team focused on eliminating bugs and inefficiencies rather than pursuing novel research breakthroughs, reflecting the philosophy that most performance problems are implementation details that yield to careful engineering work.

What is Alpenglow and how will it improve Solana?

Alpenglow is a forthcoming consensus protocol upgrade for Solana that introduces several changes to how the network reaches agreement on block validity. One concrete improvement is moving validator votes out of band through a separate system rather than including them as transactions in blocks. This reduces the scheduling burden on leaders and frees up block space for user transactions. However, McGee characterized this as a "minor improvement" in the broader performance context, with the scheduler optimizations being more significant for throughput. Alpenglow represents the consensus layer evolution while execution layer improvements continue separately.

How does Firedancer support validator mods like Jito?

Firedancer supports validator modifications through its message bus architecture, which allows external integrations to subscribe to internal message streams and inject their own messages. The Jito integration served as the initial test case for this capability, with the integration running in a sandbox that maintains Firedancer's core performance and security properties. Mods can observe validator behavior and influence block construction without having direct access to critical state or the ability to compromise the validator. Jump Crypto plans to release formal documentation and tooling for building Firedancer mods within one to two years, supporting a diverse ecosystem of modifications.

What is the "sliding scale of pain" in Solana development?

The sliding scale of pain is a prioritization framework that guides where engineering resources are focused in Solana development. User pain sits at the top as most urgent—if users experience friction like dropped transactions or slow landing times, it demands immediate attention. Developer pain comes next, as friction in building on Solana slows ecosystem growth. Validator operator pain follows, worth addressing but less critical since operators have expertise in working around challenges. Core protocol developer pain sits at the bottom as lowest priority, with the expectation that these team members will simply work through difficulties as part of their job.

Why did both teams converge on greedy scheduling algorithms?

Both Firedancer and Agave teams converged on greedy scheduling algorithms because sophisticated optimization approaches actually hurt performance in this context. Greedy schedulers simply process transactions from highest value to lowest, scheduling each for execution as soon as it doesn't conflict with already-scheduled transactions. More complex approaches that analyze transaction dependencies and optimize ordering spend cycles on analysis that could be spent scheduling. The counterintuitive insight is that finding a good-enough ordering extremely fast outperforms finding an optimal ordering more slowly. This convergent evolution demonstrates how the multi-client approach benefits the ecosystem through shared learning.

What are the two possible futures for validator modding?

Jump Crypto identifies two distinct futures for Solana's validator modding ecosystem. The concerning scenario involves centralization, where one team develops a dominant mod that captures all order flow and block construction, effectively making everyone run the same modified code and undermining decentralization. The preferable scenario involves a vibrant ecosystem with diverse mods, multiple teams experimenting, and different validators running different modifications. This diversity preserves evolutionary dynamics that allow good ideas to surface and potentially be adopted into the core protocol. Jump Crypto actively supports the latter outcome through Firedancer's architecture and planned mod support documentation.

Are Solana's performance limitations fundamental design problems?

No, according to both Jump Crypto and Anza leadership, most of Solana's performance limitations are implementation bugs rather than fundamental design problems. Alessandro from Anza characterizes them as just bugs waiting to be fixed. This perspective suggests that dramatic performance improvements don't require revolutionary re-architecting, building data centers, or solving deep computer science problems. Instead, they come through systematic identification and elimination of inefficiencies across the codebase. The gap between Firedancer's demonstrated capabilities in private clusters and current production throughput supports this view—the software is already capable of much more than currently deployed.