Onchain market-making on Solana is insufficient in a subtle but important way. And it is not because prop AMMs are poorly designed, or because Solana can’t handle the throughput. It’s because the scheduling layer underneath them is fragmented and fundamentally unpredictable.

Every validator can run a different scheduler, which means transaction ordering changes from leader to leader. For prop AMMs trying to execute precise market-making strategies, the infrastructure they depend on can behave differently every 1.6 seconds. Today, prop AMMs spend more effort landing transactions than pricing them. This type of problem does not exist in traditional financial markets or centralized exchanges (CEXs). And it's the kind of problem that, once fixed, creates value for everyone in the network: market-makers, validators, stakers, and traders.

The Maker Priority plugin is BAM’s first plugin. It's a proof-of-concept for a simple thesis: plugins that improve execution quality strengthen market structure and attract more valuable applications and higher quality services.

Why Maker Prioritization?

For the first plugin, we are servicing onchain market-makers (Prop AMMs) on Solana because they have proven product market fit, most trading volume today is routed through them, and they already offer better prices on SOL/USD markets than CEXs. We believe this class of market participants is essential for Internet Capital Markets to accelerate legitimacy, asset issuance, and price discovery on Solana.

The teams we’ve spoken to have handled billions in trading volume per week, representing approximately 40% of all spot volume on Solana and 85% of all PropAMM volume over that period. Their feedback shaped the plugin around real pain points: overspending on failed transactions, capital inefficiencies, and the risk of censorship.

The Status Quo: non-deterministic quoting leads to wider spreads

Prop AMMs on Solana face a structural challenge that has nothing to do with their pricing models or the effectiveness of the base layer. The issue is, every validator can run a different scheduler, and transaction ordering varies from leader to leader. And there isn’t a reliable way for a market-maker to update quotes when they need to. 

Below are four images showing the index position for prop AMM transactions across four different schedulers. 

The rational response to this uncertainty is to either send more oracle updates or quote wider spreads. Send the same update multiple times across multiple paths and hope one lands in a favorable position. Or if you can't be confident your quote updates will land before a taker picks you off, you need a wider spread to absorb the times they don't.

Either way, the market-maker must account for a market structure problem that has nothing to do with their pricing logic. As a result, the chain bears this cost in reverted transactions, underutilized blockspace, and worse prices and execution quality for all traders.

What Changes with the Maker Priority Plugin

The Maker Priority plugin introduces a dedicated transaction pathway for updating quotes. Here’s how it works:

BAM receives transactions and processes them in 50ms batches, ordering by fee density to maximize revenue per batch before forwarding to the leader for execution. The Maker Priority plugin provides access to a separate, dedicated TPU port exclusively for maker transactions (oracle updates) that are enrolled in the plugin. At the end of each batch, BAM takes the latest transaction from this dedicated port and places it at the top of the next batch ahead of all other transactions from standard ports. This ensures BAM schedules maker transactions before everything else in the batch, without impacting the rest of the batch. Not even extremely high paying taker transactions can override maker priority.

The result: prop AMMs get deterministic top-of-batch execution every 50ms–a level of sub-slot precision and predictability that does not exist in the status quo. Below is an image of the intended behavior. Consistent, uniform, predictable ticks for market makers.

This is a meaningful shift. Solana's standard slot times range from 360ms to over 400ms with zero determinism around when and where transactions land within a slot. With the Maker Priority plugin, market-makers can confidently update quotes more frequently because each update lands in a known top-of-batch position. Market-making on Solana becomes deterministic.

Visit the bam.dev docs for more information.

Why Deterministic Execution Matters

Deterministic execution is not a nice-to-have. It's a foundational property of well-functioning financial markets. In traditional finance, market makers know with an extremely high degree of certainty when they’ll land and how much it costs. When a market-maker knows that a quote update will execute, and knows approximately when it will execute, a few things happen:

Spreads tighten. The uncertainty premium that market-makers bake into their quotes—the buffer for reverts, stale quotes getting picked off, and unpredictable ordering—shrinks. Resources that previously went to landing transactions can be reallocated to price improvements. Better pricing means tighter spreads, which means better fills for traders.

Liquidity deepens. When market-makers can reliably update quotes every 50ms instead of randomly throughout a slot, they can afford to post more size. The risk of being stuck with a stale quote over unpredictable time slots in a fast-moving market drops. If they know their next update will land at the boundary of a 50ms interval, they can price the risk at that moment in time more accurately and commit more capital at each price level. Deeper books mean less slippage for larger trades and attract larger pools of capital.

Unnecessary transactions disappear. If market-makers can land a quote update deterministically every 50ms, they don't need to send five copies of the same transaction. Fewer failed transactions, less wasted blockspace, lower costs for market-makers, and a cleaner chain for everyone.

The core design insight is, by updating BAM’s scheduler to service deterministic execution for market-makers, it creates value for everyone through tighter onchain spreads.

Don't Trust, Verify

The BAM Verifier is a key property of BAM's architecture worth highlighting for developers evaluating this system. It validates in real time that validators are executing the exact ordered transaction stream they received from BAM Nodes, checking both ordering integrity and correct execution feedback. If the verifier detects a mismatch, the BAM Node can take enforcement action, including disconnecting the validator.

This is important because deterministic execution guarantees are only as credible as the enforcement mechanism behind them. The verifier provides consistency and determinism for plugins as dependable infrastructure. For developers building on this system, execution rules are verifiable and enforceable, not aspirational.

Plugins as a Revenue Framework

Developers who use the Maker Priority plugin must pay 20 lamports per CU in priority fees. This is designed to optimize resource usage and intended to be a starting point for maximizing adoption and growth. We will monitor activity and results to inform future adjustments. This is the first plugin, but the thesis that better execution and market structure demands a premium extends beyond maker transactions.

BAM's architecture–batched processing, fee-density ordering, dedicated transaction pathways, transparent and verifiable sequencing—is a substrate for a much larger design space of specialized execution services that can coordinate value for the entire network. The Maker Priority plugin proves that concept, driving more trading volume for market makers and generating more fees that flow to validators and stakers.

The question we're most interested in now is: what other plugins should exist?

Any use case where transactions benefit from priority access, deterministic ordering, custom sequencing, or dedicated execution pathways is a candidate. The Maker Priority plugin demonstrates that these properties are technically achievable within BAM's design. We believe plugins can unlock entirely new financial applications. If you’re interested in building BAM plugins, please fill out this form, and we will be in touch!

What's Next

The Maker Priority plugin was built internally to validate BAM’s plugin concept and deliver incremental value to a strong and relevant use case on Solana. We plan to keep iterating and improving on the initial version. 

We're now also looking outward.

If you're a developer building on Solana and you see execution problems in your domain that look structurally similar to what prop AMMs face, such as unpredictable ordering, wasted transactions, deadweight loss from non-determinism, and MEV, we want to hear from you. We're actively exploring what a more extensible plugin framework looks like, and the best way to design it is building them with the teams that believe in the Internet Capital Markets vision.

If you're a validator or staker, the vision is simple: BAM plugins create new revenue streams by making onchain markets work better, intentionally trading short term zero-sum value capture for sustainable long term value creation. If markets are better, we all win. The oracle plugin is the first proof point. It won't be the last.

For more information, refer to the landing page here.

If you’re interested in leveraging the Maker Priority Plugin, let us know by filling out this form.