JIT Liquidity on Solana: Just-in-Time LP Sandwiching for Meteora

A large SOL→USDC swap hits a Meteora DLMM pool and, for exactly one slot, a bot you've never heard of owns 100% of the liquidity in the active bin, collects the swap fee, and pulls its capital before the next block. That's JIT liquidity, and it's the closest thing Solana has to a risk-free market-making trade — provided you win the slot.

Most Solana bot content is about sniping new mints or CEX-DEX arbitrage. JIT LP is a different animal. You're not betting on price direction and you're not racing to buy a token first. You're inserting yourself as the counterparty's fee recipient for a single transaction, then leaving. The economics come from concentrating capital so tightly that your bin captures nearly the entire fee on one trade, and the risk is bounded because your exposure lasts one slot instead of hours of open inventory.

Why Meteora DLMM makes this possible

Meteora's DLMM (Dynamic Liquidity Market Maker) prices liquidity in discrete bins, each a fixed price step apart. Unlike a Uniswap-v3 range that spreads your capital across a band, DLMM lets you deposit into a single bin. When a swap crosses that bin's price, every unit of liquidity sitting there earns the fee for the volume that fills at that price. If you're the only LP in the active bin — or you dwarf everyone else — you take almost the whole fee slice.

The active bin is the crux. DLMM fills a swap starting from the active bin and walks outward as each bin empties. A large swap chews through multiple bins. If you deposit a lot into the current active bin right before a big trade lands, your liquidity fills first and earns the highest fee density before the price moves on. This is the same fee mechanic that makes Meteora DLMM fee farming with an auto-rebalance bot work, except JIT compresses the entire hold-and-earn cycle into one slot instead of leaving liquidity parked for hours.

The tradeoff versus passive DLMM farming: passive LPs eat impermanent loss and adverse selection between fee events. JIT LPs sidestep almost all of that by being present only when a known trade is about to execute. You give up base-rate fees; you gain near-zero inventory risk.

Detection: reading the mempool that doesn't exist

Solana has no public mempool, so you can't watch pending transactions the way you would on Ethereum. What you have instead is Yellowstone gRPC (the Geyser plugin) streaming account and transaction updates straight from a validator, ahead of the confirmed ledger.

Two viable signal sources:

• Transaction stream filtering. Subscribe to transactions that touch the target DLMM pool's program and account keys. When a swap instruction shows up in the stream referencing your pool with a large input amount, that's your trigger. You're reading it in the ~200–400ms window before it lands.
• Account write subscriptions. Watch the pool's reserve accounts and the router accounts (Jupiter, for instance) for state that implies an inbound fill.

The realistic detection budget is brutal. From the moment a swap appears in your Yellowstone stream to the moment it's included in a block, you have a fraction of a slot — Solana slots are ~400ms, and by the time you see it, much of that is gone. Your add-liquidity transaction has to land in the same slot, ordered before the victim swap. This is not a "submit and hope" flow.

// Sketch: Yellowstone transaction filter for a Meteora pool
let filter = SubscribeRequestFilterTransactions {
    account_include: vec![METEORA_DLMM_PROGRAM.to_string(),
                          TARGET_POOL.to_string()],
    account_exclude: vec![],
    vote: Some(false),
    failed: Some(false),
    ..Default::default()
};
// On each update: decode the swap ix, estimate fee = amount_in * bin_fee_bps,
// bail if fee < min_profit + jito_tip + rent. Otherwise fire the bundle.

Landing before the swap: bundles or bust

You cannot rely on priority fees alone to order your add-liquidity ahead of a swap you don't control. The mechanism that actually works is a Jito bundle: three transactions submitted atomically, executed in order, all-or-nothing.

1. add_liquidity — deposit a single-bin position into the current active bin.
2. The victim swap — you rebroadcast the exact transaction you saw in the stream.
3. remove_liquidity + close position — pull everything back out.

Bundle atomicity is what makes JIT safe. If the swap doesn't land (someone else got a competing bundle in, or the trade was already included), the whole bundle fails and you never deposited. You're never left holding a naked position. You pay a Jito tip to the block engine, and that tip is your real competition cost — other JIT bots and general MEV searchers are bidding on the same slot.

Rebroadcasting the victim's transaction is the subtle part. You need the full signed transaction bytes from the Yellowstone stream, and it has to still be valid (blockhash not expired, not already processed). Sometimes you'll only see the swap after it's committed, and then there's nothing to front — you drop it. A structured strategy consultation before building this saves weeks, because the profitable filter (which pools, which swap sizes, which tip curve) is far more valuable than the plumbing.

The math, worked

Say a DLMM pool has a 0.30% fee tier and a 500 SOL swap comes through, at roughly $150/SOL that's a $75,000 notional. Fee generated on that fill: ~$225. If you own 90% of the active bin during the fill, you capture ~$202.

Against that:

• Jito tip to win the slot: highly variable, $5–$80+ on a contested pool.
• Two extra transactions' base + priority fees: cents.
• Rent for the position account, reclaimed on close: net ~zero.
• Capital cost: you need enough of both tokens to be the dominant bin LP for one slot. Flash-loan-style, since add and remove are in the same bundle, your capital is exposed for milliseconds.

Net on a clean win: $120–$195. The problem is you win maybe 1 in 5 attempts on a busy pool, and losing bundles still cost you nothing but the missed opportunity (failed bundles don't pay the tip). So the strategy is volume of attempts × win rate × net-per-win minus your infra. On thin pools where you're the only JIT bot, win rates climb and tips collapse — that's where the edge lives, and finding those pools is the whole game.

Gotchas that will eat your P&L

• Bin-crossing dilution. If the swap is so large it blows through your bin and several beyond it, you only earn on the portion that filled at your bin's price. Size your deposit to the swap, not to the pool.
• Blockhash expiry. The rebroadcast swap can go stale between stream and submission. Budget for it and drop late signals rather than submitting doomed bundles.
• Competition escalation. The moment a pool becomes reliably JIT-able, tips spike and margins compress. Rotate pools.
• Program upgrades. Meteora ships changes; a decoded instruction layout that worked last month can silently break your filter. Pin the IDL version and alert on decode failures.

If you're wiring the fills into something you'll actually watch and tune, pair the bot with a real-time trading dashboard that logs every bundle attempt, win/loss, tip paid, and realized fee — you cannot optimize the tip curve blind. And before any of this touches mainnet capital, a code review and audit of the bundle construction and the remove-liquidity path is cheap insurance against a bug that strands funds mid-bundle.

Where JIT fits in a broader stack

JIT LP is a specialist play. It pairs well with other fee-and-flow strategies rather than standing alone: the Jupiter trigger and recurring-order engine generates its own predictable flow you can sometimes JIT against, and if you run perps too, the Hyperliquid spot-perp funding loop is a completely uncorrelated income stream that smooths out the lumpy, slot-by-slot nature of JIT returns.

The honest summary: JIT liquidity on Solana is real, it's not covered by the sniping crowd, and the edge is narrow and technical. Your moat is detection latency, tip discipline, and pool selection — not the DLMM mechanics, which anyone can read.

If you want a JIT LP bot built and validated before it ever risks capital, our strategy consultation is the place to start.