Understanding BAM
The Block Assembly Marketplace (BAM) represents a radical re-imagining of the full Solana stack, and by nature is a complex system.
BAM is composed of multiple hardware and software elements, many of which are interconnected in layered ways, and its architecture fundamentally alters the Solana transaction supply chain (which itself is also complex and often poorly understood).
However, despite this core complexity BAM can be mentally mapped through the lens of how transactions are processed on Solana. This blog aims to provide the layman reader with a diagram-based explanation of what BAM is and how it affects end users of Solana.
Solana’s Transaction Supply Chain: Before and After BAM
Standard transaction
Prior to BAM, the flow of a lone transaction on Solana might look roughly like this:
In this flow, a user submits a transaction through a frontend or interface which is forwarded to an RPC service. From there, the transaction is bundled into a block by the leading validator, propagated to the rest of the Solana validator network, and achieves consensus after a set number of validator votes and confirmations. Finally, the RPC service detects this state change, and reflects the result of the transaction in the interface for the user, be it a DeFi app or a wallet.
While reductionistic, this seven-step process is a simple way to understand how transactions are currently processed. More complex and complete explainers can be found here and here.
The Problem: Frontrunning and Sandwich attacks
Currently on Solana, there is a proliferation of backroom deals that puts users at risk of harmful MEV, mainly in the form of frontrunning and sandwich attacks. In simple terms, these are:
Frontrun: An attacker sees your pending transaction and submits their own first, so they profit off the price move before yours executes.
Sandwich attack: An attacker spots a pending trade, places a buy order right before it and a sell order right after, pocketing the difference.
In this diagram, the transaction supply chain is identical to a standard transaction, but the leading validator is running a modified validator client designed to sandwich user DEX swaps. These malicious validators can be difficult to detect, and systematically removing their stake in order to mitigate negative impact on users has historically been a challenging problem for the wider network.
Additionally, there are other forms of value leakage and negative MEV that can arise from the standard Solana architecture, such as in the instance of a private mempool, frontrunning by DeFi frontends or RPC services, and elsewhere.
In aggregate, these sidechannels and backroom deals between various parties within the Solana stack have been the source of significant value leakage, and a barrier to institutional adoption, which often relies on safe transaction guarantees.
BAM Node Operators
One of BAM’s core innovations is the creation of a second set of node operators, running alongside the existing Solana validator set, that run specialized hardware called Trusted Execution Environments (TEEs). TEEs are computer chips that allow computational devices to perform calculations that can be hidden from the device, and the chips are widely used for secure processing in telecommunications, finance, and other industries.
In the below diagram, a BAM Node Operator receives the transaction and orders it with other transactions before sending the transaction bundle to the leader. However, the transactions are ordered within the cryptographically-secured, private enclave of the TEE:
BAM moves the responsibility of transaction ordering from Solana validators to BAM Node Operators, and places the ordering mempool into a TEE, making sandwich and frontrun-vulnerable transactions harder to detect – ultimately shrinking the possible attack surface for users to get exploited.
BAM Attestations
Another key innovation in BAM is the use of cryptographic attestations of transaction ordering. Think of these attestations as delivery receipts: they show that a package was delivered at a particular time with particular contents, and if something in the delivery is incorrect, it can be audited.
In this diagram, the BAM node receives the transaction, bundles it with others, and submits an attestation – an order receipt – of the exact sequence in which the BAM operator structured the transactions. This means that if the leader alters the transaction sequence – for instance, by participating in a sandwich pool – the broader Solana network will know.
BAM does not ‘solve’ MEV in any practical sense. However, it structurally decreases the opportunities for bad actors to exploit users, and by creating an attestation-based system of transparency about which validators are bad actors, it provides new tools for emerging governance systems to further reduce the presence of negative MEV in the ecosystem with the goal of potentially eliminating it entirely.
New Opportunities: BAM Plugins
While we’ve discussed BAM’s hardware innovations and the ways in which it helps to mitigate harmful MEV in depth, an additional core software feature called “Plugins” introduces ways for developers to add value to transactions rather than detract.
In this diagram, the BAM node is interacting with plugins to modify the ordering of transactions, adding value to transactions rather than detracting/extracting via harmful MEV.
We’ll look at an example of a Plugin below.
Plugin In Depth: Market Cancel Priority
Let’s analyze how a Plugin can work with a tangible example: Maker Cancel Priority on DEXes.
In most financial markets, market makers are in the business of providing liquidity and tight prices to traders. They do this by constantly posting buy and sell prices for assets. They take on risk so others can trade at any time, and they make money from the small difference between their buy and sell prices—called the spreads.
But here’s the catch: markets move fast. Really fast. If prices suddenly spike or crash, a market maker’s posted prices might become outdated in a matter of milliseconds. And if they don’t update or cancel their quotes in time, traders can snipe those old prices—buying low or selling high at the market maker’s expense. This is called adverse selection: the market maker is trading at a loss because they didn’t update their prices fast enough.
Over time, if this happens too often, market makers pull back. They either quote wider spreads (worse prices for users) or stop quoting altogether (less liquidity), which hurts overall market quality.
The same dynamic applies to on-chain trading—whether on a perpetual or spot DEX. Giving market makers the ability to cancel stale orders with priority is critical. Without them, liquidity dries up, execution worsens, and markets become less efficient for everyone.
Maker Cancel Priority Logic
A perps DEX could implement this mechanism as a Plugin, allowing market makers to cancel stale orders only when it improves market quality.
Here’s one example of how it could work: detect stale orders.
When a market maker submits a cancel request, the Plugin checks if the order is far from their current fair price. If the market has moved and the order is now off-market – say, 1% or more away from the midpoint – it’s considered stale.
This would lead to the following actions in the BAM Node:
- Prioritize the cancel: If the Plugin determines the order is stale, it moves the cancel request to the front of the transaction batch—giving it priority over other actions like new orders or taker fills.
- Publish the ordering logic: Just like any BAM Plugin, the logic is transparent and auditable. Anyone can verify that cancels were only prioritized when the market had moved meaningfully.
By using the fair price based on each market maker’s current spread, the Plugin avoids needing external oracles and keeps logic self-contained within the DEX. It ensures cancel priority is only used when it’s justified—protecting market makers and ensuring fair play for takers.
The result: tighter spreads, more consistent liquidity, and better execution for everyone.