Jito Auction Timing — What 200ms Means

I now understand the ratio. Tip divided by compute units. The ranking formula. The efficiency metric. I have spent time trimming compute units, recalculating tip amounts, engineering leaner bundles. The math is clear. The formula is public. And yet bundles still vanish. Opportunities still disappear. The zero on the landing counter refuses to budge.

Something else is happening. Something the ratio alone does not explain.

The ratio determines who wins an auction. But an auction is not a permanent, always-open market. It is an event. It has a start time. It has a deadline. And if you arrive after the deadline, your ratio does not matter. You could have the best bundle ever constructed — perfect efficiency, generous tip, minimal compute — and it means nothing if you show up one millisecond late.

This is the dimension I have been ignoring. The time dimension. And in the Jito ecosystem, time is measured in units of 200 milliseconds.

The SAT Clock

Everyone who has taken the SAT knows the feeling. You are working through a reading comprehension section. The passage is dense. The questions are tricky. You are making progress, reasoning carefully through each answer. And then the proctor calls time. Pencils down. Whatever you have marked is your answer. Whatever you have not reached does not exist. It does not matter that you would have gotten questions 38 through 44 correct if you had another three minutes. Three minutes does not exist. Time is up.

The Jito Block Engine operates on the same principle. It runs auctions on a fixed tick — every 200 milliseconds. When a tick fires, the engine collects every bundle that has arrived since the last tick, evaluates them, ranks them by tip efficiency, and selects the winners. Then the next tick begins. Whatever bundles arrive during the next 200ms window compete in the next auction. The previous auction is closed. Sealed. Done.

This means that the auction is not a continuous process. It is a series of discrete events. A bundle that arrives at millisecond 190 of a tick competes in the same auction as a bundle that arrived at millisecond 10. They are in the same pool, ranked by the same criteria, given the same chance. But a bundle that arrives at millisecond 201 — just one millisecond into the next tick — is in a completely different auction. It competes against a completely different set of bundles. The opportunity it was targeting may already be gone, captured by someone who made the earlier deadline.

This is the SAT proctor calling time. One second you are in the game. The next second you are not. The boundary is sharp.

The Amtrak Problem

Here is what makes this hard. The 200ms tick is just the auction window at the Block Engine. But my bundle does not materialize at the Block Engine. It starts inside my bot. And between my bot and the Block Engine, there is a pipeline. A sequence of steps, each consuming time, each eating into that 200ms budget.

Think of it like catching an Amtrak train. The train departs at 3:00 PM from Union Station. That departure time is fixed. It does not wait. But your journey to the train starts much earlier. You wake up. You shower. You pack. You drive to the station. You park. You walk to the platform. You find your car. Each step takes time. And the train does not care how long your morning routine takes. It only cares whether you are standing on the platform when the doors close.

My pipeline is the same. An opportunity appears on-chain — a price discrepancy between two pools. My bot detects it. Then the clock starts. The bot has to analyze the opportunity. Calculate whether it is profitable after fees and tips. Determine the optimal trade size. Construct the transaction. Sign it. Wrap it in a bundle with the tip transaction. Submit the bundle to the Block Engine. And the bundle has to arrive before the current auction tick closes.

Every step in that pipeline consumes milliseconds. Detection. Analysis. Construction. Signing. Submission. Network transit. Each one is a segment of the journey from my apartment to Union Station. And if the total journey takes longer than the time between when the opportunity appears and when the relevant auction tick closes, I miss the train. It does not matter that I packed efficiently or drove fast. The train left.

The 200ms tick is the departure board. My pipeline is the commute. And right now, I am not sure my commute is fast enough.

The Relayer Window

There is another piece of timing that I did not understand until I read the documentation more carefully. The Jito relayer — the component that sits between validators and the Block Engine — holds incoming transactions for approximately 200 milliseconds before forwarding them.

This is deliberate. The relayer hold creates a window. When a transaction arrives at the relayer, it is held for about 200ms. During that hold period, searchers who are connected to the Block Engine's mempool feed can see the incoming transaction. They can analyze it. They can construct a bundle that includes a response to that transaction — a backrun, an arbitrage that exploits the state change the transaction will create.

This is the reaction window. It is worth noting that the relayer's 200ms hold and the Block Engine's 200ms auction tick are independent clocks — they share the same magnitude but do not synchronize with each other. The 200ms hold is the time I have to see an opportunity, process it, and respond to it. It is not the only source of opportunities — price discrepancies between AMM pools exist independently of any specific incoming transaction — but for searchers who operate by watching the transaction stream and reacting to it, this window defines the game.

Think of it like the closing bell at the stock exchange. The bell rings at 4:00 PM. But the most intense trading happens in the minutes before the bell, as traders scramble to place final orders based on everything they have observed during the day. The closing bell does not create the opportunity. The opportunity exists in the market. But the bell creates urgency. It creates a deadline. And the traders who profit are the ones who can process information and act within that shrinking window.

The relayer hold creates the same urgency. 200ms is the window. Inside that window, I need to receive the signal, understand what it means, decide how to respond, build the response, and submit it. Every millisecond I spend thinking is a millisecond less I have for acting. Every millisecond of network latency between me and the Block Engine is a millisecond less I have for computing.

The window is the same for every searcher. What differs is how much of the window each searcher actually uses for useful work, versus how much is consumed by overhead.

Slots and the Leader Schedule

Here is where the timing gets even more constrained. Bundles do not just need to arrive within an auction tick. They need to arrive during the right slot.

A Solana slot lasts roughly 400 milliseconds. One validator — the leader — produces the block for that slot. Then the leader rotates. New slot, new leader. The leader schedule is public, queryable through the getLeaderSchedule API. Anyone can look up which validator leads which slot, well in advance.

The critical detail: Jito bundles are only effective during slots where the leader is running the Jito validator client. If the current leader is not a Jito validator, bundles sent to the Block Engine during that slot have nowhere to go. They cannot be included because the leader does not participate in the Jito system. The bundle just sits there, aging, becoming stale, until a Jito validator takes the leader position — at which point the opportunity the bundle was targeting may no longer exist.

This is like being a pizza delivery driver with a 30-minute delivery guarantee. You have the pizza. You have the address. You are ready to deliver. But the customer is not home. They will be back in an hour. It does not matter how fast you drove or how hot the pizza is. The customer is not home. The delivery cannot happen.

Knowing the leader schedule changes everything about timing strategy. If I know that the next Jito validator slot starts at time T, I can time my pipeline to have bundles ready for submission at T, rather than submitting blindly and hoping I hit a Jito slot. Without this knowledge, I am the pizza driver who shows up at random times hoping the customer happens to be home. With this knowledge, I am the driver who calls ahead, confirms the customer is home, and times the delivery to the minute.

The leader schedule is not a secret. It is a public API call. But knowing it exists and knowing how to incorporate it into the timing pipeline are very different things. I am still figuring out the second part.

The 400ms Heartbeat

Let me put these numbers together because they interact in ways that are not obvious.

A slot is roughly 400ms. The Block Engine runs auctions every 200ms. That means roughly two auction ticks per slot. Two chances to get a bundle included in a single block. Miss both ticks, and the slot is over. The leader rotates. The state changes. Whatever opportunity existed may be gone.

Two ticks. 200ms each. That is the heartbeat of the MEV marketplace on Solana.

Compare this to Ethereum, where blocks come every 12 seconds. Ethereum MEV searchers have an eternity — relatively speaking — to detect opportunities, construct bundles, and submit them. Twelve seconds is 12,000 milliseconds. Sixty auction ticks, if Ethereum used the same 200ms cadence. The speed advantage required to compete on Ethereum is real, but the margins are generous compared to Solana.

On Solana, everything is compressed. Two ticks per slot. 200ms per tick. The entire lifecycle of an MEV opportunity — birth, detection, analysis, capture, or death — can happen in under a second. Blink and it is over. Literally. A human blink takes about 300 milliseconds. That is longer than a Jito auction tick. In the time it takes you to blink, an auction has opened, bundles have been submitted and ranked, winners have been selected, and the next auction has begun.

This is not a market that rewards careful deliberation. This is the 100-meter dash. The starting gun fires and you run. There is no time to think about form. There is no time to reconsider strategy. You either had your strategy decided before the gun and execute it reflexively, or you lose.

Where the Milliseconds Go

My pipeline has a budget. The budget is measured in milliseconds, and every step in the pipeline spends some of that budget. Let me think about where the time goes.

First, opportunity detection. Something changes on-chain. An AMM pool gets a swap that moves its price. My bot receives this information through a WebSocket subscription. How long does it take for that state change to reach my bot? It depends on the network path. The state change happens at the validator. The validator propagates it. My RPC provider picks it up. My WebSocket connection delivers it. Every hop adds latency. Every switch, every router, every cable between the validator and my machine adds microseconds that accumulate into milliseconds.

Second, analysis. My bot receives the state change and needs to determine whether it creates an arbitrage opportunity. This means checking prices across multiple pools, calculating potential profit after fees, comparing against the tip required to be competitive. This is computation — CPU cycles, memory accesses, algorithm execution. How long does it take? It depends on the complexity of the analysis, the efficiency of the code, the hardware running it.

Third, transaction construction. Once the bot decides to act, it needs to build the actual transaction. Determine the accounts involved. Calculate the instruction data. Assemble the transaction. This is more computation, more time.

Fourth, signing. The transaction needs a cryptographic signature. This is fast — modern hardware can sign a transaction in microseconds — but it is not zero.

Fifth, submission. The signed bundle needs to travel from my machine to the Block Engine. More network transit. More latency.

Add all of these up. That sum is my pipeline latency. If that sum exceeds the remaining time in the current auction tick, I miss the tick. If it consistently exceeds 200ms, I consistently miss auctions. I become the marathon runner who starts five seconds after the starting gun. I can run the same pace as everyone else, but I am always five seconds behind. I never catch up because the finish line does not wait.

The Infrastructure Arms Race

This is where MEV competition gets uncomfortable. Because the 200ms window is the same for everyone, but the pipeline latency is not. And pipeline latency is heavily influenced by physical infrastructure.

A searcher whose machine sits in the same data center as the Block Engine has nearly zero network transit time for submission. Their bundle travels across a local network — microseconds. A searcher whose machine is on the other side of the country has tens of milliseconds of network transit. A searcher on the other side of the world has hundreds of milliseconds. Possibly more than the entire auction tick.

This is not a software problem. This is a physics problem. Light travels through fiber optic cable at about 200,000 kilometers per second. New York to Los Angeles is about 4,000 kilometers. That is 20 milliseconds one way, just for the speed of light, ignoring all the routing and switching overhead. Forty milliseconds round trip. In a 200ms auction, that is 20% of the budget consumed by geography alone.

The implication is stark. Two searchers can have identical software — same detection algorithms, same analysis speed, same transaction construction logic — and the one closer to the infrastructure wins. Not because they are smarter. Not because their code is better. Because their packets arrive sooner.

This is like two equally fast marathon runners, but one starts the race a block ahead of the other. Same speed, different outcome. The finish line does not care about fairness. It cares about who crosses first.

I do not know what my latency to the Block Engine is. I know it is not zero. And I know that somewhere, someone with a closer server is spending those milliseconds on useful computation while I am spending them on network transit. That someone has a structural advantage that no amount of code optimization can overcome.

This does not mean I should give up. There are opportunities that do not require microsecond-level timing to capture. There are auctions that are not contested by colocated searchers. There are niches where being "fast enough" is sufficient, even if I am not the fastest. But it does mean I need to be realistic about which races I can win. I cannot beat a colocated searcher in a head-to-head speed contest. I need to find races they are not running.

Validators Play Timing Games Too

There is one more layer of timing complexity that I did not expect. The validators themselves — the leaders who produce blocks — are not passive participants in the timing game. They are active players.

Some validators adjust their block production timing to maximize their own MEV revenue. The exact mechanisms vary, but the principle is simple: by controlling when the block is finalized, the validator influences which bundles make it in and which do not. A validator can slightly delay block production to allow more bundles to arrive, capturing more tip revenue. Or a validator can produce the block earlier, favoring bundles that arrived first.

This means the 400ms slot time is not actually fixed. It fluctuates. Sometimes a slot takes 350ms. Sometimes 450ms. The variance is small in absolute terms but large relative to the 200ms auction tick. A slot that runs 50ms short means one fewer tick's worth of bundles can arrive. A slot that runs 50ms long means an extra window for late bundles.

This is like the stock market closing bell, except the bell ringer occasionally rings it a few seconds early or late. Most traders expect the bell at exactly 4:00 PM. But if it rings at 3:59:57, anyone who planned to place an order in those last three seconds is out of luck. And if it rings at 4:00:03, anyone who submitted an order assuming the standard close got three bonus seconds of trading.

I cannot control when validators produce blocks. I cannot predict whether a particular slot will run long or short. This is variance I have to accept. But knowing that this variance exists changes how I think about timing. I cannot just target the theoretical middle of a slot. I need to think about the distribution of actual slot times and build tolerance for the extremes.

The Pipeline Budget

All of this comes back to one concept: the pipeline budget. I have a fixed amount of time — roughly 200ms per auction tick — to complete the entire sequence from opportunity detection to bundle arrival at the Block Engine. That budget is not negotiable. The Block Engine does not give extensions. There is no extra credit. There is no "close enough."

Inside that budget, every millisecond matters. Not in the abstract, motivational-poster sense of "every second counts." In the concrete, engineering sense that a millisecond saved in transaction construction is a millisecond available for network transit. A millisecond saved in analysis is a millisecond of buffer against clock drift. These are real trade-offs with real consequences.

And the budget is shared between computation and transit. I cannot optimize one without considering the other. If I spend 190ms on computation and have 10ms of network latency, I use the full 200ms and make the tick. If I shave my computation down to 150ms but my network latency is 60ms, I use 210ms and miss the tick. The total is what matters.

This is not how I have been thinking about my bot. I have been thinking about correctness — does the bot detect real opportunities, construct valid transactions, calculate profits accurately. Those things matter. A fast bot that submits invalid transactions is worthless. But a correct bot that submits valid transactions too slowly is equally worthless. Speed and correctness are not in tension. They are both requirements. A bundle that is correct and late produces the same result as a bundle that is wrong and on time: zero landings.

I have been building a bot. I need to be building a pipeline. A pipeline where every stage is timed, measured, and optimized not just for correctness but for speed. Where the total pipeline latency is a first-class metric, tracked and reduced with the same urgency I apply to bug fixes and feature additions.

What 200ms Actually Means

Two hundred milliseconds is a strange amount of time. It is too short for a human to do anything useful. Too short to read a sentence, form a thought, make a decision. But it is long enough for a computer to do an enormous amount of work. Modern processors execute billions of operations per second. In 200ms, a CPU can perform hundreds of millions of calculations. It can analyze dozens of AMM pools. It can construct and sign multiple transactions. It can do everything my pipeline needs to do, with time to spare.

The bottleneck is not computation. Not for me, and probably not for most searchers. The bottleneck is everything else. Network latency. Serialization overhead. WebSocket message parsing. Connection management. All the plumbing that sits between the CPU doing useful work and the Block Engine receiving the finished bundle.

Two hundred milliseconds is generous for computation and brutal for everything else. The searchers who win are not the ones with faster CPUs. They are the ones who have eliminated as much of the "everything else" as possible. Who have minimized the distance between their useful computation and the Block Engine. Who have stripped their pipeline down to the essential steps and removed every unnecessary hop, every redundant serialization, every wasted round trip.

I am beginning to see my bot differently. Not as a program that runs arbitrage calculations. As a system that delivers bundles to the Block Engine under a 200ms deadline. The arbitrage calculations are a component of that system. An important component, but not the only one. And possibly not even the bottleneck.

The zero on my landing counter is starting to make more sense. I have been optimizing the engine while ignoring the transmission. I have been building a powerful car and wondering why it does not win races when the real problem is that I keep showing up to the track after the race has started.

Two hundred milliseconds. That is the window. That is the budget. That is what separates a detected opportunity from a captured one. Now I need to figure out how to live inside it.