ERC-20 Approval Risks: The Infinite-Approval Footgun Explained

Most DeFi exploits start with an ERC-20 approval the user did not realise they signed. Here is exactly how approvals work and how to manage them safely.

ERC-20 approvals are the single most exploited surface in DeFi. A wallet approves a contract to spend its tokens — often for an unlimited amount — and that approval persists indefinitely. Six months later, the contract is exploited or compromised, and the attacker uses the standing approval to drain every wallet that ever interacted with it. Understanding approvals is the highest-leverage skill a self-custody user can develop.

How Approval Works

• You hold USDC in your wallet — your address owns the tokens at the ERC-20 contract level
• To let Uniswap spend your USDC for a swap, you call USDC.approve(uniswap, amount)
• The USDC contract records: 'address X has authorised Uniswap to spend up to amount Y'
• Uniswap's swap function then calls USDC.transferFrom(yourWallet, ...) to actually execute the swap
• The approval persists until you explicitly revoke it or the spending contract has consumed the full approved amount

Why Infinite Approvals Are Default

Wallet UIs default to infinite approvals (uint256.max) because re-approving on every swap costs gas and adds friction. The trade-off is that a single infinite approval is a permanent 'this contract can drain my entire balance of this token' authorisation. If the contract is exploited later, the attacker walks away with everything you authorised — even if you have not interacted with that contract for years.

What Goes Wrong

• Old protocol's contract is exploited via an upgrade flaw — attacker drains every wallet with standing approval
• User signs an approval to a malicious contract that masquerades as a legitimate one — phishing site that swaps the contract address
• User signs Permit2 or EIP-2612 typed-data approval thinking it is a no-op signature — same effect as on-chain approval
• Wallet drainer scripts watch for high-balance addresses with standing approvals and time exploits accordingly

The Three Defensive Practices

• Approve exact amount, not infinity — modern wallets let you cap approvals to the trade size at the cost of one extra signature per future trade
• Audit standing approvals quarterly — use Revoke.cash or Etherscan's token approvals page to review and revoke
• Use a spending wallet — keep large balances in a cold wallet and a small operating balance in a hot wallet that gets approvals
• Read what you sign — if a 'connect wallet' signature requests an approval, ask why; legitimate read-only connections do not need it
• Use account abstraction session keys for known dapps — bound spending authority is safer than open-ended approvals

How Steyble Handles This

Steyble's swap router uses Permit2 with bounded amounts and time windows by default — the user authorises only the specific swap, with an expiry, and no standing approval persists after the trade. The wallet UI shows live standing approvals across every supported chain in one screen, with one-tap revoke. The result is that the typical Steyble user does not accumulate the long-tail approval debt that powers the modern drainer industry.