Block Building on Solana and the Future of Internet Capital Markets
Solana’s Block-Building Environment Today
Roughly every 400 milliseconds (a slot period), Solana produces a new block that updates the state of its decentralized ledger. This is what enables you to trade, interact with DeFi, and transact seamlessly.
In theory, the block production process looks straightforward and seems to follow clear rules. Validators take turns being the leader (block producer) for each slot (of 400ms). The leader is responsible for gathering transactions, producing a valid block, and broadcasting it to the rest of the network. Other validators then vote to verify the block’s validity and ensure it adheres to the network’s rules. And this process goes on and on forever.
But in practice, every validator has its own strategy for packing transactions into those 400-millisecond blocks, and how they do so can significantly shape the user experience on Solana. It affects whether a trade goes through, whether a user gets the expected quoted price, and ultimately whether TradFi institutions can comfortably scale their onchain operations.
In other words, the behavior of a small set of validators, deciding in an opaque way how to build and broadcast blocks in order to maximize short-term profit, can create ripple effects across the entire network and impact all stakeholders. At the extreme, this even puts pressure on Solana’s long-term ambition of becoming the home of Internet Capital Markets.
This is a big deal, and it has sparked an increasingly heated debate around how block building on Solana should be structured to best serve the network over the long term.
In this article, we’ll explore the core issues around block building on Solana, the solution Jito is proposing with BAM, and the perspective of a notable outlier in this debate: Harmonic.
Block Building Problems Identified by Jito
Jito, one of the leading infrastructure providers on Solana and a core contributor to its validator and MEV ecosystem, has spent significant time studying how validators construct blocks in practice. Given its direct exposure to validator behavior, transaction flow, and execution outcomes at scale, they are uniquely positioned to have a view on the current block-building process on Solana.
Through this work, they have identified two core issues in the current block-building environment that, they argue, materially impact user experience and put pressure on Solana’s long-term vision: late packing and slot lagging, which we’ll explore in detail below.
Problem number 1: Late packing
Solana is designed as a high-speed streaming system. In theory, validators are expected to pack transactions continuously throughout the slot while broadcasting block data as shreds over Turbine. This allows the rest of the network to reconstruct and replay the block in near real time.
However, Jito observed that some validators tend to concentrate most of their transaction packing toward the very end of the slot. The rationale behind this behavior is simple: delaying transaction inclusion as long as possible allows validators to observe more incoming transactions and, as a result, extract additional MEV or prioritize higher-paying order flow to maximize revenue per block. The issue is that this behavior is often pursued without fully accounting for the second-order effects it can have on the rest of the network.
Before going deeper, let’s just look at different block-building strategies using IBRL, a new explorer released by Jito that shines a light on block packing and provides a score to assess how closely validators adhere to best practices and standards. This allows stakers to inspect how specific validators build and pack their blocks.
Here we see different packing strategy from three different validator, Helius, Figment, and Galaxy:
We observe drastically different block-packing strategies. In this example, Helius has the highest score, which implies stronger alignment, as its blocks are packed much more uniformly throughout the slot. In contrast, Galaxy has the lowest score and clearly exhibits a late-packing pattern.
This lack of a shared standard for uniform and deterministic block packing is a real problem. We’ll explain why in a moment. But first, let’s introduce the second major issue identified by Jito: slot lagging.
Problem 2: Delaying State propagation
Slot lagging refers to the practice where validators modify their Proof of History (PoH) parameters to extend slot times beyond Solana’s default ~360 milliseconds.
Similar to the late packing issue, the rationale is straightforward. By extending the effective slot duration, validators give themselves more time to observe incoming transactions, and pack more profitable transactions into their blocks.
However, this behavior breaks an important assumption of the network: that slots progress as fast as possible and at a consistent pace. Other validators expect blocks to be produced and propagated within a tight timing window. When a leader intentionally runs longer slots, block propagation is delayed, state updates arrive late, and in some cases validators vote on the state of the network later than expected. This also means traders have to wait on new state updates which affect their operations.
Even if only a subset of validators engages in slot timing games, the impact is shared by everyone: confirmation times become less predictable, latency increases, and the network drifts away from its intended high-speed streaming model.
For instance, we can see that Jupiter has a much better slot timing score than Kiln. As a result, even though both validators do not show poor transaction packing behavior, Kiln still ends up with a lower overall IBRL alignment score compared to Jupiter.
The Downstream Implications
At first glance, these behaviors may seem understandable. Validators are economic actors, and it is rational for them to optimize for short-term profit. However, in practice, late packing and slot timing games create downstream effects that harm the network as a whole and ultimately work against Solana’s long-term goals.
Below are the main implications we observed:
Misaligned with Solana’s “Increase Bandwidth, Reduce Latency” vision
If there is one principle consistently emphasized by Anatoly, Solana’s co-founder and that should effectively serve as Solana’s guiding motto, it is this: “increase bandwidth, reduce latency.”
However, when transaction packing becomes end-loaded and validators engage in slot timing games, Solana’s block pipeline stops behaving like a true streaming system. Even if a slot technically finishes on time, state updates are propagated late across the network. As a result, other validators end up voting later than they should, not because of their own processing delays, but because they are waiting for late-arriving data from the block producer. This increases end-to-end latency and degrades overall network efficiency, which runs directly counter to Solana’s core vision.
Moreover, Solana’s consensus mechanism rewards validators for timely votes via vote credits, and there is a bounded window in which votes must be submitted to receive full rewards. While geographically clustered validators may not feel the impact of late propagation as strongly, validators that are further away from the cluster are disproportionately affected. Over time, this creates subtle pressure against geographic decentralization, as validators farther from the network’s core face higher penalties through no fault of their own.
Unfriendly market structure for market participants
From a market microstructure perspective, traditional financial markets operate in a continuous and highly deterministic environment. Orders arrive continuously and are executed on a First-In, First-Out (FIFO) basis by a centralized matching engine. This determinism allows market makers to cancel and update quotes efficiently without constantly risking being picked off. As a result, they can quote extremely tight spreads, even on trades worth millions of dollars, without relying on priority fees.
Late packing breaks this determinism. When transactions are not included continuously throughout the slot, execution becomes less predictable. This increases execution variance, introduces jitter, and makes outcomes around liquidations and auctions harder to anticipate.
A block-building environment that lacks uniformity and determinism is simply not suitable for sophisticated market participants. Over time, this makes it harder for Solana to onboard and retain TradFi and ultimately undermines its ambition of becoming a globally distributed NASDAQ.
Negative impact on user experience
Beyond abstract market structure concerns, late packing and slot timing games have very concrete second-order effects. Block building that maximizes rewards often does so at the expense of applications and users.
When block packing is inconsistent or delayed, users face higher uncertainty around transaction inclusion. A trade that should have gone through may fail. A swap may execute at a worse price than expected. A liquidation or arbitrage transaction may miss its execution window entirely. And a trader who needs the freshest info about the next state transition is operating less efficiently. From the user’s perspective, this shows up as failed transactions, unexpected slippage, or the need to repeatedly resubmit transactions with higher priority fees. Overall, this directly impacts application reliability.
If we assume that the network should improve every day, becoming faster, more reliable, and easier to interact with, then these dynamics are clearly misaligned with that goal.
The Block Assembly Marketplace
To address the block-building issues outlined above, Jito recently introduced the Block Assembly Marketplace (BAM). Put simply, BAM is a new block-building architecture designed to bring verifiability, privacy, and programmability to Solana’s transaction pipeline.
Instead of allowing each validator to independently decide how to pack and order transactions (often in short-term, profit-maximizing ways, as discussed earlier), validators can delegate transaction scheduling to specialized external BAM nodes. These nodes operate inside Trusted Execution Environments (TEEs), which provide strong cryptographic guarantees that the ordering logic is executed exactly as specified.
In other words, validators still validate and vote on blocks, but BAM nodes handle transaction ordering in a way that is verifiable, auditable, and tamper-resistant. The logic behind this is that BAM’s ordering is designed to optimize Solana’s long-term potential by bringing uniformity and determinism to the block-building process and helps create a healthier market structure.
Specifically, BAM is designed around several key properties:
BAM nodes receive transactions from clients and schedule them according to transparent, verifiable ordering rules.
BAM nodes forward transaction sequences to the leader .
The leader executes the transactions exactly in the order they were received, produces the block, and broadcasts it to the network.
BAM nodes verify execution results match the forwarded sequences. Leaders who insert or reorder transactions are disconnected.
BAM’s structure is designed to provide transaction ordering which is verifiable and enforced by secure hardware. Since launch, BAM has seen over 122m SOL staked, capturing 28.9% of total Solana stake and 367 validators running BAM.
At a high level, Jito proposed a structural shift in how block building works on Solana by creating a more predictable, fair, and deterministic execution environment with BAM. However, this has also sparked debate within the ecosystem. Some teams argue that this approach gives Jito too much influence over block building and could centralize power around a single infrastructure provider. From their perspective, BAM risks becoming a de facto monopoly over transaction ordering rather than a neutral coordination layer.
This pushback is important, as it has brought alternative viewpoints into the discussion. Notably, one of the strongest responses came from Harmonic, a competing Solana block-building solution developed by the Temporal team.
Harmonic’s Approach To Block-Building
Harmonic works as an aggregation layer that runs multiple block builders in parallel, where each builder constructs its own version of the block and the validator picks whichever one best fits its preferences. In addition to Harmonic, the Temporal team also operates Nozomi, a transaction landing service, and more notably HumidiFi, a leading prop AMM on Solana, having an established presence across multiple layers of Solana’s transaction supply chain.
At a high level, Harmonic’s core disagreements with Jito center around what should be optimized, how it should be measured, and who gets to define the standards in Solana’s block building environment.
Concerns around monopoly dynamics and metric neutrality
One of Harmonic’s core criticisms is that Jito plays multiple roles at once: infrastructure provider, BAM architect, and creator of the IBRL scoring framework. From Harmonic’s perspective, this creates an inherent conflict of interest. They argue that IBRL does not measure “good block building” in a neutral way, but instead measures compliance with Jito’s preferred architecture, and thereby penalizes competing approaches. But we will see that this claim is nuanced.
Disagreement on “late packing”
Harmonic also strongly disputes the claim that their blocks rely on late packing in the sense described by Jito. According to them, the IBRL scoring framework misses a key detail: Harmonic blocks are packed continuously by block builders running parallel block-building processes. Transactions only appear in the final ticks because that is when the auction resolves, not because block construction is delayed. From Harmonic’s perspective, it is not fair that IBRL penalizes this behavior simply because it looks less smooth on the surface.
The only metric that matter for Harmonic: execution
From Harmonic’s perspective, best execution is the only metric that truly matters if Solana is to become the home of Internet Capital Markets. On that front, they argue that BAM does not deliver the optimal outcome. They claim that when looking at execution data across DEX programs, Harmonic shows the strongest results: validators running Harmonic repeatedly outperform the cluster baseline on both mean and median throughput. For them, this is the clearest measure of best execution, and this is what Solana ultimately needs.
Innovation through competition
Harmonic’s final argument is that only open competition can sustainably drive innovation in block building. From their perspective, it is far easier for stakers and validators to hold multiple competing block builders accountable than it is to keep a single dominant architecture in check. Prematurely converging on one standard risks locking in suboptimal design choices and slowing innovation over time. Harmonic argues that Solana should remain a free market for block-building innovation, where different approaches compete on execution quality. In that way, they see BAM as an attempt to consolidate block building around Jito’s architecture in order for them to preserve its leading position.
As an alternative, Harmonic advocates for a Proposer–Builder Separation (PBS) model on Solana. The goal here is to split block production into two distinct roles. Block builders compete to construct blocks, and validators, acting as proposers, no longer build blocks themselves, and instead, choose from blocks submitted by these competing builders.
The idea is to reduce excessive proposer power and create an open marketplace for block building. In theory, this should improve execution quality, limit monopoly control, and allow innovation to emerge organically, rather than being dictated by a single block-building architecture.
Nuancing the Debate
The debate between Jito and Harmonic highlights an important and healthy tension in Solana’s evolution. Both sides raise valid points, but the reality is more nuanced than a simple “BAM vs. competition” framing.
On Monopoly and Neutrality
Harmonic’s concerns around monopoly dynamics are not unfounded. Jito does occupy multiple roles within the ecosystem, which naturally raises questions about metric neutrality. That said, it is important to put this risk into perspective. A block builder that is vertically integrated with a market-making operation, such as Harmonic, arguably poses a much larger systemic risk to Solana. In that scenario, block construction incentives can directly conflict with fair execution and overall network health in ways that are far harder to observe or constrain.
From this angle, Jito’s multiple roles do not necessarily dilute metric neutrality. Jito is not vertically integrated across the full value chain of block building and trading. More importantly, its approach with BAM explicitly promotes verifiability, transparency, and auditable transaction ordering.
Now regarding the scoring system, Harmonic is right to be a critic. Measuring “good” block building is inherently complex, and any scoring framework will necessarily involve simplifications and trade-offs. Jito should be more open to listen to Harmonic feedback in order to improve his scoring. That said, the existence of imperfections in IBRL should not, on its own, invalidate the underlying issues it aims to surface, and as Jito mentioned in its IBRL methodology section, they will continue refining the model and expanding the set of signals over time to improve accuracy.
However, if an actor is intentionally delaying shred propagation, they are, as a matter of fact, slowing everyone else down. And if this behavior is profit-motivated, then that profit is necessarily extracted from the rest of the network.
Performance alone is not sufficient
Harmonic is right to emphasize execution quality. Best execution is undeniably critical if Solana aims to support large-scale, institutional-grade markets, as it directly impacts slippage, liquidity, and overall capital efficiency. But performance alone isn’t enough. Determinism and uniformity in transaction ordering are foundational to healthy market microstructure. Sophisticated trading systems require predictable execution environments.
So yes, Harmonic validators do pack more DEX transactions per slot, but that throughput correlates with longer slot times which is precisely the kind of non-determinism TradFi institutions cannot tolerate: if execution characteristics change depending on which validator is leading, firms cannot scale their operation with confidence and the case for migrating serious flow onto Solana weakens. In that case, we can argue that higher performance at the expense of determinism and uniformity is not a Pareto improvement for the long-term health of the network and also puts bearish pressure on SOL’s potential as an asset. As Mert, CEO of Helius, recently noted on X, late packing may generate incremental short-term gains, but it reduces the probability of sustained SOL appreciation over the long run.
To be clear, these concerns are not hypothetical, they are explicitly recognized in Solana’s own roadmap. In The Internet Capital Markets Roadmap, block-building dynamics and execution quality are identified as critical challenges. While they agree that BAM is an interesting solution forward, it is true that ideally, market structure improvements should come from the protocol itself as it is uniquely positioned to optimize for long-term network health rather than short-term profit incentives.
On competition and innovation
Competition is undeniably a powerful driver of innovation, and Harmonic is right to caution against prematurely locking Solana into a single block-building architecture. Allowing multiple approaches to compete in the open can surface better designs, stress-test assumptions, and reduce the risk of stagnation.
However, market forces tend to be highly short-term oriented. In competitive environments, participants are often incentivized to optimize for immediate gains, even when those strategies degrade long term potential. This dynamic closely resembles a prisoner’s dilemma: if one validator refrains from extracting short-term value, others will not. The rational response at the individual level is therefore to maximize short-term profit, even if the collective outcome is worse for the network.
Without an entity or mechanism capable of setting clear rules and protecting against this dynamic, there is a real risk that Solana’s long-term potential is undermined. Ultimately, this would also hurt validators themselves. If Solana fails to achieve its broader mission, SOL’s long-term value will suffer and SOL price remains one of the most important determinants of validator profitability.
BAM aims to address this problem by shifting it to the application layer through plugins and ACE. In doing so, it ensures that users and applications capture more of the value, rather than having it extracted at the block-builder or proposer layer. The result is a structural shift from value extraction in block building to value creation at the application layer.
It’s also important to be clear about the limits of the PBS path Harmonic is advocating for. PBS does not inherently guarantee fair outcomes from builder competition and introduces new pressure points. To illustrate this, the Ethereum Foundation has spent several years experimenting with proposer–builder separation and open builder marketplaces. While this reduced direct proposer discretion, it introduced new centralization vectors around relays and dominant builders and did not eliminate harmful MEV strategies and instead moved to a different layer of the stack.
In other words, separating proposers from builders changed the structure of extraction, but did not fully solve the underlying incentive misalignment. Even today, more than 25% of DEX trades on Ethereum are still subject to sandwiching. Yes, Solana’s architecture is meaningfully different from Ethereum’s but the incentive problem is not architectural. As long as builder selection optimizes for short-term validator revenue, the pressure to extract rather than create value persists regardless of the underlying consensus mechanism.
Competition at the builder layer alone has not proven sufficient to guarantee fairness, determinism, or long-term alignment. That is an important lesson when considering whether Solana should replicate a similar path.
Closing Thoughts
Solana remains well positioned to become the home of Internet Capital Markets. But its block-building microstructure remains a meaningful unresolved problem. Notably, Jito has identified two major issues that break the determinism and uniformity of block building on Solana: late packing and slot lagging.
To address these issues, Jito introduced BAM, a framework designed to make block building on Solana more transparent and deterministic. Today, over 28% of the network’s stake already runs BAM.
At the same time, this new architecture has faced notable pushback, most prominently from Harmonic. Their core argument is that BAM reduces competition and could therefore slow innovation. They also claim that Jito’s metrics are incomplete, and that the only thing that ultimately matters is best execution.
In this piece, we’ve seen that some of these concerns are well founded, but they also obscure important context. Harmonic is vertically integrated with a market-making operation, which means BAM directly challenges its economic model. And while execution quality matters, determinism and uniformity are the binding constraints for a healthy market structure. Competition without clear rules can easily devolve into a prisoner’s dilemma, where validators optimize for short-term profit at the expense of Solana’s long-term potential.
At Shoal, we believe BAM is a meaningful step forward and an important solution to help Solana become the home of Internet Capital Markets. It shifts the paradigm from value extraction at the block-builder or proposer layer to value creation at the application layer. That said, over the long run the network may need a more native, protocol-level solution to create a safer and more balanced competitive environment. But that is still 12–18 months out, and Solana needs something that works today.
Finally, this is an ongoing and rapidly moving debate. None of this is settled, and there are genuine arguments on both sides. We encourage every SOL staker to look at the data, ask validators directly why they run the block-building software they do, and make their own informed decisions. Where you stake matters. It shapes the execution environment, the market structure, and ultimately the kind of network Solana becomes.
Not financial or tax advice. The purpose of this post is purely educational and should not be considered as investment advice, legal advice, a request to buy or sell any assets, or a suggestion to make any financial decisions. It is not a substitute for tax advice. Please consult with your accountant and conduct your own research.
Disclosures. All posts are the author's own, not the views of their employer. Shoal Research is a Jito delegate. At Shoal Research, we aim to ensure all content is objective and independent. Our internal review processes uphold the highest standards of integrity, and all potential conflicts of interest are disclosed and rigorously managed to maintain the credibility and impartiality of our research.
Sources
Anza. “The Internet Capital Markets Roadmap.” https://www.anza.xyz/blog/the-internet-capital-markets-roadmap
Helius. “How Solana Works: An Executive Overview.” https://www.helius.dev/blog/solana-executive-overview
Helius. “Solana Slots, Blocks, and Epochs Explained.” https://www.helius.dev/blog/solana-slots-blocks-and-epochs
IBRL. “IBRL Validator Block-Building Explorer.” https://ibrl.wtf
IBRL. “Introducing the IBRL Explorer: Measuring Validator Block-Building Quality.” https://ibrl.wtf/blog/introducing-the-ibrl-explorer-measuring-validator-block-building-quality/
Jito Labs. “Block Assembly Marketplace Explorer” https://bam.dev/explorer/
Jito Labs. “Block Assembly Marketplace Documentation.” https://bam.dev/docs/
Jito Labs. “Introducing BAM.” https://bam.dev/blog/introducing-bam/
Harmonic. “Harmonic Documentation.” https://docs.harmonic.gg/
Harmonic. “Statement on Block Building and BAM.” source
Ruggero. “How Solana Builds Blocks.” https://www.ruggero.io/blog/how_solana_builds_blocks/=
hildobby. “MEV Sandwich Trades.” https://dune.com/hildobby/sandwiches







