Order Flow Routing on Solana: Where a Signed Order Actually Goes

Order flow routing on Solana is the decision about which party gets the chance to trade against your order, made before the transaction reaches a block producer. That decision is taken by a quote service, encoded in the instruction you sign, and carried out by whoever forwards your transaction. Three separate businesses sit on that path, and each of them can be paid.

The word routing suggests a map. It is closer to a chain of custody. Between the moment you approve a swap and the moment token balances change, your order passes through a quote service that decided its shape, an RPC endpoint or relay that decided where to send it, and a validator that decided whether to include it and in what position. Every one of those parties has an economic interest, and none of them is obliged to explain it to you unless they choose to.

The path, stated once

Here is the whole sequence, without abstraction. Read it once and the rest of this site becomes a set of footnotes to it.

1. You express an intent. An interface takes a pair, a side and a size. Nothing has been committed and no counterparty exists yet.
2. A quote service builds a candidate execution. It reads on-chain pool state, and in some designs it also asks off-chain market makers to quote the same order. It returns a route and an output figure.
3. You sign a transaction. The signature commits you to a specific instruction set: named accounts, a named path, a minimum acceptable output.
4. A forwarder receives it. Usually your wallet's RPC provider. Sometimes a dedicated relay or a block engine offered by a third party.
5. The forwarder chooses a destination. It can push the transaction to the current leader, to several upcoming leaders, into an auction, or into a bundle alongside other transactions.
6. A leader orders and includes it. The validator producing the current slot decides what enters the block and in what sequence.
7. The program executes against live state. The swap program computes an output from the accounts as they exist at that instant and compares it to your minimum.
8. Settlement or revert. Balances move, or the instruction fails and only fees are consumed.

Steps two, four and five are the ones that carry commercial arrangements. Step two decides who is offered your order. Step four decides who learns about it early. Step five decides who profits from its position in the block. Everything called routing, protection, private submission or order flow sale is a variation on those three decisions.

Why Solana changes the shape of the problem

Solana does not maintain a shared public mempool in the way a gossip-and-auction chain does. Clients forward signed transactions directly toward the validator scheduled to produce upcoming slots, and the leader schedule for an epoch is known in advance, so a forwarder can address the next few leaders specifically. The validator client documentation maintained at docs.anza.xyz describes this forwarding behaviour and the transaction processing pipeline in detail.

Two consequences follow. First, there is no single public queue for a searcher to watch, so the observation problem becomes a question of which endpoints a transaction passes through rather than whether it is broadcast to everyone. Second, the party with the earliest and most complete view of pending orders is not the network at large but the specific infrastructure that receives them: RPC providers, relays and block engines.

That relocates the entire discussion. On Solana, asking whether your order is exposed is not a question about the mempool. It is a question about counterparties: which company runs the endpoint you send to, what they do with the transaction between receiving and forwarding it, and whether any part of that behaviour is contractually described. The base protocol documentation at solana.com/docs covers the fee and transaction model; it does not, and cannot, describe the commercial conduct of the intermediaries you choose.

The handoffs and who is paid at each

The useful discipline is to stop asking what a route costs in aggregate and start asking who receives each component. A total cost figure hides the arrangement. A per-party attribution reveals it.

Read the last row carefully, because it is the one traders misread most often. When a bidder pays for the right to fill your order, the money it bids has to come from somewhere, and the only place it can come from is the margin the bidder expects to make on that order. A rebate is therefore not free money appearing from outside the trade. It is a share of your own order's expected value, returned to you or to whoever negotiated the arrangement on your behalf.

The four ways a routing layer earns

Every routing product on Solana earns in one or more of four ways. Identifying which ones apply tells you more about a router than any headline output figure, because it tells you what the router is optimising for when the choices conflict.

None of these is illegitimate. Explicit fees fund development. Spread capture is how every market maker in every asset class has always worked. Order flow payment is a real arrangement with real economics behind it. The problem is never the existence of the model; it is a model that is not disclosed, because you cannot price a cost you cannot see.

Who can see your order before it lands

Visibility is the variable that matters for adverse selection, and it is a property of your path, not of the chain. Four groups can plausibly learn about your order before it settles.

• The quote service. It knows the pair, the size and the direction the moment you request a quote, whether or not you go on to sign.
• Any market maker asked to quote. In an RFQ design, the makers polled learn about a live intent of a specific size, including the ones that do not win it.
• Your RPC provider or relay. It holds the signed transaction before anyone else on the network does, for as long as it takes to forward.
• The leader and anything colocated with it. Whoever assembles the block sees the transaction and decides its position among competing ones.

Note what is not on that list: the general public. The absence of a broadcast queue means that on Solana the exposure surface is a list of named companies rather than an open channel. This makes the problem more tractable and more uncomfortable at the same time. Tractable, because you can enumerate your counterparties. Uncomfortable, because most traders have never audited the ones they use.

Attributing the cost of one order

The following is illustrative arithmetic with stated assumptions, not measured market data. Take a single order of 400 SOL into a mid-liquidity pair, and assume the same headline result under three arrangements. The point is not which total is smallest; it is that identical totals can conceal completely different distributions.

Three observations follow from this arithmetic. The pool-only route pays liquidity providers and the router, and nothing else; it is the arrangement with the fewest counterparties. The RFQ fill pays a market maker instead of a pool, which removes the pool fee but introduces a party whose quote you cannot decompose. The auctioned route looks cheapest here precisely because a bidder was willing to give back part of its expected margin, which means somebody at the end of that chain expects to earn more than the rebate they paid.

None of these totals is a claim about the real market. Change the assumed spread by four basis points and the ranking inverts. That sensitivity is the actual finding: at this scale of difference, an arrangement comparison is only meaningful if you can measure it repeatedly on your own flow rather than reason about it once. If you run size regularly enough that this arithmetic matters, the same measurement discipline described in how volume campaigns are measured applies to routing choices: fix a benchmark, log every attempt, and compare distributions rather than best cases.

What routing disclosure looks like

Disclosure in this context is not a legal document. It is a set of four factual statements a routing product can make, and each of them is either present in the documentation or it is not.

1. The fee statement. What is taken, at what rate, from which side of the trade, and whether it appears on chain.
2. The counterparty statement. Whether fills can come from parties other than public pools, and if so, what class of party.
3. The payment statement. Whether any third party pays for order flow, and if so, what happens to that payment.
4. The routing statement. What the router optimises: quoted output, expected output after failure, latency, or something else.

Aggregator documentation such as the developer material at docs.jup.ag is a reasonable place to see what a complete technical description looks like, including how quote endpoints are structured and what parameters change the returned route. Reading a router's own API documentation is often more informative than reading its marketing, because the parameters a service exposes reveal what it actually controls.

An operator checklist

This is the sequence a desk should be able to complete for any execution path it uses in size. It takes an afternoon once and then costs nothing to maintain.

• Name every party on the path: quote service, forwarder, any relay, and the venue class that ends up filling you.
• Write down which of the four revenue models each party uses, and mark the ones you inferred rather than read.
• Confirm whether fills can come from a quoted counterparty rather than a pool, and whether you can disable that if you want to.
• Confirm whether your forwarder can hold, reorder or duplicate a transaction, and whether it says so.
• Record the failure behaviour: when an order does not land, does the path retry, and who pays the fee for the attempt.
• Re-run the check when you change RPC providers, because that single change alters your exposure surface more than most routing settings do.
• Keep the transaction signatures. Attribution after the fact is only possible if you can open the transaction again.

Operators running continuous sequences rather than occasional trades face a different version of the same problem: the routing decision has to be identical across hundreds of orders, or the resulting data cannot be compared. That is the operational argument for automation generally, and it is the reason a desk that runs scheduled activity through a Solana volume bot tends to end up with cleaner attribution than a desk trading the same notional by hand. Consistency of path is what makes the numbers mean anything.

The point of the exercise

None of this is about finding a hidden fee to be outraged by. The arrangements described here are ordinary market structure, imported into a setting where the plumbing happens to be visible. Traditional equity markets settled these questions decades ago through disclosure regimes, and the resulting rules exist because the same conflicts kept appearing.

What is different on Solana is that the disclosure is voluntary and the verification is possible. You can open any transaction on an explorer and see what it did. You cannot see what the alternative would have been, which is why the reasoning above stays at the level of arrangements rather than outcomes. Know who is on your path, know how each of them earns, and treat every claim about price improvement as a claim about a counterfactual that nobody can produce.