An Introduction to Jito’s Block Assembly Marketplace (BAM)
Executive Summary
Transaction ordering on Solana is currently handled by individual validators, who have full discretion over how transactions are sequenced within their block slots. This lack of transparency and verifiability creates several challenges: validator behavior is difficult to audit, execution quality is inconsistent, and applications have no way to define how their transactions should be prioritized.
The Block Assembly Marketplace (BAM) is a proposed upgrade that addresses these limitations without altering Solana’s core protocol. It introduces a new role—BAM Nodes—that use secure enclaves and programmable Plugins to privately sequence transactions and generate cryptographic attestations of ordering. Validators then execute blocks according to this predefined logic, creating a public audit trail of how each block was built.
Broad adoption of BAM would enable programmable, auditable, and application-aligned execution across the network. It would unlock new protocol design space, improve market efficiency, and raise the standard for execution integrity—positioning Solana as the first major chain with verifiable and customizable blockspace at scale.
How Transaction Ordering Works on Solana
Solana uses a leader-based block production model, where validators take turns proposing and executing blocks in rapid, predictable intervals—typically every 400 to 800 milliseconds. When a validator becomes leader, it is responsible for producing the next block by managing the full transaction pipeline.
Collecting Transactions:
Transactions are submitted directly to the current leader through various channels (RPC endpoints, forwarders, bots, or applications). Solana does not use a global mempool—only the leader sees the full transaction set during its slot.Custom Ordering:
The leader has full discretion over how transactions are ordered. It may reorder, batch, delay, or even exclude transactions as long as the resulting block is valid. There is no global sequencing rule or verifiable logic enforced by the protocol.Execution and Block Assembly:
Once ordered, the leader executes the transactions, assembles the block, and propagates it across the network. Validators verify the final state transition, but not the internal reasoning or fairness of the transaction order.Finalization:
Blocks are confirmed via Solana’s Proof-of-History and Turbine protocols. While final state transitions are verified network-wide, the original sequencing decisions made by the leader are opaque and unverifiable.
What are the problems with current transition ordering
Validator Behavior Is Only Partially Observable
On Solana, validator leaders have full control over transaction ordering during their slot, and there are no enforced sequencing rules or cryptographic proofs of intent. The only observable output is the block itself—a finalized list of transactions with no accompanying explanation of how or why that order was chosen.
This means the only way to assess validator behavior is by manually analyzing the blocks they produce, looking for patterns like consistent front-running, sandwiching, or selective inclusion. But this kind of analysis is incomplete and noisy—there’s no way to know what transactions were seen, withheld, reordered, or dropped. The absence of structured, verifiable ordering data makes it hard to draw reliable conclusions or hold validators accountable.
As a result, users and stakers can’t meaningfully evaluate whether a validator is contributing to or degrading execution quality. Delegation decisions are mostly limited to uptime, fees, and brand—not behavior.
Arbitrary Ordering Adds Latent Cost to Every Transaction
Because validators can freely reorder transactions, users are forced to price in the risk that their transaction may be executed at the worst possible position within a block. This uncertainty adds an invisible premium to every on-chain action.
For example, a trader submitting a large swap has no guarantee that it won’t be preceded by a strategically timed buy that worsens their fill. A liquidation bot may submit a transaction based on oracle data, only to be back-run or delayed by a validator who saw an opportunity to profit. This unpredictability degrades execution quality and makes it harder to build efficient markets and protocols.
Applications can’t control transaction ordering
Solana's architecture does not allow applications to influence how their transactions are ordered within a block. All ordering decisions are made by the validator leader, with no ability for developers to insert logic that prioritizes or sequences their own transactions relative to others.
This limitation creates design friction across many types of applications. A market maker cannot guarantee that a cancel order is processed before an incoming trade. An oracle provider like Pyth must submit constant updates, since there's no way to align oracle refreshes with trade execution. A DEX cannot co-locate a user’s swap and its routing logic into a single atomic, sequenced flow. These are not theoretical edge cases—they’re core behaviors that define performance in financial systems. Without access to the sequencing layer, developers are forced to build external systems or accept degraded functionality.
What is BAM
The Block Assembly Marketplace (BAM) is a new block-building architecture for Solana that addresses these structural limitations by introducing programmable ordering logic, transaction privacy, and verifiable sequencing guarantees—all without changing Solana’s core protocol.
At the heart of BAM is a new actor: the BAM Node, which sits alongside validators and receives transactions from users, bots, and protocols. Rather than relying on validator-controlled ordering, BAM Nodes use secure enclaves (Trusted Execution Environments) to privately sequence transactions based on logic defined by Plugins—custom programs that encode application-specific rules for inclusion and ordering. These Plugins can prioritize cancels, insert oracle updates, or co-locate related transactions—capabilities previously impossible on Solana.
Every ordered bundle is sealed with a cryptographic attestation proving exactly how the ordering was determined. Validators then execute the block as instructed, returning a matching attestation to confirm proper execution. This creates an audit trail that makes transaction sequencing transparent, replayable, and accountable—for the first time on Solana.
BAM transforms transaction ordering from an opaque, validator-controlled process into a modular, programmable layer. It opens the door for more efficient markets, new protocol design patterns, and a fairer execution environment—without sacrificing speed or scale.
The Network Effects of Broad BAM Adoption
If BAM were widely adopted across Solana’s validator set, it would mark a foundational shift in how the network handles execution—moving from validator-determined ordering to a programmable, auditable, and deterministic block-building layer. This shift would have far-reaching consequences across performance, protocol design, and market structure.
With every validator enforcing Plugin-defined ordering logic, execution would become predictable and application-aligned. Developers could rely on consistent sequencing behavior across all blocks—cancel-before-trade logic, oracle co-location, and atomic batch routing would no longer require external workarounds. This reduces protocol complexity and opens new design space, particularly for advanced financial infrastructure that requires timing precision and sequencing guarantees.
Auditability would also become a native property of the chain. Since every BAM Node and Validator produces cryptographic attestations of ordering and execution, external observers—researchers, DAO delegates, or users—could verify exactly how a block was constructed. This makes validator behavior observable in real time and unlocks new forms of governance, staking, and MEV monitoring that are currently infeasible.
Finally, widespread BAM adoption would raise the baseline quality of execution across the network. With ordering logic defined in code rather than validator discretion, users would face lower uncertainty, fewer hidden costs, and tighter integration between transaction intent and actual outcomes.
Final Thoughts
BAM introduces a fundamental shift in how blockspace is treated on Solana. By bringing privacy, programmability, and verifiability to transaction ordering, it transforms sequencing from an opaque validator responsibility into an open, auditable, and application-aligned system.
This matters because ordering is not just a technical detail—it defines how value moves through the network. When protocols can’t control sequencing and users can’t trust execution order, efficiency suffers and complexity rises. BAM addresses these problems directly by giving developers a mechanism to define ordering logic and users a way to verify it.
Widespread adoption of BAM wouldn’t just improve execution—it would redefine expectations across Solana’s ecosystem. It would elevate the baseline for fairness, composability, and transparency in block-building. In doing so, it positions Solana to support a new generation of applications that rely on precise, programmable, and provably accountable access to blockspace.