Order Flow
Execution tools

Third-party console, opens in a new tab.

Order Flow Auctions Explained: Who Bids, and With Whose Money

An order flow auction sells a right connected to your order: the right to fill it, to sit beside it, or to trade immediately after it. Somebody pays for that right, and the money comes from the value your own order was going to generate anyway.

Order Auction Winning bid Bundle Block

An order flow auction is a market in which the right to interact with your order is sold before the order reaches a block. Bidders are searchers, market makers or integrators who expect to profit from that interaction. The winning bid is paid in SOL, and the proceeds go to whoever operates the auction and, in some designs, back to the originating trader or application as a rebate.

The mechanism is not exotic. It is the same idea as any exchange selling priority or any broker routing to a paying venue, expressed in a setting where the settlement is public. What makes it worth understanding on Solana specifically is that block production is fast, the leader is known in advance, and the auction therefore has to resolve in a very short window, which shapes what can be sold and to whom.

The mechanism in five moves

  1. An order arrives at an aggregation point. A wallet, an aggregator or an application collects signed transactions or expressed intents rather than pushing each one straight at a leader.
  2. The aggregation point offers something. Depending on the design, it offers the exclusive right to fill the order, the right to be executed adjacent to it, or simply early sight of it.
  3. Bidders value the right. Each bidder estimates what it can earn from the interaction, subtracts its costs and risk, and bids some fraction of the remainder.
  4. The auction clears. Usually within a fraction of a slot, because a stale right is worthless once the order has landed by another path.
  5. The winner executes and pays. The payment is distributed according to the operator's rules: to the operator, to the originating application, to the trader, or split.

Step four is the constraint that shapes everything. With a slot target near four hundred milliseconds, an auction cannot run for long. Short auctions favour participants with fast infrastructure and standing capital, which is why the bidder set in practice is small and professional rather than open and numerous. The validator pipeline that creates that timing constraint is documented at docs.anza.xyz.

Where the bid money comes from

This is the question that separates people who understand the mechanism from people who have only heard the word rebate. A bidder is not donating. It bids because the right is worth more to it than the bid. The value it expects has to come from one of three places, and it is worth naming them precisely.

The three sources of a winning bid

Spread the bidder earns
The bidder fills your order at a price better than its own hedge cost and keeps the difference. This is ordinary market making, and the bid is a share of that margin competed away.
Position the bidder gains
The bidder profits from acting immediately after your order, for example by rebalancing a pool your trade moved. The bid is a share of that expected profit.
Information the bidder receives
The bidder learns what is about to happen, slightly earlier than the market. The bid prices that advantage, and it is the source with the least visible mechanics.

All three are real and all three are financed by the same underlying thing: the economic value that your order creates by existing. Competitive bidding is what determines how much of that value comes back to you rather than staying with the bidder. This is why competition matters far more than the presence or absence of an auction. An auction with one serious bidder is a private arrangement with an auction-shaped interface.

Three things an auction can sell

Auction designs by what is actually being sold. The same word is used for all three in marketing, so the distinction has to come from the mechanics.
What is soldBidder earns fromTrader receivesTrader gives up
Exclusive right to fillThe spread on the fill itselfA price that competes with the pool baselineAccess to any better price the pool might have offered
Right to execute adjacentRebalancing or arbitrage after the tradeA share of the bid, if the design returns oneCertainty about who trades immediately after them
Early sight of the orderPositioning ahead of the flowUsually infrastructure, not cashInformational exclusivity, entirely

The first design is the one most people mean by order flow auction, and it is also the most defensible: a competitive process for the right to be your counterparty, with the price you receive as the scoreboard. The third is the one that deserves the most scrutiny, because the trader typically receives no cash at all and the compensation is bundled into a service they were going to pay for anyway.

Tips, bundles and block space

Auctions on Solana intersect with block production through bundles. A bundle is an ordered group of transactions submitted together, intended to execute in sequence and in full or not at all. Jito Labs operates a block engine that accepts bundles, and validators running its client software can source blocks from that engine; searchers attach tips to bundles to compete for inclusion. Those tips are a separate payment from the base and priority fees defined by the protocol itself, which are described in the fee documentation at solana.com/docs.

The distinction matters when you read a cost breakdown. A protocol fee is paid to the network under rules everybody can verify. A tip is a payment to a specific block-production arrangement, made under rules set by whoever operates it. Both leave your wallet. Only one of them is described in the chain's own specification.

It is also worth noting a piece of history, because it explains the current landscape. In 2024 Jito Labs publicly withdrew the mempool service it had been running, stating that the service was being used for sandwich activity. Whatever view you take of that decision, its effect was to remove one broadly accessible place where pending Solana transactions could be observed, and to push observation back toward the private arrangements described on this site. Structure of that kind changes by announcement, not by protocol upgrade, which is why an execution policy needs reviewing on a calendar.

What the trader gives up

Every arrangement on this site is stated with what it costs. Auctions cost four things, none of which appears in a fee schedule.

  • Time. An auction has to run. Even a short one adds latency between your signature and inclusion, and latency is exposure to price movement.
  • Exclusivity. Once a right over your order is sold, the buyer has it. You cannot simultaneously get the auction's benefit and keep an open path.
  • Information. Bidders learn about your order in order to bid on it. Losing bidders learn too, and keep what they learned.
  • Counterfactual visibility. You can see what you received. You cannot see what the winning bidder earned, so you cannot verify what share of the value came back.

The fourth is the structural one. In a competitive auction you do not need to see the bidder's margin, because competition compresses it. In a thin auction you would very much like to see it, and you cannot. This is the reason the number of serious bidders is the single most informative fact about any order flow auction, and the one least often published.

Where a rebate comes from, arithmetically

Illustrative arithmetic with stated assumptions. Suppose your order is expected to generate 12 basis points of extractable value to whoever wins the right to interact with it. Assume a bidder needs 4 basis points to cover its own costs and required return, and that competition forces it to bid away most of the rest.

Illustrative distribution of one order's extractable value under two levels of auction competition. Inputs are assumed; the arithmetic is the point, not the numbers.
LineCompetitive auctionThin auction
Value available from the order12 bps12 bps
Retained by the winning bidder4 bps9 bps
Paid as the winning bid8 bps3 bps
Kept by the auction operator2 bps2 bps
Returned to the order6 bps1 bp

Both columns describe an order flow auction. Both can be marketed with the same words. The difference between them is invisible from the trader's seat unless the operator publishes participation data, because the trader observes only the last row and has no way to derive the first. This is exactly why the useful question to ask an operator is not what rebate do I get but how many independent bidders competed for this order.

Rebates are a distribution mechanism, not a discount. Nobody hands value to a trader who was not already generating it. The honest way to describe a rebate is as the fraction of your own order's extractable value that competition forced back into your hands.

What an auction cannot sell

Auction designs are constrained by what is actually transferable, and two limits get glossed over in product descriptions. The first is that nobody can sell you certainty of execution. A winning bidder has bought a right, not an obligation that binds the chain; if it fails to execute, the order falls back to whatever path the operator defined, and that fallback is where the delay lands.

The second is that an auction cannot sell exclusivity it does not hold. Once your trade executes and pool state changes, the resulting opportunity is public and open to anyone watching accounts. Auctions distribute value from the pre-inclusion window; they have no power over the post-inclusion one. A design that promises to capture all of the value your order creates is promising something the settlement layer does not permit.

These limits explain why the strongest auction designs are narrow. They sell one clearly defined right, for one clearly defined window, with a stated fallback. Designs that expand the promise tend to expand it into territory where the operator cannot deliver, and the gap shows up as unexplained latency or silently reverted orders rather than as a stated exception.

Reading an auction operator terms

Operators vary enormously in what they publish. These are the items worth looking for, roughly in order of how much they change your assessment.

  1. Bidder access rules. Is participation open, permissioned, or effectively limited to affiliates of the operator.
  2. Clearing rule. First price, second price, or discretionary. Discretionary clearing means the published rule is not the rule.
  3. Distribution formula. What fraction of the winning bid reaches the trader, the application, and the operator, stated as a formula rather than an example.
  4. Non-winning bidder handling. What losing bidders are permitted to do with what they saw.
  5. Failure treatment. What happens when the winner fails to execute: does the order fall back to a public path, and who eats the delay.
  6. Opt-out. Whether a trader can decline participation entirely, and whether declining changes their fee.

An operator that publishes all six is telling you something meaningful. An operator that publishes a rebate figure and nothing else is telling you something meaningful too. Neither is proof of conduct, but the shape of the disclosure correlates with the shape of the business.

The roles, named plainly

Auction discussions collapse into jargon quickly. Five roles cover almost everything.

Who is who

Originator
The trader or application whose order creates the value being auctioned. Receives a rebate in some designs and nothing in others.
Aggregation point
The wallet, aggregator or relay that collects orders and runs or feeds the auction. Its incentive is to maximise the total bids it can attract.
Bidder
A searcher or market maker buying the right. Its incentive is to bid the minimum that still wins, which is why competition among bidders is the whole game.
Block engine
The infrastructure that turns a winning bid into an ordered set of transactions delivered to a block producer.
Validator
The party producing the block, paid in protocol fees and, where the arrangement exists, in tips attached to bundles.

Once those five are separated, most confusing claims become easy to parse. When a product says it protects you from MEV, ask which role it occupies. When it says it returns value to users, ask which role pays and which role receives. And when a desk generates continuous predictable activity rather than occasional trades, note that this flow is exactly what bidders value most, whether it comes from a market maker's hedging programme or from a SOL volume bot running a scheduled sequence. Predictable flow is a product, and someone is always willing to price it.

The takeaway

Order flow auctions are neither a scam nor a gift. They are a distribution mechanism for value that your order was always going to create, and their fairness is determined almost entirely by how many independent parties are competing to buy it. Judge them on bidder count, clearing rule and distribution formula, and treat any rebate figure quoted without those three as a marketing number rather than an economic one.

For a trader, the practical stance is unglamorous. Find out whether your path routes into an auction at all. Find out who runs it. Find out whether you can leave. Most execution disappointments come not from being auctioned but from being auctioned without knowing it, which removes your ability to price the arrangement at all.

Filed under Routes by The Order Flow Desk. Any figure used here is either a protocol constant or arithmetic labelled as illustrative; the desk publishes no measured fill data of its own. Scope and method are set out on the desk page.

Read next