The Truth About Bundle Auctions — It's the Ratio, Not the Tip

There is a number I keep staring at. Zero. Zero landings. I have been submitting bundles, attaching tips, and watching them vanish into the void. The bot detects opportunities, constructs transactions, wraps them into bundles, sends them to the Block Engine. And nothing happens. No confirmations. No inclusions. Just silence.

I have been thinking about this problem wrong. The entire time, I have been asking the wrong question. I have been asking: "How much should I tip?" The real question is: "How efficiently am I tipping?"

These sound like the same question. They are not. And the difference between them is the difference between throwing money at a wall and actually competing in the auction.

The Gas Station Fallacy

Here is a mistake I have been making, and I suspect every new searcher makes the same one.

When bundles do not land, the instinct is to raise the tip. Tip more. Spend more. If a 10,000 lamport tip does not work, try 50,000. If 50,000 does not work, try 100,000. Surely, at some point, the tip is high enough to win. This is the brute force approach — the idea that blockspace is bought with sheer spending, like an auction where the highest dollar amount always wins.

This is wrong. It is like trying to win a fuel efficiency contest by putting more gas in the tank. The contest does not measure how much fuel you carry. It measures how far you go per gallon. You can fill a Hummer's 30-gallon tank to the brim, and a Honda Civic with half a tank will still beat you on miles per gallon. The Hummer is not more competitive because it carries more fuel. It is less competitive because it wastes more fuel per mile.

The Block Engine works the same way. It does not rank bundles by total tip. It ranks them by tip divided by compute units requested. That ratio — tip per CU — is the metric. A bundle that tips modestly but requests very few compute units can outrank a bundle that tips generously but requests many compute units. The efficient bundle wins. The wasteful bundle loses, regardless of how much it spends.

I have been driving a Hummer and wondering why the Civic keeps beating me.

The Formula That Changes Everything

The ranking formula is public, documented in Jito's official documentation: tip / CU requested. That is it. That is the entire ranking mechanism for the tip-efficiency competition. No hidden weights. No secret sauce. Just a simple ratio.

And yet, the implications of this simple ratio are profound, because it means there are exactly two ways to improve your ranking:

1. Increase the numerator (tip more).
2. Decrease the denominator (request fewer compute units).

Most searchers — especially new ones like me — fixate on the numerator. Tip more, rank higher, win more auctions. This works, up to a point. But it is expensive. Every lamport added to the tip comes directly out of the profit margin. A bundle that captures a profitable arbitrage cycle but tips away all the profit is a technical success and an economic failure. You won the auction and lost money.

The denominator, though — compute units requested — is where the real leverage is. Reducing compute units costs nothing. It does not cut into the profit margin. It does not require spending more. It makes the bundle more competitive purely through efficiency. This is like a car company engineering a lighter engine that burns less fuel: the car goes the same distance, carries the same passengers, but does it on fewer gallons. The MPG goes up without the driver doing anything differently.

This is the insight I have been missing. I have been trying to outspend the competition when I should have been trying to out-engineer them.

Why Blockspace Is Not What I Thought It Was

To understand why the ratio matters, you have to understand what the Block Engine is actually doing. It is not just picking the single highest-ranked bundle and slotting it into the block. It is solving an optimization problem.

A Solana block has a finite compute unit budget. Think of it like a shipping container. The container has a fixed volume. The shipping company's job is to fill that container with packages that maximize total revenue. A large, heavy package that pays $100 in shipping fees occupies a lot of space. Three small packages that each pay $50 — totaling $150 — occupy the same space. The shipping company chooses the three small packages. More revenue per cubic foot.

The Block Engine operates on the same principle. It has a block's worth of compute units to allocate. It receives bundles from many searchers, each requesting some amount of compute and offering some amount of tip. The engine selects the combination of bundles that maximizes total tip within the compute budget. Smaller, more efficient bundles are attractive because they leave room for more bundles, which means more total tip revenue.

When I submit a bloated bundle that requests far more compute than necessary, I am that oversized package. I am occupying space that could be filled by two or three leaner bundles. Even if my tip is generous, the shipping company does not want me because I am blocking higher-value configurations. The Block Engine makes the same calculation. My bundle is not just competing against other individual bundles. It is competing against combinations of bundles. A fat bundle has to out-tip not just one lean competitor but the sum of every lean bundle that could fit in the space it occupies.

This reframes the competition entirely. I am not just trying to outbid the next guy. I am trying to be worth more per unit of space than any combination of other guys who could fill the same space.

The Priority Fee Misconception

Here is where things get confusing, and where I have been confused for longer than I want to admit.

Solana has a native mechanism called the priority fee. This is a network-level fee that transactions can attach to signal urgency. It affects the validator's scheduler — the component that decides which transactions to process first when many arrive at the same time. Higher priority fee, earlier processing. It is the Solana equivalent of paying for express shipping at the post office. You pay more, your package moves through the sorting facility faster.

The Jito tip is a completely different mechanism. It is not a network-level fee. It is a payment within the bundle auction system. It affects the Block Engine's ranking of bundles, not the validator's scheduling of individual transactions.

I have been conflating these two things. When bundles do not land, my instinct has been to crank up the priority fee on the transactions inside the bundle. More priority fee, more urgency, better chance of inclusion. Right?

Wrong. Raising the priority fee does nothing for the bundle's ranking in the Jito auction. The Block Engine ranks bundles by tip efficiency — the Jito tip divided by compute units requested. The priority fee is invisible to this calculation. It is like trying to win a bidding war at an auction by wearing a more expensive suit. The auctioneer does not care what you are wearing. The auctioneer cares what number you hold up when you bid.

Priority fees and Jito tips exist in parallel but serve different purposes. Priority fees matter for transactions that go through the normal TPU path — transactions that are not in bundles. Jito tips matter for bundles going through the Block Engine. They are separate queues, separate mechanisms, separate competitions. Spending on one does not help you in the other.

I have been wearing an expensive suit to a bidding war. The money I spent on the suit could have been added to my actual bid.

Parallel Auctions, Separate Competitions

There is another piece of the puzzle that explains why brute-force tipping does not work the way I expected.

The Block Engine does not run a single auction per block. It runs parallel auctions. When two bundles touch different accounts — different pools, different tokens, different on-chain state — they are not competing against each other. They are in separate auctions, running simultaneously, each with its own set of competitors. Your arbitrage bundle for Pool A is not competing against someone else's arbitrage bundle for Pool B. They can both win. They can both be included in the same block. There is no conflict because they do not lock the same state.

But when two bundles touch the same accounts — when they both want to swap on the same pool, both trying to capture the same price discrepancy — they are in the same auction. Only one can win. And the winner is determined by tip efficiency, the ratio.

This has a critical implication for strategy. Raising the tip does not help against bundles in different auctions, because you are not competing against them anyway. And in the auction where you are competing — the one where another searcher is targeting the exact same opportunity — the tip has to be efficient, not just large. If the competitor has a leaner bundle that requests fewer compute units, their efficiency ratio can be higher even if their absolute tip is lower. They win. You lose. And you spent more to lose.

It is like a scholarship competition at a university. A student with a 4.0 GPA and a modest application does not lose to a student with a 3.5 GPA and a flashier application. The metric is the metric. No amount of presentation makes 3.5 greater than 4.0. In the bundle auction, the metric is tip / CU. No amount of absolute tip makes a worse ratio better than a better ratio.

The Jito Tip Market: From Sideshow to Main Event

There is a broader trend that makes this even more urgent. The Jito tip market has grown enormously. By early 2025, Jito tip volume had grown from a small fraction of total priority fee volume to a substantial share — by some accounts exceeding half of all non-base fee volume on the network. Jito is no longer a niche tool for a few MEV specialists. It is core infrastructure for Solana blockspace allocation.

This growth means more competition. More searchers submitting bundles. More tips flowing through the system. The days when you could win auctions with minimal tips and sloppy bundles are over — if they ever existed. The market has matured. The participants have leveled up. The competition is not casual hobbyists. It is professional operations that have spent months optimizing every aspect of their bundle construction, tip calibration, and submission timing.

When a market matures like this, brute force stops working. In a poker game with beginners, you can win by playing more hands and betting bigger. In a poker game with professionals, you win by playing fewer hands and playing them better. The Jito tip market is increasingly a game of professionals. The searchers who survive are the ones who understand the ratio, who optimize their bundles for efficiency, who treat compute units as a resource to be conserved rather than a number to be ignored.

I am entering this market now. The learning curve is not gentle.

The Two Levers, Revisited

Let me be concrete about what the ratio means in practice.

Lever one: the tip. This is the obvious lever. Tip more, the numerator goes up, the ratio improves. But this lever has diminishing returns. Every lamport added to the tip reduces the profit from the opportunity. At some point, the tip equals or exceeds the profit, and the bundle becomes uneconomical. There is a ceiling on how much you can tip, and that ceiling is set by the opportunity's profitability.

Lever two: the compute units. This is the hidden lever. Request fewer CU, the denominator goes down, the ratio improves. And this lever has no direct cost. You do not pay more by requesting fewer compute units. You do not lose functionality. You just become more efficient.

Think about it like college credits. Two students both pay the same tuition — say, $10,000 a semester. Student A takes 12 credits. Student B takes 18 credits. Student B is getting more value per dollar: $556 per credit versus $833 per credit. If a scholarship committee is evaluating "academic output per dollar of tuition," Student B wins every time. Not because Student B paid more. Because Student B extracted more from the same investment.

In the bundle auction, the "tuition" is the compute units (the cost you impose on the block's finite budget). The "credits" are the tip (the value you deliver). Delivering more tip per CU is like earning more credits per tuition dollar. You are a better deal for the Block Engine.

Now here is what makes lever two so powerful: it is entirely within the searcher's control. The tip is constrained by the market — you can only tip what the opportunity is worth. But compute efficiency is an engineering problem. It depends on how the transactions are constructed, how the instructions are organized, what operations are included and which are excluded. It depends on code quality, architecture, and technical skill. These are problems a searcher can solve without spending a single extra lamport.

This is the realization that hit me. I have been fighting the tip war — a war of wallets. The real war is a war of engineering. The searcher with the leanest, most efficient bundle construction wins even with a lower tip. They are getting stronger without spending more.

What Efficiency Actually Means

So what does it mean to reduce compute units in practice? Without getting into implementation specifics, the general concept is straightforward.

Every instruction in a transaction consumes compute units. The more instructions, the more CU. The more complex each instruction, the more CU. The more accounts each instruction touches, the more CU. Everything that happens on-chain has a compute cost, and that cost is tallied against the block's budget.

A bloated transaction is one that includes unnecessary instructions, redundant operations, or suboptimal instruction sequencing. It does more work than needed to achieve the same result. A lean transaction is one that does exactly what is required and nothing more. It is the difference between a direct flight and a flight with two layovers — same destination, same passenger, but one consumes far more fuel.

The opportunity is in the gap between "my bundle works" and "my bundle works with the fewest compute units possible." Most searchers, when they first get a bundle to execute successfully, stop optimizing. It works. Ship it. But "it works" is not the same as "it works efficiently." A bundle that works but wastes compute is a bundle that loses to a bundle that works and does not waste compute. Functionality is table stakes. Efficiency is the competition.

This is a familiar dynamic from other domains. In the stock market, high-frequency trading firms do not just need correct algorithms. They need fast algorithms. The algorithm that gets the right answer in 10 milliseconds loses to the algorithm that gets the right answer in 1 millisecond. Speed is efficiency. Efficiency is competitive advantage.

In the bundle auction, the equivalent of speed is compute efficiency. Two bundles that capture the same opportunity and offer the same tip — the one that does it in fewer compute units wins. It is not about being richer. It is about being leaner.

The Electricity Bill Analogy

Here is another way to think about it. Imagine two factories producing the same product. Factory A produces 1,000 units per day and its electricity bill is $10,000. Factory B also produces 1,000 units per day, but its electricity bill is $5,000. Which factory is more competitive?

Factory B. Same output, half the energy cost. If the product sells for the same price, Factory B's margins are twice as wide. Factory B can afford to lower prices and still profit. Factory B can invest the savings into faster equipment. Factory B survives a downturn that kills Factory A.

In the bundle auction, the "electricity" is compute units. The "product" is the tip. Factory B — the searcher with the efficient bundle — delivers the same tip while consuming less of the block's compute budget. The Block Engine prefers Factory B because it can fit more bundles into the block alongside it, increasing total tip revenue.

This is not a theoretical advantage. It is a structural one. The efficient searcher is always better positioned than the wasteful searcher, even when they are capturing the same opportunities and offering the same tips. The wasteful searcher has to over-tip to compensate for their inefficiency. The efficient searcher does not. Over time, the wasteful searcher bleeds money. The efficient searcher compounds savings.

Rethinking My Failure

With this understanding, my zero landing rate starts to make more sense. It is not necessarily that I am tipping too little. It might be that I am tipping inefficiently. My bundles might be requesting far more compute than necessary. The ratio — tip / CU requested — might be terrible even if the absolute tip is reasonable.

Consider two searchers targeting the same opportunity. One tips more in absolute terms but requests proportionally far more compute. The other tips less but runs a leaner bundle with far fewer CU requested. The leaner bundle wins — not because it spent more, but because its ratio is better. The first searcher is outbid not by a bigger wallet but by a more efficient machine.

If I had been looking at absolute tips, I would think I am being outspent. In reality, I am being out-engineered. The competitor is not richer. They are leaner. Their bundle does the same work — captures the same arbitrage cycle — but does it with fewer compute units. Their transaction construction is better. Their code is more efficient. And that efficiency translates directly into auction ranking.

This is humbling. I have spent weeks optimizing the bot's detection algorithms, its AMM simulation accuracy, its cycle-finding logic. These are important. They determine which opportunities the bot finds and whether the profit estimates are reliable. But none of that matters if the bundle that captures the opportunity is too fat to compete in the auction. The best opportunity in the world, wrapped in the worst bundle, still loses to a mediocre opportunity wrapped in an excellent bundle.

I have been optimizing the telescope when I should have been optimizing the rifle.

The Meta-Game

There is a game theory dimension to this that is worth exploring.

In a tip-efficiency competition, there are two types of players. Type one players compete on spending — they try to win by tipping more. Type two players compete on efficiency — they try to win by requesting less. Over time, type two players dominate.

Here is why. Type one players face escalating costs. When another type one player enters the market, they both have to tip more. It is an arms race of spending. Each participant's costs increase as the competition intensifies. This is unsustainable for any player with finite capital — which is every player.

Type two players face a different dynamic. When another type two player enters the market, they both try to become more efficient. But efficiency improvements do not have the same escalating cost as tip increases. An efficiency improvement is a one-time engineering investment that pays dividends on every subsequent bundle. It is not a recurring expense. It is infrastructure.

Think of it like two competing delivery companies. Company A competes by offering faster shipping (higher tips). Company B competes by optimizing its routing algorithms to use less fuel (fewer CU). Company A's costs go up with every speed increase — more trucks, more fuel, more drivers. Company B's costs go up once — hire a better routing engineer — and then go down permanently because every delivery is more efficient. Over a long enough timeline, Company B's model is sustainable and Company A's is not.

This is why understanding the ratio changes everything. It reorients the competition from a spending war to an engineering war. And engineering wars, unlike spending wars, reward skill over capital. A solo searcher with excellent bundle construction can outcompete a well-funded operation with sloppy bundle construction. The playing field is not perfectly level — capital still matters for infrastructure, latency, and operational resilience — but it is more level than a pure spending war would be.

What I Am Doing Next

The immediate implication is clear. I need to audit my bundle construction. Not the detection logic, not the AMM math, not the cycle finding — the bundle itself. How many compute units is it requesting? Can that number be reduced? What instructions are included that might be unnecessary? Is the transaction organized in the most compute-efficient way possible?

This is a different kind of optimization than what I have been doing. Detection optimization is about finding more opportunities. Simulation optimization is about estimating profits more accurately. Bundle optimization is about expressing the same opportunity in fewer compute units. It is the difference between finding a shorter route to the airport and packing a lighter suitcase for the same trip. Both save resources. But they are fundamentally different activities.

I also need to stop confusing priority fees with tips. They are separate mechanisms, serving separate purposes, affecting separate systems. The money I have been spending on priority fees inside my bundles has been doing nothing for my auction ranking. It is wasted spend — money that could have been allocated to the tip instead, improving the actual metric that determines whether my bundle lands.

And I need to internalize the parallel auction structure. Not every bundle I submit is competing against every other bundle. I am competing only against searchers targeting the same state, the same accounts, the same pools. Understanding which opportunities are heavily contested and which are relatively uncrowded is a strategic question, not just a technical one. A slightly less profitable opportunity in a less crowded auction might land more consistently than a very profitable opportunity in a hyper-competitive auction.

The Uncomfortable Truth

The uncomfortable truth about bundle auctions is that they are not won with money. They are won with engineering. The ratio favors the lean over the rich. The efficient over the generous. The precise over the lavish.

I have been thinking of the tip as the weapon. It is not. The tip is ammunition. The weapon is the bundle — its construction, its efficiency, its precision. A sniper with three rounds and perfect aim beats a soldier with a belt-fed machine gun and no training. The number of rounds matters less than where they go.

This realization does not make the problem easier. If anything, it makes it harder. Outspending someone is simple — you either have the money or you do not. Out-engineering someone requires skill, iteration, testing, measurement, and a willingness to obsess over details that seem trivial but turn out to be decisive. Shaving compute units off a transaction is meticulous, unglamorous work. It does not feel like a breakthrough. It feels like cleaning up code. But in the bundle auction, clean code wins and sloppy code loses, and the difference is measured in landing rates.

I have been throwing bundles at the Block Engine like a pitcher who only throws fastballs. Harder. Faster. More speed. But the batters are reading the pitch before it leaves my hand. What I need is not a faster fastball. I need a changeup — the same motion, the same windup, but a fundamentally different approach to the same problem.

The truth about bundle auctions is simple, and it has been sitting in the documentation the whole time. It is the ratio, not the tip. And everything I build from here starts with that understanding.