Introduction: What’s at Stake?

Block building remains Solana’s most important problem because it directly shapes execution quality and market structure. In Solana’s current model, the single leader monopoly combined with too much freedom in block building has enabled timing games such as late packing, increasing network jitter and creating outcomes that are often adversarial to apps and end users.

Protocol-level constraints have also created demand for multiple transaction landing services, adding complexity to Solana’s transaction supply chain. Beyond competing block builders (BAM, Harmonic), there are now multiple transaction landing services (Nozomi, Jito bundles, 0slot, bloXroute, Astralane, Helius) and a fee stack split across base fees, priority fees, and out-of-protocol tips. Any discussion of block building on Solana must account for these variables as well.

The stakes are clearest in perps and CLOB-style markets, where market makers face a structural disadvantage versus toxic takers. This is one reason Solana has struggled to close the gap versus Hyperliquid, and why Solana-native teams have explored alternatives ranging from SVM chains that aim to overcome the current limitations of the L1 (e.g., Fogo) to exchanges that bypass the public transaction queue (e.g., Bullet, Bulk). If Solana wants to keep builders and users on the L1, and achieve its “decentralized Nasdaq” vision, it needs to improve its current market structure.

The goal of this report is to clarify what is broken in Solana’s microstructure today, evaluate the major block building approaches, and understand the optimal end state. Concretely, the report asks: what does “good” block building mean for a streaming chain like Solana, which tradeoffs are unavoidable, and which architecture best aligns validator incentives with user and application outcomes?

Part 1: The Block Building Landscape

Since early 2024, Jito has been the dominant force in Solana’s block building landscape. Its infrastructure became a core part of the transaction processing and block production stack, helping the network remain stable and avoid congestion during periods when baseline throughput couldn’t absorb overwhelming demand for transaction inclusion. 

As seen in the chart below, for most of 2025, Agave-Jito dominated the landscape, holding around 90% of validator stake through the first half of the year. Frankendancer began gaining traction in mid-2025, steadily eating into Agave-Jito’s share as validators adopted the hybrid client, which combines Firedancer's processing engine with the rust validator's networking stack, all while retaining Jito's block building infrastructure.

In Q4 2025, the competitive landscape shifted. After Jito debuted Block Assembly Marketplace (BAM) in late September 2025, the Temporal team introduced Harmonic – a competing block builder with an aggregation model that sources blocks from multiple builders. For the first time, Jito’s quasi-monopoly on block building faced a credible threat. 

In early January 2026, Jito released IBRL Explorer to surface late-packing behaviors amongst some validators, a move widely read as a direct response to Harmonic's growing market share. Since then, Harmonic’s stake weight grew from 3.2% to 16.8% as of Feb. 17, 2026. On its part, BAM’s stake weight grew from 12% to 27.4% as of the same date.

In aggregate, Harmonic and BAM have added about 30% of stake each in absolute terms year-to-date. Most of BAM’s growth came from Agave-Jito migrations, while Frankendancer-Jito saw a 7.7% decline in stake weight.

By validator count, BAM has grown to over 330 validators, while Harmonic has onboarded 45 validators.

Given that Solana’s block-building landscape is increasingly being shaped by these two competing systems (BAM and Harmonic), let’s examine each in turn.

Jito BAM

In July 2025, Jito announced Block Assembly Marketplace (BAM), a next-gen transaction processing system. BAM aims to improve Solana's microstructure and design space, enabling developers to build applications that require more granular control over sequencing (e.g., CLOBs, perps DEXs) or that necessitate privacy (e.g., dark pools). By enabling apps to internalize transaction sequencing, Jito is acting as a good steward for the network, despite forgoing meaningful incremental revenue if the existing Block Engine is deprecated following the adoption of BAM. 

BAM implements an encrypted mempool inside Trusted Execution Environments (TEEs) to deliver privacy, transparency, and verifiability to Solana's block building. The chart below provides an overview of BAM’s transaction pipeline.

BAM comprises a network of nodes who order transactions and send them to validators running Jito’s new client. Key stakeholders include:

• BAM Nodes: Nodes are the backbone of the processing system, running alongside the existing Solana validator set and sequencing transactions within secure enclaves that maintain privacy while ensuring verifiability. Today, BAM nodes are operated by Jito Labs, with plans to add more nodes operated by third parties over time (end goal of 50-100+).
• Plugins: Developers can leverage programmable interfaces known as Plugins to connect to the BAM Nodes’ scheduler and interact with Solana transactions in novel and provably value-accretive ways. Plugins allow for custom transaction sequencing logic. Plugin experimentation remains early, and no use cases have yet been implemented at meaningful scale.

BAM remains closed-source today, though the team mentioned they want to open-source the code in the coming months. Importantly, verifiability is dependent on BAM being open-source.

Several governance proposals have recently passed to incentivize BAM adoption by validators:

• JIP-28 introduces a tiered JitoSOL delegation program for qualifying validators running BAM, with rewards scaling alongside stake-weighted adoption of the client.
• JIP-31 redirects 100% of protocol revenue in Q1-Q2 to validators running BAM. Distributions are proportional to stake, capped at 3M SOL to mitigate centralization concerns, and then wound down linearly in Q3.
• JIP-33 (proposed Jan. 26, 2026) aims to deeply integrate JitoSOL into Coinbase’s product suite by enabling Coinbase users to mint/burn JitoSOL natively in-app and use it as collateral for Coinbase’s lending product. Under the proposal, JitoSOL attributable to Coinbase would be directed to Coinbase validators running BAM.

Transaction Ordering under BAM

BAM sorts transactions based on priority fee per compute unit (CU) with a configurable 50ms auction tick (assuming no custom sequencing via Plugins), executing all conflicting transactions in a FIFO manner. 

In this regard, one of the most underappreciated shifts of 2025 was Solana’s microstructure increasingly favoring priority fees over Jito tips, a trend that will likely continue in 2026. As shown in the chart below, priority fees accounted for 60% of REV in January 2026, their highest share since March 2024.

A persistent source of friction in the Solana-Jito implementation has been a fragmented fee market, split across base fees, priority fees, and out-of-protocol tips. Since inception, Jito tips alone have totaled more than $1.4B, but over the long run Solana’s microstructure benefits from a more unified fee market. From a user or application’s perspective, it’s far easier to reason about a single, in-protocol priority fee than to optimize across priority fees, Jito tips, and an expanding set of external transaction landing services.

On a recent tokenholder call, the Jito team indicated that the long-term goal is to collapse the fee stack down to priority fees alone, with Jito taking a cut at that layer.

With BAM, Jito is effectively forgoing an important revenue stream (tips) in service of that outcome, though it isn’t the first time the team has made a similar trade. In March 2024, Jito Labs discontinued MempoolStream, a ~200ms window that exposed incoming transactions to searchers. In practice, MempoolStream acted as a proxy mempool for Solana, and once memecoin activity surged it contributed to UX degradation and a rise in sandwich attacks.

Harmonic 

As mentioned, Harmonic emerged in late 2025 as the first serious challenger to Jito's dominance over Solana's block building infrastructure.​​ The core team behind Harmonic is Temporal, one of the most technically talented teams on Solana. Temporal operates other products, including Nozomi (transaction landing service), and HumidiFi (prop AMM). 

Harmonic raises an important question: is Solana better served by a single coordinated block builder enforcing its own standards, or by a marketplace where multiple builders compete and validators choose? 

Harmonic Block Building Dynamics

Harmonic functions as an aggregation layer that sits on top of multiple block builders. When a validator running Harmonic is scheduled to produce a block, Harmonic collects candidate blocks from competing builders and selects whichever best matches the validator's configured preferences.

• Validators can configure selection criteria based on their priorities, whether that's minimizing toxic MEV exposure, maximizing revenue per CU, or prioritizing specific transaction types.
• Harmonic's system is designed for open competition where multiple block builders compete to construct optimal blocks. That said, all three block builders on Harmonic today are operated by Temporal while the team establishes guardrails on the auction engine, with plans to open up to third party builders once the infrastructure is competition ready.
• Harmonic takes no fees currently from validators or bundles. The team is focused on value discovery and expanding infrastructure before introducing monetization, with revenue likely coming from ancillary services rather than toll fees on block production. 

Since launching in November 2025, Harmonic has grown to roughly ~16.8% of stake share, driven largely by onboarding institutional validators like Coinbase and Kraken.

Since the three block builders competing on Harmonic auctions today are operated by Temporal, there is skepticism regarding their “open competition” claims and the health of the system. Harmonic's core claim is that its three internal builders compete on packing efficiency, each running similar strategies but optimized for different network conditions. Harmonic's auction selects the block with the highest fees, which the team frames as a proxy for packing efficiency. However, our concern is this incentivizes selection drifting toward maximizing validator revenue rather than execution quality for apps and users.

As such, one could argue Harmonic's model could lead to a PBS environment like on Ethereum, where external builders compete and validators select the highest bidder. Expecting validators to prioritize application health over their own revenue may seem optimistic. Harmonic's counter is transparency: if block building becomes fully observable, stakers can hold validators accountable (e.g., a validator consistently enabling toxic MEV could lose delegation over time). However, whether stakers will actually monitor this behavior if open-sourced, and whether reputational cost outweighs short-term extraction, remains to be seen.

Positively, Harmonic recently announced a series of changes to its block building pipeline that move closer to what we believe is a healthier market structure for Solana.

• The most significant is the transition from full block auctions to 50ms microblock auctions, restoring intra-slot state updates and shred streaming that were lost under their initial design. This change directly addresses the late packing critique where blocks were only released after auction completion.
• Harmonic has also committed to respecting “dontfront” and “dontbund1e” flags, letting apps protect their transactions from front-running and extractive bundling, matching protections Jito already honors.

While the system remains closed-source, making it impossible to verify block selection criteria or whether Harmonic's own services receive preferential treatment, the team has stated that open sourcing its proposer software is imminent.

Harmonic Vertical Integration Concerns

Benedict Brady's research reveals how Solana frontends monetize user transactions far beyond visible swap fees. Axiom users pay a median $0.13 per swap through Nozomi compared to $0.001 through Jito, a 130x premium that Brady estimates flows largely back to the application and its transaction landing service. Users have no visibility into what fee level is actually necessary for inclusion, so they overpay to guarantee speed.

The vertical integration concerns compound these dynamics. Temporal operates Nozomi (transaction landing), Harmonic (block building), and HumidiFi (prop AMM). When one entity controls the pipeline from transaction submission to block construction to trading against that flow, extraction can become structural. Frontends routing through this stack may benefit from side deals invisible to users.

Part 2: Solana’s Streaming Design

Solana is built as a streaming system: when used as intended, the leader propagates shreds (small packets of data) continuously via Turbine as the block is being built. This behavior minimizes transaction landing latency, defined as the time between a validator receiving a transaction and that transaction being processed.

The diagram below illustrates how single-layer Turbine works under Alpenglow, Solana’s upcoming consensus protocol.

1. The leader creates a block of transactions.
2. The block is erasure-coded into 64 shreds. Of note, erasure coding makes propagation resilient. Shreds are encoded so the network can tolerate missing packets and still reconstruct the block once enough pieces arrive, rather than requiring perfect delivery.
3. After erasure coding, the leader sends each shred to a different relay (chosen randomly by stake weight).
4. Each relay then broadcasts its shred to all validators.
5. Validators can reconstruct the block with a majority of shreds.

In Solana’s account-based system, every transaction must declare upfront which accounts it will read and write so the runtime can safely execute thousands of non-conflicting transactions at once (i.e., parallel execution). But when many transactions touch the same hot accounts, they can’t run in parallel, and ordering becomes decisive. Today, this ordering power concentrates in a single slot leader, effectively granting a per-slot monopoly over inclusion and sequencing.

The single leader monopoly creates a last-mover advantage. The leader can co-locate with their validator, wait until the end of the slot, and late-pack the block, inserting transactions at the last moment. In some cases, they can also delay or censor competing flow, becoming the only party that reliably submits information to the chain in that slot. 

Viewed as an auction for blockspace, the leader’s privileged position causes the market to unravel into a late-timing game with weaker competition and lower efficiency. Because the leader can act later, they observe slightly fresher price information and can bid conditionally: if price moves up, they can outbid earlier bidders and capture the opportunity; if price moves down, they can simply abstain from bidding.

This turns block production into a timing game: delaying inclusion delays state propagation, increases execution variance, and erodes Solana’s streaming design. Without continuous streaming, the network loses crucial guarantees that market makers rely on, especially around intrablock cancels and deterministic execution, thereby widening spreads.

Part 3: Optimal Block Building

There has been an active debate over what “optimal” block construction means, centered on whether continuous streaming requires progressive shred release or just continuous internal execution. Harmonic's initial design released shreds only after auction completion, arguing this achieved the same result as progressive streaming. Harmonic has since shifted its position, announcing a transition to 50ms microblock auctions that restore intra-slot state updates and shred release throughout the slot, bringing their approach in line with BAM's existing 50ms auction tick.

That said, no single metric captures the full picture. To compare BAM and Harmonic, we focus on latency metrics, specifically handoff and continuation slot-time dynamics, as well as measurable market structure outcomes. Concretely, we examine prop AMM oracle update win rates and markouts by validator client.

Block Build Times: Jito vs. Harmonic

Jito’s IBRL Explorer defined optimal block packing behavior from a validator perspective as: build fast, stream continuously, and propagate state early. Jito’s IBRL score is a weighted mix of these three variables:

• Slot time (40%): Validators score well if their blocks are built within the following thresholds: less than 550ms for handoff slots from another validator, or less than 380ms for continuation slots (i.e., any remaining slot in a leader’s rotation).
• Non-vote packing (45%): The score rewards validators when transactions are distributed uniformly across the slot’s 64 ticks as opposed to cramming the majority of non-vote transactions into the final ticks of the slot (i.e., late packing). This is the most controversial variable for the IBRL score, as we'll explain later.
• Vote early (15%): Validators receive a perfect score when at least 90% of vote transactions are processed within the first 48 ticks. The score decays if votes are pushed later in the block.

Harmonic disputes IBRL's methodology, arguing it conflates their approach with rev strat validators that actually delay execution.

According to Harmonic’s co-founder, Harmonic blocks are continuously executed without delay, but shreds are released only once the auction is done. His argument is that this approach gives block builders enough time to compete and gives the rest of the network enough time to replay Harmonic blocks. Jito counters that slower build times still cascade through the network and that this claim isn't verifiable. They also note that, from a user point of view, Harmonic’s approach is not continuous when considering “sendTxn” to shred notification delay.

In any case, IBRL’s scoring methodology isn’t relevant for the purposes of this report. We use IBRL’s open-source dataset solely to measure median block build times, a practical proxy for latency.

Across epochs 909-926 (Jan. 11 - Feb. 15, 2026), IBRL data shows BAM continuation and handoff medians of 362ms and 398ms, respectively. By contrast, Harmonic’s continuation median (407ms) already exceeds BAM’s handoff median, and its handoff slots reach a 534ms median, with more than 25% of blocks breaching IBRL’s 550ms handoff threshold. Given the unusually wide dispersion in Harmonic’s handoff distribution, we next break the results out by epoch.

Harmonic claims that much of the measured latency is caused by issues in the Agave proposer that disproportionately affected Harmonic, and that the new update has since closed the gap. The data supports this, with Harmonic build times trending downward recently, however, they remain above 400ms with a ~50ms gap to BAM on continuous blocks.

Despite improvements over recent weeks, Harmonic’s aggregation layer still introduces a measurable latency cost vs. BAM. That said, Harmonic’s move toward 50ms microblock auctions, Agave optimizations, and enabling XDP by default in Agave may lead to further improvements in Harmonic’s median latency metrics. 

Block Economics: Longer Slots, Higher Fees

Harmonic’s Dissonance explorer provides block level transparency, surfacing metrics like total fees, fee per compute unit, and SOL movement by block position. In our view, optimizing for fees per block and giving validators the ability to select their blocks is problematic. 

Longer build times mechanically allow validators to observe more incoming transactions, select the highest-fee-paying ones, and maximize rewards. However, that doesn't mean the system is healthier. It may just mean validators are extracting more per slot, the same 'fishing all the fish' dynamic we've seen rather than trying to grow the pie.

Below, we see that longer slot times have consistently led to higher fees per block:

Using all IBRL block data from epoch 906 (Jan. 5, 2026) through epoch 923 (Feb. 9, 2026), we find a positive relationship between slot duration and median fees per block: longer slots tend to generate higher median fees.

Consistent with that, longer build times also correlate with higher compute-unit (CU) consumption: more time simply gives the leader more runway to pack in transactions. Harmonic argues that its higher CUs per block reflect superior packing efficiency, but that claim is impossible to validate given its closed-source implementation – especially when the data already shows a clear positive relationship between slot times and CUs. That said, it’s also possible that some of the added latency is simply overhead from running Harmonic’s auction process, which as we mentioned earlier should improve in the coming months.

Prop AMM: Oracle Update Win Rates

Prop AMMs need frequent oracle updates that land with high-priority execution. Since oracle update transactions are roughly ~100x less compute-intensive than swaps on Solana, a prop AMM can refresh internal pool parameters many times per second and still win top-of-block placement at a relatively low cost. Transaction ordering is crucial, since there’s a race to update quotes before a taker can pick them off.

As such, even when blocks aren't full, the position of a transaction within the block matters. An oracle update landing at tick 5 means every subsequent transaction executes against fresh prices. The same update landing at tick 55 means the delta in ticks of swaps, liquidations, and trades executed against stale data. 

Using data from six prop AMMs (HumidiFi, BisonFi, ZeroFi, Tessera, SolFi, and GoonFi v1), we analyzed prop AMM “win rate” by validator client across 2.82M slots over a two-week window (Dec. 30, 2025 - Jan 14, 2026). We define win rate as the prop AMM that lands the first oracle update in a given slot, measured by the earliest PoH tick. For example, if HumidiFi lands at tick 4, BisonFi at 5, ZeroFi at 6, Tessera at 7, SolFi at 8, and GoonFi at 9, then HumidiFi “wins” that slot.

The chart below summarizes results across all measured slots. HumidiFi’s win rate is substantially higher under Harmonic validators (73.4%) than under other validator clients (37.0 - 51.6%) under the measured period, consistent with concerns around vertical integration.

We would expect the relative ranking of prop AMM “wins” to look more consistent across validators than what we observe here if every validator had neutral ordering. That being said, during the sample period Harmonic represented only ~3-4% of network stake vs. ~16% today, so it’s important to verify if these dynamics have shifted over time. 

The chart below shows HumidiFi’s oracle update win rate by epoch across different validator clients. From epoch 881 (Nov. 17) through epoch 916 (Jan. 16), HumidiFi’s win rate was materially higher on Harmonic than on other validators, peaking near 90%.

However, that edge disappears starting in epoch 917 (Jan. 27-28). While we can’t pin down the exact cause, the timing coincides with HumidiFi no longer receiving order flow from Fomo and DFlow, though it’s unclear whether the two are related. Harmonic also noted that the DFlow situation was purely a technical issue that will get resolved. 

From epoch 917 onward, HumidiFi’s win rate on Harmonic declines materially and the relationship effectively flips. As of Feb. 15, HumidiFi posts its lowest win rate on Harmonic (~10%), versus ~22-31% across other validator clients. Absent full visibility into the underlying mechanics, the most plausible explanations are either (i) competing prop AMMs improved their performance, or (ii) something in Temporal’s behavior or configuration changed.

Oracle Update Positioning

Moreover, we analyzed where oracle updates actually land in blocks across different validator clients. Using data from two prop AMMs (BisonFi and HumidiFi), we tracked the average relative position of oracle updates by block builder from Jan. 1, 2026 to Feb. 16, 2026. 

Harmonic places oracle updates furthest back in the block, with wallets tightly clustered around 75% for Bisonfi and 70% for HumidiFi. BAM is less concentrated, spread broadly from 40% to 65%, with several wallets landing in the first half of the block. BAM’s earlier clustering may be more beneficial for prop AMMs, who race to refresh quotes before takers can pick them off.

BAM's plugin framework will take this further. An oracle-based Pyth plugin integration would allow price feeds to update at specific positions in the block where they're needed, triggered just in time rather than pushed more or less randomly throughout the block, which is the status quo. BAM's plugin roadmap also includes CLOB time priority for onchain order books, cancel before take policies for market makers, and liquidation sequencing for perps. 

Prop AMM: Markouts per Validator Client

Markouts are a measurement of execution quality and adverse selection for market makers, making it a useful assessment for prop AMMs who compete on the same strategy (provide delta-neutral top-of-book liquidity). As such, we can analyze markouts by leader slot to quantify how each builder environment affects short-term adverse selection, and whether any differences persist across time horizons.

Solana’s public Dune dashboard has valuable data on prop AMM markouts per leader slot by validator client. The analysis focuses on SOL-USDC swaps routed through Jupiter and executed on BisonFi, GoonFi, HumidiFi, Scorch, SolFi, and Tessera. For each onchain fill, Solana’s data team computes an implied execution price from the swap amounts and benchmarks that fill against a 1-second SOL-USDC mid-price series at fixed horizons after execution (5s, 30s, 1m, 2m, and 5m), where mid is taken from 1-second snapshots. The observed period is Jan. 26, 2026 to Feb. 9, 2026.

We applied the same methodology with two key modifications. First, for validator-client labeling, rather than relying on a static list that can retroactively misclassify validators, we mapped each validator account to its software client on a per-epoch basis. Second, beyond average markouts, we also analyzed median markouts to better reflect the typical outcome and capture how results differ across the full trade distribution.

For users to see tight spreads, makers need the post-fill price move to not systematically run against them, otherwise they widen spreads or reduce liquidity to compensate.

• A positive markout means the reference price moved in favor of the prop AMM’s position after the fill. This indicates the maker is executing soft/non-toxic flow.
• By contrast, a negative markout signals adverse selection, where the price moved against the prop AMM following the trade. That said, short horizon negatives can also reflect transient impact or benchmark effects.

The chart below shows average 5-second prop AMM markouts across every validator client. 

Breaking average volume-weighted markouts by individual prop AMM reveals meaningful dispersion, but BAM generally delivers more favorable markouts per leader slot than Harmonic on a 5-second horizon:

• SolFi v2 is the standout: markouts are positive across all clients, but BAM is meaningfully higher than Harmonic (roughly ~4 bps vs ~2 bps), indicating better execution quality for AMMs when the leader is using BAM.
   
• GoonFi shows the sharpest divergence: BAM is strongly positive (~3 bps) while Harmonic is negative (~-0.7 bps), a clear flip in sign that suggests Harmonic slots were more adverse for prop AMMs over this window.
   
• Elsewhere the differences compress, but the direction is similar: for other venues (e.g., BisonFi, Scorch, Tessera), markouts cluster near zero to modestly positive, with Harmonic typically at or below BAM (and occasionally slightly negative), implying BAM delivered better results on the margin.

That said, averages can be disproportionately influenced by a small number of outliers. Below, we present the same metric using median markouts instead of the mean. On this measure, Harmonic posts better median markouts across every prop AMM, suggesting that under “typical” conditions it outperforms BAM. But what is typical may just mean retail flow.

The divergence between Harmonic’s stronger medians and weaker averages implies that its mean markouts are being pulled down by left-tail (negative) outliers. In other words, while the median may better reflect what a retail-like fill looks like most of the time, market making is ultimately a tail-risk business: “market makers pick up pennies and lose dollars.” Harmonic may look better on the margin for benign flow, but it appears to perform worse when interacting with toxic takers, where occasional large adverse-selection events can dominate realized PnL.

At the 30-second horizon, Harmonic delivers worse average markouts for every prop AMM except GoonFi. Most notably, BisonFi and HumidiFi flip sharply negative, to nearly -1 bps, indicating materially worse execution quality under Harmonic at this interval. By contrast, under BAM, the majority of prop AMMs remain positive at 30 seconds.

Once again, when we switch to a median lens, Harmonic outperforms every prop AMM except BisonFi. But as noted above, this primarily indicates stronger outcomes under Harmonic in typical, retail-like conditions. The mean is more representative of the economic reality of market making because it incorporates the tail events that ultimately determine realized PnL.

In Harmonic’s case, the left-tail of slots appears to dominate the average. In practice, large left-tail outcomes can overwhelm many small wins and, for some venues, even drive net PnL negative over the sample period. The chart below isolates tail risk: the worst 0.1% volume-weighted markout outcomes per leader slot at a 30s horizon.

The main takeaway is that Harmonic has materially worse extreme left-tail outcomes.
Across every prop AMM shown, Harmonic’s worst-case slots are as bad as BAM’s, and in most cases meaningfully worse, implying greater exposure to rare but severe adverse-selection events under Harmonic.

Part 4: Multiple Concurrent Proposers (MCP)

Why MCP

Solana’s block-building debate ultimately comes down to incentives. As long as a single leader has broad discretion over sequencing and timing – and that discretion is sometimes profitable – some share of validators will rationally exercise it, even when it degrades execution quality for everyone else. Market-based approaches can improve outcomes, but they struggle to produce consistent guarantees. MCP is best understood as a protocol-level attempt to make those guarantees uniform across all slots.

In this regard, there seem to be two distinct issues at hand, which we can frame as better blocks vs. consistent blocks:

1. Better blocks (empirical): different block building approaches measurably change market structure outcomes (slot-time behavior, packing patterns, markouts, cancel reliability). In the observed data, BAM produced better market structure outcomes than Harmonic.
2. Consistent blocks (incentives): even if one approach is better on average, optionality at the base layer means outcomes remain leader-dependent as long as defection is available and profitable. The end state therefore requires protocol-enforced constraints, potentially MCP, constraining the design space so market structure is not contingent on who happens to be the leader.

MCP: Minimal Guarantees

From the perspective of apps and users, the goal is simple: neutrality at the base layer, and predictable rules of the game. Under the “can’t be evil > don’t be evil” lens, MCP is designed to provide two minimal properties. As Max Resnick defined at Breakpoint:

1. Selective censorship resistance (neutrality): If you submit a transaction to an honest proposer, then either you get in, or nobody should get in.
    
2. Hiding (pre-trade privacy): An adversary cannot infer the contents of an honest leader’s block before the block’s contents are already final.

Together, these reduce deterministic last-look dynamics and weaken the incentive to wait until the end of the slot, improving competitive quoting and execution.

MCP Roadmap

MCP builds on Alpenglow, a new consensus protocol for the network. Of note, Anza’s current target is to have Alpenglow in production by August 2026, so a realistic timeline for MCP to go live would be 12-18 months.

Alpenglow introduces two new core modules that are designed to replace Tower BFT, Proof of History, and gossip-based vote propagation.

• Votor: Alpenglow’s voting component. Votor can finalize blocks in a single round when ~80% of stake is participating, and in two rounds if only ~60% of stake is responsive. These two voting modes run concurrently, so finalization occurs as soon as the faster of the two paths completes. Crucially, the two-hop path can sometimes be faster than single-round voting depending on validator proximity (e.g., two hops within Europe can be faster than one hop from New York to Tokyo).
• Rotor: Alpenglow’s data dissemination sub-protocol. Rotor embraces Turbine’s approach but refines it by using a single layer of relay nodes, rather than Turbine’s multi-layer tree today. In doing so, Rotor reduces the number of network hops.

From Alpenglow to Supernova Part 1

The diagram below shows the block construction flow from Alpenglow to Supernova Part 1, which is expected to include the first iteration of MCP. Each box represents a validator; they are simply chosen by the network to participate in different roles.

In Alpenglow, a client sends transactions to a leader; the leader streams shreds to relays (or Turbine roots), which forward them to validators. Validators then vote and finalize the block under Alpenglow’s Votor consensus.

In Supernova Part 1, the client sends transactions to multiple proposers rather than a single leader. Each proposer streams shreds to relays (or Turbine roots), and those relays forward shreds to validators as they do today during the retransmit stage. In parallel, relays send an additional message (an attestation) to the leader. The leader aggregates these attestations into an aggregate block, and that is what validators ultimately come to consensus on.

Multi-Leader Turbine

The key change to enable MCP happens in Turbine’s propagation layer. Anza will keep the high-level structure of Turbine under Supernova part 1, but will add multiple proposers instead of a single leader. The diagram below shows how multi-leader Turbine will work.

Under Supernova’s multi-leader Turbine:

1. Multiple leaders propose blocks concurrently.
2. Each block is erasure-coded into 64 shreds.
3. Shreds are sent to relays in the network.
4. Relays forward shreds to validators as before, but they also send attestation messages to the consensus leader indicating which shreds they received.
5. The consensus leader packs an aggregate block that includes an aggregation of these attestations.
6. The aggregate block is broadcast to all validators, who vote under Alpenglow’s Votor mechanism.

In this regard, MCP introduces key changes to Votor. For a block to be considered valid:

• At least 60% of relays must be attested by the leader.
• At least 40% of shreds must be present in the leader’s aggregate attestation.
• With as little as 20% of shreds, validators can reconstruct the block and verify correctness before voting.

MCP: Transaction Sequencing Rules

The core market structure issue MCP addresses is leader-dependent discretion: when a single actor controls sequencing, they can delay, reorder, or selectively exclude transactions. By moving key ordering and inclusion constraints into the protocol, MCP aims to provide selective censorship resistance and more consistent rules of the game, so real-time applications aren’t forced to adapt to whoever happens to be the leader. 

MCP orders transactions by priority fee per compute unit. The longer-term goal, unlikely to ship in the first MCP iteration, is to enable Application Controlled Execution (ACE). As Resnick and Toly wrote in the original MCP post, the idea is to “give more flexibility to apps to control their ordering.” A key proposed ingredient is a syscall, get_transaction_metadata, which would allow programs to read the ordering fee of transactions that interact with them, giving apps a powerful primitive for enforcing their own ordering logic.

It’s worth emphasizing that, via different architectures, MCP and BAM are converging on a similar default behavior and endpoint. Both order by priority fee per compute unit by default, and both aim to enable ACE:

• BAM through Plugins,
• MCP through the metadata syscall and in-protocol rules.

The tradeoff is straightforward: BAM is already in production and Plugins are being tested today, while MCP is still 12-18 months out; in return, MCP’s advantage is that it’s in-protocol, enforcing a single standard rather than relying on voluntary adoption.

Part 5: Fragmentation vs Standardization

A key theme emerging from our research is that Solana's biggest risk may be that it's too decentralized, and the ability to coordinate becomes too difficult. These are headwinds any mature network eventually faces, as we’ve seen with Ethereum. Today, Jito, Harmonic, Anza, and other parties are each pursuing their own vision for the ecosystem.

This fragmentation creates execution variance that adds significant friction to applications and market makers. Solana's core value proposition depends on delivering execution quality that can compete with centralized venues. If block building dynamics and fragmentation across the transaction supply chain prevent the network from being on par with its centralized counterparts, liquidity and order flow will likely migrate elsewhere.

That said, while an in-protocol solution like MCP may be the optimal long-term outcome for Solana, centralizing block construction at the protocol layer is not without tradeoffs. BAM and Harmonic can iterate faster as out-of-protocol solutions, shipping changes without requiring coordinated network upgrades. Solana's current architecture also preserves optimistic inclusion, where users can know their trade succeeded in milliseconds, whereas MCP's multi-proposer model (at least the first iteration) requires waiting for the full block to be assembled and sorted before confirmation.  

Whether BAM and Harmonic survive the transition to MCP is an open question. Both stacks rely on validators outsourcing block construction to third-party infrastructure; once MCP brings that functionality in-protocol, that dependency largely disappears. Notably, Jito has oriented BAM toward compatibility with Solana's protocol roadmap and expressed confidence in MCP's development, arguing BAM can still provide value through privacy, verifiability, and plugin sequencing even after MCP ships. Both Jito and Harmonic remain cautious of core dev timelines to ship MCP, with Harmonic noting they will need to adapt their system post-MCP.

Transaction Landing Services and Fee Dynamics

Solana’s fragmentation issue goes beyond block building. Beyond block builders, transaction landing services have proliferated to address Solana’s default TPU limitations. 

Nozomi, Jito bundles, bloXroute, 0slot, and Astralane, all compete for this flow, each offering slightly different transaction inclusion guarantees. When congestion spikes, users and applications need a way to ensure their transactions land, and they're willing to pay for it. The result is a fee stack that has grown increasingly complex: base fees, priority fees, and out of protocol tips, often layered on top of each other without clear visibility into what's actually necessary.

Research from RockawayX and Benedict Brady found that many users, particularly those routing through frontends like Axiom, are paying significantly more in tips than required to land their transactions. Users lack visibility into what fee level is sufficient, so they overpay to guarantee inclusion, a problem compounded by frontend UIs that default users into aggressive tip levels benefiting the application and its infrastructure partners.

**Jito has signaled plans to simplify fee structures over time. **On a recent tokenholder call, the team indicated that the long-term goal is to collapse the fee stack down to priority fees alone, with Jito taking a cut at that layer. We believe this is the right direction. Today, market makers operate across a convoluted stack of base fees, priority fees, and out-of-protocol tips, each with its own sorting logic and venue, creating opacity that ultimately gets priced into every trade. A flattened fee structure where participants can know exactly what they paid and where they landed gives market makers clearer cost inputs to model, which should translate into tighter spreads and better execution for end users. 

Simplifying the fee stack is only part of the equation. BAM's guarantees only deliver their full value with majority stake adoption. At roughly 27% today, market makers still face inconsistent execution slot to slot. In this regard, there is precedent for rapid convergence: Jito bundles reached 97% adoption purely through economics without protocol enforcement. If BAM follows a similar path, de facto standardization could arrive before MCP. But if adoption stalls, Solana's block space risks fracturing into tiers where market makers widen spreads during non-BAM slots, producing a worse outcome for everyone.

Part 6: The Centralization Advantage

Timing matters and the competitive pressure is real. Solana is the clear L1 leader today, but emerging players with more centralized development processes can ship protocol-level changes with far less coordination overhead. Of course, this is a sign of Solana’s network maturity and an unavoidable headwind, but it’s important the community is aware of it.

On these chains, a tighter set of decision-makers can more easily align on execution environment design and block construction. That structural advantage lets them iterate faster, without the coordination burden that comes with Solana’s more fragmented infrastructure landscape:

• Sui's object model provides deterministic ordering and parallel execution by design, with transactions touching independent state bypassing consensus entirely. The properties Solana is building toward with MCP, such as censorship resistance and removing validator ordering power, are essentially native to Sui's architecture. 
   
• Aptos is shipping an encrypted mempool natively at the protocol level, ensuring transaction confidentiality and preventing frontrunning before execution. Transaction ordering is handled by a single consensus pipeline with no third-party block building. 
   
• Sei's Giga builds MEV resistance and application-specific ordering directly into the protocol, allowing apps to control transaction sequencing within their own execution context. Frontrunning protection and batch auction mechanics are native to the chain. 

While activity on the chains above is still relatively small, Hyperliquid dominates the perps landscape in part because its design guarantees the execution environment traders need. Solana’s L1 leadership means little if high-value use cases keep migrating to purpose-built alternatives. When a market maker can go from zero to quoting on Hyperliquid far more quickly, the cost of Solana's infrastructure complexity isn't just wider spreads, it's flow that never arrives.

Hyperliquid has acknowledged that a multiple proposer block building setup as a key decentralization milestone. Hence, Solana is trying to standardize a fragmented system through MCP, while Hyperliquid is trying to decentralize one that already delivers the execution quality traders demand. The difference is that Hyperliquid iterates toward decentralization from a position where market structure already works. Solana has to fix market structure before the full weight of its integrated architecture and existing decentralization become a genuine competitive advantage.

Conclusion

Solana's block building landscape is defined by competitive dynamics, but analyzing it closely reveals a fundamental coordination problem the chain must solve. BAM delivers measurably better market structure outcomes today, but its benefits remain partial as long as adoption is voluntary and execution quality varies from slot to slot. Meanwhile, Harmonic is committed to open-sourcing its system and improving block construction design with 50ms microblock auctions. MCP represents the definitive fix by moving transaction ordering guarantees into the protocol itself, eliminating the fragmentation that forces market makers to price in infrastructure uncertainty. Until that arrives, the gap between what Solana can offer and what purpose built venues are able to deliver is the window competitors will continue to capitalize on. 

 

 

The information contained in this report and by Blockworks Inc. and related affiliates is for general informational purposes only and is not intended to provide legal, financial, or investment advice. The report should not be construed as an offer or solicitation to buy or sell any security, token, or financial instrument and does not represent any recommendation or endorsement of any investment or financial product or service. Blockworks Inc. and related affiliates are not registered as a securities broker-dealer or an investment advisor in any jurisdiction or country.