Coin Nest / Knowledge library · Security · 2 min read
Approval creates spending authority
An ERC-20 allowance permits a spender address to transfer a specified amount of your tokens through the token contract’s authorization mechanism. The spender may be an application contract, router, or another address. It is the approved address that matters, not the logo on the page requesting permission.
Approval and transfer are different actions. Approving does not necessarily move tokens immediately, but it can enable a later transfer. A wallet’s “connect” action usually exposes account information to a website; disconnecting that connection does not automatically erase onchain allowances already granted.
A hypothetical two-step trade
Lee intends to swap 40 units of a token. The interface first requests permission for a router to spend that token, then requests the swap transaction. If the approval is unlimited, the permission can outlast the 40-unit trade and apply to later holdings under the token’s rules.
Choosing an allowance near the required amount can reduce exposure, though later interactions may require another approval and fee. The tradeoff is between recurring authorization friction and a larger persistent permission. It should be visible to the user rather than hidden as an inconsequential setup step.
Now suppose the swap fails after approval succeeds. Lee still has the tokens, but the allowance may remain. Checking only the failed swap receipt misses the successful authorization. Review each transaction in a multi-step workflow separately and decide whether unused permissions should be removed.
Signatures can grant permissions too
Some mechanisms allow a signed message to authorize spending when another party submits it. A request that charges no gas at signing time can still have economic consequences. Read the spender, asset, amount, deadline, network, and other domain information presented by the wallet.
An expiry displayed for one signed instruction may differ from the lifetime of a separate onchain approval. Likewise, NFT operator permissions follow different interfaces and can cover all tokens in a collection. Avoid assuming that every permission screen means only a one-time token payment.
Build a permission review routine
List allowances by network and token. Compare spender addresses against independently verified application deployments. Revoke permissions you no longer need through a trusted interface or direct contract interaction, taking account of the required network fee.
If a private key itself is compromised, removing one allowance does not restore exclusive control. An attacker with the key can authorize new actions. Treat key compromise as a different incident from an unwanted spender permission. The recovery plan must match the source of authority that was exposed.
- Check the spender address rather than trusting a human-readable name.
- Choose a deliberate amount and understand whether permission persists.
- Inspect each step after a partly completed application workflow.
- Review message signatures as carefully as paid transactions.
- Remember that disconnecting a website is not an onchain revocation.
Frequently asked questions
Can revocation undo transfers already completed?
No. It changes future spending permission under the contract rules. It does not reverse prior transfers.
Is every unlimited allowance malicious?
No. Legitimate applications may request it for convenience. The persistent exposure still deserves an explicit decision and periodic review.