From quote to fill: what a swap actually executes
A quote is a preview built from a particular moment. The trade only exists after a signed transaction lands, runs successfully, and changes your balances. Here is what happens between those two events.
The short answer
A swap has six useful states: quoted, built, signed, submitted, executed, and reconciled. Trading apps often compress them into one button, but each state has different evidence and different failure modes. “Quoted” means a route was found. “Submitted” means a signed transaction was sent. Only a successful onchain result means the swap filled.
The difference matters most in fast or thin markets. Pool balances can change after the quote, a blockhash or deadline can expire, a required account can be missing, or another trade can move the route beyond your protection threshold. The transaction can then fail even though the preview looked valid seconds ago.
The six-stage lifecycle
Quote
A router reads current pools and returns an expected route, input, output, fees, price impact, and protection threshold. No assets have moved and no price has been reserved.
Build
The app turns that route into chain-specific instructions or calldata, adds limits and expiry, and may add setup, approval, compute, or cleanup work.
Sign
The wallet authorizes the exact transaction presented. A signature approves this payload; it does not certify that the quote is still current or the app is trustworthy.
Submit
The signed transaction reaches an RPC, a specialized sender, validator path, or sequencer. Submitted is only a delivery state—not a successful trade.
Land and execute
The chain orders and runs the transaction against state at that moment. Limits, balances, accounts, gas, compute, and contract rules can still make it fail.
Reconcile
The receipt, logs, token balances, native balance, and fees reveal the actual fill. These wallet deltas—not the preview—belong in the journal.
What the quote knows—and what it cannot know
A router can inspect available pools and calculate an expected output for a given input. It may compare direct and multi-hop paths, split the order across venues, estimate price impact, and include known pool or platform fees. Jupiter's current order flow, for example, returns the route and a transaction to sign; execution is a separate step.
The quote cannot know the exact state that will exist when the transaction runs. A later swap can alter reserves, an account balance can change, or a pool can become unusable. That is why a transaction carries protections such as minimum output, maximum input, or an expiry. The protection converts an unacceptable fill into a failure; it does not preserve the old price.
Compare routes using the amount expected to reach the wallet after route-level costs. The route's internal amount can differ from the total wallet input or output when setup, wrapping, integrator fees, or other transfers are involved.
What the wallet actually signs
On Solana, a swap is usually a versioned transaction containing one or more program instructions plus the accounts they may read or write. The payload can include compute-budget settings, token-account creation, wrapped SOL setup, several swap instructions, and cleanup. Its recent blockhash gives it a limited validity window.
On an EVM chain such as Robinhood Chain, the wallet signs a transaction to a contract address with calldata, value, gas settings, chain ID, and a nonce. The router call commonly carries an amount limit and deadline. If the router needs permission to spend an ERC-20, an approval may be an earlier transaction or a signed permit—not part of the swap itself.
That sequencing determines whether authority survives a failure. See approvals in the execution flow for ERC-20 allowances, permits, Permit2, and Solana delegates.
A human-readable wallet preview is a convenience layer over that payload. Verify the network, destination, asset, amount, spending permission, and expected result. Use the contract-reading guide when the destination or authority is unfamiliar.
Landing is chain-specific; success is still binary
Solana
The signed transaction is sent toward the current leader through an RPC or specialized submission path. Compute limits, priority fees, and tips can affect landing strategy. Instructions execute atomically: if a required instruction fails, the transaction does not leave a partial swap, although the transaction fee can still be charged.
Robinhood Chain
The signed EVM transaction reaches an RPC and sequencer, then produces a receipt after execution. Robinhood Chain documents first-come, first-served ordering by sequencer arrival rather than a higher-fee transaction jumping the queue. A reverted call changes no swap state, but still consumes gas.
“Pending” and “confirmed” are also not accounting outcomes. A transaction may be confirmed with an error or a reverted status. Always inspect the result before treating the trade as filled.
Continue with ETH gas under pressure for EVM fee caps, nonces, and replacements, or Solana rent and token-account cash flows when native balance changes include setup and cleanup around the swap.
Where a valid-looking trade can fail
Before signing
The route disappears, the app cannot build a valid transaction, the wallet is on the wrong network, or the required balance and destination accounts do not exist.
After signing, before landing
The blockhash or deadline expires, the transaction is dropped, the nonce is replaced, submission is too slow, or fee settings are insufficient for the chosen path.
During execution
The pool moves past the amount limit, an allowance or token balance is insufficient, compute or gas runs out, a contract rule rejects the call, or another required instruction fails.
After success
The interface reports a stale status, the received asset is not the expected contract, wrapping or account flows obscure the totals, or the journal mistakes transfers and rent for trade P&L.
The evidence hierarchy
- Quote or order response: what the router expected before the signature, including the path, expiry, and protected limit.
- Signed transaction: the exact instructions or calldata the wallet authorized.
- Onchain result: success or failure, block or slot, logs, and fees paid.
- Wallet deltas: actual input spent, output received, native fee change, token-account or wrapping flows, and remaining inventory.
The journal should retain both the expectation and the result. Without the quote, you cannot evaluate execution quality. Without the onchain deltas, you do not know what you actually bought or sold. The next guide separates the movement caused by your own size from movement that occurred while the transaction was in flight: slippage, price impact, and failed swaps.
Primary sources
Reconstruct the result
Start with what landed, not what the preview promised.
Paste a public address to separate swaps, transfers, fees, approvals, and remaining balances. No wallet connection or signature is required.
Open the journal