Illustration of a digital wallet with a permission checkmark being overridden by a warning icon

Almost every interaction with a decentralized application, from trading on a decentralized exchange to staking a token, requires granting that application permission to move a specific token on the wallet owner's behalf. This permission is called a token approval, and it is a legitimate and necessary part of how most blockchain applications function. The problem is not that approvals exist. The problem is that most wallet interfaces present them briefly and technically, and most users confirm them quickly without understanding exactly what they are authorizing.

According to Chainalysis's 2026 Crypto Crime Report, onchain scams netted at least fourteen billion dollars in 2025, up from twelve billion the year before, and approval based phishing has been a persistent contributor to that figure, with more than a billion dollars in cumulative reported losses since 2021 attributed specifically to this technique.

What a token approval actually grants

When an application requests an approval, it is asking the wallet to authorize a smart contract to transfer up to a specified amount of a token, on the owner's behalf, at a time of the contract's choosing. Many applications request an unlimited approval by default, since it is more convenient for the app and avoids asking the user to re approve every future transaction. That convenience is exactly what makes the permission dangerous if the contract receiving it is malicious or is later compromised, because the approval itself does not expire and does not require any further confirmation to be exercised.

Key Point

An approval is not a one time transaction. It is a standing authorization that remains active indefinitely, on chain, until it is manually revoked, regardless of whether the site that requested it is ever visited again.

ERC-20 approvals, Permit, and Permit2 explained

The standard approve function

The original ERC-20 token standard includes a function called approve, which a wallet owner calls to authorize a specific contract address to spend up to a specified amount of that token. This requires an on chain transaction, meaning it costs a network fee and is recorded permanently on the blockchain the moment it is confirmed. Because it is a visible, separate transaction, most wallet interfaces will show at least a generic warning that a contract interaction, rather than a simple transfer, is being requested.

Permit and off chain signatures

A newer standard, commonly referred to as Permit, allows the same kind of approval to be granted through a signed message rather than an on chain transaction. The signature itself costs no network fee and does not need to be broadcast immediately, since the receiving contract can present it to the blockchain at any later point to activate the approval. This is convenient for legitimate applications, since it lets a user approve and complete an action, like a token swap, in a single interaction instead of two separate transactions. It is also exactly what makes Permit based phishing harder to notice, since a signature request often looks visually similar to signing a harmless message, and many wallet interfaces have historically displayed less detail for a signature request than for a full transaction.

Permit2 and universal approvals

Permit2, a further extension adopted broadly across decentralized exchanges, allows a single approval granted to a central Permit2 contract to then be reused across many different applications without a separate approval for each one. This reduces friction and fees for legitimate users, but it also means a single phished Permit2 signature can potentially expose a token to any application built to interact with the Permit2 system, widening the practical blast radius of one successful phishing attempt compared to an older style single contract approval.

A realistic scenario: a fake airdrop claim that grants unlimited approval

  • A message circulates in a crypto community claiming a well known token project is distributing a surprise airdrop to holders of a related asset, with a link to a claim page.
  • The claim page asks the visitor to connect their wallet and click a button labeled Claim Now, which triggers a wallet popup requesting approval for the project's token, described only as a contract interaction.
  • The requested approval amount is set to the maximum possible value the token standard allows, rather than a specific claim amount, though this detail is not surfaced prominently in the wallet's default confirmation view.
  • The victim confirms, receives no tokens since there was never a real airdrop, and closes the tab assuming the claim simply failed or was already exhausted.
  • Weeks later, once the token's price has risen or the victim has accumulated a larger balance, the attacker exercises the standing approval and transfers the full balance out in a single transaction the victim never approved directly.

The delay between the original phishing interaction and the eventual loss is deliberate. It disconnects the theft from its cause in the victim's memory and makes the specific phishing page far less likely to be reported or connected to the loss when it eventually occurs.

Why approval phishing is harder to notice than a direct drainer transfer

A direct wallet drainer, covered in our companion guide, typically empties a wallet within seconds of a signature being confirmed, which at least makes the cause and effect obvious to the victim immediately afterward. Approval phishing is structured differently. The approval transaction itself moves nothing, so a victim who checks their balance right after confirming sees no change and reasonably concludes nothing happened. The actual loss can occur days, weeks, or months later, executed by the attacker at a time of their choosing, which means the connection between the original phishing page and the eventual theft is frequently never made by the victim at all. This is also why routine approval audits matter more for this specific threat than for direct drainer attacks, since there is a real window, however uncertain in length, during which revoking the approval prevents any loss from occurring at all.

How the attack is typically carried out

Fake claim and verification pages

The most common setup is a page mimicking an airdrop claim, a wallet verification step, or a routine protocol interaction. The victim connects their wallet expecting a simple confirmation, and the site instead requests an approval covering a valuable token, framed in the wallet's popup as a generic contract interaction rather than anything alarming.

Permit and Permit2 signature phishing

A newer and more difficult to detect variant abuses a signature standard, often referred to as Permit or Permit2, that allows an approval to be granted through an off chain signed message rather than an on chain transaction. Because signing a message does not always trigger the same visual warnings as a transaction, and does not cost a network fee, victims are more likely to sign it without close scrutiny. One widely reported case involved a trader losing roughly one million dollars in a single Permit2 signature after mistaking it for a routine confirmation on a decentralized exchange interface.

Delayed exploitation

Because an approval does not need to be used immediately, attackers frequently harvest large numbers of approvals across many wallets and exercise them later, in batches, often timed to periods when a token's price has risen or when the victim is less likely to be actively monitoring that wallet. This delay is part of why victims are sometimes unable to connect a loss back to the original phishing interaction, since weeks or months may separate the two events.

How to check and revoke existing approvals

  • Use a reputable approval checking tool that reads your wallet's on chain approval history and lists every active permission, along with which contract holds it and what amount it covers.
  • Revoke any approval you do not recognize or no longer need, particularly unlimited approvals tied to unfamiliar or rarely used contracts.
  • Pay special attention to Permit2 style approvals, since they are less visually obvious in most wallet interfaces than a standard on chain approval transaction.
  • Make revocation a routine practice after interacting with any new or unfamiliar decentralized application, not just something done reactively after a loss is discovered.

Beyond checking existing approvals, a few specific signs in the moment a new approval is requested are worth treating as an immediate stop signal rather than something to review later.

  • The requested amount shown for the approval is the maximum value the token standard allows, rather than a specific number tied to the claimed action.
  • The page asks for an approval before showing any tangible benefit, reward, or service, rather than as a natural second step of an interaction you initiated.
  • The wallet popup describes the request only as a signature or a generic contract interaction, without a human readable summary of what is being authorized.
  • The site combines urgency, such as a countdown timer or limited claim window, with a request for wallet approval rather than a direct transaction.

A full walkthrough of the revocation process itself, including which tools are commonly used and how to interpret what each approval actually authorizes, is covered in our dedicated guide on revoking token approvals. That process is one of the few genuinely effective defensive steps available to a wallet holder, since it directly closes off standing access rather than relying on avoiding future phishing attempts alone.

When an approval has already been exploited

If funds have already moved through an exploited approval, the approval itself should still be revoked immediately to prevent any remaining allowance from being used again, even after an initial theft. The transaction that executed the theft, along with the original approval transaction, should be documented with timestamps and identifiers, since that sequence is often what allows an investigator to establish how the compromise occurred and whether it connects to a broader pattern of drainer activity, discussed in more detail in our guide on wallet draining attacks.

token approvalspermit phishingsmart contract securitywallet security

Frequently asked questions

Most reputable approval checking tools now support viewing and revoking Permit2 based approvals alongside standard ones, though the interface may separate them into a distinct section. It is worth checking both categories specifically, since Permit2 approvals are less visually obvious in many wallet interfaces.

No. Revocation only prevents an existing approval from being used again in the future. It has no effect on funds already transferred, since blockchain transactions cannot be reversed once confirmed.

Most wallet interfaces are designed for general purpose use and display approvals as a standard contract interaction rather than flagging the specific amount or duration. Specialized approval checking tools generally provide clearer detail than a wallet's default confirmation screen.

It can be. Signature based approvals, particularly Permit2 style requests, can grant the same spending access as an on chain approval transaction, but they are often presented with less visible warning and no network fee, which makes them easier to overlook.

A reasonable practice is reviewing active approvals every few weeks for an actively used wallet, and immediately after interacting with any new or unfamiliar decentralized application, airdrop claim, or minting page.


Sources and further reading


Related reading

Reviewing and Revoking Token Approvals, A Practical GuideHow Wallet Draining Attacks WorkRecognizing a Fraudulent Contract Before You DepositHow Seed Phrase Theft Happens and How to Prevent It