Intermediate
Approval Patterns & Token Permissions — Key concepts
Understand token flows.
Developer Intermediate
3/6 — Approval Patterns & Token Permissions — Key concepts
Why it matters An approval is long-lived power. Unlimited allowances make spending convenient but enlarge the blast radius of compromised spenders. Permits reduce friction but must be validated carefully.
The root problem with conventional currency is all the trust that’s required to make it work.
Design lens Default to least privilege, make revocation obvious, and show spender/amount every time. Teach users in-product.
Attack reality Many “token drain” exploits are simply approvals used by compromised dApps. Detecting risky spenders and nudging toward limits reduces harm.
Operational habits Encourage periodic allowance reviews and make revoke flows cheap and clear. Treat approvals as inventory users should manage.
Allowance remaining
remaining = approved − spent
Track and display remaining allowance; warn when it exceeds sensible limits.
Permit digest (concept)
digest = keccak256(domainSeparator ∥ structHash)
EIP-2612 signs a typed hash; always verify domain, deadline, and nonce before accepting.
Key points
- Allowance:Approve/transferFrom semantics, race conditions (front-run to drain), infinite approvals trade-offs.
- Permit (EIP-2612) and Permit2:Gasless approvals via signatures; domain separators, deadlines, nonces.
- Revocation:Set to zero, per-spender/per-action caps, time-bounded approvals, spend limits in UI.
- UI clarity:Always show spender + amount; default to minimal allowances; warn on unlimited approvals.
- Contract safety:Pull vs push; avoid approving arbitrary spenders; reentrancy concerns in token callbacks.
- Monitoring:List current allowances, provide one-click revoke links, and educate users on risk.