[{"data":1,"prerenderedAt":19},["ShallowReactive",2],{"blog-content-en-token-approvals-and-permit-explained":3},{"slug":4,"title":5,"excerpt":6,"description":7,"bodyHtml":8,"faqItems":9},"token-approvals-and-permit-explained","Token Approvals, Allowances and Permit: What You Actually Sign","Every time a dApp asks you to 'approve' a token, you are granting a contract the right to spend your balance. Here is how ERC-20 allowances really work, what Permit and Permit2 change, and how to stop old approvals becoming a liability.","ERC-20 approvals explained: how approve and allowances work, the risk of infinite approvals, EIP-2612 Permit and Permit2 signatures, drainer scams, and how to review and revoke token approvals safely.","\u003Ch2>Why dApps ask for approval at all\u003C\u002Fh2>\n\u003Cp>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 \u003Cem>approve\u003C\u002Fem> 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.\u003C\u002Fp>\n\n\u003Ch2>What approve() actually grants\u003C\u002Fh2>\n\u003Cp>When you sign an approval, the token contract records an \u003Cem>allowance\u003C\u002Fem>: 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 \u003Cem>contract you approved\u003C\u002Fem>, 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.\u003C\u002Fp>\n\n\u003Ch2>Infinite approvals: convenient, and a standing risk\u003C\u002Fh2>\n\u003Cp>Because each approval costs gas, many dApps request an effectively \u003Cem>unlimited\u003C\u002Fem> 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.\u003C\u002Fp>\n\n\u003Ch2>Permit and Permit2: approvals by signature\u003C\u002Fh2>\n\u003Cp>The modern refinement is \u003Cstrong>Permit\u003C\u002Fstrong> (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. \u003Cstrong>Permit2\u003C\u002Fstrong> 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 \u003Cem>reading what you sign\u003C\u002Fem> matters more than ever, not less.\u003C\u002Fp>\n\n\u003Ch2>The attack surface: drainers and stale allowances\u003C\u002Fh2>\n\u003Cp>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 \u003Ca href=\"\u002Fblog\u002Fhow-to-connect-wallet-to-dapp\">how to connect your wallet to a dApp\u003C\u002Fa>.\u003C\u002Fp>\n\n\u003Ch2>Approval hygiene that actually works\u003C\u002Fh2>\n\u003Cp>Three habits cover most of the risk. Approve \u003Cem>scoped amounts\u003C\u002Fem> when the dApp allows it, especially for large balances — the extra approval later is cheap insurance. \u003Cem>Review and revoke\u003C\u002Fem> 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 \u003Ca href=\"\u002Fblog\u002Fcrypto-wallet-security-best-practices\">our wallet security best practices\u003C\u002Fa>.\u003C\u002Fp>\n\n\u003Ch2>How WATS fits in\u003C\u002Fh2>\n\u003Cp>Approvals are signatures, and signatures are the wallet's territory. \u003Ca href=\"\u002Fhot-wallet\">WATS\u003C\u002Fa> is fully non-custodial — you hold your keys, WATS never holds one — so every approval, Permit signature and revocation happens only when \u003Cem>your\u003C\u002Fem> 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, \u003Cstrong>ATS\u003C\u002Fstrong>, instead of the chain's native gas — via an \u003Cstrong>ERC-4337 paymaster\u003C\u002Fstrong> on EVM and an equivalent fee-payer\u002Frelayer 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 \u003Ca href=\"\u002Fats-fee\">ATS fee page\u003C\u002Fa>.\u003C\u002Fp>",[10,13,16],{"q":11,"a":12},"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.",{"q":14,"a":15},"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.",{"q":17,"a":18},"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.",1784634268861]