In September 2025, Jito launched the next iteration of transaction scheduling on Solana — Block Assembly Marketplace (BAM). Given the questions we’ve received from many ecosystem stakeholders, we took Mert’s advice to “proactively seek out and steelman all the counters against BAM in a long-form post.”

This article is an effort to address the most common questions we’ve received, and in doing so lay out our vision for why we designed BAM in the manner that we did. 

Centralization

“BAM is a centralized sequencer with a block-building monopoly.”

Steelman

This critique argues that BAM introduces a single sequencer that will do all transaction scheduling for Solana. Even if the infrastructure is distributed, the scheduling rules originate from one system, which is controlled by Jito. Stakeholders worry this undermines Solana’s natural diversity of schedulers into one that could behave like a centralized sequencer, becoming a single point of failure and concentrating too much influence in one scheduler and one party.

Response

BAM is designed so that no single entity – including Jito – can unilaterally control transaction ordering. The system will decentralize both its operation and governance of scheduling logic through a combination of:

1. Open participation: Any operator that meets BAM’s operational and security requirements (similar to running a validator) can run a BAM Node. Operators run their own BAM Nodes, verify attestations independently, and will be able to propose, adopt, or reject scheduler improvements and upgrades.

2. Global coverage: BAM Nodes will be deployed across a geographically diverse network of independent operators. Collaboration with leading data center providers like TeraSwitch, Latitude, Cherry and servers.com — which today are trusted by many validators on Solana — will enable broad regional distribution beyond the status quo, as BAM will expand onboarding beyond these providers to ensure multi-region redundancy and the highest possible diversity of operators.

3. Open-source, verifiable scheduling: 

The worst possible outcome for Solana is that the market becomes a black box, diffused across multiple, closed source schedulers. 

To solve this, all BAM code will be open source and fully auditable, with every scheduling decision accompanied by cryptographic attestations that any market participant can independently verify. No operator, including Jito, can modify ordering rules without the network being able to detect it.

Lastly, BAM will be opt-in, and validators can fall back to Agave, Jito-Solana, or Firedancer clients, so there doesn’t exist any form of “vendor lock in”, as they will be free to connect or disconnect from BAM at any time.

Although today BAM Nodes are run by Jito while the system is still being battle-tested, beginning in Q1 2026, we will open-source the full codebase, onboard independent operators and provide more details of the composition and duties of the ecosystem advisory committee that will support BAM governance. 

“As a validator, BAM ties me up to only one scheduler”

Steelman

This critique says that by opting into BAM, a validator effectively surrenders control over transaction ordering to a single scheduler. Instead of being able to run or adopt different schedulers, experiment with their own strategies, or switch between competing designs, they are bound to one system.

Response

To enable Internet Capital Markets on Solana, applications, market makers and institutions need deterministic and transparent ordering rules, similar to what traditional financial markets provide today.

Proliferation of different closed-source schedulers make it effectively impossible to guarantee the above, as blockbuilding and inclusion rules vary from slot to slot. This fragmentation is fundamentally at odds with highly performant applications and latency sensitive users.

Recognizing this, BAM adopts a uniform and deterministic scheduler by creating standardized and verifiable block building where all participants operate under the same transparent system, and every ordering decision can be audited.

Many scheduler “optimizations” create friction for Solana users and dapps by delaying transactions to generate additional fees (e.g. slot lagging). These short term gains hurt Solana’s future and shrink the pie for everyone. BAM creates a framework for innovation by focusing on positive-sum improvements for the ecosystem.

Additionally, BAM’s Plugins enable a tool for scheduling optimization without the fragmentation, providing applications with an accessible developer platform, immediate network effects from existing BAM stake and broad distribution across Solana through a uniform Plugin market, eliminating friction tied to one-off validator onboarding. BAM is open to collaborating with any of these teams to integrate their product and accelerate ecosystem innovation.

“BAM monopolizes Solana orderflow.”

Steelman

Stakeholders argue that aggregating public transactions into a single pipeline creates a central chokepoint through which all orderflow passes and gives advantages to whoever controls it. Even if neutral initially, BAM controls order flow, which can reinforce its competitive position and prevent other solutions from gaining traction.

Response

BAM collects transactions using the standard Solana TPU transaction sending mechanism and other public sources. When validators connect to BAM, their TPU is pointed to BAM, which schedules transactions and delivers them for execution. There is no such thing as "BAM transactions" versus "non-BAM transactions”; validators receive the same public transactions that would otherwise arrive directly at their TPU, simply scheduled through BAM's verifiable ordering layer with no rate limits. Validators can disconnect at any time and immediately revert to their native TPU with no switching costs. This keeps all orderflow transparent, verifiable, and fully public, rather than fragmenting it into opaque private channels.

Performance and Rewards

“BAM introduces extra latency vs. validator’s native TPU.”

Steelman

Stakeholders argue that one of Solana’s performance edge comes from transactions flowing directly to the leader’s TPU with minimal hops. Any intermediary routing layer, even a fast one, risks adding latency, jitter, and new points of failure under load, and could weaken IBRL mission compared to native TPU scheduling.

Response

BAM will have a global footprint, with over 100 nodes expected to be live including currently underrepresented regions. This breadth of coverage and co-location opportunities ensure the vast majority of nodes can maintain latency under 5ms round trip.

Current performance indicates that BAM nodes, which are already running inside TEEs, can process transactions with similar performance characteristics as the Agave validator client, which can be verified by comparing client performance on Firedancer Reports,

BAM’s highly tuned TEE software stack provides latency within a few percent of bare metal servers. The BAM node uses thread pinning, CPU isolation, IRQ affinity management, and other systems-level networking optimizations to guarantee the highest performance. BAM's networking stack is actively being optimized with plans to migrate to DoubleZero and implement additional systems-level improvements. As the system matures, performance will continue to improve, with the colocated deployment model ensuring any optimizations benefit from minimal physical distance.

“BAM produces less rewards vs. other clients”

Steelman

Validators have expressed concerns that BAM’s scheduling logic might reduce tips and overall rewards vs other blockbuilder or scheduling opportunities. Additionally, Plugin fee markets are not yet live, making upside theoretical while downside appears immediate.

Response

We believe in profit maximalization. Specifically, we believe in long-term profit maximalization.

Today, BAM’s rewards are comparable to Jito-Agave's, as shown in Firedancer Reports dashboards. BAM has only been live on mainnet for two months, and significant optimizations are in progress that will further improve performance.

Over the past months, Firedancer has outperformed both clients due to its “Revenue Scheduler,” which prioritized packing Jito bundles early in the slot and delayed standard transactions. The Firedancer team has communicated that this scheduler will be deprecated in a future release because it degrades execution quality during high activity and creates negative ecosystem externalities. Aligning all clients around healthier defaults strengthens the network over the long term.

In the short term, BAM’s rewards are competitive. Over the medium to long term, sustainable yield comes from increased economic activity, not short-term scheduling games. Jito Tips started at immaterial levels as the network required validators to bootstrap demand for the primitive. Since then, they have generated over $1.3bn in value for validators and stakers by providing improved execution on Solana.

BAM’s potential value to Solana is even greater given its additional features. Once a critical mass of stake has onboarded to BAM and the first applications start leveraging Plugins, these benefits will be visible and validators can capture additional fee streams. Through its Plugin architecture, Application-Controlled Execution (ACE), and Plugin fees, BAM is uniquely positioned to sustainably raise all boats through organic on-chain activity.

“As a validator, I need to give my stakers the highest yield.”

Steelman

Stakers often choose validators based strictly on rewards. Even a small decrease in tips or variance in earnings across one epoch can cause delegated stake to flow elsewhere. Validators fear that adopting BAM early could put them at a competitive disadvantage if peers delay adoption.

Response

We understand that validators must maximize yield for themselves and their stakers, but must also consider second order effects of their actions. 

Any additional short term gains produced through sandwiching, slot-lagging, and timing games degrade the quality of Solana as an execution layer and ultimately risk driving away applications, liquidity and traders. Over time, these dynamics reduce SOL’s value far more than minor short-term APY differences, creating worse economic outcomes for those invested in Solana’s future.

The only sustainable path to higher yield is deeper on-chain activity, which can only be enabled by better applications, deeper liquidity and tighter spreads. BAM’s core mission is to enable that by providing flexibility and better execution guarantees to applications and market makers, and in turn, benefit stakers as long term investors in the network.

Market Need

“Application-Controlled Execution (ACE) is not important”

Steelman

Stakeholders argue that Solana applications already run well under Priority Fee and Tips inclusion mechanisms. Introducing ACE may increase complexity and create uneven execution guarantees between sophisticated apps and smaller developers. They worry that allowing applications to define ordering logic could lead to BAM privileging certain actors.

Response

In order to remain competitive with emerging layer-1 and layer-2 ecosystems, Solana must enable ACE as quickly as possible. 

ACE allows applications to define their own market structure by specifying transaction ordering rules that make their markets more efficient, deepen liquidity, and tighten spreads. Examples include market maker cancel priority on CLOBs, oracle update priority for PropAMMs, and liquidation priority on lending markets to reduce bad-debt risk.It’s not enough for these rules to exist in theory; applications and their users need confidence they will be reliably enforced. Market makers and traders only size up if they know they won’t be front-run by hidden ordering games. Without ACE on Solana, teams may flock to other execution environments that provide both this flexibility and guarantees. Today, the clearest example is Hyperliquid, a CLOB DEX that in any given month does 10–15x the volume of Solana perp exchanges combined, partly thanks to a permissioned validator set that must adhere to strict ordering rules like maker priority.

ACE on BAM aims to bring those guarantees into Solana’s shared, permissionless environment, thanks to its cryptographic attestations that allow anyone to verify that transaction ordering rules are being followed. 

Importantly, ACE doesn’t increase complexity for everyone. Teams don’t need to design custom logic from scratch, as they can adopt shared, battle-tested Plugins that encode common ACE patterns as reusable primitives. These Plugins will be completely opt-in for applications –  and, ultimately, for users as well, as they choose the apps that offer the best execution and experience. In that sense, ACE expands what’s possible for those who need it, while leaving existing Priority Fee and Tips flows unchanged for those who don’t.

Some ecosystem members have proposed Asynchronous Market Queues (AMQ) as an alternative path to ACE via a purely on-chain ordering system. We don’t think this is viable for the use cases above: AMQs break atomicity and composability, can’t integrate cleanly with routers, expose queued actions to front-running, and only offer slot-level (400ms) time resolution instead of smaller windows (such as 10–20ms) that ACE use cases require. Despite being theoretically possible for years, no major project has implemented AMQs in production.

The core Solana architectural thesis is to create the execution environment for everything, which ACE enables. Without it, apps will fork away to create their own custom VMs or proprietary L1s.

“FIFO ordering is the fairest transaction ordering logic”

Steelman

Stakeholders argue that simple FIFO (first-in, first-out) ordering is the fairest and most neutral way to schedule transactions on Solana. It mirrors time-priority from traditional markets, is easy for users to understand (“if my tx arrives first, it executes first”), and avoids the “pay-to-win” dynamics of most blockchains.

Response

FIFO looks fair because it promises “first come, first served,” but at scale it just creates money-burning latency races, where the winner is whoever can spam the hardest over the fastest pipes, not whoever produces the most value to the network or end users.. 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.

Security

“Aren’t BAM’s Trusted Execution Environments (TEEs) vulnerable to attacks?”

Steelman

TEEs have a history of side-channel vulnerabilities, firmware bugs, and supply-chain risks. Stakeholders argue that relying on TEEs for block scheduling could introduce correlated failure modes: if a hardware exploit affects SEV-SNP, BAM as a network could be compromised. They also argue that TEEs shift trust onto hardware vendors and data center providers.

Response

We have covered this in depth in the following article: https://bam.dev/blog/tees-and-bam-secure-block-building-in-practice/, but will provide a TLDR for this post.

BAM runs its scheduler inside AMD SEV-SNP TEEs that produce attestations proving the right code is running on untampered hardware, with all traffic encrypted end-to-end. The hardware is hosted in already-trusted, certified data centers with strong physical security (24/7 monitoring, multi-factor access, mantraps, and escort-only entry, rack-level restrictions) and global compliance certifications like ISO 27001 and SOC 2, making hands-on TEE attacks unrealistic. 

A perfect AMD backdoor would be a risk for all CPUs, including those that power Solana validators today, not just TEEs. SEV-SNP actually reduces the trust surface by letting validators verify a measured TCB (Trusted Computing Base) and reject bad firmware or hardware via attestation. If attestations fail or a node behaves extractively, validators can simply disconnect or fall back to a different Node in their region, Jito-Agave or Agave. In a worst-case compromise of a BAM Node, you may lose BAM’s privacy and ordering guarantees on that node, but validator keys remain secure and the chain’s history cannot be rewritten.

Conclusion

BAM is not an attempt to centralize Solana’s block building, but to make it transparent, verifiable, and programmable in a way that unlocks better markets for everyone. By converging on an open, attestable scheduler, enabling Application-Controlled Execution through Plugins, and hardening the system with a decentralized network of TEEs and diverse operators, BAM aims to replace zero-sum scheduling games with durable upside from deeper liquidity, tighter spreads, and more predictable execution. 

If Solana is to become the home of Internet-scale capital markets, it needs this kind of shared, credible execution layer.  BAM is Jito’s contribution toward that goal.