Review a token allowance before signing it

Practical guide · prepared 19 September 2026. Sources were checked for this workflow; linked interfaces and policies can change. Research scope.

An approval is authority, not a payment

An ERC-20 approve(spender, value) call changes how much a spender may later move with transferFrom. No token has to leave during the approval transaction. That delay is precisely why a wallet prompt saying 'permission request' deserves the same attention as a transfer: the contract can exercise the permission later, after the page is closed. Start by recording the chain, token contract, owner account, spender address and amount in base units. Then convert the amount using the token contract's decimals and compare it with the balance you intend to use.

Run four checks before signing

1. Identity: verify the token and spender by contract address from first-party documentation. A symbol or interface label is not enough.
2. Ceiling: distinguish an exact allowance from a very large integer commonly rendered as unlimited. Prefer the smallest amount the intended action needs when the application supports it.
3. Path: ask which later contract call will use the allowance. Decode that call with the method in the transaction-reading workflow.
4. Exit: locate the current allowance(owner, spender) read and a way to set it to zero. Disconnecting a website does not change contract storage.

If replacing one non-zero allowance with another, inspect how the token and wallet handle the change. ERC-20 itself warns that interfaces should first set the allowance to zero because a spender may race an allowance change. That interface convention reduces a known ordering problem; it does not stop a spender from using authority already granted before the zeroing transaction confirms.

The underlying interface is narrow, as the ERC-20 guide explains. ERC-2612 moves the approval into a signed message called permit; it does not make the resulting allowance harmless. Review its token, spender, value, nonce, deadline, chain-aware domain and verifying contract. A short deadline limits when the signature can first be submitted, not necessarily how long the allowance remains after submission.

Hypothetical example

Hypothetical: a swap page needs 75 SAMPLE, but the wallet displays a typed-data signature for spender 0xD…, value equal to the maximum integer and a deadline thirty days away. The page names a router at 0xR…. Stop because the addresses differ until first-party documentation or verified code explains the delegation. If the application can request 75 SAMPLE with a near deadline, that bounds one dimension of exposure. It does not certify the router or protect other tokens.

After the intended action

Read the allowance again from the token contract. If it remains materially larger than needed, revoke it through a transaction whose token and spender you independently verify. Revocation is prospective: it cannot reverse a completed transferFrom, and a pending malicious transaction may win ordering. Approval dashboards are useful inventories, but reproduce important entries from the contract rather than trusting their labels. Contract-wallet modules and newer approval systems can add expiries or granular rules, but their own authority must be reviewed. This is a permission-audit workflow, not a guarantee against malicious code or investment advice.