Order Flow
Execution tools

Third-party console, opens in a new tab.

Where your Solana order actually goes

Between your signature and your fill there is a quote service, a forwarder and a block producer, and each of them has a business model. Order Flow names those parties, explains the arrangements between them, and states who pays for each one.

This desk assumes you already understand slippage and price impact. It starts one level up, at RFQ fills, order flow auctions, private submission paths and the cost of sandwich defence.

The console linked above is a third-party product. It appears here because readers who care about routing arrangements usually want to see what execution software does with them, and for no other reason.

The five handoffs, and who is paid

01 Quote construction A service reads state and builds a route. Paid by an explicit fee, an embedded spread, or neither.
02 Counterparty selection A pool that cannot refuse, or a maker that can. Paid through the pool fee or the quoted spread.
03 Forwarding An RPC endpoint or relay holds your signed transaction first. Paid by subscription, or by whoever wants the flow.
04 Auction, where one exists The right to interact with your order is sold. Funded entirely by the value your order creates.
05 Inclusion and ordering A block producer decides position. Paid in protocol fees, and in tips where that arrangement applies.

Each row is unpacked in order flow routing on Solana.

Arrangements, not opinions

Every commercial structure covered here is described the same way: what is being sold, who buys it, who is paid, and what the trader gives up in exchange. If any of those four cannot be stated, that gap is reported rather than filled in.

Pool fills

A program that trades with anyone at a published formula. No discretion, no refusal, fully reconstructible after the fact from public state.

Compare the two contracts

Quoted fills

A market maker that names a price for your specific size and may retain the right to decline. Tighter quotes, discretionary behaviour, an embedded spread.

See where the money comes from

Private paths

A submission route that reduces who sees the transaction before inclusion, at the cost of tips, throughput and a concentrated dependency.

Read the cost breakdown

Two sections and a reference page

Routes covers who your order meets. Protection covers what you can close and what closing it costs. The questions page answers everything that did not need two thousand words.

Routes

The path from signature to fill, the two contracts a fill can take, and the auctions that decide who gets to be your counterparty.

Open the routes section

Protection

Private submission, the four layers of sandwich defence and their interactions, and how to assess the business you handed the order to.

Open the protection section

Questions

Twelve compact answers: who chooses your route, whether priority fees defend anything, and whether any of it matters at small size.

Read the questions

When execution software earns its place

Nothing on this site argues that a tool trades better than a person. The argument is narrower and harder to dispute: an arrangement can only be evaluated if it is applied identically across many orders, and people do not apply anything identically across many orders.

A desk that changes its endpoint on Tuesday, its constraint on Wednesday and its size on Thursday has produced three weeks of data that cannot be compared with anything. Software holds a configuration still, which is the boring precondition for every measurement described here.

See the execution console

Consistency is what makes a comparison fair. Same pair, same size distribution, same window, one variable changed.

Attempts are the denominator, not fills. A log that records only successes will flatter every fragile configuration you ever run.

Distributions beat averages. A slightly worse mean with a much thinner tail is usually the better arrangement.

How this desk works

A short statement of method, because the subject attracts a lot of confident numbers that nobody can source.

What we publish

Descriptions of arrangements, drawn from public documentation and from the transaction record. Where a service is named, it is named because its mechanism is documented, and the description stops where the documentation does.

What we never publish

Fill statistics we did not produce, price improvement percentages, latency measurements, review scores or rankings of named services. If a number is not a protocol constant or clearly labelled illustrative arithmetic, it does not appear.

Where the limits are

We cannot see the counterfactual, so nothing here claims one arrangement produced a better outcome than another would have. We describe structure and incentive, and leave outcome measurement to your own logs.