RFQ Versus Pool Fills: Two Different Contracts, Not Two Prices
A pool will always trade with you at a price determined by a formula. A market maker will trade with you at a price it chose, if it still wants to. Comparing the two on output alone misses the fact that you are comparing an obligation with a decision.
An RFQ fill and a pool fill differ in what they guarantee, not in what they cost. A constant-product or concentrated-liquidity pool is an obligation: submit a valid instruction and the program will trade with you at the price its formula produces, always, with no discretion. A request-for-quote fill is a decision: a market maker looks at your order and chooses whether to take the other side at the price it named. Everything else follows from that distinction.
Traders compare the two by reading two output numbers side by side, which is the one comparison the structure does not support. The pool's number is a function evaluated at a state. The maker's number is a commercial offer with conditions attached, some of which are visible and some of which are not. A better output from a party that can withdraw is not straightforwardly better than a worse output from a party that cannot.
What each side actually promises
Strip both mechanisms down to the commitment and the difference becomes obvious.
The commitment in each case
- Pool fill
- The program will execute against whatever reserves exist at the instant of execution, using a published formula, for anyone who calls it. It has no view of who you are, no inventory preference, and no ability to refuse. Its price moves only because state moved.
- RFQ fill
- A named counterparty offers a price for a specific size, valid under conditions it sets. It has a balance sheet, a hedging cost, an opinion about the pair, and in many designs a window in which it can still decline. Its price reflects all of that.
Because the pool cannot refuse, its risk to you is entirely about state changing between your quote and your execution. Because the maker can refuse, its risk to you is about selection: the cases where it declines are systematically the cases where trading with you would have been unprofitable for it, which are often the cases where you most wanted the fill.
The maker problem behind every quote
A market maker quoting your order is solving a specific problem, and understanding it explains most of what quotes do. When it fills you, it holds inventory it did not choose. It must either hedge that inventory somewhere else, hold it and accept the risk, or find offsetting flow. Each of those has a cost, and the quote is that cost plus a margin plus a charge for the risk that you know something it does not.
That last component is the interesting one. Makers price adverse selection: the possibility that the reason you are selling is that the price is about to fall. Flow that is uninformed on average earns a tighter quote than flow that is informed on average, which is the entire economic basis for order flow segmentation. It is also why the same maker can quote two identical orders differently depending on where they came from.
Nothing about that is unique to crypto. What is unusual on Solana is that the settlement leg is transparent even when the quoting leg is not. The swap that results from an RFQ is an ordinary transaction and can be opened on an explorer like any other, so the fill is auditable even where the quoting logic that produced it is proprietary. The transaction and account model documented at solana.com/docs is what makes that half-visibility possible.
Last look, and what its presence means
Last look is a maker's right to decline a trade after seeing that you accepted its quote. It exists in foreign exchange markets, it exists in some crypto RFQ designs, and it is neither a scandal nor a trivial detail. It is a specific transfer of optionality from you to the counterparty, and it has a price that shows up as a tighter quote.
| Property | Firm quote | Quote with last look |
|---|---|---|
| Who holds the option | You, briefly | The maker, during the window |
| Effect on the quoted price | Wider, because the maker carries the risk | Tighter, because you carry it |
| Behaviour in calm conditions | Fills | Fills |
| Behaviour when the price moves against the maker | Fills anyway | May be declined |
| What you experience on a decline | Not applicable | A retry into a market that has already moved |
| What to measure | Realised price | Realised price and decline rate together |
The correct response to last look is not avoidance. It is measurement. A tighter quote that fills nine times out of ten may be better than a firmer quote that fills every time, or it may not, and the only way to know is to record both the price and the outcome of every attempt, including the ones that did not happen. A venue that reports average executed price without reporting decline rate is reporting the numerator of a fraction.
The comparison that matters
Set output aside and compare the two contracts on the properties that actually differ.
| Dimension | Pool fill | RFQ fill |
|---|---|---|
| Counterparty | The pool, and by extension its liquidity providers | A named or pseudonymous market maker |
| Price formation | Deterministic function of reserves | Commercial judgement, refreshed continuously |
| Right to refuse | None | Present in some designs |
| Cost visible on chain | Pool fee, fully visible | Spread, embedded and not decomposable |
| Behaviour at larger size | Degrades along a known curve | Depends on maker inventory and appetite |
| Information leakage | Only at execution | At quote request, to every maker polled |
| Failure mode | Revert against your minimum output | Decline, expiry, or no quote returned |
| Auditability after the fact | Complete: state and formula are public | Partial: the fill is public, the reasoning is not |
The row about information leakage deserves emphasis because it is the one with no analogue in pool trading. Requesting a quote for a large size tells every maker polled that a large order exists, whether or not any of them win it. Losing makers now hold a piece of information they did not have, and they are under no obligation to ignore it. In a design where quotes are requested from many parties, the request itself is a broadcast.
Why size flips the answer
Pool cost grows with size along the curve of the invariant, which is convex: doubling the order more than doubles the impact component. A maker's cost grows with size too, but for a different reason, namely its hedging cost and the inventory it must carry, and that relationship is not necessarily convex over the range you care about. Where the two curves cross is where the answer changes.
This produces the pattern most desks observe qualitatively. Small orders on liquid pairs are usually fine against pools, because the impact term is negligible and the pool fee is the whole cost. Very large orders on thin pairs are where a maker can genuinely improve on the pool, because the maker prices its own risk rather than mechanically walking your order up a curve. The awkward middle is where the answer depends on the day.
A useful way to hold this: a pool charges you for the shape of its curve, and a maker charges you for its opinion. When the curve is punishing and the opinion is calm, the maker wins. When the curve is flat and the opinion is nervous, the pool wins.
Where pool fills remain the better contract
There are cases where the deterministic contract is preferable even at a worse headline price, and they are worth stating explicitly because routing interfaces rarely surface them.
- When certainty of execution matters more than the last few basis points. A pool that cannot refuse is worth something when the alternative is a retry into a moved market.
- When you need the trade to be reconstructible. Pool fills can be verified against public state; a spread cannot be decomposed after the fact.
- When the pair is new or thinly covered. Makers quote what they can hedge, and coverage of long-tail pairs is uneven.
- When you do not want to reveal size. A pool learns your order at execution; a quote request tells several parties in advance.
- When you are running a repeated schedule. Deterministic pricing produces comparable data across attempts; discretionary pricing does not.
That last case is where post-migration AMM trading tends to concentrate. Once a token has graduated to a standard pool and the depth is public, a desk that wants comparable numbers across a long sequence of orders will often prefer the formula to the negotiation, which is why tooling aimed at pool activity, such as a Raydium volume bot, is built around pool state rather than quoted counterparties. Determinism is not a virtue in itself, but it is a precondition for measurement.
The same order under both contracts
Illustrative arithmetic with stated assumptions, not observed data. Assume a pair where the pool charges 25 basis points and your order would create 40 basis points of impact on the available depth. A maker quotes the same order at 45 basis points inside the pool's effective price, with a last-look window and an assumed decline rate of one attempt in ten.
| Line | Pool route | RFQ route |
|---|---|---|
| Cost per successful fill | 0.65% | 0.20% |
| Attempts that fill | 10 of 10 | 9 of 10 |
| Assumed adverse drift on the retried attempt | 0.00% | 0.50% |
| Cost of the retried attempt | n/a | 0.70% |
| Average cost across ten attempts | 0.65% | 0.25% |
On these assumptions the quoted route wins comfortably. Now change one input: assume declines cluster in exactly the conditions where the market is moving, so the drift on a retried attempt is 2.0% rather than 0.5%. The average cost of the RFQ route rises to roughly 0.40%, still ahead but by less than half the original margin. Push the decline rate to three in ten with the same clustering and the two arrangements converge.
The lesson is not that one route is better. It is that the ranking is dominated by two numbers most traders never record: how often the quoted route declines, and what the market did in the moment it declined. A desk that runs enough flow to care about basis points and uses a professional Solana volume bot to keep its order schedule constant is in a much better position to record those two numbers than one that trades ad hoc, because only a constant schedule makes the comparison fair.
A decision procedure you can repeat
Rather than choosing once, encode the decision. The following sequence takes a few minutes per pair and does not require any private data.
- Establish the pool baseline. Compute what the pool alone would cost for your size at current depth, fee tier included. This is your reference contract.
- Request the quote and record it, whether or not you trade. The spread against the pool baseline is the maker's asking price for taking the other side.
- Ask whether last look applies. If the documentation does not say, assume it might and plan to measure the decline rate.
- Decide what a decline costs you. If a retry is cheap because the pair is calm, tolerate declines. If a retry is expensive, weight firmness heavily.
- Check the leakage cost. If your size is large relative to the pair and the design polls many makers, treat the request itself as information you are giving away.
- Log the outcome with its attempt. Store the quote, the result, the timestamp and the transaction signature together, or the record is not usable later.
- Re-evaluate on a schedule, not on a bad fill. One disappointing trade is noise. A shifted decline rate over fifty attempts is a signal.
Aggregator documentation such as the quote and swap endpoints described at docs.jup.ag shows what parameters a routing service exposes, which is the practical way to find out whether quoted counterparties are part of a given path and whether you can exclude them. If a parameter to exclude a fill source exists, the source exists.
What to hold onto
Two contracts, two failure modes, one honest comparison. The pool cannot refuse you and charges a published fee for that certainty. The maker can refuse you and charges an unpublished spread that already prices its opinion of your flow. Neither arrangement is exploitative and both are ordinary, but only one of them can be fully reconstructed after the fact, and that asymmetry should inform how much of your measurement effort you spend on each.
If you take one operational habit from this page, make it recording declines. Executed prices are easy to collect and systematically flattering, because they exclude every case where the counterparty chose not to trade. The distribution you actually live in includes those cases, and it is the only distribution worth optimising against.