Backrun Bundles on Solana: From Theory to the Submit Button

The 200-Millisecond Window

A big swap just hit a Solana DEX. The same token's price on a different DEX hasn't moved yet — the two pools still think they're in sync, even though they aren't. There's a temporary mispricing, maybe a few cents per token, maybe a few dollars in total. If somebody buys on the cheap side and sells on the expensive side before the rest of the world catches up, that's free money — or as close to free money as anything on-chain ever gets.

The catch: I have something on the order of two hundred milliseconds to notice the opportunity, calculate the route, build a transaction, attach it to the original swap, sign it, and ship it to Jito's block engine. Two hundred milliseconds is shorter than it takes most people to blink twice. And I have to do all of it while competing with other searchers trying to do the exact same thing.

I've spent the previous sections learning Jito mechanics — tips, auctions, gRPC plumbing, leader schedules. Now I'm trying to put it all together into a real backrun bundle. This is where theory bumps into the submit button.

What a Backrun Actually Is (and Why Bundling Matters Here)

A backrun is the polite cousin in the MEV family. Frontrunning shoves your transaction in front of someone else's to skim value from their slippage. A sandwich does both — buy before, sell after, squeeze the original trader in the middle like a double line-cutting trick at a Disney World ride. Both of those are predatory: the target ends up materially worse off than they would have without you there.

A backrun doesn't do any of that. According to a leading Solana MEV primer, the backrunner shows up after a large swap and corrects the price imbalance that swap created — buying on the cheaper venue, selling on the more expensive one. The original trader's transaction lands exactly as they intended. You're just cleaning up the puddle they left behind.

The hard part on Solana is the ordering. On Ethereum, mempool monitoring plus a large enough priority fee gets your transaction placed where you want it in the next block. On Solana there's no traditional mempool — transactions go straight from RPC nodes to the current block leader. If I see a juicy swap and want to land my arbitrage in the very next slot, I have no native way to guarantee my transaction shows up immediately after the target. The leader might process them in either order, or stuff dozens of unrelated transactions in between.

This is exactly the gap that Jito bundles are designed to close. As described in Jito's official docs, a bundle is a small group of transactions — up to five — that the block engine processes sequentially and atomically. Either every transaction in the bundle executes in the order I specified, or none of them do. If I bundle the victim transaction together with my arbitrage transaction, the block engine guarantees: victim first, arb second, same slot, no surprises.

That guarantee is the whole reason backrunning is viable on Solana. Without it, I'm gambling on slot ordering. With it, I'm running a deterministic strategy.

Detection: Watching a Chain That Has No Mempool

Before I can backrun anything, I need to see the target transaction while it's still in flight — not after it lands. This is where Solana gets weird.

Solana's design deliberately skips a public mempool. RPC nodes forward transactions directly to the current leader, who packages them into a block. There's nothing equivalent to Ethereum's pending-transaction soup that you can subscribe to and rummage through. From a vanilla RPC, by the time you see a transaction, it's already confirmed — which is way too late for a backrun.

What Jito offers instead is sometimes called a "pseudo-mempool": transactions submitted through Jito sit briefly inside the block engine, waiting their turn for the next auction. According to the same writeup, that holding window is on the order of 200 milliseconds — short enough that you can't dawdle, long enough that you can theoretically read it, simulate it, and bundle a response.

Reading that pseudo-mempool requires subscribing to streaming data from the block engine. The reference implementation in an open-source MEV bot repository listens for transactions touching specific DEX programs, then resolves any address lookup tables they reference to figure out which pools are actually involved. If a stablecoin vault balance is about to drop by a meaningful amount, that's a sell signal you might be able to capitalize on.

The naive mental model — "just watch the mempool" — falls apart fast. Solana transactions are dense: a single swap might reference dozens of accounts, some directly and some indirectly through lookup tables. You can't tell what a transaction does just by skimming its account list. You have to resolve the lookup tables, parse the instruction data, and often simulate the transaction to know what it's going to do. All of that has to happen inside the same 200-millisecond window.

This is the part where every published account I've read converges on the same conclusion: detection speed is the binding constraint. The same open-source README explicitly notes that backrunning requires "the highest hardware and RPC setup requirements" because the detection window is so narrow. An individual developer who wrote up his experience at a personal blog puts it even more bluntly: "The difference between a 50ms and 200ms response time is the difference between winning and losing every single opportunity."

Prediction: Simulating Before You Submit

Detecting a swap isn't enough. You need to know how much the swap moves the price, and whether the resulting mispricing is profitable enough to justify the tip you'll have to pay to win the auction.

Both of those questions are answered by simulation. A reference bot pulls real-time pool state from a streaming gRPC source, maintains its own in-memory model of each pool, and asks the same question over and over: "If this swap goes through, what does the post-swap state look like, and is there a profitable arbitrage route through 2-hop or 3-hop pools afterward?"

This is where the AMM math from earlier work becomes load-bearing. To estimate profit, you need to do the constant-product calculation for the original swap on the first pool, then walk through every plausible arbitrage route across other pools that share the same token. With the broader DEX universe on Solana, the search space gets big quickly.

The open-source reference implementation uses a step-unit divisor to evaluate routes at several candidate trade sizes rather than trying to solve the optimal-size equation analytically. That's a practical concession: solving the optimization exactly is doable in theory, but in a 200-millisecond budget you don't have time. Approximate-and-iterate beats exact-and-slow.

The output of all this work is a single number: expected profit, denominated in SOL or a stablecoin, before tip. That number then has to clear two hurdles. First, it has to be large enough to justify the tip needed to win the auction. Second, the simulation has to actually match what happens on-chain — which, as I keep finding out, is not the same thing as the simulation being right on a fresh devnet pool.

Construction: Five Transactions, All-or-Nothing

Once a profitable opportunity is identified, the bundle itself has to be assembled. The Jito docs lay out the constraints clearly. A bundle holds at most five transactions. They execute sequentially and atomically — either all of them land in the same slot in the specified order, or none of them do. A bundle cannot cross a slot boundary, which means the entire bundle has to fit inside one leader's slot of activity.

For a backrun, the bundle structure I'm working toward looks something like this:

1. The target transaction — the original large swap, copied as-is from the pseudo-mempool.
2. My arbitrage transaction — which contains the actual on-chain work.

That second transaction is where things get dense. An open-source reference bot constructs its arbitrage transaction with roughly this sequence: borrow funds via a flashloan on a Solana lending protocol, execute a multi-hop swap route, repay the flashloan, and pay the Jito tip. (To be precise about flashloans: the term originated on Ethereum, where they're built into protocols like Aave. On Solana, similar atomic-borrow-and-repay primitives exist on a few lending platforms.) The tip payment is the last thing the transaction does, which means if the arbitrage somehow fails before reaching it, the tip isn't paid.

That ordering matters. Jito's docs explicitly warn: "Make sure your Jito tip transaction is in the same transaction that is running the MEV strategy." If you put the tip in a separate transaction, you can end up paying the tip even when the strategy itself fails. Tip-in-same-tx-as-strategy guarantees both succeed or both fail together.

There's also a peculiar lookup-table constraint I hadn't appreciated before reading the implementation: a transaction in a bundle cannot use a lookup table that has been modified earlier in the same bundle. That sounds like a footnote, but it's actually a meaningful constraint on how you can structure dependent transactions. The open-source bot caches lookup tables it sees in the pseudo-mempool and picks the ones that minimize transaction byte size — because Solana transactions are still bounded in bytes, and lookup tables are how you fit more accounts into a single transaction.

Tips: Why the Quoted Floor Is Almost Meaningless

The Jito docs list a minimum tip of around 1,000 lamports (other sources cite 10,000 lamports — the official documentation has the lower figure). Either way, the minimum is functionally irrelevant. In any competitive opportunity, a 10,000-lamport tip is a rounding error.

The way Jito's block engine selects winners is, in plain English, through tip-efficiency-based competition. Within each batch of conflicting bundles — that is, bundles trying to touch the same accounts — bundles are ranked by tip per compute unit. The most efficient bundles per unit of compute get picked first. It's similar in spirit to how an airline boards a flight: it's not just who paid the most for the ticket, it's who's worth the most per slot of cabin capacity they take up.

That structure has a brutal economic consequence. If a backrun opportunity has, say, half a SOL of capturable value, and three other searchers also see it, the winning tip is going to consume a substantial fraction of that value. Jung-Hua Liu's economic analysis models this as an equilibrium where bidders converge toward bidding nearly the full value of the opportunity when competition is heavy. In other words: the more people are competing, the closer your net profit gets to zero.

Empirically, the personal-blog account reports competitive tip ranges of 0.01 to 0.5 SOL per bundle — many orders of magnitude above the documented minimum. The open-source reference bot includes logic to calculate tips dynamically based on the expected profit of a given opportunity, which is the only sane way to play in this environment. A fixed-tip strategy bleeds money against everyone who's adapting their tip to opportunity value.

The reassuring side of this: failed bundles don't land on-chain. According to multiple sources, you don't pay the tip if your bundle doesn't win the auction. So while losing is painful in terms of opportunity cost, it isn't a direct cash burn the way a failed Ethereum transaction is. That's a meaningful structural difference between Solana MEV and Ethereum MEV, and it's the reason this game can be played at all by people who aren't already running a fortress of infrastructure.

Reality Check: Why Most Bundles Never Land

This is the section where the gap between research and practice yawns open.

The 2024 MEV Report notes that in April 2024, more than three quarters of Jito-routed transactions were reverting on-chain. That number dropped meaningfully after a major scheduler update in the Agave client later in the year, but the underlying lesson is the same: most attempts don't succeed, even when the math looks right. The Jito explainer estimates that "over 60% of attempted trades fail due to network congestion, latency issues, or competition."

For an individual developer with cloud infrastructure, the picture is worse. The personal-blog writeup logs a bundle success rate below 5 percent and a net loss over a two-week trial period. The author's bottom-line conclusion: cloud VPS instances can't compete with bare-metal servers co-located near validators. Every millisecond of network round-trip is a millisecond a competitor is already using to outbid you.

A few patterns surface across every source I've read:

• Latency dominates. Detection window, simulation time, tip calculation, signing, and network ping to the block engine all have to fit inside a budget measured in milliseconds. Bundle the wrong way and you've burned 50 milliseconds you can't get back.
• Simulation drift kills. A profit calculation that worked on devnet, or on the same pool state from five seconds ago, doesn't necessarily hold on mainnet at the moment of submission. Pool state moves under you while you're calculating.
• Competition is asymmetric. The professional bots — the ones running tens of thousands of opportunistic transactions per day with high success rates, per the same MEV report's analysis of one prominent operator — aren't running on the same infrastructure most independent developers have access to. They're running on optimized stacks with co-location, custom RPC paths, and tip-pricing models tuned against months of historical auction data.

None of this means individual builders shouldn't try — it just means going in with realistic expectations. The same MEV report notes that the average profit per successful arbitrage transaction in 2024 worked out to roughly $1.58. The fortunes-being-made narrative gets a lot of clicks; the reality is that most successful arbs are small, and any meaningful cumulative profit comes from doing them many, many times per day.

What This Means for Solo Builders

Putting all of this together, here's the picture I'm working with as I try to actually construct and submit my first real backrun bundle.

The theory is well-documented and the tooling is largely open-source. There's no secret recipe. Jito's docs are public, an open-source reference bot is on GitHub, and the auction mechanics have been written up in detail by multiple independent research groups. Anyone with the patience to read can understand how this works.

The execution gap, on the other hand, is enormous. Detection latency, simulation accuracy, tip pricing, infrastructure quality — each of those is a separate engineering problem, and they compound multiplicatively. A 90th-percentile setup on every dimension still loses to a 99th-percentile setup. That's why so many individual MEV attempts end in net losses despite using the same conceptual playbook as the professionals.

For someone like me, working alone with reasonable but not extraordinary infrastructure, the realistic path isn't to compete head-to-head with professional searchers on the most contested opportunities. It's to find opportunities the professionals haven't bothered with — smaller pools, more exotic routes, less-traded tokens — and to be one of the few bidders for those. That's a humbler ambition than "profit by lunchtime," but it's the one the data actually supports.

The other useful framing is that the first bundle that lands isn't really about profit. It's about validating the end-to-end pipeline: detection works, simulation matches reality within tolerance, the bundle gets accepted by the block engine, the auction logic does what I expected, and a real transaction settles on-chain. That's the milestone I'm chasing right now. Profitability is a separate problem to solve once the pipeline is verifiably alive.

Key Takeaways

• A backrun is non-predatory MEV. It profits from price imbalances created by a large swap, executed in the very next slot, without inserting before or harming the original trader.
• Jito bundles make backrunning viable on Solana by guaranteeing atomic, sequential execution of up to five transactions in the same slot. Without that guarantee, you can't reliably land a transaction immediately after a specific target.
• Detection is the binding constraint. With roughly a 200-millisecond window and no traditional mempool, you need streaming data, fast lookup-table resolution, and real-time simulation.
• Bundle tip minimums are misleading. The documented floor is around 1,000 lamports, but competitive opportunities require tips many orders of magnitude higher. Equilibrium bidding theory and practitioner accounts both point in the same direction: net profit shrinks toward zero as competition grows.
• Most bundles don't land. Reported success rates range from under 5 percent for individuals on commodity infrastructure to high success rates for professional operators on optimized stacks. Realistic expectations matter more than clever code.