• Solana's long-term success depends on deterministic execution infrastructure that scales transparently as the network grows. BAM exists to ensure that as Solana scales, the execution layer remains transparent, fair, and aligned with the applications and users who drive network growth.
• BAM provides cryptographically verifiable transparency for sequencing that no other solution can provide: every ordering decision proven, not promised.
• BAM will help everyone using or building on Solana succeed:
  • Applications gain the execution certainty needed to offer tighter spreads and predictable fills through Application Controlled Execution (ACE). 
  • Traders benefit from superior execution quality that rivals or exceeds other venues.
  • Validators get open-source infrastructure they can verify. When applications succeed on Solana, validators succeed. 

What Is BAM?

Solana stands alone: the only blockchain where trading SOL is cheaper and faster on-chain than on centralized exchanges. With BAM, that lead widens as apps gain the tools to outprice and out-execute other exchanges. BAM provides the execution infrastructure necessary to make on-chain trading not just competitive with centralized venues, but categorically superior.

The Block Assembly Marketplace (BAM), which Jito Labs revealed in July, represents the evolution toward a more transparent and application-driven transaction processing paradigm. BAM addresses a fundamental challenge that has constrained the network's growth: the inability for applications to provide predictable, high-quality execution guarantees to their users.

Why Solana's Block Building Needed to Evolve

We’ve detected at least seven different transaction schedulers operating on Solana, each with distinct ordering logic and timing characteristics. This fragmentation creates fundamental uncertainty for applications and traders who depend on predictable execution. Traders cannot determine whether they're receiving fair execution or being systematically disadvantaged by opaque scheduling decisions made by validators with competing interests. The result is wider spreads and reduced liquidity as market makers price in execution uncertainty, while developers face inconsistent environments that undermine their ability to compete with centralized alternatives.

Why Jito Labs Is Building BAM

Jito Labs helped pioneer trading infrastructure on Solana through our Block Engine. While these systems created significant value for validators and improved transaction execution, we've also watched how they've evolved. We've seen concentration dynamics emerge, observed the pressure toward private orderflow relationships, and recognized that without intervention, Solana risks following the same path toward opacity that degraded Ethereum's execution layer.

Ethereum's experience with proposer-builder separation (PBS) offers particularly instructive lessons. While PBS introduced competitive block building, it created perverse incentives: builders maximize MEV extraction to win block auctions, often at users' expense. This dynamic leaves the network stuck in a positive feedback loop that can be hard to unwind. Increased sandwich attacks and other forms of extractive MEV pushed orderflow private, as users sought protection through direct builder relationships. Builders offered rebates for exclusive access to this orderflow, and those with the most private flow could pay higher auction fees, winning more blocks and attracting even more exclusive deals. The result is a concentration of power among a small number of builders, increased opacity in transaction processing, and timing games that degraded network performance. Most concerningly, some dominant builders were operated by trading firms with direct financial incentives to exploit the blocks they built, creating opaque markets they could manipulate at will.

Recent efforts like BuilderNet and TOOL, which aims to add transparency and collaboration to Ethereum's block building through TEE-based infrastructure, represent a promising path forward. The Ethereum community recognizes these issues and is working to correct the course. Solana has an opportunity to learn from this evolution and adopt transparent execution infrastructure from the start.

BAM represents our commitment to building the next generation of execution infrastructure with transparency and neutrality built in from the start. BAM is the only block builder on Solana with cryptographically verifiable transparency: every ordering decision can be proven, not just promised. We're not claiming to have gotten everything right the first time, but we are applying what we've learned from operating MEV infrastructure on Solana, observing Ethereum's PBS evolution, and listening to feedback from applications, validators, traders, and users about what the network actually needs.

Application Controlled Execution

As detailed in the original BAM announcement, the main initial feature inside BAM will be application-controlled execution (ACE), the most commonly requested feature from applications on Solana.

Why Users Should Care About ACE

ACE translates directly into better execution quality for end users by giving applications direction over their market microstructure. When perps DEXs can guarantee transaction ordering, they offer tighter spreads and more predictable fills. This predictability particularly benefits professional traders and market makers who provide essential liquidity to Solana's DeFi ecosystem. With execution certainty, these participants can quote tighter markets and provide deeper liquidity rather than widening spreads to protect against adverse selection, ultimately delivering superior execution for all users.

Why FIFO Isn't Sufficient

A common question is whether simple first-in-first-out (FIFO) ordering would solve these problems. First off, FIFO lacks sybil resistance. Blockchains achieve sybil resistance by requiring economic cost for block space in the form of base and priority fees. Since earlier arrival guarantees earlier execution under FIFO, users are incentivized to spam the network with duplicate or speculative transactions to secure queue position. This spam exacerbates congestion, further degrading latency for legitimate transactions. A priority fee mechanism naturally discourages spam by making it more expensive to use blockspace during congestion, while FIFO makes spam economically rational by abandoning the economic cost that provides sybil resistance.

FIFO also breaks down when the demand for blockspace exceeds supply, a frequent occurrence on Solana. When transaction queues grow long, FIFO processing increases latency for everyone: transactions that arrive during congestion must wait for everything ahead of them to clear, creating unpredictable delays that undermine execution quality. Finally, FIFO doesn't address the needs of applications that want to implement specific ordering policies for their users. A perps platform might want to process liquidations before regular trades, or a DEX might want to batch related transactions together. These application-specific requirements to ensure optimally functioning markets cannot be satisfied by blind FIFO ordering at the validator level.

BAM's Plugin Framework

BAM addresses the lack of ACE on Solana through a plugin system that allows applications to implement custom sequencing logic while maintaining transparency and verifiability. Applications can integrate with plugins that define how transactions should be ordered relative to each other, giving them the tools necessary to experiment with their market microstructure and provide better execution guarantees to their users.

The plugin framework maintains BAM's core transparency properties. All plugin code runs inside the TEE and is subject to the same attestation requirements as BAM's base scheduler, providing verifiable guarantees that other solutions cannot match without using the same technology. When applications can optimize their market microstructure for better user experiences, more sophisticated traders and larger volumes flow through Solana. This increased activity translates directly into more transactions, higher priority fees, and greater validator revenue.

BAM Security & Decentralization

Trusted Execution Environments

When designing BAM, we recognized that validators, applications, and users needed verifiable transaction settlement, not just trust in operators. The challenge: how can participants cryptographically verify what code is actually running?

After extensive research, Trusted Execution Environments (specifically AMD SEV-SNP) emerged as the optimal solution. TEEs provide cryptographic attestations proving specific code is running without tampering, with minimal performance overhead. Alternative approaches like zero-knowledge proofs or fully homomorphic encryption introduce computational costs that make them impractical for high-throughput block building. TEEs allow us to decentralize the system with many distributed operators able to participate in BAM.

Addressing Physical Security Concerns

Discussions around TEE security often focus on physical attack vectors, and these concerns deserve direct acknowledgment. Physical attacks against TEE hardware are well understood by teams working seriously with this technology, and Jito Labs has been aware of these considerations since the project's inception. However, context matters significantly when evaluating this risk.

BAM's physical security model aligns with existing validator trust assumptions. Every validator on Solana already relies on physical security for their operations. Validator keypairs typically sit unencrypted in memory during operation, trusting that physical security measures prevent unauthorized access that could lead to theft of funds or network disruption. The threat model for BAM's TEE implementation is fundamentally similar to these existing security assumptions that validators accept when operating in data center environments.

By requiring BAM to run in vetted, enterprise-grade data centers, Jito ensures that operators cannot easily access TEE hardware. These facilities implement defense-in-depth security with multiple layers of protection: perimeter fencing, biometric access controls, multi-factor authentication, 24/7 on-site security personnel, comprehensive CCTV surveillance, anti-tailgating turnstile gates, and rack-level access restrictions. Entry typically requires a combination of physical credentials, PIN codes, and biometric scans, with each zone requiring additional verification. This layered approach makes unauthorized physical access to BAM hardware infeasible.

TEE technology will continue to improve alongside Solana's core protocol. Physical attack resistance is strengthening through innovations like Proof of Cloud, physically unclonable functions, enhanced encryption standards, and tamper-detection technologies. BAM will maintain rigorous operational security standards, receive audits from security experts on deployment best practices, and will undergo comprehensive third-party audits before open source release.

Confidentiality

BAM's TEE implementation ensures that node operators cannot access or tamper with transaction data in transit. QUIC certificates are generated inside the TEE rather than by the host machine, which prevents operators from performing man-in-the-middle attacks or decrypting QUIC packets containing transactions. This means that even the entities running BAM infrastructure cannot see the contents of transactions flowing through the system. Communication between validators and BAM also uses TLS encryption, providing an additional layer of protection for sensitive transaction data.

This design ensures that confidentiality is cryptographically enforced rather than depending on operator trustworthiness. Node operators can verify they're running authentic BAM code and prove this to others through attestations, but they cannot intercept, read, or modify the transaction data being processed - the TEE hardware prevents these actions at a fundamental level.

The Future: Open Source, ACE, and Hardware Acceleration

BAM's roadmap centers on five developments that will strengthen its position as neutral infrastructure for Solana's execution layer.

Open sourcing the codebase: Making the scheduler code publicly available allows validators and the community to verify BAM operates as described, audit TEE security properties, and contribute improvements. This establishes BAM as community infrastructure rather than a closed product and enables applications to build features without relying on Jito Labs. BAM is currently in feature code freeze entering audit, with open source release expected before year end.

Expanding Application Controlled Execution. ACE enables trading applications to provide execution guarantees approaching or exceeding centralized exchanges. For perps DEXs competing with centralized venues, ACE provides the primitives necessary to match user expectations from traditional platforms. BAM is actively onboarding applications to test implementations and refine the feature set.

Decentralizing the operator set. Moving to a model where vetted operators run nodes achieves meaningful decentralization while maintaining TEE security guarantees. This requires establishing operator standards, implementing robust monitoring and attestation systems, and developing fault tolerance mechanisms. The goal is a diverse, geographically distributed operator set that maintains security and performance while ensuring no single entity controls the execution layer.

Enabling collaborative block building. BAM is designed as an extensible platform where developers can modify the scheduler through plugins, submit mini-blocks with custom ordering, and contribute optimizations, all inside TEEs with full attestation guarantees. This verifiable transparency ensures innovation in block building remains distributed across the Solana community rather than concentrated in a single entity.

Hardware acceleration through FPGAs. Running BAM on specialized hardware, for instance in Double Zero, would further improve determinism and reduce latency. FPGA deployment would provide additional security properties and performance characteristics benefiting the entire validator ecosystem, representing the natural evolution of scheduler optimization as network demands grow.

Conclusion

BAM represents infrastructure built for Solana's long-term success. The team at Jito Labs is deeply committed to seeing Solana thrive as the premier blockchain for high-performance applications and to making internet capital markets a reality. When applications succeed on Solana, validators succeed. When users receive superior execution quality, more activity flows through the network and more revenue is generated for all stakeholders. BAM exists to ensure that as Solana scales, the execution layer remains transparent, fair, and aligned with the applications and users who drive network growth.

If you are a validator and any of this resonates with you, please reach out to me and consider running BAM today. The BAM validator client code requires one additional command line argument and is open sourced here.