The Internet Capital Markets Roadmap

The original mission of Solana was to build the decentralized backbone for Internet Capital Markets (ICM). Increasing bandwidth and reducing latency (IBRL) are absolutely necessary—but not sufficient to achieve this. The third pillar of Solana’s roadmap needs to address the intricacies of market microstructures. There are a lot of moving parts in markets, all of which have large, sometimes difficult-to-reason-about effects on the general equilibrium. And until now, it wasn’t clear how market microstructure for ICM should differ from TradFi.

The ecosystem is now consolidating around a shared vision: Application-Controlled Execution (ACE). The ultimate objective of ACE is giving smart contracts millisecond-level control over their own transaction ordering. In our conversations with teams across the ecosystem, market microstructure is the single most important problem in Solana today.

Everyone across the Solana ecosystem is working to address this problem from all angles.

Right now, Solana is by far the best place in crypto to build if you want access to tons of users, liquidity, regulatory clarity, great wallets, and global onboarding infrastructure, but some apps still choose to build their own tech because they want to experiment with new market structures. Solana needs to be the best place to build if you want access to an existing userbase and want to experiment with new market microstructures.

The rest of this post has two major sections:

1. An overview of the major tradeoffs in market microstructure

2. Specific near-, medium-, and long-term solutions to enable flexible market microstructure on Solana mainnet.

Let’s begin.

Tradeoffs in Market Microstructure

There are so many dimensions of microstructure that it's impossible to provide an exhaustive list. But here are a few of the more common tradeoffs (inspired by this tweet) that apps are thinking about today across the industry:

Privacy vs. Transparency

A question people ask about both sides of markets is: should orders be hidden before execution or not? For large retail orders, broadcasting your trade may improve execution because it reduces asymmetric information between you and market makers. Conversely, hidden liquidity may result in more liquid markets because hiding orders protects market makers from toxic adverse selection. But this protection comes at a cost. Hidden liquidity reduces transparency and makes it difficult for traders to know what their execution will be before execution.

Speedbumps vs. Unrestricted Trading

Protective taker speedbumps should reduce adverse selection, resulting in tighter spreads and more liquid markets; however, taker speedbumps also reduce volume (because there are fewer toxic trades) and slow price discovery (because informed trades happen faster on venues without speedbumps). But volume is a vanity metric. What users actually care about is liquidity; that is, users trade where they get the best prices. Some volume is good for making markets more efficient, other volume—in particular toxic-taker volume—makes markets less liquid. When market makers consistently lose money to toxic-takers correcting tiny price discrepancies between venues, they compensate by giving users worse prices. If you make changes that reduce toxic-taker volume, you may lower overall volume but increase liquidity on the exchange.

Solana should host the world's most liquid markets, not the markets with the highest volume.

Inclusion vs. Finality vs. Execution Latency

Although the tweet referenced above presents this design decision as a tradeoff, it is in fact not one. Time-to-inclusion is primarily about transaction lifecycle before a transaction hits the chain and slot-times (currently 400ms); time-to-finality is primarily about the consensus algorithm.

While faster finality is important because it reduces the need for market makers to account for complicated forking logic, shortening time-to-inclusion is more important for liquidity because it determines how quickly market makers can update their quotes. As time-to-inclusion shrinks, market makers become less susceptible to “gap risk” where prices move offchain and they are unable to cancel stale quotes before they are picked off by takers.

Solana today offers optimistic finality on the order of  ~1s. Post Alpenglow (more on that below), which is expected to hit Solana mainnet in early 2026, time-to-inclusion is expected to decrease towards 50-100 ms, and finality to be ~150 ms.

Colocation vs. Geographic Decentralization

On the surface, many believe colocation is faster, but it doesn’t necessarily get all of the world's information on-chain as fast as possible. As a thought experiment, let’s assume all validators for a chain are located in New York. Then suddenly the Japanese government announces a loosening of trade restrictions on American Cars. The geographic distance between the news event and the validator set delays the information about the market’s reaction over a hundred milliseconds before it reaches the American validators. With geographic decentralization and multiple concurrent leaders (MCL), information from around the world could theoretically be fed into the system during the same 20ms execution tick.

By decentralizing transaction inclusion via MCL and pushing transaction inclusion to the edge,  Solana can further reduce the time it takes for information to affect price discovery, irrespective of the origin of the information.

Colocation systems also produce extreme information asymmetry, making them definitionally local. Centralized trading makes extensive use of arbitrage between exchanges, which can appear like a global market, but in reality each colocation system operates as a time-based regional market.

Geographic decentralization has other advantages besides synchronizing the world's information as fast as possible. It makes the network more resilient to local natural disasters and power grid failures. It also makes the network more difficult to corrupt by hostile entities, and, in general, reduces the round trip time for users since users can send transactions to leaders close to them rather than having to send their transactions to leaders on the other side of the world.

Makers- vs. Takers-First

The spread is determined by a zero-profit condition that balances two competing forces: revenue from uninformed traders and costs from getting picked off by informed traders. Across other markets, giving priority to makers produces a more healthy market with tighter spreads than giving priority to takers because giving priority to takers increases adverse selection dramatically (widening spreads). 

As a practical matter in Solana today, the system does not explicitly prioritize one party over the other. Unfortunately, the implicit result of that is that takers have effective-priority on Solana because of periodic auctions in the scheduler. Other decentralized layer 1 networks have it even worse because their auction periods are even longer.

Below, in the solutions section, we will discuss in depth how ACE can enable individual applications to define custom rules with regards to makers vs. takers (e.g., speedbumps, executing cancels before takers orders, etc.).

Retail vs. Institutional

Exchanges should strive to attract as many uninformed traders as possible because they create the tightest spreads. To the extent that retail and institutions require different architectures, Solana’s hope is that different apps will be built to serve the needs of each, and that both will thrive on Solana mainnet.

Flexible vs. Opinionated

There are no zealots in Solana, only pragmatic engineers who want to build a platform that can support the world's most liquid financial markets. If the community was confident that a single specific market structure was better than all the rest, the community would advocate for building that into the protocol—but they aren’t. 

The only way to tell which market structure is best at a specific moment in time is to test them in production, gather data, iterate, and repeat. Solana is building a flexible foundation to facilitate ACE because we believe it is the fastest possible path to convergence on the best possible market structure.

Solana applications will run many experiments concurrently testing all of the tradeoffs above. That will lead to the best long-term equilibrium in market microstructure as quickly as possible.

Hybrid vs. Fully On-Chain

Solana is building for 100% on-chain markets—not a settlement layer for a centralized, offchain exchange. There is no technical impossibility or open problem that will prevent the community from getting there. All that's left is to build.

Solana’s priority is to get as much liquidity on mainnet as possible.

The Short-, Medium-, and Long-Term ICM Roadmap

Solana mainnet today is not an ideal environment for CLOBs for a variety of reasons—but it will be soon. Teams across the ecosystem have been working across the entire stack to make CLOBs thrive on mainnet, and several key developments are coming as early as next month, with more improvements to follow in the medium and long term.

Below we will outline the short-, medium-, and long-term developments that ensure CLOBs thrive on Solana, and to ultimately allow trading programs to compete with their centralized counterparts.

Short Term: Jito’s Block Assembly Marketplace (BAM); Anza’s Transaction Landing Improvments

In this section, we define short-term as the next 1-3 months—e.g., projects that have been in the works for some time and that are coming to mainnet imminently.  

Block Assembly Marketplace

Jito’s Block Assembly Marketplace (BAM) is a next-generation, high-performance transaction processing system that gives Solana validators, traders, and applications powerful new tools to improve performance and create value.

Jito Labs began working on the Block Assembly Marketplace (BAM) at the end of 2024 because they recognized the need for more intra-slot transaction determinism. BAM is launching testnet in the next few days.

In the near term, BAM offers something close to full ACE. Design partners—including Drift, Pyth, and Dflow—are already building BAM plugins now. 

BAM operates through a global, decentralized network of operators running the BAM software stack inside Trusted Execution Environments (TEEs). Validators simply connect to BAM nodes via the new Jito-Solana client; no complex integration is required. The BAM TEEs create a unique privacy layer that keeps transactions confidential until execution while enabling fully-transparent, verifiable sequencing through open source code and TEE attestations. BAM generates cryptographic proofs of every operation, delivering the most transparent transaction processing system in existence.

Via plugins, BAM includes a system that allows application developers to define intra-slot transaction sequencing rules. This effectively acts as ACE, but runs in BAM rather than on Solana mainnet directly.

BAM transforms Solana blockspace into an open sandbox where developers can build modular programs that add functionality to transaction processing. For the first time, apps can implement customizable sequencing rules, enabling Central Limit Order Books (CLOBs) that rival traditional exchanges. CLOB plugins can run inside BAM and rely on a mixture of off-chain and on-chain logic, allowing full transparency and deterministic execution. Unlike traditional approaches that require forking the validator client to add custom functionality and negotiating BD deals with every validator, developers simply build their CLOB logic inside BAM through a plugin and instantly tap into Solana’s global on-chain network effects—reaching the entire ecosystem from day one while ensuring every trade is cryptographically verified and transparently sequenced.

Validators earn more through better block construction. Users get faster, cheaper, and more reliable execution. Professional traders gain unprecedented trust in Solana's infrastructure because BAM's open source and verifiable nature will guarantee fairness with no hidden games or backdoor deals. Everyone benefits as the network effects compound, driving a virtuous cycle of innovation and value creation.

BAM is rolling out in late July. You should expect dramatic improvements in trading experience as BAM rolls out. BAM will help Solana mainnet applications feel much closer to CEXs.

Anza’s Transaction Landing Improvements

Concurrent with BAM, Anza is working to improve transaction landing reliability with the goal of making transactions land in the same slot reliably.

A year ago it was very difficult for transactions to get past the ingest stage, and scheduling was basically random. After fixing some bugs with the QUIC implementation and the introduction of a unified scheduler, the Solana transaction pipeline is now in a much better place.

Agave 2.3, which is recommended for mainnet use right now, includes a brand new TPU client which will substantially reduce transaction send latency. In addition, Anza engineers have been working with top market makers and RPC services to fix QUIC bugs and leader targeting issues that were impacting transaction landing rates. One change to Triton’s transaction landing can be seen here. Most of these changes are already live and market makers are now observing p95 0 slot transaction latency through the standard TPU pathway. 

Medium Term: DoubleZero, Alpenglow, Async Program Execution (APE)

In this section, we define medium-term as the next 3-9 months—e.g., projects that are known, making progress and that are expected to come to mainnet in Q4 2025 or Q1 2026. 

DoubleZero

DoubleZero (DZ) is a high-performance dedicated fiber network for distributed systems, purpose built to enable blockchains like Solana to reach throughput and latency numbers not possible on the public internet. In addition to offering significantly reduced latency and increased bandwidth, DoubleZero also acts as a robust filtering layer to both protect the Solana network from denial-of-service interruptions, and to take the excess traffic processing load off of validators and RPCs so they can focus their resources on reducing execution latency and increasing blockspace, leading to increased network REV. DoubleZero will enable Solana transactions, blocks, and consensus messages to be propagated over Multicast, which is hardware acceleration for packet replication, thus further reducing traffic processing overhead throughout the network and increasing fairness. When combined with low transmission latency and near-zero jitter, this means that Solana will have the performant backbone it needs to improve protocol primitives and attract and retain high-quality market makers and additional retail trading volume.

Overall, Double Zero expects real-world performance on mainnet to improve substantially as the network is adopted by the validator cluster. Reducing latency by up to 100ms (including zero jitter) along some routes, and increasing bandwidth available to the average Solana validator tenfold. 

DoubleZero is on testnet today with over 100 validators and 3% of mainnet stake, and it is expected to go to mainnet in mid-September 2025. After DoubleZero mainnet goes live, it will take a few weeks for longtail Solana mainnet validators to adopt the DoubleZero network, at which point core contributors to Solana can begin raising protocol limits. 

The Solana community should expect meaningful improvements in time-to-inclusion as more Solana mainnet validators adopt DZ in September and throughout Q4 2025.

Alpenglow

Alpenglow is Solana’s brand new, state-of-the-art consensus protocol. The current consensus model provides finality in 32 slots (~12.8s). Alpenglow will finalize blocks in 1-2 slots, or roughly ~150ms. 

Alpenglow represents a sweeping set of changes to consensus and block propagation designed to reduce end-to-end latency substantially. Additionally, Alpenglow is actually simpler to reason about than Solana’s current consensus model, which makes development easier and future changes like multiple concurrent leaders and async execution easier to design for and implement as well.

Anza is targeting late 2025/early 2026 for Alpenglow activation on mainnet. You can learn more about Alpenglow here and here.

Asynchronous Program Execution (APE)

Asynchronous Program Execution (APE) removes execution replay from the critical path of transaction landing, reducing latency. 

APE has been a goal for Solana for almost 4 years now, and with the simplifications coming to consensus with Alpenglow, much of the complexity required to implement APE (mostly around special treatment for the vote program) will be removed. 

In the past few weeks there have been a flurry of new SIMDs targeted towards APE. SIMDs 192, 290, 297, 298, and 301 include more details on APE. Anza expects it to be activated on mainnet shortly after Alpenglow rolls out in early to mid 2026.

Long Term: Multiple Concurrent Leaders and Protocol-Enforced Application Controlled Execution (ACE):

In this section, we define long-term plans as those aiming for 2027—e.g., projects that are currently in development by core developers at Anza and across the ecosystem. 

MCL and ACE

To build the most liquid markets on chain, we need 3 things:

1. The chain must have more than enough capacity to ingest all market-relevant information in real time at line rate

2. The chain must have fast confirmations and an even faster tick rate (slot time)

3. The chain must allow applications to control their own execution ordering in order to facilitate experiments with new market microstructures

At any time in a single-leader blockchain (almost all modern chains are single-leader), a single leader controls access and ordering of transactions during their leader window. This means that if the chain wants to give applications control over their own transaction execution, it must have the cooperation of friendly leaders. In a global permissionless system, you cannot count on friendly leaders to play nice with billion-dollar financial applications. 

Multiple concurrent leaders (MCL) is a solution to the Single Leader Problem: the chain can control ordering by enforcing reordering at the replay stage but this doesn’t prevent validators from selectively including certain transactions and censoring others in order to manipulate the final ordering for their own gain. 

To solve the selective censorship problem, the number of leaders who can add transactions to the chain during any given leader window must be increased. If one leader censors a transaction, another may include it, therefore making it difficult for any one leader to control the final execution outcome. 

Merging the blocks from these individual leaders is easy. Simply sort in descending order of priority fee.

Once transactions have been sorted intra-block in priority order, applications automatically have a lot of leeway to control their own sequencing by reading the priority fee and executing conditional logic based on that. It's simple to implement cancel prioritization with this setup. In general it’s also possible to run arbitrary auctions if app developers get creative. 

Synchronizing The World’s Information

Multiple concurrent leaders allows Solana to ingest information from around the world at the same time—faster than colocated infrastructure. And, because smart contracts are general purpose languages, market makers can now combine real-time information generated in New York and Tokyo in their quoting strategies by reading both information streams into the same smart contract. 

This is a feature of multiple proposer blockchains that cannot be replicated by a single server anywhere in the world. In other words Solana will offer tools for internet capital markets that are unique to decentralized blockchains and cannot be replicated by centralized competitors.