An ERC-20 approval is a standing permission that lets a specific smart contract spend up to a set amount of a specific token from your wallet. Approvals exist because tokens cannot be spent by another address on your behalf — so a decentralized exchange cannot take payment from you directly the way a merchant terminal takes a card. You approve, then the contract pulls. The permission survives the transaction that created it: an unlimited approval granted once remains spendable until revoked or overwritten, which makes approval phishing — tricking users into signing a drainer contract — one of the largest loss categories in the industry's history.
Bitcoin Trader publishes information, not investment advice. Self-custodied assets carry operational risks and losses can be permanent; this explainer covers token mechanics and hygiene.
Why do approvals exist at all?
The ERC-20 standard defines tokens with two move operations: transfer, which the owner calls directly, and transferFrom, which another address calls after the owner has set an allowance. That second path is what makes decentralized finance composable. A swap on an automated market maker, a deposit into a lending protocol, a bid in an NFT marketplace denominated in tokens — each requires the protocol's contract to pull tokens it does not own, under an allowance the owner granted.
The pattern resembles a card-on-file system more than a single payment. Approval sets the credit line; the contract's later transfers draw it down. And like card-on-file systems, the security posture is defined by how large the line of credit is and how trustworthy the party holding it — except on-chain the holder is immutable code that cannot be cancelled by phone call.
What does 'unlimited approval' mean?
Wallet interfaces, for cost reasons, commonly default to approving the maximum allowance rather than the exact transaction amount. Each approval is itself an on-chain transaction with a fee, so approving precisely 250 dollars of a token for one swap means paying another approval fee on the next swap. Most interfaces therefore offer unlimited approval by default and disclose it in a warning field — and most users, historically, click through.
The consequence is arithmetic: an unlimited approval to a legitimate contract is low-risk if the contract is immutable and audited, because its code will only draw what its logic calls for. The same approval to a malicious contract is a full wallet balance waiting to be pulled — not at signature moment, which is why nothing seems to happen, but whenever the drainer chooses, days or months later. The signature does nothing visible; that is exactly why the attack works.
How do approval scams actually take money?
Through signature, not key theft. Drainer kits — phishing infrastructure sold as a service — induce a user to connect a wallet to a lookalike site and sign what the interface presents as a routine action: mint, claim, verify. The payload is an approval to the attacker's contract. The user's seed phrase never leaves the device; no virus is needed; the blockchain faithfully executes the permission the user granted. Losses to such kits have totaled in the billions of dollars across the industry, with individual mass-drain events regularly exceeding tens of millions — figures tracked by blockchain-analytics firms and reflected in the security advisories that exchanges and the SEC's investor alerts publish about wallet-drainer campaigns.
The defense is verification at the only layer the attack cannot fake: the transaction itself. Revoke-any-allowance tools and block explorers list standing approvals per wallet; disciplined users check them periodically and clear stale lines of credit. Wallets increasingly simulate transactions before signing, flagging approvals and their beneficiaries — a partial defense that shifts the burden to whether the user reads the warning this time.
How should allowances be managed?
The mechanical hygiene list is short. Approve exact amounts where the interface allows, accepting the extra fee as the price of a smaller attack surface. Treat any approval to a contract you cannot name as hostile until proven otherwise. After using a protocol — especially one used once — revoke its allowance with a dedicated revocation tool, the on-chain equivalent of deleting a stored card. And treat signature requests arriving from unsolicited sites, airdrops, and 'wallet verification' prompts as the primary attack surface they are.
None of this protects against a compromised or malicious protocol drawing an allowance it was legitimately granted — that risk is about the protocol's code, not your approvals. Approval hygiene limits the blast radius of phishing; protocol due diligence limits the blast radius of code.
What did standards change after the drain era?
Two directions emerged. ERC-7674 and similar proposals harden the approval operation itself — notably by requiring code at the spender address, closing the signature-based burn vector where an approval to an address without contract code destroys tokens. And the broader account-abstraction work — ERC-4337 and the passkey wallets built on it — moves permissions into programmable policy layers: session keys with spend caps, allowlists, and revocation that does not require an on-chain transaction per line item.
The architectural lesson compounds across all of it: on-chain permissions are real authorities, granted by signature and enforced by consensus. The interface calls it 'connecting a wallet'; the chain calls it what it is — a power of attorney, durable until someone revokes it.
How do permit signatures differ from approvals?
The ERC-2612 standard added a gasless cousin of the approval: instead of an on-chain transaction, the holder signs an off-chain message authorizing an allowance, and the counterparty submits that signature on-chain when spending. The user pays no gas at signing — which is why 'gasless' approvals became popular for airdrops, claim sites and dashboards — and the permission produced is the same standing allowance as before.
The security profile shifts rather than improves. A conventional approval phishing requires the victim to pay gas and see a pending transaction — friction that wakes some users. A permit phishing requires only a signature in a wallet pop-up that many interfaces label ambiguously, and drainer kits adopted permit en masse for exactly that reason: the signature reads like a login, but it authorizes an allowance that can be executed later by the attacker's transaction, not the victim's. The defenses are identical at the layer that matters — read what is being signed, distrust unsolicited signature requests entirely — and revocation tools increasingly list permit-based allowances too. The taxonomy for readers is simple: any signed message that grants a future spending right is an approval in disguise, whatever the interface calls it.
For more context, read What Smart Contract Audits Prove — and What They Quietly Don't.
For more context, read how amms work.
For more context, read How Memecoins Launch and Why They Collapse.
