A token approval does not send an asset. It gives another address permission to move a defined amount later. That distinction is central to using Ethereum applications safely: a wallet can still display the tokens while an approved contract retains authority over them.
Allowance is persistent onchain state
ERC-20 separates approval from transfer. The token owner calls approve to set an allowance for a spender. The spender can then call transferFrom, provided the requested amount fits within the recorded allowance and the owner has enough tokens.
The authorization lives in the token contract, not in the browser session. Closing a tab or disconnecting a wallet stops the website from making new interactive requests, but it does not alter the allowance. A revocation is another state-changing transaction, usually setting the allowance to zero.
Allowances are also specific. The relevant tuple is the owner, token contract, and spender on one network. A permission for one token does not cover every asset, and the same ticker on another chain may refer to a different contract.
Why unlimited approvals exist
Applications often request a very large allowance so repeat users do not need to approve every interaction. That can save transactions and simplify a swap or deposit flow. The trade-off is duration and scope: authority can remain after the intended action, and future balances may be reachable if the spender is compromised or behaves unexpectedly.
An approval amount is a ceiling, not evidence that the amount has already moved. Incident review should therefore distinguish an approval event from a later token transfer. Revocation can prevent future use of a remaining allowance, but it cannot reverse a completed transfer or guarantee priority over an attacker’s pending transaction.
Signatures can create permissions too
EIP-2612 adds permit, which lets an owner sign structured data authorizing an allowance. Another party can submit that signature onchain. The signed message includes a nonce and deadline, but a permit deadline limits when the signature may be submitted; it does not automatically impose an expiry on the resulting ERC-20 allowance.
This is why “only a signature” is an incomplete description of risk. The important question is what the signed payload authorizes, for which spender, and for how long it remains usable.
Permit2 introduces another model. A token may first approve the Permit2 contract, after which Permit2 can manage application permissions through signature-based transfer or allowance flows. Reviewers may need to inspect both the token-to-Permit2 approval and the downstream Permit2 permission. Clearing one layer does not necessarily erase state or signed messages in the other.
A practical review sequence
- Confirm the network and exact token contract.
- Identify the spender by address rather than interface label alone.
- Compare the allowance with the intended transaction size and frequency.
- Determine whether the permission is a direct ERC-20 allowance, an EIP-2612 permit, or a Permit2 flow.
- For obsolete permissions, submit the appropriate onchain reduction or revocation and verify its confirmation.
- Repeat the check on every network the wallet has used.
Hardware signing devices protect keys from extraction, but they cannot make an authorized permission harmless. Approval hygiene is therefore about limiting durable authority, understanding each permission layer, and verifying changes onchain.
Source: BTC-Pulse.