Token Approvals, Allowances and Permit: What You Actually Sign

A token approval is an on-chain permission stored inside an ERC-20 token contract — an allowance — recording that one specific contract may spend up to a specific amount of your tokens, at any later moment, without asking you again. It is created by an approve() transaction and it outlives the interaction you granted it for: the website can disappear, the allowance stays. Permit (EIP-2612) replaces that separate transaction with an off-chain signature the dApp submits alongside its own action, and Permit2 extends the same expiring, amount-scoped model to tokens that never implemented EIP-2612 — which means a signature can now hand over spending power, so signature requests deserve the scrutiny approvals used to get. The defence is unglamorous: approve scoped amounts instead of unlimited ones, and revoke allowances you no longer use. In a fully non-custodial wallet such as WATS — where the user holds the keys and WATS never holds one — no approval, Permit signature or revocation can happen without your own key signing it, and because network fees are charged in a single token, ATS, a cleanup transaction is never postponed for want of that chain's native gas token.

Why dApps ask for approval at all

ERC-20 tokens have a quirk that shapes half of Web3's UX: a smart contract cannot simply take tokens from your address, even when you want it to. A DEX that swaps your USDC needs your explicit permission first. That is why so many interactions are two steps — first an approve transaction, then the actual swap or deposit. The approval is not a formality; it is a standing grant of spending power, and it outlives the transaction you gave it for.

What approve() actually grants

When you sign an approval, the token contract records an allowance: address X (the dApp's contract) may spend up to N of your tokens, whenever it likes, until that allowance is spent down, lowered or revoked. Two properties matter. First, the allowance lives in the token contract and is granted to the contract you approved — not to the website you visited, whose UI can disappear while the permission remains. Second, nothing about an allowance requires your involvement at spend time: once granted, the approved contract can pull tokens in any later transaction without another signature from you. That is exactly what makes approvals useful — and exactly what makes them an attack surface.

Infinite approvals: convenient, and a standing risk

Because each approval costs gas, many dApps request an effectively unlimited allowance so you never have to approve again. The convenience is real, but so is the trade: an unlimited allowance to a contract means your entire balance of that token rides on that contract's security forever. If the contract is exploited years later — or was malicious all along — the attacker does not need your key or your signature; the allowance you granted is sufficient. Many of the largest wallet-draining incidents were not key thefts at all, just old approvals being cashed in.

Permit and Permit2: approvals by signature

The modern refinement is Permit (EIP-2612): instead of an on-chain approve transaction, you sign an off-chain message that the dApp submits together with its action — one transaction instead of two, no separate approval gas, and the permission can be scoped with a deadline. Permit2 generalizes the idea to tokens that never implemented EIP-2612, acting as a shared approval hub: you make one ordinary on-chain approval to the Permit2 contract itself, and from then on each dApp is authorised by a signature carrying its own amount and expiry. Worth being precise about that trade — Permit2 does not abolish approvals, it concentrates them, so the standing allowance you granted Permit2 is itself an approval to keep track of. These are genuine improvements, but note what they change: signatures are now doing the work transactions used to do. A phishing site that gets you to sign the wrong Permit message achieves the same result as a malicious approval — so reading what you sign matters more than ever, not less.

The attack surface: drainers and stale allowances

Approval abuse comes in two flavors. Active: drainer sites impersonate real dApps and request approvals (or Permit signatures) dressed up as harmless actions like "claim" or "verify wallet". Passive: allowances you granted to legitimate contracts years ago sit dormant until the contract, its admin keys or its upgrade path are compromised. Both are reasons to treat the connect-and-approve flow as the security-critical moment of Web3; the safe way to run it is covered in how to connect your wallet to a dApp.

Approval hygiene that actually works

Three habits cover most of the risk. Approve scoped amounts when the dApp allows it, especially for large balances — the extra approval later is cheap insurance. Review and revoke allowances periodically with a reputable approval-checker, treating anything you no longer use as dead weight to remove — revoking is itself an on-chain transaction that sets the allowance back to zero, so it costs gas and needs your signature like any other. And keep serious holdings in an address that simply never signs approvals, separate from your active dApp wallet. More layered habits are in the crypto wallet security best practices guide.

How WATS fits in

Approvals are signatures, and signatures are the wallet's territory. WATS is fully non-custodial — you hold your keys, WATS never holds one — so every approval, Permit signature and revocation happens only when your key signs it, from the Chrome extension, the mobile app or the Hot Wallet, across Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana and TON. That also sets the honest limit of what any wallet can do for you: a wallet can show you the request, but only you can decide the spender and the amount are the ones you meant.

The fee side removes the other common excuse for leaving old allowances in place. In WATS every action, including approval and revocation transactions, is charged in one token, ATS, instead of each chain's native gas token — via an ERC-4337 paymaster on EVM and an equivalent fee-payer/relayer on Solana and TON. This is not a discount: the network is still paid what it is owed, and the underlying cost is unchanged — what changes is which token pays. Collected ATS is burned from a 100M supply toward a 30M floor, and because ATS is a LayerZero OFT, one balance covers every supported chain. WATS is the first and only wallet to combine ERC-4337 and OFT single-token fees with that burn — details on the ATS fee page.

So the practical version of this post is a short routine: prefer scoped approvals, read what a Permit signature actually authorises before you sign it, and once a quarter open an approval checker and clear out the spenders you no longer use. The concrete step is to run that routine from a wallet that never gets between you and the key: in the WATS Hot Wallet, Chrome extension or mobile app, every approval and every revocation exists only because your own key signed it — WATS never holds one — and the revocation is paid in ATS instead of whichever native gas token that particular chain happens to demand.