Quick overview of Solana's latest roadmap: BAM transaction optimization, DoubleZero launch, Alpenglow consensus
TechFlow Selected TechFlow Selected
Quick overview of Solana's latest roadmap: BAM transaction optimization, DoubleZero launch, Alpenglow consensus
Where is Solana headed in the future?
Navigating Web3 tides with focused insightsAuthors: Anatoly Yakovenko, Solana Labs; Max Resnick, Anza; Lucas Bruder, Jito Labs; Austin Federa, DoubleZero; Chris Heaney, Drift; Kyle Samani, Multicoin Capital
Translation: Alex Liu, Foresight News
Solana's original mission was to build the decentralized infrastructure for "Internet Capital Markets" (ICM). While increasing bandwidth and reducing latency (IBRL) is necessary, it’s not enough. The third pillar of Solana’s roadmap must address the complexity of market microstructure. Markets consist of many dynamic factors that often have significant yet unpredictable impacts on overall equilibrium. Until recently, it remained unclear how ICM’s market microstructure should differ from traditional finance (TradFi).
Today, the Solana ecosystem is converging around a shared vision: Application-Controlled Execution (ACE). The ultimate goal of ACE is to enable smart contracts to control transaction ordering with millisecond-level precision. Conversations with multiple teams across the ecosystem indicate that market microstructure has become the most critical challenge currently facing Solana.
The Solana community is tackling this problem from every angle.
Currently, Solana remains the best platform in crypto for building applications—boasting large user bases, abundant liquidity, clear regulatory environments, excellent wallets, and globally accessible infrastructure. Yet some applications still choose to build their own underlying tech to explore new market structures. Solana needs to become the go-to platform that both connects to existing users and enables bold experimentation with market microstructures.
The following content is divided into two parts:
-
Key trade-offs in market microstructure;
-
Concrete proposals to support flexible microstructures on mainnet, categorized into short-term, mid-term, and long-term phases.
Trade-Offs in Market Microstructure
The design space for market microstructure is extremely rich and cannot be fully enumerated, but below are the core trade-offs currently top of mind for application builders:
Privacy vs Transparency
Should orders remain hidden before execution? For large retail orders, pre-broadcasting may improve execution quality by reducing information asymmetry between traders and market makers. However, hiding liquidity can also protect market makers from "toxic order flow," thereby improving overall market liquidity. This protection comes at a cost: hidden orders reduce transparency, making it harder for traders to estimate outcomes before execution.
Rate Limiting vs Unrestricted Trading
Implementing "protective rate limiters" for takers can reduce adverse selection, narrow bid-ask spreads, and enhance market liquidity. However, rate limiting also reduces trading volume and slows price discovery. Importantly, volume alone is not the sole metric of market quality. What users truly care about is where they can get the best prices. Thus, reducing toxic taker activity might lower total volume but actually increase real liquidity.
Transaction Inclusion vs Finality vs Execution Latency
Many apparent “trade-offs” can actually be co-optimized. Solana currently achieves optimistic finality in about 1 second. Once the Alpenglow protocol launches in early 2026, transaction inclusion time is expected to drop to 50–100 milliseconds, with finality reduced to approximately 150 milliseconds. This will allow market makers to update quotes faster and reduce "gap risk."
Colocation vs Geographic Decentralization
Many assume colocation is faster, but if all validators are concentrated in New York, sudden news from Tokyo creates propagation delays. Through Multiple Concurrent Leaders (MCL) and edge transaction inclusion mechanisms, Solana can achieve globally synchronized data ingestion, greatly enhancing price discovery efficiency and resilience.
Market Maker Priority vs Taker Priority
Granting priority to market makers reduces adverse selection and tightens spreads. Under Solana’s current mechanism, takers implicitly enjoy priority due to scheduling auctions. Future ACE implementations will empower developers to define priority logic (e.g., cancel-first rules, rate limiters, etc.).
Retail vs Institutional
The most liquid markets are often driven by retail participants. Solana encourages building differentiated applications that support the coexistence and development of both institutional and retail users.
Flexibility vs Uniformity
The Solana community has always favored pragmatism over dogma. Since there is no single optimal market structure, the only path forward is testing, iterating, and optimizing directly on mainnet. Therefore, Solana is building flexible infrastructure to support ACE and accelerate the evolution of market structures.
Mixed Architecture vs Fully On-Chain
Solana aims to build fully on-chain markets, not merely serve as a settlement layer for centralized exchanges. There are no technical barriers to this goal—only continued development is required. Solana’s primary focus is bringing more liquidity onto the mainnet.
ICM Roadmap: Short-Term, Mid-Term, and Long-Term Plans
The current Solana mainnet is not yet an ideal environment for CLOBs (Central Limit Order Books), but this is about to change. Multiple teams across the ecosystem are systematically upgrading the entire tech stack to enable CLOBs to thrive on mainnet. We outline the future roadmap in stages:
Short Term (1–3 months): Jito BAM and Anza Transaction Landing Optimization
Jito’s Block Assembly Marketplace (BAM)
BAM is Jito’s next-generation high-performance transaction processing system, scheduled to launch on testnet by end of July 2025. Running on a globally distributed network of nodes within Trusted Execution Environments (TEE), BAM delivers powerful capabilities to Solana validators, traders, and applications—approaching full ACE functionality. Projects like Drift, Pyth, and Dflow have already joined as early design partners.
BAM supports application-specific transaction ordering logic via plugins, enabling developers to build transparent, verifiable execution systems for CLOBs. Transactions remain confidential until execution, while the ordering process itself is open-source and auditable. This model requires no validator client modifications or protocol integration negotiations—simply build a plugin for BAM and plug into the entire Solana network.
Recommended reading: No more frontrunning on SOL? Understanding Jito’s new BAM
Anza Transaction Landing Optimization
Anza is simultaneously advancing improvements in transaction landing stability. Agave 2.3 introduced a new TPU client that significantly reduces transaction submission latency and fixes QUIC-related issues. Most optimizations are already live, with top market makers observing 95th percentile latency of 0 slots via standard TPU paths—achieving extremely high determinism.
Mid Term (3–9 months): DoubleZero, Alpenglow, Asynchronous Execution (APE)
DoubleZero (DZ)
DZ is a fiber-optic network custom-built for Solana, dramatically reducing latency and increasing bandwidth, while optimizing data transmission via hardware multicast. Over 100 validators and 3% of mainnet stake are already active on testnet, with mainnet launch expected mid-September 2025. As DZ adoption grows, Solana will achieve faster transaction inclusion and further improve network resilience and fairness.
Alpenglow Consensus Protocol
Alpenglow is Solana’s next-generation consensus protocol, reducing block finality from 12.8 seconds to approximately 150 milliseconds. It also simplifies the architecture to better support future MCL and APE upgrades. Alpenglow is expected to launch on mainnet by late 2025 or early 2026.
Asynchronous Program Execution (APE)
APE removes the replay mechanism from the transaction landing path, reducing latency—a long-standing priority for Solana. With the simplified Alpenglow consensus, APE implementation complexity is significantly reduced. Multiple proposals (SIMD 192, 290, 297, 298, 301) have been submitted and are expected to roll out in the first half of 2026 following Alpenglow’s deployment.
Asynchronous execution
Long Term (2027): Multiple Concurrent Leaders (MCL) and Protocol-Level ACE
MCL and Protocol-Level ACE
To build the most liquid on-chain markets, Solana must achieve three things:
-
Sufficient capacity to ingest all market data in real time;
-
Faster confirmation and higher tick rates;
-
Applications must have control over transaction ordering.
Single leader can censor transactions
Most blockchains today rely on a single leader model, which cannot guarantee fair or censorship-resistant transaction ordering.
MCL reduces the risk of censorship or manipulation by having multiple leaders jointly build blocks during the same timeframe. Transaction ordering is based on priority fees, allowing each application to design its own logic—such as cancel-first rules.
Cancel based on priority fee
Global Synchronized Data Ingestion
MCL also enables globally distributed data to enter the chain synchronously. Market makers can incorporate real-time signals from both New York and Tokyo within the same contract for strategy execution. This capability is difficult to replicate in traditional centralized systems and represents a unique competitive advantage of decentralized infrastructure in capital markets.
Solana’s vision for Internet Capital Markets is accelerating into reality. From the foundational tech layer to application-level innovation, the entire ecosystem is working toward building the world’s most liquid on-chain financial system. ACE will serve as the core paradigm, transforming transaction ordering on Solana and enabling smart contracts to truly control financial infrastructure.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@anza_xyz
