An ERC-20 token approval authorises a specified spender to move tokens from an owner’s balance within the permitted amount. It is a permission record, separate from a completed token transfer. The token standard’s approve, allowance and transferFrom functions explain why reviewing a purchase alone may leave a spending permission unexamined. Ethereum ERC-20 token standard
Follow the evidence
Trace how the event could reach markets, then inspect a competing explanation.
Compare explanations
Switch lenses to see what each account explains—and what remains uncertain.
WFN analysis: consider a hypothetical transaction in which a user permits a contract to spend 1,000 units and then makes a 100-unit purchase. The purchase receipt establishes one action; it does not by itself establish that every permission associated with the interaction has ended. The actual remaining allowance must be read from the relevant token contract and owner-spender pair. The contract address matters more than a familiar interface name. A permission review should identify the network, token address, owner and spender before comparing the amount. Otherwise, a correct-looking allowance on one network or for one token could be mistaken for evidence about a different permission. Matching the fields makes the review specific and reproducible. A narrowly scoped permission and an ongoing permission serve different operational needs. Their trade-off should be explained in terms of the authorised action and amount, rather than promised safety. A small permission cannot validate a dishonest destination, while a functioning interface does not establish that its requested authority is appropriate for the user’s intended transaction.
WFN analysis: consider a hypothetical transaction in which a user permits a contract to spend 1,000 units and then makes a 100-unit purchase. The purchase receipt establishes one action; it does not by itself establish that every permission associated with the interaction has ended. The actual remaining allowance must be read from the relevant token contract and owner-spender pair. The contract address matters more than a familiar interface name. A permission review should identify the network, token address, owner and spender before comparing the amount. Otherwise, a correct-looking allowance on one network or for one token could be mistaken for evidence about a different permission. Matching the fields makes the review specific and reproducible. A narrowly scoped permission and an ongoing permission serve different operational needs. Their trade-off should be explained in terms of the authorised action and amount, rather than promised safety. A small permission cannot validate a dishonest destination, while a functioning interface does not establish that its requested authority is appropriate for the user’s intended transaction.
For a signed request, record what the wallet actually displayed and which contract is supposed to act on the signature. For an on-chain approval, retain its transaction and the resulting allowance. These are suggested review steps, not a claim that every wallet displays identical fields or that every token implements the optional permit extension. When investigating an unexpected transfer, distinguish the permission that enabled it from the transaction that exercised it. That distinction helps narrow the evidence needed: the owner-spender relationship, relevant contract implementation and actual transfer record. The standards explain the mechanism; they do not certify a specific application, identify an attacker or establish that an unreviewed signature is harmless.
The permission recorded by the standard
The approve function sets a spender’s allowance; another call replaces the existing amount. The allowance function reports how much that spender remains authorised to withdraw, and transferFrom enables a transfer on another account’s behalf. The standard also includes a warning about changing an existing allowance directly between non-zero values. Ethereum ERC-20 token standard
Signed approvals can follow a different route. ERC-2612 defines permit, which can update an allowance using a signed message, subject to checks including a nonce and deadline. A signature request can therefore be relevant to token-spending authority even when the user is not submitting an ordinary approve transaction themselves. Ethereum ERC-2612: Permit extension for signed approvals
Review the permission separately from the trade
WFN analysis: consider a hypothetical transaction in which a user permits a contract to spend 1,000 units and then makes a 100-unit purchase. The purchase receipt establishes one action; it does not by itself establish that every permission associated with the interaction has ended. The actual remaining allowance must be read from the relevant token contract and owner-spender pair.
The contract address matters more than a familiar interface name. A permission review should identify the network, token address, owner and spender before comparing the amount. Otherwise, a correct-looking allowance on one network or for one token could be mistaken for evidence about a different permission. Matching the fields makes the review specific and reproducible.
A narrowly scoped permission and an ongoing permission serve different operational needs. Their trade-off should be explained in terms of the authorised action and amount, rather than promised safety. A small permission cannot validate a dishonest destination, while a functioning interface does not establish that its requested authority is appropriate for the user’s intended transaction.
Keep signed requests in the audit trail
For a signed request, record what the wallet actually displayed and which contract is supposed to act on the signature. For an on-chain approval, retain its transaction and the resulting allowance. These are suggested review steps, not a claim that every wallet displays identical fields or that every token implements the optional permit extension.
When investigating an unexpected transfer, distinguish the permission that enabled it from the transaction that exercised it. That distinction helps narrow the evidence needed: the owner-spender relationship, relevant contract implementation and actual transfer record. The standards explain the mechanism; they do not certify a specific application, identify an attacker or establish that an unreviewed signature is harmless.