Thoughts on BAM, the New Block Building Architecture Introduced by Jito

TL;DR:

• Solana is entering a new era with the launch of the Block Assembly Marketplace (BAM), announced by Jito.
• The architecture introduces block builders (BAM nodes) operating within Trusted Execution Environments (TEEs) to protect transaction privacy and enforce block integrity.
• This effectively brings a Proposer-Builder Separation (PBS) to Solana, where transaction sequencing (builders) is decoupled from block validation (validators).
• Plugins, or interfaces that interact with BAM nodes, enable previously impractical use cases and introduce a new economic layer to the network, adding L2-like flexibility directly within Solana’s core transaction pipeline.
• The architecture is designed to limit toxic MEV, but risks remain, including unencrypted orderflow leakage, enforcement of validator execution integrity, and the potential for permissionless Plugin misuse.
• Additional challenges include builder centralization and the technical and adoption hurdles of running TEEs across the network.

Introduction

At Solana Accelerate in May, Anza introduced Alpenglow, a new consensus mechanism capable of finalizing blocks in as little as 150ms. Overhauling consensus is a colossal task for any blockchain, but it’s just one of the major changes coming to Solana in the months ahead.

This week, Jito, a core piece in Solana’s infrastructure, announced the Block Assembly Marketplace (BAM). Together, Alpenglow and BAM completely rethink how Solana works. The new architecture will enable use cases previously out of reach, introduce new economic dynamics, reduce toxic MEV, and lay the groundwork for broader institutional adoption.

In this article, we’ll explore what’s changing, what it means for the network, validators, and users, and the challenges ahead.

The BAM Era

At the heart of Solana’s upcoming infrastructure overhaul is the Block Assembly Marketplace (BAM). It introduces several changes:

• BAM nodes will replace the current relayers and decentralize Block Engine. These nodes receive transactions directly from RPCs and validators and operate within Trusted Execution Environments (TEEs), which allow them to run encrypted mempools that protect orderflow from leaking and ensure execution integrity.
• Plugins, or modular applications that live on top of BAM nodes, will enable novel use cases and introduce a new layer of economy to the network.
• Validators will continue to propose and validate blocks, but BAM nodes will handle transaction scheduling.

Here’s what the new transaction flow looks like:

A lot is happening here, so let’s break it down step by step.

Trusted Execution Environments

Solana's new architecture is inspired by Flashbots' BuilderNet, where Trusted Execution Environments (TEEs) play a central role. TEEs are isolated areas within processors (like Intel SGX or Intel TDX) that protect data and code execution from all external access.

In Solana’s upcoming design, TEEs enable:

• Encrypted mempools: Transactions are submitted to an encrypted mempool inside the TEE. This prevents third parties, including the host machine, from accessing transaction details.
• Verifiable attestations: TEEs will generate cryptographic proofs of transaction ordering. These attestations can be publicly verified, pressuring validators to execute transactions exactly as the BAM node proposed.

The use of TEEs also comes with trade-offs. Their security has been questioned, and there’s even a dedicated site, sgx.fail, that tracks known vulnerabilities in Intel’s SGX platform. Common attack vectors include side-channel attacks (e.g., Spectre) or hardware-level vulnerabilities (e.g., Plundervolt). However, if such an attack is launched against Solana, the most severe likely consequence might be transaction reordering, including sandwiches, an arguably acceptable cost for revealing a vulnerability.

BAM Nodes

In the current Jito architecture, RPC nodes and validators send transactions to a relayer, the current leader (i.e., the validator building the block), and a few upcoming leaders. The relayer filters these transactions and passes them to the block engine. Meanwhile, MEV searchers create transaction bundles and also submit them to the block engine. The block engine then processes and forwards these transactions and bundles to the validators for inclusion in the block.

The new architecture changes this. BAM nodes take over the roles of both the block engine and the relayer. These specialized nodes receive transactions from RPCs, sequence them, and forward to validators. This effectively introduces Proposer-Builder Separation (PBS) to Solana.

Another feature of BAM nodes is support for customizable schedulers, which allow developers to influence the block-building process through Plugin apps.

Initially, Jito will operate all BAM nodes. Over time, the plan is to expand to a permissioned set of operators, with the long-term goal of supporting a permissionless model.

Plugins

One of the most exciting innovations in the new Jito architecture is the introduction of Plugins, or interfaces that interact with BAM nodes. These plugins can access live transaction streams and use custom logic to influence ordering or insert their own transactions. While the scheduler still determines final ordering, plugins can use priority fees to shape block composition.

This opens up new possibilities for both developers and users. It also aligns with Solana’s IBRL philosophy, enabling new use cases that push the limits of what Solana currently supports.

From an economic standpoint, plugins introduce a revenue-sharing model that can benefit validators, delegators, and developers. That said, open questions remain about how different plugins will interact with each other, and how their economics will evolve.

Because plugins run within TEEs, they have full access to incoming transactions. This means the Plugins’ permissionlessness must be significantly constrained; otherwise, it would risk enabling harmful MEV extraction.

A practical example of plugin potential is how they might improve Central Limit Order Book (CLOB) exchanges on Solana.

A Plugin-Powered Approach to CLOBs

CLOB exchanges let users place limit orders, specifying price, size, and direction. But building efficient, on-chain CLOBs on Solana is notoriously difficult due to:

• Block times: Even with ~400ms block times, market makers typically need at least two slots (~0.8s) to place, cancel, or update orders. In practice, delays are often longer due to network congestion.
• Account contention: Solana’s write lock model prevents parallel updates to shared states, like those operated in order books.

Bulk Trade offers a new approach: directly integrating the order book into the validator stack. Orders are received through a dedicated port, matched deterministically in 25ms cycles across validators, and aggregated into a net-delta commitment that’s later posted onchain.

The downside? Validators must run additional software, which is a tough sell.

However, with BAM, this ultra-fast order-matching functionality could be implemented as Pugin. That makes adoption far easier without requiring validators to manage separate systems.

Why Plugins Are Important

Plugins effectively extend Solana’s native capabilities. In this way, their role is comparable to that of L2s on Ethereum. However, because Plugins are built at the heart of Solana’s transaction pipeline, they contribute economic value to the network, rather than extracting it like traditional L2s often do.

That said, the approach isn’t without challenges, particularly for Plugins that must maintain shared state. Bulk Trade is a good example: its orders, cancellations, and fills need to be managed deterministically and synchronized across multiple nodes. The challenge is essentially a distributed consensus problem, but for high-frequency trading with sub-second finality. In such cases, the advancements in Alpenglow’s shred distribution system, Rotor, would hopefully provide meaningful support.

Ultimately, plugins bring three major benefits to Solana:

1. Unlock new developer potential, enabling previously impractical or too expensive applications to be built.
2. Remove latency bottlenecks, helping Solana stay true to its IBRL vision.
3. Create new revenue streams for developers, validators, and delegators.

BAM validators

In the current Solana architecture, validators handle both transaction sequencing and execution. The new model separates these responsibilities: transaction sequencing is delegated to BAM nodes, while validators are responsible for executing and validating the proposed blocks.

Here’s how it works:

• BAM Validators receive pre-sequenced transaction bundles from BAM nodes.
• Transactions are executed in FIFO order, based on the sequencing determined by the BAM scheduler.
• If a validator executes transactions in a different order, it may be subject to penalties.

To support this model, BAM validators will run an updated version of the Jito-Solana client, which will be adapted to receive transactions from BAM nodes. In the future, BAM will integrate as a modular scheduler within Agave and Firedancer, allowing validators to leverage the optimized scheduling of BAM and the improved performance of these clients.

Assessing the Impact on Solana

The changes introduced by the new architecture fall into three categories:

1. Implementing Proposer-Builder Separation.
2. Enabling innovation through Plugins.
3. Limiting toxic MEV extraction.

It’s too early to say which will have the most significant impact, but each will substantially contribute to changing Solana’s economics and dynamics. Let’s start with PBS.

Proposer-Builder Separation (PBS)

So far, Ethereum is the only blockchain that has implemented PBS. Traditionally, validators build (select and order transactions) and propose (submit the block to the network). PBS splits these roles, introducing specialized builders alongside proposers.

The motivation is straightforward: specialized builders can construct more valuable blocks and extract MEV more efficiently. PBS helps address the fact that most validators lack the resources or sophistication to maximize block value on their own.

How Ethereum PBS Works

PBS is implemented on Ethereum offchain via a sidecar software called MEV-Boost. Here’s how it works:

1. Block Builders: scan the mempool, assemble blocks, and submit blind bids (including a fee for the proposer) to a marketplace.
2. Block Proposers (validators selected randomly per slot): choose the highest bid without seeing the block’s contents.
3. Relays: act as intermediaries, hiding block data until a proposer commits to a bid.

This model improves block quality but comes with trade-offs, especially around centralization.

Currently, two builders, Titan and Beaverbuild, create over 65% of blocks on Ethereum (down from over 80%). This makes block building the centralization hotspot in Ethereum’s transaction pipeline.

Much of this concentration comes from private transaction orderflow. Builders enter exclusive deals with wallets and exchanges to receive transactions before they hit the public mempool, which creates strong feedback loops that reinforce their dominance.

BuilderNet: A Response to Centralization

In late 2024, Flashbots introduced BuilderNet to tackle these centralization risks. BuilderNet, the main inspiration for the BAM architecture, allows multiple parties to operate a shared builder, offering equal access to orderflow at the network level. MEV proceeds are then distributed to orderflow providers based on open-source refund logic.

Participation is permissionless for both builders and orderflow providers. The broader goal is to prevent any single party from dominating block building.

Today, BuilderNet is jointly operated by Flashbots, Beaverbuild, and Nethermind and plans to expand. Within eight months, BuilderNet captured 30% of the market. Beaverbuild has largely transitioned its infrastructure over, and plans a full migration.

While promising, BuilderNet's long-term effectiveness remains uncertain. As long as individual builders can offer better orderflow deals to wallets, market makers, searchers or exchanges, centralization incentives will not disappear.

Implications of PBS for validators

PBS in Solana will introduce several economic shifts, but also some trade-offs, especially for validators:

Decreased MEV share for validators and delegators: With a new player in the block-building pipeline, rewards must be split. As seen on Ethereum, this can reduce delegator rewards and validator income.

• However, more efficient block building, the new economics surrounding plugins, and a healthier MEV market will likely increase total network revenue, increasing the net proceeds for stakers and validators.

Elimination of client-level optimizations

• Today, validators can modify the client code to optimize transaction ordering on the scheduler level. This encourages competition among the validators, where those with better optimizations can earn more rewards, which may lead to having more stake. With block building outsourced, that opportunity disappears. Validators will no longer have control over client-side performance improvements. Instead, their role becomes more uniform: sign and propose blocks.

While these are important points, the upside for the broader ecosystem is real: PBS improves network efficiency and user experience by enabling more competitive, higher-value block construction.

PBS seems inevitable as networks reach sufficient activity and ecosystem maturity. The incentives to fix block building inefficiency become strong enough that a market participant will always rise to fix it. PBS reflects this evolution: a step toward optimized infrastructure that benefits the network and its users. We should all be happy that Solan has reached this point.

Limiting Toxic MEV

Beyond economics, one of BAM's key goals is reducing toxic MEV. Solana’s new design includes two security mechanisms to help achieve this:

1. Encrypted mempool: Transactions are encrypted when they enter BAM nodes ****and decrypted inside the TEE at the execution stage.
2. Ordering attestation: ****Each BAM transaction bundle includes a cryptographic record of the intended order. Validators are accountable for executing the transactions as proposed, or risk penalties.

These safeguards raise the bar for MEV attacks significantly. That said, risks remain:

• Leaky transaction pipeline: since transactions are not encrypted at the client level, RPC nodes will still have the opportunity to leak the orderflow.
• TEE vulnerabilities at the hardware or software level could expose encrypted transactions. If attackers can decrypt transactions sent to the BAM node, they could exploit the existing searching infrastructure for sandwiching attacks.
• With their access to transaction information, malicious plugins could exploit transaction data unless plugin deployment is permissioned.
• Validator dishonesty: executing transactions in a different order than proposed remains possible. Having verifiable attestations is not enough. There must be a credible enforcement (e.g., slashing or temporary lockouts).

While MEV will always be a game of cat and mouse, BAM makes harmful extraction meaningfully harder. While this benefits all users, it is especially important for attracting institutions that demand deterministic execution, privacy, and auditability. By enabling these features, BAM can drive higher activity and volume on Solana, ultimately increasing total network REV.

Infrastructure and Adoption Risks

Solana will likely face some of the same hurdles Ethereum encountered in its PBS transition:

• Bootstraping TEEs
• BAM nodes must run within TEEs, which will take time to roll out, especially as the network moves toward permissionless participation. Moreover, once the BAM code is open-sourced, mirrored block builder systems that operate outside enclaves could emerge.
• Keeping blockbuilding decentralized
• Once the framework is firmly established, TEEs will reduce the likelihood of BAM nodes privately selling order flow. However, keeping the process decentralized over time is no small task. Centralization pressures may persist, particularly if block builders invest heavily in attracting top searchers and developers to optimize block construction and dominate the market.

Conclusions

Solana is entering a new phase, defined not just by faster Alpenglow consensus, but by a fundamental rethinking of how blocks are built, ordered, and validated.

With the introduction of BAM, Solana is embracing Proposer-Builder Separation, TEE-based privacy protections, and programmable transaction pipelines through Plugins. These structural upgrades shift how value is created and flows through the network.

Yes, there are trade-offs. Validators may lose some of the flexibility and MEV opportunities they enjoy today. Client-level optimizations will become less relevant. Decentralization risks around block building will also be an issue. But these changes come with big upsides:

• A fairer MEV environment, where toxic extraction is harder and incentives are better aligned.
• Greater innovation potential through Plugins, allowing developers to build application-specific logic into the block-building process.
• Stronger appeal to institutions, primarily due to the new MEV safeguards and enhanced privacy.

The transition won’t be easy. TEEs must be widely adopted, and builders and validators must adjust to new roles.

At Chorus One, we support upgrades that make Solana more efficient, resilient, and user-friendly. BAM brings these benefits. We’re excited to help build and support the next phase of Solana’s growth!

‍