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 the allowance is spent or changed. Two properties matter. First, the allowance is held by the contract you approved, not the website you visited — the UI can disappear and 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 with expiring, amount-scoped grants. 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 — we cover the safe way to do it 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 a transaction). And keep serious holdings in an address that simply never signs approvals, separate from your active dApp wallet. More layered habits are in our wallet security best practices.
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 browser extension or mobile app, across EVM, Solana and TON. The fee side is where WATS is unlike anything else: every action, including approval and revocation transactions, is charged in one token, ATS, instead of the chain's native gas — via an ERC-4337 paymaster on EVM and an equivalent fee-payer/relayer on Solana and TON — so cleaning up old allowances never stalls because you ran out of a gas token. Collected ATS is burned from a 100M supply toward a 30M floor, and ATS is a LayerZero OFT, so one balance covers every 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.
Frequently asked questions
What is a token allowance?
An allowance is a standing permission recorded in an ERC-20 token contract: it says a specific contract may spend up to a specific amount of your tokens. It is created when you sign an approve transaction, and it persists — independent of the website you used — until it is spent, changed or revoked. At spend time, the approved contract needs no further signature from you.
Are unlimited (infinite) token approvals safe?
They are convenient but carry a permanent tail risk: your whole balance of that token depends on the approved contract never being exploited or malicious, indefinitely. For small active balances the convenience often wins; for large holdings, prefer scoped amounts, and periodically revoke allowances you no longer use. Many major draining incidents were old approvals being exploited, not stolen keys.
What is the difference between Permit and a normal approval?
A normal approval is its own on-chain transaction that costs gas before the dApp can act. Permit (EIP-2612) replaces it with an off-chain signature the dApp bundles into its transaction — one step, with optional deadlines; Permit2 extends the pattern to tokens without native Permit support. The security model shifts accordingly: a signature can now grant spending power, so scrutinize signature requests exactly as you would an approval.