Main Paper
WPRC SG [35] Internet Capital Markets- Rongxin (WPRC) 24 Feb 2026
Summary
Solana’s ecosystem is converging on “Application-Controlled Execution” so trading apps can set their own transaction-ordering rules and achieve tighter spreads and more reliable execution on mainnet. This will be broken into 3 parts: Short, Mid and Long term ambitions. [1]
Why This Is Important
(i) DeFi protocols get TradFi-level market structures (e.g., maker-priority, speedbumps), attracting sophisticated market makers and increasing liquidity [1]. (ii) Traders benefit from tighter spreads and faster, more decentralized price discovery [2]. (iii) The Solana network captures more Maximum Extractable Value (MEV) as on-chain financial activity grows [2].
Key Innovation
No single market structure is optimal as each app and platform has their own requirements. So Solana is building (i) Application-Controlled Execution (ACE): a framework where each smart contract defines its own “intra-slot” ordering rules. (ii) The short-term vehicle is Jito's BAM (off-chain TEE plugins, testnet July 2025). (ii) The mid term, which is already being implemented in the development of faster, simpler and more decentralized networks (iii) the long-term approach is Multiple Concurrent Leaders (MCL, ~2027). This makes ACE protocol-enforced and censorship-resistant by having dozens of geographically distributed leaders simultaneously propose transactions. MCL also produces a structural advantage over colocated TradFi: information from any geography enters the system within the same ~20ms execution tick—something no single-server matching engine can replicate. This is the first consolidated public roadmap where Solana Labs, Anza, Jito, DoubleZero, Drift, and Multicoin jointly articulate the path.
Stakeholders & Incentives
(i) App Developers (Drift, Phoenix, etc.): Want to build competitive, specialized exchanges (e.g., for retail or institutions) but need control over order flow sequencing (e.g., cancel priority, speedbumps) to manage liquidity, which is currently impeded by the shared, immutable leader schedule. (ii) Validators & Node Operators: Want to maximize revenue from block production and MEV while minimizing operational complexity. incentives align with adopting performance upgrades (e.g., BAM, DoubleZero) but could conflict if custom app rules reduce their extractable value or require significant new infrastructure. (iii) Market Makers: Want to provide liquidity without being picked off by toxic arbitrage; they benefit from conditional liquidity and faster inclusion to reduce "gap risk," but their need for predictability may conflict with takers' desire for low-latency access. (iv) Takers & Traders: Want lowest latency to capitalize on new information and best execution prices; their incentive to "pick off" stale quotes conflicts with MMs, creating a classic adverse selection problem that different market structures attempt to solve.
Background
Why Solana CLOBs don't feel like CEXs: 3 problems: (i) intra-slot ordering is soft (single-leader + 400ms slots means makers can't guarantee cancel-before-taker), (ii) fee competition creates taker priority in practice (toxic for tight spreads), and (iii) poor transaction landing reliability forced makers to quote wide just to avoid being picked off. Why ACE/ICM is happening now: Microstructure quality, not raw TPS, is the real CLOB bottleneck. Two near-term unlocks appeared simultaneously: Jito BAM (custom sequencing via TEE-verified plugins, no deep protocol changes required) and Agave v2.3's TPU rework (concrete latency/throughput improvements in the send path). Note: Ethereum and Solana came to same problem, but have different solutions. What you can do today vs. what's still blocked: BAM gives you ACE-like ordering today: apps can run custom sequencing logic with confidentiality + post-execution verifiability. What's still missing is trustless enforcement — in a single-leader model, a leader can still bias inclusion or order regardless of plugin rules. Real ACE requires Multiple Concurrent Leaders + replay-stage enforcement so sequencing rules are protocol-level, not operator-negotiated. Alpenglow/consensus work is the long-term dependency here.
Core Trade-offs
(i) Predictable ordering vs. centralization: Someone has to enforce sequencing rules, which means giving some entity ordering power over your transactions. (ii) Hidden orderflow vs. transparency — concealing orders stops you from getting picked off, but reduces auditability. BAM's compromise: confidential until execution, verifiable after. (iii) Faster confirmations vs. fairer access — speed advantages compound. Without explicit fairness rules, low-latency players extract more, making the game worse for everyone else.
(iv) Ordering improvements today vs. trustlessness — BAM moves fast, but you're relying on a specific operator, not the protocol itself. Real trustlessness requires waiting for protocol-level ACE.
Deep Dives
Focus on BAM,
BAM (Now → ~1–3 months): Right now, sending a transaction on Solana is like shouting into a crowd and hoping the right person hears you in time — these two upgrades make sure your message gets to the right person, and that they read everyone's messages in a fair, predictable order.
(i) BAM — fixes ordering: An external "scheduler node" (running in a TEE - Trusted Execution Environment) takes over transaction sequencing from the validator. Instead of the block producer ordering transactions however it wants, it receives a pre-ordered, signed stream and must execute in strict FIFO. Apps (like Drift or Pyth) can plug in custom intra-slot ordering rules. Validators opt in via --bam-url. Question:Is this similar to Ethereum’s PBOS. (ii) Anza TPU improvements — fixes delivery: Solana has no mempool — transactions must physically arrive at the right leader in time. The new tpu-client-next replaces the old ConnectionCache to reduce latency/jitter when forwarding to upcoming leaders. Underlying QUIC fixes address throttling bugs (e.g. MAX_STREAMS delays) that were silently dropping valuable transactions before they ever reached the block producer.
DoubleZero + Alpenglow (~3–9 months): Think of Solana like a city's road system — DoubleZero paves private highways between validators, Alpenglow replaces the traffic light system with something 100x faster, and APE lets cars start moving before the light fully turns green. (i) DoubleZero — fixes the network underlay: Replaces reliance on the public internet with a decentralized mesh of contributed fiber links. An outer ring uses FPGAs to filter spam/DDoS and verify signatures at the edge before traffic even reaches validators. An inner ring routes clean traffic over dedicated bandwidth with near-zero jitter. Multicast enables one-packet-to-many delivery in-network. Launched mainnet-beta Oct 2, 2025 — 386 validators, ~20.8% of stake at launch. Double Zero Summary: docs.google.com/document/d/1wMnrU3YBQNpJN7Jlrt16SheLCPieKbXaNu94EihEeZs. (ii) Alpenglow — replaces consensus entirely: Drops both Proof-of-History and TowerBFT. Introduces Votor (voting/finalization) + Rotor (data dissemination, later SIMD). Votes become offchain direct messages with BLS aggregate signatures into certificates — no more gossip, no more onchain vote transactions. Finalizes in 1 round at 80% stake participation, 2 rounds at 60%. Target: ~150ms finality vs. ~12.8s today. Tradeoff: 20+20 resilience model (tolerates 20% byzantine + 20% offline) vs. classic 33% byzantine. Adds VAT (~1.6 SOL/epoch burned) to replace vote-fee skin-in-the-game. Status: still "under development" as of Feb 26. Alpenglow Summary: docs.google.com/document/d/15pdRrTXEdSNkS_rrnGpdVUPWopf37Z62VM4afmY881U + Podcast: youtube.com/watch?v=PMkMDjL4a2M. (iii) APE (Async Program Execution) — decouples voting from execution: Validators vote on blocks before finishing execution replay, removing execution time from the confirmation critical path. Requires two safety prerequisites: (1) block-invalidating errors get demoted to transaction-level failures (SIMDs 0290, 0297), and (2) bank_hash moves to block footer (SIMD-0298) so execution consensus remains detectable without being in votes. SIMD-0297 and 0298 are already marked "Active." Full APE targeted shortly after Alpenglow ships. random.

Multiple Concurrent Leaders (MCL) (~2026–2027): Right now, one validator controls which transactions get included and in what order — like a single tollbooth operator who can wave friends through and block others. Multiple Concurrent Leaders fixes this by running several tollbooths simultaneously, then merging all traffic using one neutral rule: whoever paid the highest fee goes first, and no single operator can cheat that.
Problem today: (i) Censorship: a single leader can censor a maker's cancel while executing taker orders, making "cancel-before-take" guarantees impossible without trusting that leader. MCL runs multiple leaders producing blocks in the same window — if one censors a transaction, another includes it. (ii)The geographic angle: with leaders distributed globally, information from New York and Tokyo can theoretically enter the chain within the same ~20ms execution tick — making the network a real-time global information aggregator rather than just a fast local ledger.
The merge rule is simple: (i) collect blocks from all concurrent leaders, deduplicate (keep highest-fee copy), (ii) sort by priority fee descending, execute. The ordering signal is just the existing micro-lamport priority fee field (already in the protocol today at 10⁻¹⁵ SOL precision) — no new primitive needed, just a credibly neutral rule for resolving it. ACE (Application Controlled Execution) — lets apps program ordering logic
Once ordering is fee-determined and enforced by protocol rather than a trusted leader, applications can read the priority fee field onchain via a proposed get_transaction_metadata syscall and build real microstructure logic on top — maker protections, MEV taxes, speedbumps, app-specific auctions — without needing offchain infrastructure or trusting a sequencer. The fee structure split: the roadmap proposes separating fees into inclusion fees (paid to the validator) and ordering fees (burned), so no single leader economically "owns" the ordering signal and has incentive to manipulate it.

Profiles
Anatoly Yakovenko (Solana Labs): Co-founder/CEO; ex-Qualcomm (12 yrs) + Mesosphere + Dropbox; UIUC CS ’03;. Max Resnick (Anza): Consensus/execution lead; ex-Flashbots MEV research; NYU PhD Econ (mechanism design/microstructure);. Treats the chain like a live market; driving Alpenglow with an “economics-first” lens on fees/congestion/fairness. Lucas Bruder (Jito Labs) — CEO; ex Tesla/Ouster/Built Robotics (firmware/robotics). Turned Solana MEV from spam into structured bundles/tips and built the validator-side plumbing (Jito client + JitoSOL). CMU ECE ’16; Austin Federa (Co-founder DoubleZero); ex Solana Foundation Head of Strategy + Bison Trails + Republic; Lawrence University. Building a dedicated low-latency network layer (HFT-style pipes) because the public internet is the bottleneck for real-time finance. Chris Heaney (Drift) CTO/co-founder; quant + high-performance dev background; finance education (NYU). Builds and operates one of Solana’s major perps venues; optimizes for market quality (spreads/liquidity) in production. Kyle Samani (Multicoin Capital); NYU Stern ’12; ex Pristine (Google Glass enterprise software). Thesis-driven investor who pushed the “monolithic Solana” narrative: performance comes from keeping execution on one high-throughput chain vs fragmentation.