# Who is holding your tokens at each step of a swap

> Canonical: https://blazephoenix.xyz/learn/where-your-tokens-are-during-a-swap
> License: CC BY 4.0 (attribution + link) · © 2026 BlazePhoenix
> Updated: 2026-08-13

A swap traced instant by instant, naming the holder at every step: nothing moves until the router pulls your tokens using the allowance you wrote, the pools hold them one leg at a time, and the floor check at the end decides settlement — all inside one atomic transaction with no pause a human could act in, which is why a failed swap cannot leave you halfway through.

You press a button and, some seconds later, one token has become another. In between, your tokens exist somewhere, held by someone, under some rule. This article names the holder at every instant, because that is the only honest way to answer the question people actually mean when they ask whether a swap is safe.

Everything below assumes the previous article: your balance is a row in the token contract, and an allowance is a ceiling you wrote permitting a contract to move up to some amount of it. We now spend that allowance.

## Before you press anything

You hold 100 of token A. The interface shows you a quote for token B. That quote was computed by asking a contract, at a recent block, what a trade of 100 would return. Nothing has been reserved, nothing has been locked, and no one has touched your row. A quote is a calculation, not a commitment.

Two rows exist that concern you: your balance of A, and the allowance you granted to the router for A. If the allowance is smaller than 100, the swap cannot pull your tokens, and your wallet will ask for an approval transaction first. That approval, again, moves nothing.

## Step one: the transaction is signed and broadcast

You sign. At this instant you still hold all 100 tokens. The signed transaction goes to the network and waits to be picked up and put into a block.

This waiting room is public. Anyone watching can see that you intend to trade 100 of A for B, and at what minimum. That visibility is the origin of front-running, and it is worth naming here rather than at the end: it cannot be prevented by any contract, because the contract does not exist until the transaction runs. What a contract can do is bound the damage, which is the subject of the article on minimum output.

Nothing is charged yet. If the transaction never gets included, your balance never changes.

## Step two: the router pulls your tokens

The block producer includes your transaction and the code runs. Its first act is to call the token contract and move 100 of A from your row to the router contract, using the permission you wrote earlier.

Two numbers change in the same instant: your balance of A falls by 100, and your allowance for the router falls by 100 — unless you granted the unlimited value, in which case it stays where it was.

From this moment until the end of the transaction, the router holds your 100 tokens. This is the interval people are really asking about. Note what "holds" means: no person can act during it. The whole transaction is executed by one machine, in one step, with no pause in which a human could intervene. There is no window between step two and step six.

## Step three: the tokens go to the pools

The router now sends your tokens into one or more pools, according to the plan the quote produced. If the plan splits the order, it sends the pieces to different pools; if it routes through an intermediate token, the output of one pool becomes the input of the next.

Each pool holds your tokens for the duration of its own leg and gives back the output its formula requires. Those pools are not ours. They are third-party contracts holding third-party liquidity, and this is a genuine risk surface: routing through a pool means executing that pool's code.

What limits the exposure is that the router does not choose pools by reputation. It quotes them on-chain, against their real balances, and a pool that cannot deliver what it advertised fails the checks that come next.

## Step four: the router counts what actually arrived

Here is the distinction that separates a careful router from a careless one. After each leg, the router does not assume it received the amount the pool said it would send. It reads its own balance before and after, and takes the difference as the amount received.

Why this matters can be shown with a number. Suppose a pool reports sending 90.66 tokens, but the token itself takes 1% on transfer, so 89.75 actually arrives. A router that trusts the report is now working with 90.66 tokens it does not have, and every subsequent number it computes is wrong — including the amount it promises you. A router that measures works with 89.75, which is the truth.

The general form of the rule is worth keeping for everything else you read about DeFi: trust the measured quantity, never the nominal one.

## Step five: the floor check

With the final amount measured, the contract compares it against a minimum. Two minimums apply, and both must hold.

The first is yours: the amount you accepted when you set your slippage tolerance. The second is the protocol's own, and you cannot switch it off. Each leg of the route must return at least 8,000 basis points — 80% — of what the chain itself quoted for that leg immediately beforehand, and the aggregate floor is clamped so that it can never fall below 80% either. The reference is the on-chain quote for the last hop, taken before the protocol fee is applied.

Be exact about what 80% is for. It is not a good deal; it is a catastrophe stop. A route that delivers 81% of its own on-chain quote is a terrible fill that the protocol will still execute. The number that protects your wallet in ordinary conditions is the tighter one you set yourself.

If either floor fails, the transaction reverts.

## What "reverts" means, and why it is the whole safety story

A revert is not a partial trade or a refund. The chain undoes every state change the transaction made, as though it had never run. Your 100 tokens of A are back in your row, the pools are back to their prior balances, and the allowance decrement is undone with everything else.

What you do not get back is the chain fee, because the network did the work of running the code and finding out that it failed. That is the honest cost of a failed swap, and it is the reason this article quotes no gas figures anywhere: a gas number is not reproducible without stating the chain, the block, the build and whether the storage was warm or cold, and a number you cannot reproduce is a number you should not be given.

So the interval in step two, where the router holds your tokens, has this property: either all six steps completed and you hold your output, or none of them did and you hold your input. There is no state in which the router has your tokens and you have nothing.

## Step six: you are paid, and the fee is taken

The router keeps 28 basis points of the output — 0.28% — and sends you the rest. On an output of 90.6611 tokens the fee is 90.6611 x 0.0028 = 0.2539, and you receive 90.4072. That constant has no setter anywhere in the contract, which means it cannot be raised on you later.

One residue remains after everything settles: your allowance. If you approved an exact amount, it is now spent to zero. If you approved the unlimited value, the router can still move your A tokens tomorrow. Nothing in this transaction cleaned that up, and nothing will unless you do it.

**Verify it yourself:** Open your swap transaction on a block explorer and read the Token Transfers list. Every movement in the six steps above is one line: your address to the router, the router to each pool, each pool back, and the router to you. Count them and compare with the route the quote showed you.

Related: https://blazephoenix.xyz/learn/signing-vs-sending · https://blazephoenix.xyz/learn/three-prices · https://blazephoenix.xyz/learn/minimum-output-explained · https://blazephoenix.xyz/learn/what-is-a-transaction · https://blazephoenix.xyz/learn/measured-not-nominal