Solana in 2026: Technical Roadmap

By: Dean Hanson

Solana’s 2026 technical roadmap reinforces its position as institutional-grade infrastructure by prioritizing predictable finality, execution integrity, bandwidth and latency improvements, and validator client diversity to support an Internet-native capital market.

Solana’s 2026 technical roadmap is about hardening the network into something institutions can treat as infrastructure, not just a high-throughput chain. Rather than chasing headline TPS, the focus shifts to predictable finality, execution integrity, and redundancy.

This blog walks through four pillars of that evolution:

1. Alpenglow: A consensus rewrite
2. ACE: A new fairer execution model
3. IBRL: Bandwidth and latency improvements
4. Validator client diversity: Redundancy and competition

Together, they outline how Solana is positioning itself as a credible backbone for an Internet-native capital market.

This article is the technical companion to our executive guide Solana in 2026: A Guide for Financial Institutions , which focuses on strategy, use cases and organisational impact.

1. Alpenglow: Laying the Foundation for Predictable Consensus

Alpenglow is Solana’s next consensus protocol upgrade, designed to stabilize block production and synchronization under heavy network conditions.

How Solana Works Today

At the time of writing, Solana combines a proof-of-history-driven leader schedule with a Tower BFT-style voting system on block “shreds.” Leaders are pre-assigned slots by stake-weighted PoH. They produce blocks as shreds. Other validators vote on them, and votes are recorded on-chain.

Alpenglow is Solana’s next consensus protocol upgrade, designed to stabilize block production and synchronization under heavy network conditions.

Why Alpenglow Matters for Institutions

• Predictability and finality: Reduces uncertainty in transaction ordering and confirmation times, which are essential for funds and market operators that rely on deterministic execution.
• Operational resilience: Improves fault tolerance at the validator layer, reducing the risk of downtime or partial halts.
• Upgrade path stability: Enables future innovations (such as ACE) without compromising chain safety.

These qualities move Solana closer to the operational characteristics of traditional financial infrastructure, where continuity and determinism matter more than theoretical peak throughput.

2. ACE: Fairness and Control

ACE (Application Controlled Execution) introduces configurability into how applications interact with the network. Instead of relying solely on validators and builders to decide transaction order, applications can influence how their own transactions are processed.

The MEV problem

Solana, like many blockchains, is vulnerable to MEV. This is where searchers and validators profit by exploiting pending transactions and block structure.

Even without a traditional public mempool, leader-schedule predictability, local queues, and priority-fee markets create opportunities for order-flow exploitation and opaque routing.

Institutions need to demonstrate that their orders were handled in accordance with clear, auditable rules. MEV runs counter to best-execution obligations and fair-access expectations.

Why ACE Matters to Institutions

ACE enables applications to control how their transactions are executed on Solana. Rather than treating execution as purely the validator’s domain, ACE allows programs to define or constrain aspects of ordering, batching, or matching logic with:

• Fair order flow control: Financial applications can enforce specific sequencing rules or internal matching logic.
• Reduced MEV risk: By limiting opportunistic reordering, ACE helps align blockchain execution models with regulated best-execution principles.
• Custom execution environments: Banks or funds deploying tokenized markets or structured products could tailor latency or batching behavior for compliance or risk reasons.

New Governance and Block Production Models

For ACE to happen, the Solana ecosystem is reshaping its governance and block-production models to better align with institutional norms:

• Proposal-builder separation. Separating block construction from block proposal introduces competition among block builders and clearer roles, echoing multi-venue execution in equities markets and reducing censorship.
• Multiple concurrent proposers (MCP). Enabling multiple validators to simultaneously propose blocks introduces parallel block production and distributed proposal rights, echoing market-making competition across multiple exchanges, and reduces single-point censorship while increasing network throughput.

These changes reduce concentration risk, improve transparency, and align Solana’s architecture with principles familiar to regulated markets: separation of duties, competition, and auditability.

The Roads to ACE

The evolution toward Application-Controlled Execution (ACE) is already in progress with examples including:

JitoBAM

JitoBAM (Block Assembly Marketplace) introduces a modular transaction layer built on top of the Solana blockchain. BAM operates using Trusted Execution Environments (TEEs), which create an encrypted mempool where transactions remain private until execution, reducing exploitative MEV such as sandwich attacks. This separates block construction responsibilities:

• BAM Nodes handle transaction sourcing and prioritization in secure enclaves.
• Validators maintain execution and consensus.

The plugin framework enables Application-Controlled Execution (ACE), allowing developers to define custom transaction ordering logic tailored to their specific applications. Use cases include:

• Instant oracle updates, with Pyth able to update prices just-in-time.
• Cancel-before-take policies for market makers that protect against adverse selection.
• Custom sequencing for perp exchanges and CLOBs.

ACE’s promise is infrastructure-level fairness, giving institutional applications predictable, auditable control over how trades, payments, or transactions are realized on-chain.

Harmonic

Harmonic introduces an open aggregation layer that turns block building into a competitive marketplace rather than a single-source pipeline. It continuously collects and evaluates block proposals from multiple independent builders including Jito, Temporal, JitoBAM, and Paladin, presenting them to validators in real-time for selection.

Validators can continuously choose from multiple block proposals, aligning Solana’s execution path with familiar multi-venue models in traditional markets. For institutions, Harmonic’s model helps address concentration, fairness, and governance concerns that arise when a single client or builder controls most block flow:

• Reduced concentration risk: Aggregating multiple builders through a neutral layer lowers dependency on any single MEV-aligned client or infrastructure provider.
• Fairer execution paths: Institutions can work with validators who use transparent, policy-driven block selection (for example, preferring blocks sourced from encrypted mempools such as JitoBAM to limit toxic MEV).
• Governance and auditability: Because selection logic is explicit, it is easier to document and attest to how orders flow from application to builder to block, supporting best-execution and fair-access frameworks.

3. IBRL: Performance Optimization with Institutional Predictability

IBRL (Increase Bandwidth, Reduce Latency) is the umbrella under which the Solana ecosystem groups bandwidth, scheduler, and latency improvements, including Alpenglow. Its focus is on user-perceived performance: how quickly transactions are confirmed and how reliably capacity is available during busy market periods.

Institutional Benefits of IBRL

For institutions, IBRL means transaction times that align with operational SLAs and service-level expectations comparable to those of traditional financial networks:

• Lower latency = better market integration. Trading and treasury systems can depend on consistent confirmation windows.
• Higher throughput = better asset-class diversity. A network capable of sustained, predictable flow supports tokenized debt, FX, and derivatives at scale.

4. Validator Client Diversity: Redundancy by Default

Multiple independent clients are a key milestone toward system robustness, a familiar concept for banks that rely on multi-venue market infrastructure.

Solana Validator Clients & Infrastructure:

• Agave (Anza): The reference Rust implementation serves as the primary Solana validator client and baseline against which performance and compatibility are measured.
• Firedancer (Jump Crypto): A complete ground-up reimplementation in C designed for maximum throughput, fault isolation, and client diversity, eliminating dependency on the Agave codebase.
• Frankendancer (Jump Crypto): A hybrid validator merging Firedancer's high-performance networking stack and block production components with Agave's execution runtime and consensus layer, providing immediate performance gains while the full Firedancer client matures.
• Jito-Solana: A performance-optimized fork of Agave that historically included an off-protocol mempool for MEV extraction, commanding the majority of network stake among validators prioritizing MEV revenue.
• Rakurai: A fork of jito-solana incorporating proprietary transaction scheduling and pipeline optimizations that achieve 5x higher TPS and up to 35% greater block rewards through superior block packing, enabling validators to share enhanced yields with delegators.

Block Building Infrastructure:

• JitoBAM (Block Assembly Marketplace): A modular transaction layer operating via Trusted Execution Environments (TEEs) that creates encrypted mempools and enables Application-Controlled Execution (ACE), allowing developers to define custom transaction ordering logic for their applications while reducing exploitative MEV.
• Harmonic: An open block-building aggregation layer that creates a competitive marketplace by continuously collecting and evaluating block proposals from multiple independent builders (Jito, Temporal, JitoBAM, Paladin), then presenting them to validators for selection.

Blockdaemon Operates Multiple Clients

For leading, network-conscious infrastructure providers like Blockdaemon, client diversity means:

• Resilience. No single codebase failure can bring down the network, which is critical when staking supports custody, ETFs, or corporate treasuries.
• Performance optimization. Operators can select clients that best match their hardware, geography, and latency profile, improving both yield and stability.
• Investor confidence. A multi-client network provides redundancy as the default.

Solana in 2026: Implications for Institutional Stakeholders

Solana’s evolution over the past two years signals a deliberate shift from experimentation toward institutional usability. This is continuing to gather pace in 2026, with potential real-world benefits for financial institutions, including:

1. Settlement reliability. Alpenglow and the broader IBRL program aim to deliver predictable, sub-second finality with higher fault tolerance, narrowing the gap between blockchain and exchange-style settlement.
2. Execution integrity. ACE, MEV-aware infrastructure, and proposal-builder separation reduce opaque sequencing and give applications tools to encode and prove their own execution policies.
3. Operational resilience. Multiple independent validator clients and maturing governance processes make the network more robust to software bugs, attacks, and operator failures.
4. Strategic alignment. The Internet Capital Markets vision directly aligns with institutional tokenization, cross-border settlement, and digital-asset market-structure strategies.

If the "Internet Capital Market" vision succeeds, Solana will be among the first to align crypto-native performance with the operational discipline of financial infrastructure.