Author: Carlos, Luke Leasure
Original Title: Solana’s block-building wars
Compiled and Edited by: BitpushNews
2026年1月5日, JITO launched a public tool called IBRL Explorer, designed to measure the block packaging behavior of validators on Solana and expose the previously invisible "timing games" in block construction.
First, we need to understand some background about Solana's market structure. Solana is designed as a streaming system: ideally, while a block is being built, the leader continuously disseminates data fragments (i.e., small data packets). This behavior aims to minimize transaction landing latency (the interval between a validator receiving a transaction and that transaction being processed). However, whether Solana's transaction pipeline is truly continuous actually depends on how validators assemble their blocks.
Jito defines the optimal block packaging behavior from the validator's perspective: fast construction, continuous streaming transmission, and early state propagation. Jito's IBRL score is a weighted mix of these three variables:
-
Slot Time (35%): Validators score higher if their block is built within the following thresholds: a handover slot taken over from another validator is less than 550 milliseconds, or as a continuous slot (i.e., any remaining slot in the leader's rotation) is less than 380 milliseconds.
-
Non-Vote Transaction Packaging (40%): Validators are rewarded with points when transactions are evenly distributed across the 64 ticks of a slot (rather than cramming most non-vote transactions into the last few ticks of the slot, i.e., "delayed packaging"). This is the most controversial variable in the IBRL score, which will be explained in detail later.
-
Early Voting (25%): Validators get a full score when at least 90% of the vote transactions are processed within the first 32 ticks. The score decreases if votes are pushed to later parts of the block.
IBRL Explorer shows that many validators exhibit delayed packaging of non-vote transactions, and in some cases, even extend the slot time. Delayed packaging postpones state propagation, increases the variance of execution results, undermines Solana's streaming design, and thus reduces network latency. What you get is not a continuous data stream, but a bursty data eruption.
In an optimal block, as in the example below from a Helius validator, most vote transactions are processed in the first half of the block ("early state propagation"), while non-vote transactions are relatively evenly distributed across the 64 ticks of the slot ("continuous streaming transmission").
According to Lucas Bruder, co-founder and CEO of Jito Labs, validators are incentivized to wait until the last moment of the slot to observe more incoming transactions, selecting those with the highest fees to maximize rewards.
But why should users care? While maximizing profit is rational behavior for an individual validator, this behavior introduces hidden censorship, delays state propagation, and forces the next leader to "catch up," thereby slowing down the entire network.
More importantly, delayed packaging is also directly related to Solana's emerging "Payment for Order Flow" (PFOF) dynamics, as outlined by Benedict Brady in this article. Because wallets and applications often generate pre-routed signed transactions (i.e., market orders with slippage limits), valuable "back-running" options are embedded in the orders. The user-beneficial practice is to sell this back-running right to trading firms, while the extractive practice is to conduct "sandwich attacks." Either way, there is an incentive to increase the value of back-running by slowing down transaction landing speed, which is exactly what delayed packaging achieves.
This incentive pushes Solana towards a more adversarial market structure for applications and users. It also weakens the key guarantees that market makers rely on, particularly regarding in-block cancellations and deterministic execution, leading to wider bid-ask spreads. Without streaming, no matter how excellent the application logic, a truly real-time market remains out of reach for Solana.
Temporal vs. Jito Debate
Before delving into how Solana addresses this issue, it must be acknowledged that there is an active debate even about what constitutes "good" block construction. Temporal, a core contributor to Harmonic, has raised objections to Jito's framework and IBRL scoring method. Their criticism is that the score embeds a specific set of design preferences that favor Jito's block construction method and by default make Harmonic appear worse, reflected in the consistently lower scores of validators running Harmonic.
According to the Harmonic co-founder, Harmonic's blocks are executed continuously without delay, but data fragments are only released after an auction process lasting about 300 milliseconds is completed. This method gives block builders enough time to compete and gives the rest of the network enough time to replay Harmonic's block. The visualization below shows the same slot (391,822,619) from Temporal Emerald, a validator running Harmonic.
From the context of how the block is propagated (above figure), Harmonic's execution appears to be evenly spaced. In other words, the block builder continuously constructs the block through parallel block construction, and the reason transactions are only concentrated in the final ticks (below figure) is because that is the moment the auction resolves.
Over the past 30 days, Harmonic has outperformed both Jito and Firedancer in terms of average and median total revenue per block (priority fees + tips), thereby delivering higher rewards to validators and stakers. The open question is whether this superior performance is achieved at the expense of users through the timing games described above.
Source: https://reports.firedancer.io/
Multiple Concurrent Proposers (MCP) & BAM
After presenting both sides, one point still holds true: continuous streaming is crucial.
Harmonic's claim is not that streaming is unimportant, but that IBRL fails to capture how Harmonic achieves it and may misclassify its auction mechanism as "timing games." At this stage, I do not yet have sufficient technical background or data to form a definitive opinion, but Solana is already developing a protocol-level solution aimed at addressing the underlying incentive problem.
This solution is Multiple Concurrent Proposers (MCP), an architecture developed by Anatoly Yakovenko and Max Resnick. The motivation is simple: under the current single-leader model, one proposer controls ordering and can effectively act later than others, enabling delayed packaging and reinforcing the PFOF-like dynamics described above. MCP eliminates the single leader's monopoly by having multiple proposers build candidate blocks in parallel and independently. This architecture prevents a single leader from unilaterally suppressing transactions or delaying execution to extract profits.
That said, a prerequisite for MCP is the launch of Alpenglow on the mainnet. Alpenglow is expected to launch in 2026, but the timeline remains uncertain. In the meantime, Jito's BAM might drive change by making ordering logic auditable. BAM aims to expand Solana's micro-structural design space, enabling applications that require finer control over ordering (e.g., prioritizing cancellation orders for perpetual contract trading venues), while also helping to mitigate negative MEV externalities like front-running. The figure below outlines BAM's transaction pipeline.
It will be worth watching how the competitive dynamics of block construction evolve in the coming months and what this means for Solana's market structure.
