If a protocol has been audited, why can it still get drained through old approvals?
An audit report verifies a contract's code logic at the moment the audit was performed — it's not a guarantee the contract will never have issues in the future, nor does it mean every user who ever interacted with that contract set conservative allowance amounts. Take Li.Fi as an example: the 2024 issue stemmed from a vulnerability later discovered in the contract itself, not from a poorly done audit — but what actually determined the scale of the loss was how many user accounts still had unlimited approvals sitting active from earlier interactions. Had every user originally approved only the exact amount needed, even with the contract vulnerability, an attacker could only have taken what that single transaction required — not the entire wallet balance.
That means an audit addresses "does the contract's logic itself have a flaw," while how many old approvals a user still has sitting active is a completely separate layer of risk that doesn't automatically become safe just because a protocol has been audited — which is also why regularly checking and revoking unused approvals is still recommended even for well-known protocols with thorough audit histories.
If most of my approval amounts are already set to just what's needed, do I still need to bother revoking them?
Setting exact-amount allowances does significantly lower the ceiling on how much a single vulnerability could cost you — that's the right direction and worth doing. But it doesn't mean revoking becomes entirely unnecessary. An old approval, even with a limited amount, is still an attack surface: if a protocol you haven't used in a long time stops being maintained, or its contract permissions get maliciously seized, even a limited allowance could still be found and exploited by some method. Limited approvals can also be chained together in composite attacks — combined with other vulnerabilities to stack multiple limited approvals into a larger total loss.
The more practical consideration is that the longer your approval list grows, the harder it becomes to remember and identify which spender address belongs to which protocol and whether you're even still using it. A list with a dozen or twenty approvals untouched for years makes it genuinely difficult to tell which ones are safe and which are stale and overdue for revocation. A more practical approach isn't demanding yourself revoke immediately after every single transaction — it's building a habit of reviewing your approval list periodically (quarterly, say) and clearing out approvals for protocols you've clearly stopped using, keeping the list at a size you can actually identify and judge item by item.
Do Permit and Permit2, these signature-based approval mechanisms, sound safer or riskier?
It depends on the context they're used in. Permit (EIP-2612) and Permit2 were originally designed to solve the hassle of the traditional approve flow — sending a separate approval transaction before the actual operation transaction, a two-step process that costs gas twice. Replacing one of those on-chain transactions with a signature is, in theory, a more efficient, gas-saving design for legitimate use cases — it wasn't created to circumvent any security mechanism.
But it's precisely because this signature costs no gas and doesn't immediately show up on a Block Explorer that it's become an increasingly favored phishing technique — victims feel like they're "just signing something," which triggers far less psychological caution than "sending a transaction," while what's actually approved through that signature carries the exact same effect as a traditional approval transaction. So the mechanism itself isn't inherently riskier — the danger lies in users generally being less vigilant about a "signature" action than about a "transaction" one. What matters for assessing risk isn't which mechanism is being used, but whether you carefully verify the spender address, allowance amount, and contract location listed inside every signature or transaction request that pops up.
If I discover I've accumulated a dozen or so approvals I've never cleaned up, how should I decide which ones to revoke first?
The first priority is checking the current remaining allowance — if Etherscan or Revoke.cash shows a number close to that astronomical figure for a given approval, it's an unlimited allowance, and these carry the highest ceiling on potential damage (an entire Token balance, if something goes wrong), so they should be handled first. The second priority is whether you still recognize this spender contract and are still actively using it — if it's a protocol you haven't interacted with in months or even years, it's worth revoking regardless of the amount, since you're no longer tracking that protocol's security status or operational updates.
The third priority is the value and size of your holdings in the token that approval corresponds to — if your wallet's balance of that token is small, even an unlimited allowance can only cause limited actual damage; conversely, if it's your largest holding, it's worth prioritizing a check on that spender contract's current security status even if the allowance amount looks reasonable. Revoking itself costs gas, so there's no need to immediately process every single item on your list — ranking by "unlimited amount first, long-unused first, high-value asset first" usually surfaces the handful that genuinely need attention.
Before your first transaction on almost any DeFi protocol, you'll typically see a confirmation popup called "approve" — and you may have clicked confirm without thinking twice, since there's no way to proceed otherwise. What that action does is let a Smart Contract move a certain Token's balance out of your wallet in the future, and many wallets default to requesting not "the amount you're about to use" but an unlimited allowance (typically written as the astronomical number 2^256-1). That means if a vulnerability is ever found in that contract's code, or its permissions get seized by an attacker, the approval you once granted is enough to let someone drain your entire balance of that token in a single transaction — no Private Key required, because you already handed over the permission yourself.
A common misconception is that disconnecting your wallet from a website removes the risk. That's not how it works at all — an allowance is a record written on-chain, belonging to the token contract itself, not a connection state between a website's frontend and your wallet. Disconnecting just means the site can no longer see your wallet address temporarily; the record of "this contract can move your tokens" stays on-chain indefinitely until you actively send a transaction to revoke it. That's also why checking your approvals can't be based on "have I interacted with this site recently" — you need to directly query the chain for your wallet address and see which approvals you've ever granted, and which ones are still active right now.
For Ethereum, the most direct free tool is Etherscan's built-in Token Approvals page. Go to etherscan.io/tokenapprovalchecker and click "Connect to Web3" to link your wallet (this is read-only lookup and won't ask you to sign any transaction). The interface lists every currently active approval for that address, including each approval's Original Allowance and Current Allowance — if the current allowance shows a number near that astronomical figure, it's an unlimited approval. Find the item you want to revoke and click its corresponding "Revoke" button; your wallet will prompt a transaction request that essentially calls that token contract's approve function and resets the allowance back to zero, requiring a Gas Fee to take effect — revoking is itself an on-chain transaction, not a free action. Multi-chain users can also use third-party tools like Revoke.cash or Debank to review approvals across several chains at once.
Exploiting unlimited approvals isn't a hypothetical concern. In 2023, Hardware Wallet maker Ledger's Connect Kit component was hit by a phishing attack that tricked users into signing unlimited approvals, leading to stolen funds. In 2024, a contract vulnerability in cross-chain protocol Li.Fi was exploited, causing roughly $9.7 million in losses that stemmed from pre-existing unlimited approvals sitting in many user accounts. That same year, decentralized exchange aggregator ParaSwap's Augustus V6 contract had a vulnerability that affected users who had previously granted approvals; Stablecoin protocol SenecaUSD lost about $6.5 million after attackers exploited existing approvals via a contract flaw; Cross-Chain Bridge protocol SocketDotTech (Bungee) saw users with unlimited approvals lose about $3.3 million due to incomplete input validation; and liquidity protocol ConcentricFi lost roughly $1.72 million after attackers seized control of its upgradeable contracts, prompting the team to publicly advise all users to revoke their approvals. What these cases share in common: the underlying flaw was in each protocol's own contract, but whether assets were actually drained depended on whether victims still had old, long-overdue approvals sitting active in their wallet.
Recent phishing attacks increasingly avoid asking victims to send an obviously suspicious on-chain transaction, opting instead for signature mechanisms like EIP-2612 (Permit) or Permit2 — this kind of signature doesn't immediately appear on a Block Explorer and doesn't require you to pay gas, making it look like a "free, harmless" one-time signature, when in fact what you're signing produces an effect identical to submitting a traditional approval transaction. That means checking for risk can't stop at watching for when your wallet pops up a "confirm transaction" screen — when it pops up a "signature request" screen too, you need to carefully verify the spender address, amount, and contract location listed inside, rather than reflexively hitting confirm the moment a popup appears.