A wallet previously allowed a spender to use 100 token units, and the owner decides to leave only 50. After changing the value, the owner sees the new number and expects total spending to be capped at 50. However, allowance describes the permission remaining in the current state. It is not a lifetime limit covering transfers before and after the change.
What approve changes
ERC-20 describes approve as setting a new allowance for a spender. A repeated call replaces the current value. It neither adds that amount to the old permission nor returns tokens transferred earlier. The owner, token contract and spender identify the particular relationship being checked.
- Balance
- The tokens held by the owner in the state under consideration.
- Allowance
- The amount a particular spender is still permitted to spend.
- Already completed spending
- A separate result of an earlier action. A new allowance does not undo it.
An owner's transfer and a spender's use of transferFrom are different operations. First establish what the interface is asking you to confirm: a transfer, permission for a particular contract, or something else. The word โexchangeโ does not explain the requested operation.
A teaching example with two queues
Suppose the initial finite allowance is 100 atomic units. The owner has already chosen two updates: first 0, then 50. The other party makes two spending attempts: first 100, then 50. Each queue keeps its internal order, while the two queues can interleave in different ways.
Call the owner's updates U1 and U2, and the spending attempts S1 and S2. In this model every approve successfully replaces the allowance. Spending succeeds only when the allowance is sufficient and then reduces it. An insufficient-allowance attempt is recorded as unsuccessful without changing the permission. Balance is assumed sufficient and is not modelled separately.
| Order | Successfully spent units | Final allowance | What happened |
|---|---|---|---|
| U1 U2 S1 S2 | 50 | 0 | 100 fails, then 50 succeeds |
| U1 S1 U2 S2 | 50 | 0 | The first attempt encounters zero permission |
| U1 S1 S2 U2 | 0 | 50 | Both attempts occur before the new permission |
| S1 U1 U2 S2 | 150 | 0 | 100 is spent before zeroing, another 50 after the new approval |
| S1 U1 S2 U2 | 100 | 50 | The second attempt encounters zero permission |
| S1 S2 U1 U2 | 100 | 50 | The first 100 exhausts the permission |
Why zeroing does not return earlier transfers
ERC-20 recommends that interfaces set the allowance to zero before changing it to another value. This does not make a transfer completed before zeroing disappear. In the fourth row, the first 100 has already been spent before U1. The later U2 creates the preselected new permission of 50, so successful spending totals 150 in this model.
Transaction ordering when an allowance changes is also examined in the research paper Resolving the Multiple Withdrawal Attack on ERC20 Tokens. The table is a separate, deliberately limited example. It neither reproduces a real network nor proves how every token behaves.
What the tool enumerates
Enter the initial allowance, up to three new values chosen by the owner, and up to four spending attempts. Every amount is an integer number of atomic units of one token. The tool does not convert human-readable decimals. For example, 100 here does not necessarily mean 100 whole coins, and the tool does not discover the token's decimals.
It preserves the order within each queue and enumerates only their interleavings. Two actions in each queue produce six variants; three owner actions and four attempts produce thirty-five. Amounts use exact integer arithmetic. The minimum and maximum describe only the listed variants under these rules, not possible losses from a real wallet.
Real contract details outside the model
- Special treatment of maximum allowances and nonstandard tokens.
- Insufficient balances, fees, pauses, recipient restrictions and failed approvals.
- Permit signatures, temporary permissions, batched or atomic operations.
- Mempools, gas pricing, transaction priority, cancellations and reorganizations.
The tool does not read the blockchain or inspect an address's permissions. Investigating an actual case requires the network, exact token contract, spender and confirmed operations. Do not enter private keys, seed phrases or signatures here. There are no fields for them, and explaining the mechanism does not require them.
The KOT.CASH How It Works page describes a process using a deposit address. That is no reason to assume an unrelated approve prompt belongs to your order. Compare the action with the current instructions for the order and clarify an unfamiliar request before confirming it. This article explains the meaning of an allowance; it does not ask you to grant a new one.
Compare allowance update orderings
Integer atomic units 0โ10^30. One token, owner and spender. Each queue keeps its order. Approve always succeeds and replaces permission; successful spending reduces it. Balance is assumed sufficient. No unlimited mode, permit, gas, network prediction, wallet connection or real operations. The calculation runs on your device; nothing you enter is sent anywhere.