ERC-20 token approval is the permission a wallet grants to a smart contract to transfer a specified amount of an ERC-20 token on the owner’s behalf. It is usually implemented through an allowance value, which the contract can spend until the limit is changed or revoked by the token holder.
How ERC-20 token approval works
ERC-20 approval is not a transfer by itself, it is a delegated spending right. The wallet holder sets an allowance so a contract can move tokens on their behalf, usually up to a chosen limit and until that allowance is changed or consumed.
This pattern is what makes decentralised finance and other token-based applications usable, because contracts can perform actions without the owner signing every transfer. It also means the approval layer is part of the asset-control boundary, not just a convenience feature.
Why approvals matter for token custody
An approval can effectively stand in for standing access to assets. If the approved contract behaves as expected, the risk is limited to the intended use case. If the contract is malicious, compromised, or overly broad in what it asks for, the same mechanism can become a pathway to unauthorised token movement.
That is why token approval should be treated as a permission decision with real security impact, especially when the allowance is large, open-ended, or granted to a contract the holder no longer uses. In practice, the security question is not only whether the token exists, but who can spend it under what conditions.
Common failure modes in approval design
The main failure modes are excessive allowance, stale allowance, and deceptive approval prompts. Unlimited or long-lived approvals increase exposure if the spender contract is later abused. Users also make approvals to look-alike applications, phishing pages, or malicious signature flows that disguise what they are actually authorising.
Because approval is separate from transfer, a wallet can appear safe at the moment of granting access while still leaving future value exposed. That separation is useful for application design, but it also creates a delay between the point of trust and the point of loss.
How to evaluate and control approval risk
Good approval hygiene starts with knowing which contracts can spend which tokens and why. Review allowances regularly, revoke approvals that are no longer needed, and prefer narrowly scoped permissions when the application supports them. For higher-value wallets, it also helps to separate active DeFi use from long-term holdings so a single approval does not expose the full balance.
When the approval model is part of a broader workflow, such as sign-in with wallet or contract-based treasury operations, Token and Session Security Guide is a useful companion for understanding how delegated authority, replay resistance, and revocation fit together. For readers focused on approval abuse in the wild, Crypto Scam and Drainer Guide explains how attackers abuse token approvals through phishing, fake airdrops, and wallet drainers.
Risk and Threat Considerations
ERC-20 approval risk is concentrated in the spender relationship, not the token contract alone. A malicious or compromised spender can drain approved balances without needing to steal the wallet’s private key, which makes approval abuse a common way to convert a successful phishing or dApp compromise into direct asset loss.
Failure mechanism: The attacker gets a contract approved for spending, then uses that allowance to transfer tokens later, often after the victim has stopped paying attention to the original approval transaction.
Impact: Funds can be moved out of the wallet even when the wallet itself is not fully compromised, and recovery is usually difficult once the transfer has occurred.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Token approvals can grant contracts excessive spending power over wallet-held assets. |
| NHI-07 — Long-Lived Secrets | Open-ended approvals function like long-lived delegated access to token balances. | |
| Recommendation — Limit allowances to the minimum needed and revoke stale approvals promptly. Prefer short-lived or narrowly scoped approvals and remove standing access when it is no longer needed. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Allowance lifecycle maps to controlled issuance, storage, rotation, and revocation of access-enabling material. |
| AC-6 — Least Privilege | Approvals should constrain what a contract may spend, which is a least-privilege decision. | |
| Recommendation — Apply lifecycle controls that let users revoke, replace, and limit spending authority. Restrict token allowances to the smallest amount and shortest duration practical. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | A spender contract exercising more token-moving power than intended is an authorization failure. |
| Recommendation — Verify that each contract function can only spend the tokens and amounts it is entitled to use. | ||
Practitioner Guidance
Why practitioners should care: For teams building wallets, token dashboards, or DeFi interfaces, approval design shapes whether users understand the scope of delegated authority. Clear permission prompts and sensible defaults reduce the chance that users grant broader access than intended.
What to watch for: Watch for unlimited approvals, repeated approval requests from the same app, and contracts that ask for allowance long before they actually need it. Those patterns often indicate weak permission design or an attempt to increase the size and lifetime of exposure.
Practitioner takeaway: Treat approval as a security control, not a usability detail, because once delegated spending is granted, the blast radius depends on contract integrity as much as wallet hygiene.