Tip Floor API — Real-Time Competition Data

I know the ratio. Tip divided by compute units. I know the auction timing. Every 200 milliseconds, a new tick fires and bundles compete. I know what determines the ranking. I know how slots work and why the leader schedule matters. The mechanics are clear. The rules are public. The formula is transparent.

But there is a problem. I am building my bundles in the dark.

Every time I construct a bundle and attach a tip, I am guessing. Is this tip enough? Is it too much? Am I leaving money on the table by tipping too aggressively, or am I throwing bundles into a void by tipping too conservatively? I have no idea what the current competitive landscape looks like. I do not know what other searchers are tipping right now. I do not know whether this particular slot is intensely contested or nearly empty.

It is like placing a bid at a real estate auction without knowing what the house next door sold for last week. I have a number in my head. I have a budget. But I have no market data. No comparable sales. No Zillow estimate. Nothing to anchor my bid to the reality of what other buyers are actually paying.

That changes today. Because there is an API endpoint that provides exactly this kind of market intelligence.

The Zillow Estimate for Tips

When you are buying a house, you do not walk into the auction blind. You check the comps. You look at what similar properties in the same neighborhood sold for recently. You pull up the Zillow estimate. You check Redfin. You talk to your agent about recent closing prices. None of this tells you exactly what this specific house will sell for today. But it gives you a range. A starting point. A reality check against the number in your head.

The Jito Tip Floor API serves the same function. It is the Zillow estimate for bundle tips.

The endpoint is simple: https://bundles.jito.wtf/api/v1/bundles/tip_floor. A straightforward REST call. No authentication required. No API key. No rate limit concerns for reasonable usage. You send a GET request, and you receive a snapshot of what the tip market looks like right now.

The response contains five numbers, organized as percentiles: p25, p50, p75, p95, and p99. Each value is denominated in lamports — Solana's smallest unit of currency, where one SOL equals one billion lamports. The response also includes the current slot number, anchoring the data to a specific moment in time.

That is the entire interface. Five percentiles and a slot number. Deceptively simple. But what those five numbers represent is a window into the competitive reality of the MEV marketplace.

Reading the Scoreboard

Think of the tip floor data like the scoreboard at a baseball game. The scoreboard does not tell you what will happen in the next inning. It tells you what has already happened. Runs scored. Hits recorded. Errors committed. The scoreboard is historical. It is backward-looking. But every manager in every dugout stares at that scoreboard constantly because it is the best available indicator of how the game is going.

The five percentiles work the same way. They represent the distribution of tips from bundles that have recently landed — bundles that actually made it into blocks. This is not theoretical data. These are real tips that real searchers paid, and that real validators accepted.

The p50 — the median — means that half of recently landed bundles tipped below this amount and half tipped above. It is the middle of the market. If the overall tip market were a neighborhood, p50 is the price of the house right in the center. Not the cheapest fixer-upper on the edge of town, not the waterfront mansion, but the solid three-bedroom that represents what a typical buyer actually pays.

The p25 is the bottom quartile. One in four landed bundles tipped at or below this level. These are the bundles that squeaked through — the ones that landed not because they tipped generously, but because competition happened to be light at the moment they submitted. They got lucky with timing, or they targeted opportunities that nobody else noticed, or they hit a slot where few other searchers were active. The p25 is the clearance rack. It works sometimes, but you cannot build a strategy around it.

The p95 and p99 are the other end. These are the bundles that tipped aggressively — the top 5% and top 1% respectively. These searchers either spotted extremely profitable opportunities that justified large tips, or they were engaged in fierce competition where multiple searchers targeted the same arbitrage and the winner had to outbid everyone else. The p99 is the bidding war. Two families both want the same house, both have the cash, and the price rockets past anything the comps suggested.

What the Numbers Actually Mean

Here is where it gets interesting. The percentiles are not a menu. They are not prices I can choose from, like selecting a shipping speed on Amazon — standard, expedited, overnight. They are a distribution. A statistical summary of a complex, dynamic market. And understanding the difference between "a menu of prices" and "a distribution of outcomes" is the difference between using this data correctly and using it dangerously.

Consider what happens if I naively interpret the p50 as "the price I should pay." Half of landed bundles tipped at or below this level. So if I tip at p50, I should land about half the time, right?

Wrong. The percentiles describe bundles that already landed. They do not describe the bundles that failed. Think about that. If 1,000 bundles were submitted and only 200 landed, the percentiles describe those 200 winners. The 800 losers are invisible. Their tips are not reflected in the distribution. If all 800 losers tipped at p50 and still lost — because they were competing for the same opportunities as searchers who tipped at p75 or higher — the percentile data would not tell me that.

This is a classic case of survivorship bias. When analysts study successful companies to identify what they did right, they miss the critical insight — hundreds of failed companies did the exact same things. Looking only at winners tells you what winners did, not what caused them to win. The tip floor data has the same blind spot. It tells me what landed bundles tipped. It does not tell me what failed bundles tipped.

The minimum tip to even be considered is 1,000 lamports. Below that threshold, the Block Engine does not process the bundle at all. That is the cover charge. The price of admission just to get through the door. But getting through the door is not the same as getting a table. A 1,000-lamport tip puts me in the building. It does not put me in the auction.

Surge Pricing for Blocks

Anyone who has used Uber during a rainstorm or after a concert understands surge pricing. Under normal conditions, a ride from downtown to the airport costs a predictable amount. But when demand spikes — everyone leaving the stadium at the same time, everyone wanting a ride when it starts pouring — the multiplier kicks in. 1.5x. 2x. 3x. The price reflects real-time supply and demand. The car supply has not changed, but the number of people wanting rides has exploded.

The tip floor data reveals the same dynamic in the MEV market. When competition intensifies — when a large price dislocation creates an obvious arbitrage opportunity that dozens of searchers spot simultaneously — the percentile values climb. The p50 that was 10,000 lamports five minutes ago might be 50,000 lamports now. The p95 might jump by an order of magnitude. The market is surging.

And when competition is low — late at night, during periods of low on-chain activity, when few large swaps are creating arbitrage opportunities — the percentiles contract. Tips drop. The p50 approaches the floor. The surge multiplier falls back to 1x.

This is real-time market intelligence. Not about the price of tokens. Not about the value of arbitrage opportunities. About the intensity of competition for block space. About how many other searchers are active right now and how aggressively they are bidding.

No individual data point tells the whole story. But watching the percentiles move over time — seeing the p50 climb when a volatile token starts swinging, seeing the p95 spike when a large liquidity event creates obvious opportunities, seeing everything settle back down when the excitement fades — that is market data. That is information I can use.

The Stock Ticker Analogy

There is a more precise way to think about what the Tip Floor API provides, and what it does not.

Consider a stock ticker. It shows you the last trade price for a stock. AAPL: $187.42. That number tells you what one specific buyer paid one specific seller at one specific moment. It does not tell you what the next trade will execute at. It does not tell you how many shares are sitting on the bid or the ask. It does not tell you about the orders that were placed and then cancelled before they could execute. It does not tell you about the institutional buyer who is about to dump a million shares.

The last trade price is useful. It is the best single number for "what is this stock worth right now?" But professional traders do not make decisions based solely on last trade price. They look at the order book. They look at depth. They look at volume. They look at the bid-ask spread. The last trade price is one input among many.

The Tip Floor API is the last trade price. It tells me what recently landed bundles tipped. It is the best single source of data for "what does the tip market look like right now?" But it has the same limitations. It does not show me the order book — the bundles currently sitting in the Block Engine waiting for the next auction tick. It does not show me the depth — how many searchers are competing for the same opportunity I am targeting. It does not show me the spread — the gap between what losers tipped and what winners tipped.

The data is backward-looking by nature. By the time I query the API, process the response, and adjust my tip, the market may have already moved. The percentiles might be stale by one tick, two ticks, five ticks. In a market where auctions happen every 200 milliseconds, "a few ticks old" can mean the data describes a completely different competitive environment than the one I am actually submitting into.

This is not a flaw in the API. It is a fundamental characteristic of any market data. The stock ticker shows the last trade, not the next trade. The Zillow estimate shows the last comparable sale, not the future sale price. The Uber surge indicator shows current demand, not demand five minutes from now. All market data is, by definition, a record of what already happened.

WebSocket: The Live Feed

The REST endpoint I described is not the only way to access tip floor data. Jito also provides a WebSocket-based TipStream subscription. Where the REST endpoint is like checking a stock price on your phone — you pull up the app, see the number, close the app — the WebSocket is like having a Bloomberg terminal. The data flows continuously. Every update pushes to your connection in real time. No polling required.

For a bot that submits bundles multiple times per second, the difference matters. Polling the REST endpoint every time I need tip data means making an HTTP request, waiting for the response, parsing the JSON, and incorporating the result. That round trip — even on a fast connection — adds latency. Latency that compounds with every other latency source in my pipeline. In a world where 200ms is the auction window, spending 20ms on an HTTP round trip to check tip data is 10% of my budget gone on a single API call.

The WebSocket feed eliminates that round trip. The data arrives as it updates. My bot maintains a local copy of the latest percentiles, refreshed automatically whenever the values change. When it comes time to calculate a tip for a new bundle, the data is already there, sitting in memory, zero additional latency to access.

This is a meaningful architectural decision. The REST endpoint is simpler. Easier to implement. Easier to debug. The WebSocket is more complex — connection management, reconnection logic, heartbeat handling, all the familiar headaches of maintaining a persistent connection. But the performance difference is real, and in this game, performance differences translate directly into competitive advantage.

The DoorDash Problem

Here is the practical challenge I face. Every time my bot detects an arbitrage opportunity and constructs a bundle, it needs to attach a tip. And that tip needs to thread a needle.

Think of it like being a DoorDash driver deciding which delivery to accept. The app shows you a delivery: $6.50 for 3.2 miles. Is that worth it? If you accept, you commit your time and fuel. If the payout is too low relative to the effort, you lose money on the delivery. But if you decline and wait for a better offer, someone else takes the delivery and you sit idle.

My bot faces the same calculus, but in reverse. I am not deciding whether to accept a payout — I am deciding how much to pay for the privilege of having my bundle included. Tip too low, and my bundle loses the auction. The opportunity goes to a competitor who tipped more. Tip too high, and I win the auction but eat into my profit margin so aggressively that the arbitrage is barely worth executing. The delivery gets made, but the driver loses money on gas.

The tip floor data helps me frame this decision. It tells me what the current market rate is for landing a bundle. It gives me a baseline. But it does not make the decision for me. The decision still requires judgment — judgment about how competitive the current moment is, how time-sensitive the opportunity is, how confident I am in the profit estimate, how much risk I am willing to accept.

And there is a deeper problem. The tip floor data tells me about the aggregate market. The average level of competition across all bundles. But my specific bundle is not competing against the average. It is competing against the specific set of bundles that target the same opportunity, in the same slot, within the same auction tick. The aggregate data is a weather report. What I need is a hyper-local forecast for my specific block of the city.

If I spot an arbitrage opportunity between Pool A and Pool B, and three other searchers also spot it and are constructing their own bundles right now, the effective competition for my specific bundle is much higher than what the aggregate percentiles suggest. Conversely, if I spot an obscure opportunity that nobody else notices, the effective competition is near zero — even if the aggregate percentiles are showing elevated values because of intense competition on other opportunities.

The tip floor data is the weather report. It tells me the general conditions. But my bundle lives in a specific microclimate.

What About 95% Validator Adoption?

One detail that shapes how I interpret the tip floor data: approximately 95% of Solana's stake (as of April 2025) runs on the Jito validator client. This is not 50%. Not 70%. Ninety-five percent.

This means that the tip market reflected in the Tip Floor API is not a niche sidecar market. It is the primary market. Nearly every slot is led by a Jito validator. Nearly every block is produced by a validator that participates in the tip economy. The data from the Tip Floor API does not describe a small, specialized corner of the Solana block production pipeline — it describes the dominant mechanism.

This matters for interpreting the percentiles. If only 30% of validators ran Jito, the tip data would describe a fragmented market — some slots would use the tip mechanism and some would not, and the percentile distribution would be noisy, reflecting the unevenness. But at 95% adoption, the market is nearly universal. The percentiles describe a consistent, market-wide phenomenon. They are, in a statistical sense, representative.

It also means that the tip market is mature. It is not a nascent experiment that might change radically next month. Ninety-five percent adoption means the economics have settled. Validators have chosen to participate because the tips represent meaningful revenue. Searchers have adapted their strategies to the tipping mechanism because it covers nearly all block production. The rules of the game are established.

This does not mean the specific tip levels are stable — those fluctuate constantly with competition, as the percentiles show. But the mechanism itself is stable. The infrastructure is reliable. The data is meaningful. This is not a beta API that might disappear. This is the operating system of Solana MEV.

Five Numbers and a Slot

I step back and look at what I now have. Five percentiles. One slot number. Updated in real time via WebSocket or on-demand via REST. A window into the competitive landscape of the Jito auction system.

The data is not a crystal ball. It does not predict the future. It does not tell me what tip will win the next auction. It does not tell me who my competitors are or what they are doing right now. It is backward-looking, aggregate, and subject to the same survivorship bias as any market data that only tracks winners.

But it is the first real market data I have encountered in this entire journey. Up until now, I have been working with on-chain data — pool states, token balances, price ratios. That data tells me about opportunities. The tip floor data tells me about competition. Opportunities and competition are two completely different axes. Knowing that an arbitrage opportunity exists and knowing what it costs to capture that opportunity are different questions, answered by different data sources.

Think of it this way. A stock screener tells me which stocks meet my criteria. Undervalued. High momentum. Whatever filters I set. That is the opportunity data. But the bid-ask spread tells me what it will cost to actually trade those stocks. A stock might look amazing on a screener but have a spread so wide that the transaction cost eats the entire expected return. The screener and the spread are both essential. Neither alone is sufficient.

The on-chain data is my stock screener. The tip floor data is my bid-ask spread. Together, they start to form something approaching a complete picture of whether a given arbitrage is worth pursuing — not just in terms of the gross profit from the price discrepancy, but in terms of the net profit after paying the cost of competing for inclusion.

I have been flying with one instrument for months. Now I have two. The cockpit is still sparse. There are gauges I wish I had — real-time competitor analysis, per-opportunity competition density, forward-looking tip prediction. But two instruments is twice as many as one. And in a game where I have been stumbling through zero percent landing rates, any additional source of information is valuable.

Five numbers and a slot. That is what the Tip Floor API gives me. It is not enough. But it is a start.