Inside Jito’s New Solana Plugin Strategy | Eric & Hayden

Jito's Maker Priority Plugin gives market makers a dedicated transaction processing unit on BAM nodes that is separate from the standard validator client TPU. BAM advertises this TPU on the gossip network and schedules transactions in 50-millisecond batch auctions, deduplicating sequential quote updates within each window so only the most recent one, identified by a sequence number in the instruction data, lands on chain. If a market maker sends 10 sequential updates in one window, only the latest is included, cutting priority fee costs by up to 10x in that scenario. Within each batch, transactions are ordered by fee density, defined as fee divided by compute units requested, using a greedy scheduling algorithm. An additional fee applies to use the plugin, and validators running BAM collect that fee.

The plugin directly targets the non-deterministic scheduling environment on Solana, where market makers cannot know which validator or client will process their transaction, causing them to quote wider spreads and withhold liquidity. By reducing that uncertainty during BAM slots, the plugin is intended to produce tighter spreads and better execution for end users even though the mechanism is invisible to them. SOL-USDC quotes from prop AMMs already show better execution than Binance for smaller trade sizes, with centralized exchanges becoming more favorable above roughly 20,000 to 50,000 dollars.

BAM currently holds approximately 28 percent of network stake, so the plugin benefits market makers only about 28 percent of the time. The legacy Jito client holds approximately 28 percent and Harmonic approximately 19 percent. Eric noted that greater consistency of consecutive BAM slots would likely produce a more exponential improvement in market structure rather than alternating between different client environments. Competing market makers are unlikely to bid up priority fees against each other in practice because they write to their own programs and different accounts.

BAM uses trusted execution environments so participants can verify that scheduling rules were applied correctly, and enforcement actions can be taken when validators include transactions out of order or insert their own transactions. TEEs also enable privacy use cases, which could benefit institutions wanting to trade with size without revealing liquidation prices. Jito plans to introduce an on-chain numerical BAM batch ID representing each 50-millisecond window, giving developers a finer unit of time than the current slot clock, which updates roughly every 400 milliseconds. With 50-millisecond batch IDs, market makers could tighten spreads during BAM slots and widen them outside BAM slots more frequently than is currently possible.

Jito is exploring plugin development for the perps landscape in collaboration with Phoenix, whose oracle can update every 50 milliseconds. Next priorities for perp DEX support after oracle integration are likely liquidation operations and market maker quote updates. The plugin does not require being a market maker since any party writing to an oracle account can use it, and some pairs outside SOL-USDC are already being updated through the plugin, though initial focus is on short-tail markets to build legitimacy. JTX is positioned to deliver the best possible execution for users through an incentive structure tied to BAM slots, and because JTX only improves execution during BAM slots, the architecture creates a self-reinforcing push toward broader BAM adoption.

Hayden identified MCP's main advantage over BAM as solving validator fragmentation at the protocol level through standardized scheduling, which BAM cannot do because it cannot dictate what non-BAM validators do. In an MCP world some BAM functionality would be redundant, but features such as the maker priority plugin and a potential darkpool plugin are described as net additive and not easily implemented at the protocol level. Eric framed the broader contrast as validators currently holding a monopoly over transaction scheduling, with BAM proposing a world where builders have a say over how transactions are scheduled. Solana protocol changes being discussed over the next 12 to 24 months include shorter slot times, bigger blocks, higher throughput, Alpenglow, and MCP, raising the question of whether BAM retains a distinct role in a post-Alpenglow plus MCP world. Eric said censorship resistance is a core priority for both Jito and the broader Solana ecosystem and that BAM addresses it through TEEs, while noting that exact MCP implementation details remain subject to open discourse.

Faster and more deterministic writing of off-chain data to the chain is expected to encourage more asset tokenization on Solana. Carlos draws a distinction between tokenized spot equities and pre-IPO assets, arguing that assets like SPY or Tesla are less compelling on chain because most first-world users already have brokerage access, whereas pre-IPO deals like OpenAI or SpaceX are genuinely inaccessible to global retail investors. Both Carlos and Hayden acknowledge that bringing institutional assets on chain requires regulatory engagement and will take months if not years. Hayden describes prediction markets as feeling inevitable on Solana but notes that Polymarket raised at a 20 billion dollar valuation, making direct competition extremely difficult, and that Flow, Phantom, and Jupiter are likely integrating with Polymarket or Kalshi on the back end rather than building natively.