Block Assembly Marketplace (BAM)

Many thanks to Lucas Bruder, Sebastian Hauer, Alejandro Morante, and Mert for reviewing earlier versions of this work.

Actionable Insights

• Today, Solana leaders have sole authority over transaction ordering during their slots, offering limited transparency into how blocks are constructed. BAM introduces a verifiable, decentralized alternative that makes sequencing logic auditable.
• The BAM network clearly separates responsibilities: BAM nodes manage sourcing, prioritization, and filtering of Solana transactions, while BAM validators handle execution, consensus, and state management. This approach moves Solana closer to a Proposer-Builder Separation (PBS) like architecture.
• BAM’s plugin framework allows developers to define custom ordering logic and introduce new scheduling primitives. This enables Application-Controlled Execution (ACE), where apps can enforce their own transaction scheduling rules.
• Jito has committed to eventually open-sourcing BAM and designing it with transparency at its core. This marks a major improvement over the current Jito block engine, which is closed-source and run by a single trusted party.
• BAM nodes will run on AMD processors, which support enhanced Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP). Thanks to hardware acceleration, SEV-SNP introduces only 2–5% overhead, fast enough for real-time processing.
• The first implemented scheduler for BAM nodes will run periodic intra-block auctions within their mempools, subdividing the block into N slots and equally allocating CUs across each auction.
• Application-Controlled Execution (ACE) may reduce the need for rollups or network extensions to enforce custom logic, helping retain more activity on Solana mainnet. It also significantly expands the design space for novel applications that leverage programmable blockspace.
• Jito plans to route 100% of protocol fees from both the Block Engine and the upcoming BAM system to the Jito DAO Treasury. Currently, Jito charges a 6% fee on tips, split evenly between Jito Labs and the DAO. In Q2 2025, the DAO earned 22,391.31 SOL (~$4 million) from these fees via the Tip Router.
• BAM draws inspiration from Flashbots’ BuilderNet, adopting a similar approach of block building within trusted execution environments. On Ethereum mainnet, approximately 40% of blocks are already built in TEEs.

Introduction

Jito’s Block Assembly Marketplace (BAM) represents the most ambitious redesign of Solana’s block construction process to date. Over eight months in development, BAM was born out of the desire for more privacy, transparency, and deterministic intra-slot execution on Solana to enable the next wave of advanced applications. The result is a re-imagined transaction pipeline that replaces today’s opaque, validator-driven ordering model with a private, programmable, and provably fair system for sequencing transactions.

BAM introduces an encrypted mempool running inside Trusted Execution Environments (TEEs), where all transactions remain confidential until execution. This privacy-preserving architecture aims to significantly reduce, if not eliminate, many of the most extractive forms of MEV, providing users with stronger execution guarantees and better pricing. Validators gain the ability to offer higher-quality execution, while developers and searchers can build directly on top of a new programmable layer of blockspace.

BAM introduces application-controlled execution (ACE) logic via a plugin system. This enables use cases such as maker-priority matching for perpetuals, just-in-time oracle updates, time-in-force order enforcement, and other forms of custom routing and execution. With fine-grained control over transaction ordering, developers can build more sophisticated and reliable financial primitives on Solana, including central limit order books, dark pools, and aggregator layers.

In doing so, BAM directly addresses many of the longstanding criticisms of Solana’s block production model: opaque validator behavior, inconsistent execution quality, and the proliferation of gray markets through private mempools and out-of-band deals. Today, Solana leaders have unilateral control over transaction ordering during their slots, with little insight into how final blocks are assembled. BAM replaces this with a verifiable, decentralized alternative that still integrates cleanly with Solana’s high-performance runtime.

BAM builds on real-world precedent and draws inspiration from Flashbots’ BuilderNet, adopting a similar approach of block building within trusted execution environments. On Ethereum mainnet, approximately 40% of blocks are already built in TEEs, while on Unichain (Uniswap’s custom L2), that number reaches 100%. BAM extends this model to Solana, with the advantage of native support for application-level programmability, low-latency execution, and deep integration with the Jito validator clients, which today secure over 89% of total stake across Jito-Agave and Jito-Firedancer.

Crucially, Jito has committed to eventually open-sourcing BAM and designing it with transparency at its core. This marks a major improvement over the current Jito block engine, which is closed-source and run by a single trusted party. BAM generates on-chain attestations, cryptographically signed proofs that confirm exactly what code was run and how transactions were ordered, enabling any observer to verify fair execution.

High-Level Overview of BAM

At its core, BAM is a transaction sequencing network. BAM nodes handle the sourcing, prioritization, and filtering of Solana transactions, while BAM validators focus on execution, consensus, and state management. This separation of concerns preserves the core responsibilities critical to network liveness within the validator while enabling greater flexibility and experimentation around sequencing logic within BAM nodes.

The BAM node itself comprises a transaction processing unit (TPU) and a transaction scheduler, operating within a TEE. It also runs a gRPC server to enable communication with connected validators. The modified Jito-validator client features a first-in-first-out (FIFO) executor, optimized for concurrency and parallelism through account-aware locking.

Each BAM node can support multiple validators, though each validator connects to only one BAM node at a time. Currently, Jito operates seven block engines. With BAM, the network aims to scale significantly, targeting 50 to 100+ BAM nodes distributed across all major geographic regions for greater decentralization and redundancy. Communication between the BAM node and the validator occurs via a bidirectional gRPC stream, with execution results streamed back from the validator to the BAM node for real-time feedback.

All transactions within BAM nodes are encrypted within Trusted Execution Environments (TEEs) until the moment of execution, ensuring that the transaction flow remains private until it is executed.

To guarantee fair execution, the ordering of transactions is verifiably recorded using attestations. These are cryptographic proofs, signed and timestamped by BAM nodes, that confirm specific events or conditions were observed. The result is an immutable audit trail, enabling observers to prove that transactions were executed in the correct order.

The audit trail includes the transactions forwarded to the validator and the sequencing, e.g., transactions A, B, and C were sent to the Helius validator on this slot. The system offers real-time monitoring tools and analytics, enabling users to track their transactions from submission to execution. Users and applications will be able to verify whether the BAM validator fulfilled the ordering and know exactly what code was run in the BAM node.

BAM nodes are transparently visible on the network, similar to existing Jito relayers. When a validator connects to BAM, it advertises the BAM instance through its TPU and TPU forward ports, which serve as the entry points for receiving transactions.

Users can still submit transactions through their usual RPC clients. However, for enhanced security, they have the option to send transactions directly to BAM instances, preventing malicious validators from intercepting or viewing the transaction packets.

When a transaction enters BAM, it undergoes a standard sanitization process that includes deduplication, signature verification, and checks for a valid format, blockhash, fee payer, nonce, and Address Lookup Tables.

Once validated, transactions enter BAM’s mempool, where they participate in a frequent periodic auction. After an auction concludes, transactions are dispatched to validators. The full transaction sequence is signed by the BAM software and recorded in a database. Validators then stream back execution results through an API modeled after the one proposed by Anza’s modular scheduler.

With a secure scheduling environment and a local fee market, validators now operate under a much stronger opt-in contract. They receive a predefined transaction sequence that must be scheduled exactly as provided, eliminating opportunities to insert or reorder transactions for malicious purposes.

Several enforcement mechanisms are being explored to address any event of validator misbehavior, such as sandwiching, based on audit trail evidence. While not yet finalized, potential responses include:

• Removing the offending validator from the BAM network.
• Requiring collateral from validators in the form of bonds, which could be slashed for misconduct (though this may raise the entry barriers for new validators).
• Applying blacklists or greylists to restrict or limit participation by violators partially.

Fees

Jito Labs and the Jito Foundation are jointly drafting a Jito Improvement Proposal (JIP) that will redirect 100% of protocol fees collected from both the Block Engine and the upcoming BAM system to the Jito DAO Treasury. This proposal, expected to be formally submitted in the coming weeks, represents a significant shift in Jito’s economic model and is subject to approval by the DAO. If passed, it will reinforce the DAO and JTO token holders' central role in the Jito ecosystem.

Currently, the Jito protocol charges a 6% fee on tips, evenly split between Jito Labs and the DAO. In Q2 2025 alone, the DAO earned 22,391.31 SOL (~$4 million) from these fees via the Tip Router. The DAO’s other primary revenue stream comes from jitoSOL fees, which totaled 13,223.73 SOL (~$2.38 million) during the same period.

Trusted Execution Environments (TEEs)

A Trusted Execution Environment (TEE) is a hardware-backed architecture designed to ensure the confidentiality and integrity of both computation and memory. Also known as enclaves, TEEs isolate code execution from the host system’s operating system, kernel, and hypervisor, typically through hardware-level separation. This isolation significantly reduces the attack surface, making it extremely difficult, though not impossible, to observe or tamper with enclave operations.

TEEs have been in use since the 2000s in domains like digital rights management, content protection, and secure payment systems. Today, they are widely used across consumer devices and cloud services to handle sensitive data and code securely. On smartphones and laptops, Apple’s Secure Enclave and Android’s TrustZone protect biometric data, payment credentials, and encryption keys. Game consoles like PlayStation and Xbox use AMD or Pluton-based processors to prevent tampering and piracy. In the cloud, providers such as Azure and Google Cloud leverage AMD SEV-SNP, Intel TDX, or AWS Nitro Enclaves to isolate workloads and enable confidential computing. Crypto wallets like Ledger and Trezor use secure elements to protect private keys, while the new Solana Seeker phone relies on TEEs for the same purpose.

TEEs are the standard hardware-based approach for processing private data, providing a practical alternative to purely cryptographic methods, such as fully homomorphic encryption (FHE) and secure multiparty computation (MPC). While FHE and MPC provide strong theoretical guarantees, they are often impractical in real-world settings due to high complexity and performance overhead.

BAM relies on two core properties of TEEs:

Confidentiality: Code and data inside the TEE are encrypted and isolated from the rest of the system. Neither the operating system, hypervisor, nor any external software can access or inspect what runs within the enclave.

Attestability: TEEs support attestations, a mechanism that produces cryptographic proof of the enclave’s origin and current state. This allows third parties to verify that a result was produced by a genuine TEE executing trusted code, rather than by a compromised or emulated environment.

TEE Implementation in BAM

BAM will run on AMD processors, which support enhanced Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP). Unlike smaller enclave-based approaches, SEV-SNP protects the entire BAM application with minimal performance overhead, making it well-suited for high-throughput, low-latency transaction systems.

Thanks to hardware acceleration, SEV-SNP introduces only 2–5% overhead, fast enough for real-time processing. It can support complex, stateful networked applications, not just isolated computations. The technology is battle-tested, with deployments across major cloud providers including Google Cloud, Azure, and AWS, and backed by years of security research and operational experience.

The SEV-SNP used in BAM provides several key security guarantees. Each TEE instance runs inside its own hardware-isolated virtual machine, with memory encrypted at runtime to ensure strong VM-level isolation. BAM leverages hardware-rooted attestation, allowing each TEE to cryptographically prove it is executing genuine, unmodified code. This attestation chain is anchored in AMD’s hardware root keys, which are physically embedded in the CPU during manufacturing. Additionally, TLS keys are generated using the processor’s internal hardware random number generator, ensuring that they are never exposed in unencrypted memory.

When a client connects to BAM, they receive a TLS certificate containing the standard connection certificate, an AMD SEV-SNP attestation report, and cryptographic proof that the TLS private key was generated inside the attested TEE. This certificate chain is cryptographically bound to AMD’s hardware root of trust. It cannot be forged without access to AMD’s private root keys, eliminating the need to trust any intermediary beyond AMD’s chip manufacturing process.

Plugins

Today, applications on Solana can influence transaction ordering only through priority fees or bundled transactions with associated tips. With multiple sequencers in play across clients like Agave and Firedancer, there’s no guarantee which ordering logic will be applied, leaving applications with limited control over how their transactions are ordered.

Plugins solve this. 

Through BAM’s plugin framework, developers can implement bespoke ordering logic and introduce new scheduling primitives. They enable Application-Controlled Execution (ACE), allowing apps to define custom transaction scheduling policies. While ACE has many potential applications, the most widely recognized and discussed use case is prioritizing order book cancels—a mechanism that reduces adverse selection and allows for tighter spreads.

Prioritizing Order Book Maker Cancels

Today, on-chain order book market makers on Solana operate at a disadvantage. Market makers manage risk by constantly updating or canceling stale quotes when the fair price changes. When the market price moves, they need to cancel existing orders before informed takers can take advantage of the opportunity.  

Without fine-grained control over transaction ordering, their quotes are vulnerable to a toxic flow that exploits their stale pricing. Market makers may lose out, even when they act quickly, because the Jito auction prioritizes bids over intent. Essentially, whichever party pays more is sequenced first.

This dynamic forces market makers to widen their spreads to manage risk, thereby reducing overall liquidity and resulting in worse pricing for users. These toxic trades, where the taker profits from stale pricing and the counterparty regrets the trade almost immediately after it is made, add little to the user experience but substantially increase friction for market makers and liquidity providers.

BAM plugins allow for "cancel-before-take" policies to be enforced at the application level. By giving programs fine-grained control over transaction ordering, applications can choose to process maker cancels before taker trades. This simple policy change has profound implications:

• Reduces Adverse Selection: Makers are no longer routinely picked off when the market moves.
• Filters Toxic Flow: Although the overall volume may decline due to fewer toxic trades, the quality of the flow and execution improves.
• Enables Tighter Spreads: With reduced risk, makers can quote more aggressively.
• Improves Liquidity: Both professional makers and retail traders are more confident to provide quotes, resulting in deeper liquidity.

Just In Time Oracle Updates

Another example of an application-specific plugin is Pyth’s planned implementation of just-in-time oracle updates. As Solana’s leading oracle provider, Pyth maintains over 1,700 individual price feeds. Updating all of them every block would be prohibitively expensive and inefficient in terms of blockspace.

With BAM, Pyth can update specific price feeds precisely when they’re needed by inserting the oracle update directly ahead of a user’s transaction within the same block. This reduces the risks associated with stale oracle data, such as inefficient liquidations and oracle manipulation, enabling DeFi applications to operate more reliably and competitively.

Further Plugins

Ultimately, BAM aims to be a permissionless platform where application developers can build, test, and deploy plugins to control their transaction sequencing. Many more plugins are expected to follow, with BAM nodes eventually supporting hundreds of customizable extensions. While most applications will continue to operate using the default scheduler, those requiring custom sequencing logic will be responsible for developing and maintaining their own plugins. 

Furthermore, applications will be able to monetize plugin functionality by charging fees, with the potential for a portion of revenues to be shared with governance token holders or validators.

Prospective General Purpose Plugins

Plugins aren’t limited to a single application. Jito has already proposed several examples of general-purpose, cross-application plugins that could be developed for BAM:

Blockspace Futures: Enable users and applications to reserve or trade the right to use blockspace at a future time, providing predictable access and pricing even during periods of high network demand.

Time in Force (TIF): refers to the duration an order remains active before being automatically canceled if it's not fully executed, for example, making an order book transaction only valid for 20 milliseconds. A crude version of this is possible today on Solana by deliberately using older blockhashes to ensure a transaction is only valid for the most recent block(s).

Pre-Confirmations: Users can be notified when their transaction is forwarded to a validator before it is executed and propagated out to the network. Confirming transactions with some level of confidence earlier.

Feeless transactions: allow users to cover transaction costs using an SPL token (e.g., stablecoins) instead of SOL, abstracting away native token requirements and enabling flexible fee payment.

Low-Latency Aggregator and Request for Quotation (RFQ): Users submit trade intents directly to BAM, where a locally run aggregator identifies the optimal route.

Transaction Cancel and Replace: Users can submit transactions with special markers that allow them to cancel, drop, or replace previously submitted transactions.

Roll Out

During the launch phase, Jito Labs will operate the initial set of BAM Nodes to ensure stability, performance, and security. A permissioned group of early validator partners, including Helius, SOL Strategies, Triton One, and Figment, will run the BAM client, securing a high single-digit percentage of the total network stake shortly after launch. 

In parallel, an initial cohort of Solana applications, including Drift, Pyth, and DFlow, will begin designing and testing the first wave of Plugins. By the end of the launch phase, BAM is expected to have validated its core functionality and established the foundation for broader participation from node operators and validators. 

Validators, application developers, or searchers interested in participating in BAM can complete this form.

An Ecosystem Advisory Committee, comprising prominent stakeholders from the Solana validator and developer community, including the Solana Foundation, will advise Jito Labs. This committee will help guide BAM’s expansion, promote decentralization, and foster community-led innovation.

As of now, the BAM codebase remains closed-source, with plans to open it in the near future to enable third-party plugin development. Once open-sourced, BAM will welcome community contributions across several key areas:

• Plugin Development: Build custom plugins to expand BAM’s capabilities.
• Scheduling Algorithms: Design and contribute new transaction ordering strategies tailored to specific use cases.
• Integration Libraries: Develop SDKs in multiple programming languages to simplify BAM integration.
• Analytics Tools: Create dashboards and monitoring systems that leverage BAM’s attestation data.
• Research Contributions: Propose and implement novel approaches for MEV mitigation and system optimization.

Implications

BAM represents a pivotal point for Solana—one that has the potential to unlock a wave of innovation by addressing concerns around MEV exploitation and efficient block packing. TEE-secured sequencing and BAM’s plugin framework could reduce the incentive for application teams to build network extensions, rollups, or Solana Permissioned Environments to enforce their own custom logic or opinionated blockspace, thereby keeping more activity on Solana mainnet. Additionally, with increases in per-block compute limits and the demand for more efficient token programs and frameworks that use fewer CUs (e.g., the rising popularity of Pinocchio and p-token), there will be more bandwidth on mainnet, further reducing the incentive for developers to build custom solutions.

BAM’s privacy features should also significantly reduce the prevalence of sandwich attacks, as transactions remain hidden until execution, thereby limiting bots’ ability to frontrun users. This will likely result in improved DEX efficiency and more competitive pricing for users. However, it’s unlikely that BAM will eliminate MEV entirely. MEV is inherently a cat-and-mouse game, and sandwichers will adapt, perhaps via subtle plugin exploits or gaming external oracles (i.e., oracles that do not have their own plugin) since these aren’t part of the encrypted pipeline. 

Reducing MEV through BAM may negatively impact Jito’s revenue, echoing its 2024 mempool shutdown, which cut short-term earnings but ultimately benefited the network. BAM’s improvements could offset this by driving overall higher transaction volumes and plugin fees, thereby increasing long-term revenue through better rates of adoption. However, BAM’s exact implementation, its phased rollout, and economics pose potential centralization risks and open questions, which we explore in subsequent sections. Nonetheless, these risks and open questions are countered with various benefits, each with its own set of implications regarding MEV redistribution, PBS, and the development of a “new” client.

MEV Redistribution

BAM fundamentally reshapes Solana’s MEV landscape from unchecked extraction to a more structured redistribution model. In traditional setups, MEV often leaks user value via frontrunning or spam, with validators or bots capturing value through harmful tactics such as sandwich attacks. However, BAM’s TEE-encrypted mempool hides transactions until execution, thereby limiting visibility for negative MEV. Instead, value is internalized through plugins and custom sequencing. This, in turn, allows for apps, developers, and searchers to capture positive forms of MEV that enhance the ecosystem’s efficiency (e.g., tighter DeFi spreads, reduced oracle spam).

This redistribution channels MEV profits back to its stakeholders as plugin fees are shared amongst BAM Node operators, validators, stakers, and Jito’s DAO. This has the potential to create sustainable revenue streams. For example, a DEX could have a plugin that optimizes order matching and converts potential MEV extracted by validators into app-generated fees, which can be redistributed to token holders. This “protected” approach to trader activities could turn MEV from a zero-sum game into one that deepens liquidity and attracts institutional capital.

However, redistribution comes with risks. The important thing to note is that BAM does not erase MEV—it relocates it. This relocation has the potential for early plugin authors, BAM Node operators, and Jito-aligned entities to accrue outsized gains. Despite being constrained by cryptographic attestations, if TEE vulnerabilities (e.g., side-channel attacks) emerge, privileged access for searchers could enable new subtle extraction vectors, ultimately undermining privacy assurances. This also opens up the door for “protected” forms of backrunning, whereby searchers can deploy code to append transactions after a user’s (e.g., to capture arbitrage from a price-moving swap) without exposing strategies or enabling frontrunning. Moreover, in the absence of programmatic slashing, adaptive attackers might pursue harmful strategies around attestations, which are post-execution and currently rely on community enforcement.

Ultimately, while MEV redistribution positions BAM as a catalyst for Solana’s north star (i.e., a decentralized NASDAQ), its success is contingent upon the adoption of equitable fee models and robust TEE security. If mishandled, it could fragment the network, erode user trust, and invite scrutiny over “protected” yet opaque searcher activities.

Proposer-Builder Separation (PBS)

Most blockchains are designed such that the same entity both proposes and builds blocks, giving them monopoly control over the ordering and inclusion of transactions within their designated slots. This is advantageous for these entities, which are free to censor or otherwise manipulate transaction flows. For example, they could propose and build blocks using sophisticated, albeit harmful, strategies to include transactions in a specific order, thereby maximizing MEV.

Proposer-Builder Separation (PBS) is a design pattern that addresses this by separating block building from block proposal. Under this design, block builders create ordered lists of transactions and submit bids for these blocks. Block proposers, typically validators, then accept and commit the highest-bid block, redistributing any MEV through auctions or tips without needing to run sophisticated sequencing strategies themselves. 

PBS has been implemented out-of-protocol via MEV-Boost on Ethereum since The Merge in 2022. MEV-Boost is a “sidecar” that runs alongside a validator’s dual execution layer and consensus layer client software. Validators running MEV-Boost can connect to multiple relays and accept pre-built blocks from block builders. They do not see the contents of the block before it is included on-chain, as they only receive block reward amounts and block headers from the relays. Note that this design is still in an active research phase, as PBS awaits full protocol enshrinement (ePBS), which may include features such as inclusion lists to further mitigate censorship.

With BAM, Solana is moving toward a PBS-like future, which separates block construction (i.e., sequencing in TEE-secured BAM Nodes) from execution, which remains the responsibility of validators. This has the potential to democratize positive forms of MEV for apps and searchers via plugins. However, it also risks exacerbating Solana’s stake centralization if plugin economics favor incumbents. This is apparent in Ethereum, where three builders (i.e., Titan Builder, BuilderNet, Beaverbuild) now dominate over ~90% of all blocks, creating relay trust issues and barriers for smaller participants. 

Although MEV-Boost introduced PBS to Ethereum, a fairer comparison here is BuilderNet, a decentralized block-building network launched in November 2024 and operated by Flashbots, Beaverbuild, and Nethermind. BuilderNet uses TEEs for private block building, which decentralizes the process across multiple node operators to neutralize exclusive orderflow deals and reduce centralization. It focuses on value creation (i.e., sharing MEV refunds with overflow providers, such as users, wallets, and apps), rather than orderflow games (e.g., fighting for private deals). BuilderNet still uses MEV-Boost relays, but they are not strictly required, meaning direct builder-proposer interactions can occur in TEEs. 

BAM’s phased, permissioned rollout must prioritize equitable fees and open-source plugins to mitigate these pitfalls of Ethereum, especially given its hardware dependencies (i.e., TEEs versus Ethereum’s software relays), which introduce vendor lock-in aspects and maintenance costs. Solana hopes to skip the orderflow games and leap to a BuilderNet-esque system, focusing on value creation. 

Ultimately, this shift in block construction and proposal diminishes the validators’ role, offloading sequencing complexity but potentially reducing their agency and revenue if fees aren’t shared broadly. We explore this in more detail in our section titled The Diminished Role of Validators.

Above: comparing Ethereum’s PBS with Solana’s BAM

A “New” Client Emerges

The Jito-Agave client closely mirrors the core Agave codebase, primarily differentiating itself through the addition of MEV capabilities. Jito’s “Agave plus MEV” model enabled its client to integrate smoothly with Solana’s existing validator ecosystem, boosting rewards while minimizing changes to the core architecture. As a result, the Jito-Agave client now leads the network with a 79% share of validator adoption at the time of writing. Thus, validators can rely on Agave’s foundational logic while benefiting from Jito’s extra revenue streams.

BAM represents a departure from Jito’s earlier approach of closely mirroring Agave. The introduction of a dedicated network of BAM Nodes establishes a new infrastructure layer. This evolution shifts Jito from being simply an “enhanced Agave” to a more distinct client, complete with its own programmable ecosystem for embedding application-specific logic.

This divergence is evident in Agave’s upcoming scheduler bindings, which Anza announced in May. Custom scheduler implementations are becoming increasingly common as MEV on Solana matures. While custom schedulers may increase revenue for their operators, their current implementations have several disadvantages, including the need to run a different validator version binary, reliance on closed-source code, and potential liveness concerns. 

Anza’s upcoming scheduler bindings introduce modularity by allowing validators to connect to external block-building services without altering the core validator binary, enabling support for custom schedulers. This design promotes transparency, safety, and easier DevOps. However, BAM removes the need for Jito users to use these bindings, as sequencing is handled upstream by the BAM Node scheduler. This bypasses Agave’s planned scheduler bindings, potentially streamlining operations but raising questions about future ecosystem fragmentation due to their divergence from Anza’s standardization efforts (e.g., complicating Firedancer integrations).

Jito, however, is positioning BAM as part of a unified validator client. BAM validators will run an updated version of the Agave client that integrates the BAM scheduler, only accepting transactions in FIFO order from BAM nodes. This design avoids client fragmentation while enhancing system resilience. Jito plans to release its BAM-compatible client ahead of Anza’s modular scheduler rollout. This move highlights BAM’s dual impact: it fosters innovation and advances Solana’s MEV infrastructure, but also risks further entrenching Jito’s position as the dominant validator client.

It is also possible that BAM will use these bindings. If BAM operates within the modular scheduler, Firedancer support becomes trivial, and a new question of whether Jito actually needs a validator client arises. Only time will tell as we await the open-source code implementation and rollout of BAM.

Open Questions

The Diminished Role of Validators

BAM’s design fundamentally alters Solana’s validator landscape by offloading transaction sequencing to a separate network of TEE-secured BAM Nodes. This leaves validators primarily responsible for execution, consensus, and state management. Such separation is beneficial for apps, as it enables custom sequencing and revenue-sharing possibilities for token holders. It also benefits users by reducing negative MEV and offering more favorable pricing. However, it raises questions about the diminishing agency and economic incentives for validators.

When producing blocks as the leader, validators currently have complete discretion over transaction ordering, allowing them to run custom schedulers to optimize their blocks as they see fit. BAM removes this responsibility from validators. Now, validators receive pre-sequenced transactions to execute in strict FIFO order, stripping away their autonomy over block construction. At the extreme end of this spectrum, if all transactions go through BAM, validators become mere “rubber stamps,” questioning the need for decentralized validators at all. 

However, counteracting factors exist. Namely, plugin fees provide new revenue streams shared with validators and stakers. BAM’s unified client and automated fallbacks align self-interest with network health, thereby improving overall resilience. The opt-in phased rollout also preserves choice, and long-term open-sourcing allows validators to have a say in BAM development, fostering community-driven enhancements and preserving aspects of agency.  Validators will also have the possibility to propose scheduler improvements to BAM, potentially opening the door to capturing fees from higher volumes. Moreover, the idea of validators as mere rubber stamps is likely an overstatement, as validators still have a key role in consensus and fork choice. The real question is how much agency will validators truly lose? Could BAM actually enhance validator focus on liveness and state integrity?

Several questions remain:

• How do validators compete beyond hardware and uptime if BAM Nodes handle sequencing and MEV extraction? 
• In a high-adoption scenario, will validators’ execution-only focus reduce the overall decentralization of Solana, and if so, what metrics could measure this diminishment?
• If BAM pushes validators towards more nefarious avenues in the search for revenue, what safeguards, beyond attestations, can prevent this without further reducing incentives?
• Could TEE vulnerabilities or plugin exploits lead to validators being unfairly penalized? 
• Drawing from Ethereum’s experience with PBS, what can Solana do to counteract the diminishing agency of validators?

Malicious Node Operators

BAM’s architecture introduces new trust assumptions regarding validators. That is, validators will not act maliciously when interacting with BAM Nodes, such as by tampering with pre-sequenced transactions or leaking data. At launch, BAM will rely on a permissioned operator set due to TEE limitations. This permissioned set will be entrusted with running an updated Jito-Solana client and faithfully executing forwarded transactions. These validators must trust BAM Nodes not to manipulate the ingress, creating dual-layer trust (i.e., BAM Nodes pre-TEE, validators post-TEE), which heightens risk in a permissioned setup. The critical question is: what prevents BAM Node operators from peeking at transactions before they reach the TEE? The answer is QUIC encryption for verified nodes—they’ll embed the attestation in the QUIC certificate. Another way to observe whether BAM Nodes are honest is to check their hashes against BAM’s open-source repository to see whether a given BAM Node is running the software that it says it’s running. Assuming someone hasn’t broken the TEE, the QUIC certificates for the TPU will be generated inside the TEE. Thus, all traffic in and out will be encrypted.

However, censorship and selective manipulation of transaction packets at the network ingress and egress points are notable concerns. Malicious operators maintain significant censorship capabilities, despite not being able to view encrypted transaction details. Operators could identify protocol types via TLS signatures, filter based on connection endpoints, perform timing analysis to identify certain patterns, and block all encrypted data that matches certain characteristics. So, the malicious operator may not be aware of the exact transactions being transmitted, but they can still drop packets based on metadata and certain traffic patterns. To mitigate this, enhanced transparency may be achieved by incorporating DoubleZero’s packet filtering and timestamping capabilities. Mitigating network censorship attacks is, ultimately, a valid reason for a permissioned rollout.

There are also new trust assumptions surrounding physical access, as it almost always is a security failure, and TEEs are no exception. While TEEs offer strong security guarantees, they can still be compromised if an attacker gains physical access to the server. Exclusive partnerships with SOC 2-compliant providers will help mitigate this, ensuring robust, layered security at the data center level. However, it is unclear which compliant providers will be partnered with. Interestingly, finding information about SOC 2-compliant validators can be somewhat of a struggle for the average user. For example, roughly half of Solana’s validators use TeraSwitch, Latitude, and Cherry Servers. TeraSwitch is SOC 2-compliant, yet all publicly accessible information on their site fails to mention this. Latitude is ISO 27001:2013 compliant and not SOC 2-compliant, although the former is typically considered synonymous with the latter for compliance reasons. Cherry Servers does not mention anything at all regarding compliance. At face value, this opacity and initial confusion about what constitutes a credible SOC 2-compliant data center partner raises concerns around validator diversity, especially in a network where traditionally high hardware requirements already limit validator diversity. 

Several questions remain:

• If a malicious operator censors packets or leaks data, how will enforcement work?
• In the permissioned phase, how will operator selection avoid collusion, and what metrics can be used to measure progress to decentralization? 

Composability and Plugin Interaction

One of the most important open questions for BAM is how plugins will interact with each other in practice. A single transaction might rely on multiple plugins simultaneously, for example, using an oracle plugin for just-in-time price updates, a DEX plugin for determining optimal swap routes, and a token plugin to handle specific SPL token behaviors. Ensuring these components work together predictably and securely is critical.

Plugins may need to fetch external data to function effectively. However, this creates a potential attack surface as malicious plugins could abuse external calls to leak sensitive transaction information. Defining strict boundaries around what plugins can access and share is essential to maintain trust in the system.

Another layer of complexity comes from the interplay between application-level plugin logic and Solana’s fee mechanics. How do plugin execution order, Jito tips, and priority fees interact when multiple plugins are competing to influence block construction? These economic dynamics must be clearly defined and transparently enforced to avoid unintended manipulation or abuse.

To manage these risks, the rollout of BAM plugins is expected to begin in a permissioned environment. This allows early-stage experimentation and auditing of plugin behavior before gradually moving toward a permissionless model.

TEE Trust and Liability

The reliance on TEEs introduces new trust assumptions, as it uses a special hardware enclave instead of creating a trustless system to guarantee verifiable compute. Reliance on a single hardware vendor, like Intel or AMD, introduces monoculture risks—a firmware recall or exploit has the potential to halt BAM, and possibly trigger network-wide downtime depending on network adoption. If these vulnerabilities cannot be fixed with firmware, microcode, or BIOS updates, replacing hardware takes time and imposes a recurring capital expenditure on BAM Node operators, further exacerbating the impact of potential downtime. 

These concerns are grounded in historical vulnerabilities that have shown TEEs can fail and have the potential to expose encrypted data. For example, Intel’s Software Guard Extensions (SGX) have been plagued with issues that have affected blockchains. In August 2022, the Secret Network was vulnerable to the xAPIC and MMIO vulnerabilities. Together, these vulnerabilities could be used to extract the consensus seed—a master decryption key for private transactions executed on the network. 

A multitude of other issues ultimately led to Intel deprecating SGX from 11th and 12th-generation Intel Core processors. AMD’s Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) also has several disclosed vulnerabilities. Notably, in February, CVE-2024-56161 was disclosed—a vulnerability that allowed malicious microcode injection with admin access. 

Updates to mitigate vulnerabilities are not always backward-compatible and may require physical upgrades. For example, the disclosure of CVE02020-12967 and CVE-2021-26311 meant there was the possibility for arbitrary code execution within guest virtual machines on AMD Secure Encrypted Virtualization-Encrypted State (SEV-ES) machines, the company’s previous-generation TEE implementation. AMD did not release updated firmware to address these vulnerabilities and has provided mitigation in the SEV-SNP feature, which was only supported on 3rd Gen AMD EPYC (i.e., “Milan”) processors. 

BAM's TEE infrastructure is built on the latest generation SEV-SNP architecture, which includes the hardware-level protections necessary to prevent these known exploits. Also worth noting is that in the event of a zero-day vulnerability being discovered, the network could remain operational, as Jito-Validators can automatically fall back to their own TPU when disconnected from a BAM Node. This failover mechanism ensures validators continue running while security patches are applied.

Several questions remain:

• How does BAM’s reliance on hardware vendors affect long-term trust, given past exploits? Can alternatives such as Zero Trust Execution Environments (ZTEEs) be used to reduce this dependency?
• Who bears liability for financial losses if private transaction data leaks from a compromised TEE?
• How would trust be restored if TEE failures occur? Could offer an alternative?

Conclusion

Validators are ultimately free to run the software of their choice. As profit-driven businesses operating in a highly competitive market, their decisions are shaped by the potential returns for both themselves and their delegators, who are free to shift stake to wherever yields are highest. The widespread adoption of the Jito-client reflects this dynamic, with its success in large part driven by its ability to deliver additional revenue to both operators and delegators. BAM's adoption will hinge on similar dynamics. If running BAM proves consistently more profitable than the status quo, validators will adopt it. If not, they may be hesitant to switch even if BAM succeeds in providing substantial benefits to other stakeholders.

With BAM only recently announced, many questions about its design and operation remain unanswered. We look forward to more details, documentation, and community discussions in the months ahead on this exciting development.

Further Resources

• Introducing BAM: The Future of Block Building on Solana - Jito
• BAM Whiteboard Series - Jito Learn
• Jito BAM and the Future of Solana - 0xResearch