Quote vs Fill: Why Your Swap Landed at a Different Price

Your swap landed at a different price than the quote because the two numbers are separate readings of the same pool, taken at different moments. The quote is a projection built from reserves at a recent slot. The fill is what the on-chain program computes from the reserves that exist at the instant your transaction executes. Everything below is about what happens in the gap between those two moments, and which parts of it you control.

What happens between a quote and a fill

It helps to see the whole path once, because most confusion comes from imagining a quote as a reservation. It is not. Nothing is held for you, no price is locked, and no counterparty has agreed to anything. A quote is a calculation someone ran on your behalf against state they had recently read. The only part of it that becomes binding is a single number written into the instruction you sign.

1. You request a route. The interface asks a quote service for the best way to convert input token A into output token B for a given input amount.
2. The service reads pool state. It pulls reserves, fee tiers and tick or bin data for candidate pools as of some recent slot, then simulates the trade across one or several routes.
3. It returns two numbers. An expected output, which is a projection, and a minimum output, which is the expected output reduced by your slippage tolerance.
4. You sign. Your wallet signs a transaction containing the swap instruction, the route, the minimum output and a recent blockhash.
5. The transaction is forwarded. Your RPC provider relays it toward the validator currently producing blocks, and often toward the next ones in the schedule.
6. It competes for inclusion. The block producer selects and orders transactions. Yours may be included in the next block, several blocks later, or never.
7. The program executes. At execution the swap program reads the pool account as it is right then, computes the output from those reserves, and compares it to your minimum.
8. The result settles. Either token balances change and the transaction succeeds, or the instruction reverts and only fees are consumed.

Notice which step contains the price you were shown. Step three. Notice which step contains the price you receive. Step seven. Between them sit signing latency, network relay, block production and the ordering decisions of whoever is producing that block. The expected output never travels on chain in any enforceable form. Only the minimum does, and it functions as a floor rather than a target.

Every point where a quote goes stale

Staleness is not one event. It accumulates in layers, and each layer has a different fix, which is why a single setting rarely solves a persistent fill problem. Work through them in order and you can usually name the layer that is hurting you.

• Read lag. The quote service read the pool at a slot that was already committed. By the time the number renders in your browser it describes the past, not the present.
• Decision time. The seconds between the quote appearing and you pressing the button. On a fast-moving pair this is often the largest single contributor, and it is entirely within your control.
• Signing and relay. Hardware wallet confirmations, extension prompts and the hop to your RPC endpoint all add wall-clock time before the transaction is even in flight.
• Inclusion delay. Once forwarded, the transaction waits for a block producer to pick it up. Under load this wait can span many slots, and the pool keeps trading throughout.
• Retries. Clients commonly rebroadcast the same signed transaction until it lands or expires. Every retry is an attempt to execute an old projection against newer state.
• Ordering inside the block. Even at the moment of inclusion, other transactions in the same block can touch the same pool ahead of yours and change the reserves your instruction reads.

The outer bound on all of this is the blockhash. A transaction references a recent blockhash that remains valid for 150 slots; past that window the transaction can no longer be processed and simply expires. That gives you a hard ceiling of roughly one minute at the target slot time, but treating one minute as your quote's shelf life is a mistake. The economically meaningful shelf life on an active pair is a small number of seconds.

Slot timing and the 400 millisecond target

Solana targets a slot time of about 400 milliseconds. Traders often read this as a guarantee that little can change between quote and fill. That reading confuses the clock with the content. A slot is a time box for producing a block, not a limit on how much activity fits inside it. A single block can contain a large number of transactions, and several of them can touch the pool you are trading against.

So there are two independent clocks to think about. The first is how many slots elapse between the state your quote was built from and the state your transaction executes against. The second is how many pool-touching transactions are ordered ahead of yours inside the block that includes you. The first is a latency problem. The second is an ordering problem, and no amount of speed on your side fully removes it.

This is also why a quote that refreshes every few seconds is not an interface annoyance. It is the interface telling you, correctly, that the previous number has expired. If you find yourself signing a quote that has been on screen for twenty or thirty seconds, the mismatch you are about to see is not a bug in the router.

Competing flow in the same pool

On a constant-product automated market maker, price is a pure function of the two reserve balances. Nothing else sets it. That makes the mechanism easy to reason about: anyone who trades before you leaves the pool at a different point on the curve, and you inherit that point.

Two things are worth extracting from that. First, the shortfall was not caused by the router being wrong; the router was right about the state it saw. Second, the shortfall scales with how much size arrives ahead of you relative to pool depth, which is why the same tolerance behaves completely differently on a deep pair and a thin one. The general relationship between size, depth and cost is covered in our full breakdown of slippage on Solana.

Failure versus a worse fill inside tolerance

These are two different outcomes with two different remedies, and traders routinely diagnose one while suffering the other. The deciding number is the minimum output written into your instruction. If the program can deliver at least that amount, the swap succeeds at whatever price the reserves produce. If it cannot, the instruction reverts and you keep your input tokens.

A revert is not free. The transaction was still signed, transmitted, included and processed, so the base signature fee of 5000 lamports is consumed, along with any priority fee you attached. Since SOL carries nine decimals, that base fee is 0.000005 SOL per signature. It is small individually and not small when you are failing repeatedly on a pair you have not sized correctly.

Read the last column carefully. Raising tolerance from 2 percent to 5 percent did not make this particular fill worse. What it did was widen the range of outcomes the transaction would have accepted without complaint. That unused headroom is the difference between what you would have taken and what you must take, and it is exactly the quantity that reordering strategies aim at, which is the subject of how the sandwich pattern works on Solana.

Partial fills: AMM pools versus order books

On a pool swap there is no such thing as a partial fill in the order-book sense. The instruction either moves the full input amount and produces at least the minimum output, or it reverts. There is no mechanism for the program to take half your input, deliver half the tokens, and hand the rest back. Any interface language about partial execution on an AMM route means something else.

What it usually means is a split route. An aggregator can send portions of one order through several pools inside a single transaction. Those legs are still atomic together: if any leg cannot satisfy its constraints, the whole transaction reverts and nothing settles. So a four-leg route does not give you four chances to fill; it gives you four ways to fail, which is one reason longer routes fail more often than short ones.

Limit-order venues behave differently because resting liquidity is discrete. An order can match against part of the book, fill for what is available, and leave the remainder resting or cancel it, depending on the order type. That is a genuine partial fill, with a genuine remainder you can act on. If you are used to that model, the all-or-nothing behaviour of a pool swap reads as a malfunction when it is simply a different settlement rule.

Symptom to cause: a diagnostic table

Most execution complaints reduce to a handful of mechanisms. The table below maps the symptom you observe to the cause that most often produces it, the evidence that confirms it, and the change that addresses it. Work from the symptom column and confirm before you change anything, because two of these symptoms have opposite fixes.

Reading your own transaction on an explorer

Guessing is expensive. A signature contains almost everything you need to reconstruct what happened, and reading one takes a couple of minutes once you know the order to read it in. Do this for your next three surprising fills and the pattern will usually be obvious before you finish the third.

1. Confirm the status. Establish whether the transaction succeeded or failed, and if it failed, capture the program error rather than the interface message.
2. Note the slot. Record the slot that included the transaction and compare it with when you requested the quote. That difference is your staleness budget for this trade.
3. Read pre and post token balances. Every token account touched has a before and after amount. The difference for your output mint is your realised fill, independent of any label the interface used.
4. Find the minimum output. Locate the enforced floor in the decoded swap instruction and compare it with the realised amount. The distance between them tells you how close you came to reverting.
5. Expand the inner instructions. A routed swap shows one inner transfer pair per leg. This is where a split route becomes visible, and where you can see which venue actually produced most of your output.
6. Check compute units consumed. Compare consumed units against what the transaction requested, remembering the 1.4 million unit ceiling per transaction. Long routes that sit near their requested limit fail for compute reasons that look nothing like slippage.
7. Check the fee paid. Separate the base signature fee from any priority fee. On a failed transaction this is your entire cost, and summing it across attempts is the honest price of a tolerance that is too tight.
8. Look at neighbouring activity. Scan the same pool in the same and preceding slot. Ordinary competing flow and deliberate reordering both appear here, and you cannot tell them apart from your own transaction alone.

What to change, in order

The reason to fix these in sequence is that the cheap changes remove most of the problem, and the expensive change makes every remaining problem worse if you apply it first. Widening tolerance is the expensive change: it converts failures into fills, but it also converts a narrow band of acceptable outcomes into a wide one.

• Shorten the time between the quote you see and the signature you produce.
• Size the order against pool depth, not against how much you want to trade today.
• Split large orders into clips and let each clip get its own fresh quote.
• Make sure a transaction that fails to land is diagnosed as a landing problem, not a slippage problem.
• Only after the above, adjust tolerance, and adjust it in the smallest step that clears the pair.
• Verify every change against explorer data rather than against how the next fill felt.

Items one and three are where manual execution loses the most ground, because nobody re-quotes and signs the tenth clip as carefully as the first. Closing that particular gap is the narrow job a Solana trading volume bot does, and the thing to check in any such tool is how old its quote is at the moment of signature, not what it claims about output.

None of this eliminates the gap between quote and fill. The gap is structural: a public pool keeps trading while your transaction is in flight, and no interface can promise you a price it does not control. What you can do is shrink the window, shrink the order, and stop paying for headroom you never needed. The rest of the execution basics section builds out each of those levers in turn.

Frequently asked questions