What Is Jito — Solana's MEV Infrastructure

I have been building an arbitrage bot for weeks. I have written math. I have decoded on-chain data layouts. I have learned how AMMs calculate swap outputs, how concentrated liquidity ticks work, how bin-based DEXes partition price ranges. The bot detects cycles, simulates profits, constructs transactions. But there is a question I have been dancing around, one that sits underneath everything: how does the transaction actually get into a block?

On Ethereum, the answer is familiar enough that it barely needs explaining. There is a mempool. Transactions sit in it. Miners — or validators, post-merge — pick them up. MEV searchers have tools to route their transactions in specific ways, to avoid the public mempool, to bid for priority. The infrastructure is mature, well-documented, heavily competed.

On Solana, the answer is different. There is no mempool. Transactions go directly to the current leader — the validator producing the next block. The leader processes transactions in the order they arrive, more or less, and the block is produced in about 400 milliseconds. This is fast. This is efficient. And for someone trying to execute MEV strategies, this creates a problem: how do you ensure your transaction is not only fast but atomic, sequential, and prioritized?

The answer, for roughly 95% of Solana's staked validators, is Jito.

The FedEx Hub Model

To understand Jito, think about how FedEx moves packages. You do not drive your package from Memphis to Miami yourself. You drop it at a FedEx location. FedEx consolidates packages at its hub in Memphis. At the hub, packages are sorted, prioritized, and loaded onto planes heading to their destinations. The system works because FedEx sits between senders and recipients, providing sorting, routing, and guarantees that individual senders cannot provide on their own.

Jito is the FedEx hub for MEV on Solana. It sits between three parties — searchers, validators, and the blockchain itself — and provides infrastructure that none of them could efficiently build alone. It sorts, prioritizes, and routes transactions in ways that benefit all three parties. Without it, MEV on Solana would be a free-for-all: every searcher spamming transactions directly at validators, hoping to get lucky, wasting compute, clogging the network.

With it, there is a system. And understanding that system is no longer optional for me. Every bundle I submit passes through this infrastructure. Every opportunity I try to capture is mediated by Jito's machinery. If I do not understand how Jito works, I do not understand why my bundles land or do not land. And right now, they are not landing.

The Three Players

Jito's ecosystem has three distinct participants, and understanding each one is essential.

Validators: The Block Producers

Validators on Solana produce blocks. They receive transactions, order them, execute them, and append them to the chain. In the standard Solana validator client — the one maintained by Solana Labs — this process is straightforward. Transactions come in through the TPU (Transaction Processing Unit), the validator processes them, the block is produced.

Jito's contribution here is a modified validator client: the Jito-Solana client. This is a fork of the standard Solana Labs validator, optimized for MEV. It is open source, publicly auditable, and it has achieved something remarkable in adoption — approximately 95% of Solana's stake (as of April 2025) runs on the Jito-Solana client. That is not a niche tool. That is the de facto standard validator client for the network.

What makes the Jito-Solana client different from the standard one? It integrates with Jito's Block Engine. Instead of just receiving transactions through the normal TPU path, Jito validators also receive curated bundles — pre-ordered, pre-simulated groups of transactions that have won the tip competition. The validator does not need to figure out which transactions are more valuable or how to order them optimally. The Block Engine has already done that work. The validator just includes the winning bundles in its block, collects the tips, and moves on.

For validators, this is a straightforward economic upgrade. They earn more revenue by running the Jito client because they receive tips from searchers — revenue that would not exist without the MEV infrastructure. This is why adoption is so high. Running the Jito client is not charity. It is rational self-interest. Validators who do not run it leave money on the table.

Searchers: Us

Searchers are the participants who identify MEV opportunities and submit transactions to capture them. Arbitrageurs, liquidators, anyone who profits from the ordering or timing of transactions. This is what I am building. This is what the bot does. In Jito's ecosystem, the searcher is the customer — the party that pays for the service of having their transactions included in a block with specific ordering guarantees.

The word "searcher" comes from the Ethereum MEV ecosystem, where it originated with Flashbots. The concept translates to Solana, but the mechanics are different. On Ethereum, a searcher might submit a bundle through Flashbots' relay to a block builder, who assembles an entire block and submits it to validators for attestation. The process takes place over Ethereum's 12-second slot time, giving relatively generous windows for computation and submission.

On Solana, the searcher submits a bundle through Jito's Block Engine, and the bundle needs to arrive, be evaluated, and be included within a slot time of roughly 400 milliseconds. That is 30 times faster than Ethereum. The margin for error is not slim — it is nearly nonexistent. Every millisecond of latency in detecting an opportunity, constructing a transaction, and submitting a bundle is a millisecond that a competitor might use to get there first.

I am a searcher. My bot is a searcher. And right now, I am a searcher who does not fully understand the venue where the competition takes place. That needs to change.

Block Engine: The Auction House

The Block Engine is the center of the system. If validators are the auctioneers who ultimately sell blockspace and searchers are the bidders trying to buy it, the Block Engine is the auction house that runs the entire event. It receives bids, evaluates them, determines winners, and forwards the results.

Here is how it works: searchers submit bundles to the Block Engine. A bundle is a group of up to five transactions that must execute sequentially and atomically — all of them succeed or all of them fail. The Block Engine receives these bundles from many searchers simultaneously. It simulates every bundle, verifying that the transactions are valid and will not fail. It evaluates the tip each bundle offers. Then it selects the combination of bundles that maximizes total tip efficiency — the ratio of tip paid to compute units requested — and forwards that combination to the current leader validator.

This is a tip-efficiency-based competition. The Block Engine does not simply pick the highest total tip. It picks the highest tip per unit of compute consumed. A bundle that tips 10,000 lamports but uses 200,000 compute units is more attractive than a bundle that tips 15,000 lamports but uses 500,000 compute units. Efficiency matters, not just absolute spending. This is because blockspace is limited — a block can only hold so many compute units — and the Block Engine's job is to maximize the total value extracted from that limited space.

The minimum tip to participate is 1,000 lamports. That is the floor. But the floor is not the competition. The competition is against every other searcher submitting bundles for the same opportunities in the same slots. The actual tips required to win are determined by the market — by what other searchers are willing to pay for the same blockspace.

Think of it like an Uber dispatch center. Drivers (validators) want rides (bundles) that pay well. Riders (searchers) want to be picked up quickly. The dispatch center (Block Engine) matches them, optimizing for the best overall outcome. But unlike Uber, where the dispatch center sets the price, Jito's Block Engine lets the market set the price through competition. Searchers bid by tipping. The most efficient tips win.

The Fourth Player: The Relayer

There is a fourth component that often gets overlooked: the relayer. The relayer is a TPU proxy — it sits between the network and the validator, filtering and verifying transactions on a separate server before they reach the validator itself. This reduces the computational load on the validator, which is critical when the validator is processing blocks every 400 milliseconds and cannot afford to waste cycles on invalid or malicious transactions.

The relayer is like a building's security desk in a Manhattan office tower. Every visitor — every transaction — has to check in at the desk before going upstairs. The security desk verifies ID, checks the appointment list, and turns away people who do not belong. This is work that the people upstairs (the validator) should not be doing themselves. They have their own jobs. The security desk handles the filtering so the offices can focus on productive work.

For searchers, the relayer is mostly invisible. Bundles go to the Block Engine, not the relayer. But the relayer matters because it is part of the infrastructure that makes the whole system viable at Solana's speed. Without it, validators would be overwhelmed, blocks would be slower, and the MEV infrastructure would not function at scale.

Bundles: The Currency of MEV

The bundle is the fundamental unit of participation in Jito's ecosystem. It is worth understanding precisely what a bundle is and what guarantees it provides.

A bundle is a sequence of up to five transactions. The transactions execute in order — transaction one, then transaction two, then three, four, five. This ordering is guaranteed. There is no possibility that transaction three will execute before transaction two. And the execution is atomic: if any transaction in the bundle fails, none of them execute. All succeed or all fail. There is no partial execution.

This atomicity is what makes MEV strategies viable on Solana through Jito. An arbitrage cycle, for example, might require multiple swaps across multiple DEXes. Each swap depends on the previous one completing successfully. If the first swap executes but the second fails, the searcher is left holding an intermediate token with no way to complete the cycle — a loss, not a profit. Atomic execution eliminates this risk. Either the entire cycle completes profitably, or nothing happens.

Without bundles, a searcher would have to submit individual transactions and hope they all land in the right order in the same block. On a network with 400-millisecond slots and no mempool, this is essentially gambling. Bundles turn gambling into structured bidding. The searcher constructs the exact sequence of operations needed, wraps them in a bundle, and submits them as a single unit. The Block Engine either includes the whole package or drops it.

Think of it like a contractor bidding on a home renovation. The contractor does not bid on each task separately — plumbing, electrical, framing, finishing. The contractor submits one bid for the complete job: "I will do all of this work, in this order, for this price. You accept the whole bid or you reject it. I am not interested in doing just the plumbing." The homeowner (the validator) evaluates the complete bid against other contractors' bids. The best overall package wins.

The Missing Mempool

There is a piece of history that matters here. Jito once operated its own mempool — a transaction pool where pending transactions were visible before execution. This was significant because Solana itself does not have a mempool. Transactions go directly to the leader validator. There is no public waiting room where unexecuted transactions can be observed.

Jito's mempool was, for a time, a de facto substitute. It provided a place where pending transactions could be seen, and this visibility created opportunities for certain MEV strategies. But it also created risks. MEV concerns grew within the community. The visibility that the mempool provided was being used in ways that harmed ordinary users — strategies that profited from front-running user transactions, extracting value at users' expense. In 2024, Jito made the decision to shut down its mempool.

This decision reshaped the MEV landscape on Solana. Without the mempool, certain strategies became much harder or impossible. Front-running user transactions requires seeing those transactions before they execute, and without a mempool, that visibility largely disappears. The strategies that remain viable are the ones that do not depend on seeing pending user transactions — strategies like arbitrage, which profits from price discrepancies between pools regardless of what any individual user is doing.

For me, this is actually favorable. Arbitrage does not require a mempool. I do not need to see user transactions before they execute. I need to see pool states, identify discrepancies, and act on them. The mempool shutdown did not remove my opportunity — it removed some of the dirtier strategies that were giving MEV a bad reputation, while leaving the legitimate ones intact.

Comparing to Flashbots

Jito is often called "the Flashbots of Solana," and the comparison is useful but imperfect. Flashbots pioneered the concept of an off-chain MEV marketplace on Ethereum, and Jito clearly draws inspiration from that model. Both systems provide a way for searchers to submit bundles to validators through a mediated channel, avoiding the public transaction pool and competing on tip efficiency rather than raw spamming.

But the structural differences between Ethereum and Solana make the two systems fundamentally different in practice.

Ethereum has 12-second block times. Solana has approximately 400-millisecond slot times. That is a 30x difference in the time available to detect opportunities, construct transactions, and submit bundles. On Ethereum, a searcher has seconds to react. On Solana, a searcher has hundreds of milliseconds. The latency requirements are an order of magnitude more demanding.

Ethereum has a mempool. Solana does not (and Jito's former mempool is shut down). On Ethereum, many MEV strategies involve observing pending transactions and reacting to them. On Solana, strategies must rely on observing confirmed state — pool balances, account data — rather than pending transactions. This changes the nature of the search problem entirely.

Ethereum has a block builder role — a separate party that assembles entire blocks and submits them to validators. Solana does not have this separation. The Jito Block Engine curates bundles and forwards them to the leader validator, but the validator still assembles the final block. The validator has more direct control over block contents on Solana than on Ethereum.

These differences mean that expertise in Ethereum MEV does not directly translate to Solana MEV. The concepts transfer — bundles, tips, priority, atomicity. The execution reality does not. The speed requirement alone filters out strategies and approaches that work perfectly well on Ethereum's leisurely 12-second heartbeat.

The Economic Loop

Money flows through Jito's ecosystem in a specific pattern, and understanding it clarifies everyone's incentives.

Searchers identify profitable opportunities. They construct bundles to capture those opportunities. They attach tips to their bundles — payments that go to validators as compensation for including the bundles in their blocks. The Block Engine selects the bundles with the highest tip efficiency. Validators receive the tips.

But the story does not end with validators pocketing the tips. The economic model distributes MEV revenue to both validators and their stakers. Stakers — the SOL holders who delegate their stake to validators — receive a share of the MEV revenue. This means that Jito's infrastructure creates value not just for searchers and validators but for the broader ecosystem of SOL stakers. It is a three-party economic loop: searchers pay for priority, validators provide blockspace, and stakers provide the security that makes the whole network function.

For searchers, this means the cost of doing business is the tip. The tip is the price of blockspace — the cost of having your transactions included in a block with the ordering guarantees you need. If the opportunity you are capturing is worth more than the tip required to win the auction, you profit. If the tip exceeds the opportunity's value, you lose. The entire game is finding opportunities large enough to justify the tips required to win them.

This is the same dynamic as any auction market. A real estate developer identifies a property that could be flipped for a profit. The developer attends the auction and bids. The winning bid determines whether the deal is profitable. If the bidding war pushes the price above the property's resale value, the developer walks away. If the developer wins at a price below the resale value, the developer profits. The margin between the winning bid and the resale value is the developer's compensation for identifying the opportunity and executing the deal.

In Jito's auction, the property is blockspace. The winning bid is the tip. The resale value is the MEV opportunity. And just like in real estate, the margins get thinner as more participants enter the market and competition intensifies.

What This Means for My Bot

Understanding Jito's architecture reframes how I think about the bot's performance problems.

The bot's job is not just to find profitable arbitrage cycles. That is necessary but insufficient. The bot's job is to find profitable cycles, construct valid bundles, attach competitive tips, and submit those bundles to the Block Engine with enough speed and precision to win the tip-efficiency competition against every other searcher targeting the same opportunities.

Each piece of that chain is a potential failure point. Finding the cycle depends on fresh data. Constructing the bundle depends on accurate AMM simulation. Attaching a competitive tip depends on understanding the current competitive landscape — how much other searchers are tipping for similar opportunities. Submitting with enough speed depends on infrastructure — network latency, processing efficiency, connection quality to the Block Engine.

I have been focusing on the detection and simulation parts of the chain. Finding cycles, getting the math right, modeling the on-chain behavior accurately. These are important. They are necessary. But they are not sufficient. The Jito layer — the bundle construction, the tip strategy, the submission timing — is equally critical, and I have been treating it as a black box. Submit bundle, hope for the best.

That approach does not work when the competition is submitting bundles with carefully calibrated tips, optimized compute unit requests, and microsecond-level timing. They are not hoping for the best. They are engineering for the best. They understand the auction mechanism and they are exploiting that understanding to maximize their win rate. I am just throwing bundles at the wall.

The 95% Number

It is worth pausing on that adoption statistic. Approximately 95% of Solana's stake runs on the Jito-Solana validator client. This is not just impressive — it is definitional. When 95% of the network uses a particular piece of infrastructure, that infrastructure is not optional tooling. It is the platform.

This means that the vast majority of blocks on Solana are produced by validators running the Jito client. The vast majority of slots are Jito-connected slots. The Block Engine has access to nearly the entire validator set. For a searcher, this is good news: you can submit bundles and be confident that whatever validator happens to be the leader, there is a very high probability it is running the Jito client and can process your bundle.

But it also means that every other searcher has the same access. The infrastructure is not a competitive advantage — it is table stakes. You do not gain an edge by using Jito. You fall behind by not using it. The edge comes from how you use it: what opportunities you find, how efficiently you construct your bundles, how accurately you calibrate your tips, how quickly you submit.

Where I Am Standing

I now understand the venue. Jito is the auction house where blockspace is sold. The Block Engine runs the auction. Validators are the sellers. Searchers are the bidders. Bundles are the bids. Tips are the price. Efficiency — tip per compute unit — determines the winners.

I am a searcher. I am standing in the auction house, paddle in hand, surrounded by bidders who have been doing this far longer than I have. They know the auctioneer's patterns. They know how to read the room. They know when to bid aggressively and when to hold back. They have spent months or years refining their strategies, their infrastructure, their timing.

I have the paddle. I have the bank account. I have a seat in the room. But knowing how the auction works is not the same as knowing how to win it. The structure is clear. The strategy is not.

The bot can detect opportunities. The bot can simulate profits. The bot can construct transactions and wrap them in bundles and submit them to the Block Engine. All of that machinery is built and running. What the bot cannot do — not yet — is compete effectively in the tip-efficiency competition that determines whether those bundles actually make it into blocks.

How do you calibrate a tip? Too low, and you lose the auction to someone who tipped more efficiently. Too high, and you win the auction but give away all the profit — or worse, overpay and lose money on a winning bid. Somewhere between those extremes is the optimal tip: high enough to win, low enough to profit. Finding that point, dynamically, in real time, against competitors who are solving the same optimization problem — that is the challenge I am facing.

And behind the tip question sits a deeper one. The tip only matters if the opportunity is real. The opportunity only appears real if the data is fresh. The data is only fresh if the infrastructure delivers it fast enough. Every layer depends on the layer below it, and the foundation — the data pipeline, the latency, the raw speed of information flow — determines whether anything built on top of it can function.

I understand the auction house now. The question is whether I have enough speed, enough accuracy, and enough strategic sophistication to actually win any auctions.