Solana’s ACE: A New Fairer Execution Model

Solana processes thousands of transactions per second at minimal cost, which is often lauded as a genuine engineering achievement that has attracted developers and traders alike. Yet as high-frequency trading systems and on-chain order books have progressed on the network, a subtler problem has come into focus: how transactions are ordered matters just as much as how quickly they confirm.

This insight has prompted the Solana ecosystem to identify market microstructure as the network’s single most pressing unsolved problem. The response came in the form of the “Internet Capital Markets” (ICM) roadmap, a community-authored blueprint co-written by leaders from the Solana Foundation, Anza, Jito Labs, DoubleZero, Drift, and Multicoin Capital. At the center of that roadmap sits Application-Controlled Execution, or ACE, a framework designed to give applications direct authority over how their transactions are sequenced and executed.

Solana’s Single-Leader Problem and Why It Hurts Traders

To understand why ACE matters, first, it helps to understand the structural issue it aims to solve.

Today, Solana operates a single-leader model, where one validator at a time controls which transactions are included in a block and the order thereof. While the system does not go as far as to explicitly favor one class of participant over another, the practical result of periodic auction windows in the scheduler is that takers (those placing orders) have effective priority over makers (those providing liquidity).

This dynamic creates a persistent disadvantage for market makers. When prices make a sudden move, makers are forced to cancel their stale quotes before a taker can fill against them at an outdated price. And yet, since takers usually land their transactions first, makers often face being picked off. This whole thing inevitably brings about thinner liquidity, wider spreads, and, in the end, an environment that is structurally susceptible to Maximal Extractable Value (MEV) extraction.

The ICM roadmap identifies six key microstructure trade-offs that applications should be free to resolve on their own terms: 

• privacy or transparency?
• speed bumps or unfettered trading?
• inclusion, finality, or latency?
• colocation or geographic decentralization?
• makers-first or takers-first ordering?
• flexible or opinionated architecture?

In simpler terms, if those are affordable, it implies enforcing a single answer at the protocol level, Solana’s strategy is to build infrastructure that lets developers experiment with these trade-offs in production.

What Is ACE on Solana?

Application-Controlled Execution is a framework that gives smart contracts millisecond-level authority over how their own transactions are sequenced. It shifts control away from validators and into the hands of application developers themselves.

Instead of relying on a single leader to decide transaction order, applications under ACE define custom execution logic. A decentralized exchange, for instance, could choose to process maker cancellations before taker fills, impose speed bumps on aggressive orders, run in-block mini-auctions, or apply quote protection rules. The key principle is that the application, not the block producer, sets the rules of engagement.

A practical form of ACE is already available today through Asynchronous Market Queues (AMQs). In the simplest terms, AMQs are designed in such a way that they enable programs to batch instructions from multiple users and sort them according to application-defined rules before execution.

Furthermore, this whole approach is fundamentally different from relying on pure first-come, first-served ordering, as it often happens in the vast world of trading. Importantly, AMQs can be implemented within existing Solana programs without altering the core protocol.

That said, AMQs reduce atomicity and degrade composability between programs, because asynchronous instructions cannot be atomically composed with other programs whose execution is deferred, which matters for developers weighing on whether this model fits their use case.

Full ACE at the protocol level has a relatively simple goal, which is to work in tandem with Multiple Concurrent Leaders (MCL). The latter is a longer-term upgrade that is set to allow multiple validators to propose transactions simultaneously.

Working at once, ACE and MCL are reasonably expected to eliminate the single-leader bottleneck entirely, and thus enable true parallel validator participation and fairer sequencing across the network.

ACE Roadmap: BAM, DoubleZero, and Alpenglow

ACE does not exist in isolation. A series of supporting technologies, each targeting a different time horizon, forms the broader infrastructure layer that enables or complements application-controlled execution.

BAM (Block Assembly Marketplace)

A near-term solution from Jito Labs that turns Solana’s blockspace into a programmable environment. BAM provides developers with a much-sought-after opportunity to integrate custom sequencing logic directly instead of tireleslly modifying the validator client. It also delivers a practical version of ACE today through a decentralized, TEE-powered network. This version enables central limit order book (CLOB) plugins with transparent, deterministic execution. Think of BAM as the first concrete step toward giving applications control over their own order flow.

DoubleZero

A dedicated fiber network that replaces the public internet for Solana block propagation. It reduces latency and jitter across the network, enabling multicast hardware acceleration and protecting validators from denial-of-service attacks. This frees up validator resources that can be redirected toward lower execution latency and increased blockspace. DoubleZero has been live on mainnet beta since October 2025 and is expected to continue rolling out across mainnet validators.

Alpenglow

It’s Solana’s next-generation consensus protocol. It targets block finality in roughly 150 milliseconds. It’s a dramatic improvement from the approximately 12.8 seconds required under the current consensus model. Alpenglow also simplifies consensus logic considerably, making it easier to design and implement future upgrades such as MCL and asynchronous program execution (APE).

MCL (Multiple Concurrent Leaders)

As far as MCL goes in this particular context, multiple validators are expected to propose transactions simultaneously. In turn, it would provide Solana with the ability to ingest real-time global market signals in parallel. In a somewhat practical example, if critical price information emerges in one region, traders there could update prices through a nearby validator rather than waiting for data to travel across the world. MCL’s timeline is contingent on Alpenglow’s stable deployment.

Everstake: From Early Solana Validator to Institutional Infrastructure Provider

As ACE and its supporting technologies mature, the performance demands on market participants grow substantially. Transaction inclusion speed, data latency, and uptime all become more critical in an environment where applications compete to land custom-sequenced transactions within tight time windows.

Everstake has operated as a Solana validator since the network’s early days, part of the foundation of validators that helped establish Solana’s decentralized security.  This deep validator expertise directly informs the infrastructure products Everstake has built for professional Solana participants. Rather than offering only standard staking services, Everstake has developed a dedicated Solana product suite tailored to the high-performance environment that ACE-era markets demand.

How SWQoS Gives Your Transactions Priority Access to Solana Blockspace

As far as the formal definition goes, Stake-Weighted Quality of Service (SWQoS) is described as a mechanism that prioritizes transaction forwarding in strict dependence on the originating validator’s stake weight. In practical terms, the more stake a validator holds, the higher its priority when forwarding transactions to the current block leader.

Everstake’s SWQoS product provides clients with consistent, priority access to blockspace through exclusive routing and guaranteed throughput, even during peak network demand. The service is backed by the observed uptime of 99.98%.

SWQoS is most relevant to DeFi protocols, trading bots, market makers, and real-time applications that cannot afford delayed or missed transactions. With the emergence of ACE, which is an arrangement where applications compete to land custom-sequenced transactions within tight time windows, priority access to blockspace turns out to be an honest, structural operational advantage. Most crucially, this particular advantage is capable of definitively determining whether a cancellation lands before a fill, or whether a liquidation executes on time.

What Is Solana ShredStream and Why Does It Matter for Low-Latency Applications?

A “shred” is a fragment of a Solana block. The network splits blocks into data and coding shreds for parallel propagation, which is what enables Solana’s fast block times. Validators with a higher stake receive shreds earlier through Solana’s stake-weighted Turbine propagation topology, giving them a built-in informational advantage over less well-positioned infrastructure operators.

Everstake’s ShredStream is based on a very simple and honest premise of delivering raw shred data directly to clients before blocks are fully confirmed, thus providing earlier visibility into the on-chain state than standard RPC or WebSocket feeds and saving hundreds of milliseconds compared to conventional data sources.

For latency-sensitive applications, such as market makers, liquidation bots, and arbitrage strategies, seeing block fragments earlier enables faster reactions and better positioning. Everstake provides global redundancy across multiple geographies, SLA-backed reliability, and transparent pricing for the service.

ShredStream and SWQoS are designed to work in tandem. ShredStream provides earlier visibility into network state, while SWQoS ensures that the transactions you submit in response land with priority. Together, they form a complete infrastructure edge for participants operating in high-performance on-chain markets.

What to Expect from ACE on Solana

ACE, BAM, DoubleZero, Alpenglow, and MCL form a compounding roadmap that extends through 2027 and beyond. Their emergence can be easily seen as a structural evolution of how markets function on-chain.

For builders, this roadmap opens a permissionless sandbox for experimenting with market structures that would be nearly impossible to test in traditional finance. Speed bumps, quote protection, order privacy, and custom auction mechanisms all become tools available to any developer willing to deploy them.

For market participants, the trajectory points toward fairer execution, where an application’s own rules govern transaction ordering rather than the discretion of a single validator.

Everstake’s SWQoS and ShredStream are built for this trajectory. The products of an early Solana validator that understands the network’s infrastructure at a foundational level. They are designed to deliver the speed, reliability, and priority access that the next generation of on-chain markets will require.