Data Revelation: Solana Transfers Slow Down, Is It Validators "Messing Around"?

Author: Carlos, Luke Leasure

Original Title: Solana’s block-building wars

Translation and Editing: BitpushNews

On January 5, 2026, JITO launched a public tool called IBRL Explorer, aimed at measuring validator block packing behavior on Solana and revealing the previously unseen “timing games” in block construction.

First, we need to understand some background about Solana’s market structure. Solana is designed as a streaming processing system: ideally, as a block is being built, leaders continuously propagate data fragments (small data packets). This behavior aims to minimize transaction finality delay (the time between a validator receiving a transaction and processing it). However, whether Solana’s transaction pipeline is truly continuous depends on how validators assemble their blocks.

Jito defines the optimal block packing behavior from a validator’s perspective: fast construction, continuous streaming, and early state propagation. Jito’s IBRL score is a weighted blend of these three variables:

• Slot Time (35%): Higher scores are awarded if the block is completed within a threshold: less than 550 milliseconds for handoff slots from another validator, or less than 380 milliseconds for consecutive slots (i.e., slots remaining in the leader’s rotation).
• Non-voting Transaction Packing (40%): Validators earn points when transactions are evenly distributed across the 64 ticks of a slot (rather than packing most non-voting transactions into the last few ticks, i.e., “delayed packing”). This is the most controversial variable in the IBRL score, explained in detail below.
• Early Voting (25%): Validators receive full points if at least 90% of voting transactions are processed within the first 32 ticks. If votes are delayed to later parts of the block, scores decrease.

IBRL Explorer shows that many validators engage in non-voting transaction delay packing, sometimes even extending slot times. Delayed packing postpones state propagation, increases variance in execution results, disrupts Solana’s streaming design, and reduces network latency. Instead of a continuous data flow, what you get is a burst of data.

In an optimal block, as shown in the example from Helius validators below, most voting transactions are processed in the first half of the block (“early state propagation”), while non-voting transactions are relatively evenly distributed across the 64 ticks (“continuous streaming”).

In contrast, intentional delayed packing is clearly visible in the example block from Galaxy below, where most non-voting transactions are packed into the last few ticks of the slot. By doing so, validators prioritize extractive value over network health by delaying state transitions until the last moment.

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 and choose to pay the highest fees, thereby maximizing rewards.

But why should users care? While maximizing profit is rational for individual validators, this behavior introduces covert censorship, delays state propagation, and forces the next leader to “catch up,” slowing down the entire network.

More importantly, delayed packing is directly related to Solana’s emerging “Order Flow Payment” (PFOF) dynamics, as outlined by Benedict Brady in this article. Since wallets and applications often generate pre-routed signed transactions (market orders with slippage limits), the order embeds valuable “post-execution” options. A user-friendly approach is to sell this post-execution right to trading firms, while extractive strategies involve “sandwich attacks.” Both motives aim to slow transaction finality to increase the value of post-execution options, which delayed packing enables.

This incentive pushes Solana toward a more adversarial market structure against applications and users. It also weakens key guarantees relied upon by market makers, especially regarding in-block cancellations and deterministic execution, leading to wider bid-ask spreads. Without streaming, no matter how excellent the application logic, true real-time markets remain out of reach for Solana.

Temporal vs. Jito Debate

Before delving into how Solana might address this issue, it’s important to acknowledge that there is an active debate about what constitutes “good” block building. Harmonic’s core contributor Temporal has challenged Jito’s framework and IBRL scoring method. Their criticism is that the score embeds specific design biases favoring Jito’s block construction approach and implicitly makes Harmonic look worse, reflected in validators running Harmonic consistently receiving lower scores.

According to Harmonic co-founders, Harmonic’s blocks are executed continuously without delay, but data fragments are only released after about 300 milliseconds of auction completion. This approach gives block builders enough competition time and allows the rest of the network to replay Harmonic’s blocks. The visualization below shows the same slot from a Harmonic validator, Temporal Emerald, at (391,822,619).

From the context of how blocks propagate (above), Harmonic’s execution appears evenly spaced. In other words, block builders continuously construct blocks in parallel, and transactions only cluster at the final tick because that’s when the auction resolution occurs.

Over the past 30 days, Harmonic has outperformed Jito and Firedancer in both average and median total revenue (priority fees + tips) per block, delivering higher rewards to validators and stakers. The unresolved question is whether this superior performance is achieved through the timing game described above, at the expense of user interests.

Source: https://reports.firedancer.io/

Multi- proposer concurrency (MCP) and BAM

After presenting both sides, one point remains clear: continuous streaming is crucial.

Harmonic’s argument is not that streaming isn’t important, but that IBRL fails to capture how Harmonic achieves it and may misclassify its auction mechanism as a “timing game.” At this stage, I lack enough technical background or data to form a definitive opinion, but Solana is already developing an on-chain protocol solution aimed at addressing underlying incentive issues.

This solution is Multi-Concurrent Proposers (MCP), an architecture developed by Anatoly Yakovenko and Max Resnick. The motivation is simple: under today’s single-leader model, one proposer controls ordering and can, in effect, act later than others, enabling delayed packing and reinforcing the PFOF-like dynamics described above. MCP eliminates the monopoly of a single leader by allowing multiple proposers to independently build candidate blocks in parallel. This architecture can prevent a single leader from unilaterally suppressing transactions or delaying execution for profit.

In other words, a prerequisite for MCP is the launch of Alpenglow on mainnet. Alpenglow is expected in 2026, but the timeline remains uncertain. Meanwhile, Jito’s BAM may drive change by making the ordering logic auditable. BAM aims to expand Solana’s microstructure design space, enabling applications that require finer control over ordering (e.g., prioritizing cancellations in perpetual futures exchanges), while also helping mitigate negative MEV externalities like front-running. The diagram below outlines BAM’s transaction pipeline.

BAM (Agave-BAM) is currently the third-largest client on Solana by staked share (~12%), after Agave-Jito and Frankendancer-Jito. About 205 validators are running BAM, highlighting its rapid adoption among Solana validators. In comparison, Harmonic remains relatively small, with just over 3% of staked share and around 20 validators.

It will be interesting to see how the competition in block building evolves in the coming months and what this means for Solana’s market structure.