Approval phishing: why your wallet can be drained without a signature

📖 Why a wallet can be drained “without a signature”

Approval phishing (or ice phishing) is not about stealing a seed phrase and does not require breaking into the wallet. The attack abuses legitimate permission functions: the user confirms Approve (a transaction that records the right to spend tokens for a specific address) or SetApprovalForAll (enabling an operator that can transfer all NFTs in the owner’s collection) once, after which a smart contract receives the right to move assets without new confirmations.

Goal of this guide: explain how permissions work (approval is the act of granting rights, allowance is the recorded spending limit), break down the main approval phishing scenarios, show how to inspect granted rights across EVM networks, and explain how revoking permissions works so that after the transaction the spender/operator address no longer has the right to spend assets.

The main vulnerability here is the expectation that every spend will require a separate signature. In a wallet interface the signature looks like an ordinary step (“allow”, “connect”, “confirm for swap”), so the user confirms not a transfer, but a grant of rights that is stored in the contract and used later without another confirmation window.

An unnecessary allowance (a limit recorded in the contract that defines how many tokens may be spent) for a stablecoin or an active setApprovalForAll (operator status for an entire NFT collection) creates long-lived access to assets: token spending through transferFrom (an ERC-20 function that lets a contract spend tokens from the owner’s address within the allowance without a new signature) or NFT transfer by an operator is possible at any moment until the permission is revoked.

Approval phishing uses permission grants through approve/permit (creating or changing an allowance) or setApprovalForAll, not a “hack” of the protocol. One signature is enough for a rights record to appear in the contract, allowing assets to be spent later without the owner’s participation.

One approve/permit signature or setApprovalForAll creates a rights record in a contract; token withdrawal or NFT transfer can happen later, without a new confirmation window, while the permission remains active.

🎣 What approval phishing is and why its “honesty” is dishonest

Approval phishing uses normal permission mechanisms: the grant of rights looks legitimate, does not cause an immediate loss of funds and therefore is often not perceived as a risk at the moment of signing.

Approval phishing is an attack in which a user is persuaded to grant a permission (approval/allowance) to manage tokens or NFTs, and that right is then used to withdraw assets. The dangerous action is disguised as a familiar interface step: “confirm for swap”, “allow for mint”, “sign for claim”, “grant access for deposit”.

Unlike key theft, the attacker does not need the private key and does not need a direct transfer of funds. It is enough for the user to once grant a specific address the right to spend assets: a spender for ERC-20 tokens or an operator for NFTs. After that, the withdrawal is performed without new wallet windows and without repeated confirmations by the owner.

At the blockchain level, the transactions look valid: the user really changed the contract state and granted rights to a specific address. That is why the wallet is not formally “hacked”: assets leave through previously granted permissions, not through a bypass of the signature.

In simple terms: approve is not a transfer, but a grant of spending rights to a specific address. Approval phishing means the user is tricked into granting that right to an attacker-controlled address while it is presented as a normal swap, mint or claim step.

Approval phishing works through valid permissions. The danger appears after the signature, when an active spending right is used without the owner’s participation.

Permissions in EVM are records of rights in contracts, not one-time actions; that is why approve can remain active for months and be used without a repeated signature.

🧠 How permissions work in EVM: allowance, spender and “infinite approve”

An EVM permission is a state record in a token or NFT contract that connects your address with a specific spender/operator address. This record defines who can spend tokens through transferFrom or transfer NFTs as an operator, and it remains valid until the owner changes it with a new transaction.

1. ERC-20: approve → allowance → transferFrom
   • The user calls approve(spender, amount) and specifies the spender address.
   • The token contract stores the allowance limit — the maximum number of tokens the spender can spend.
   • The spender calls transferFrom and spends tokens without new signatures until the allowance becomes 0 or is exhausted.
   • The contract checks allowance during transferFrom; it does not request the owner’s signature for every spend.
2. Allowance is tied to owner → spender → token
   • The permission exists only for a specific token and a specific spender.
   • An approve for USDT does not grant access to USDC and does not extend to other contracts.
   • Every new token or new spender requires a separate approve.
3. Unlimited approval is the maximum allowance value
   • With unlimited approve, the allowance stores the maximum numeric value.
   • The spender receives the right to spend tokens from that contract within this value, including future deposits to the address.
   • The permission remains active until a revoke transaction, even if the service is no longer used.
4. NFT: setApprovalForAll is operator status without a limit
   • setApprovalForAll(operator, true) enables operator status for the owner’s entire NFT collection.
   • This is not a limit by quantity or value: the right remains until setApprovalForAll(operator, false) is sent.
   • If the operator is compromised, NFTs can be withdrawn without new owner confirmations.

EVM permissions are long-lived rights records in contracts. One approve can work for months, unlimited increases the available spending limit, and setApprovalForAll removes quantity limits for the NFT operator.

A permit signature (for example EIP-2612) gives an application the right to set allowance through a signed message; the application then uses that signature in a transaction that grants rights and performs the action in one call.

🧾 Permit, Permit2 and message signatures: how permissions are granted without a separate approve and why attackers use this

In addition to ordinary approve, EVM has ways to grant permission without a separate transaction. The user simply signs a message, and the application uses that signature in its own transaction, which both grants the spending right and performs the action — swap, deposit or claim. These mechanics are called permit and extensions such as Permit2.

From a UX point of view, this looks like fewer steps: there is no separate approve transaction and no gas is required for a separate approve call. The technical consequence is the same: a spending right appears in the contract, and that right may remain active beyond a single operation if the signature parameters set a broad limit or a long expiration.

Permit and “gasless signatures” change only the form of confirmation. A message signature can install access rights to tokens or NFTs just like approve, so signature parameters must be read as permission grants.

In typical approval phishing schemes, the user is led to sign approve/permit or setApprovalForAll under the pretext of “Claim”, “Mint” or “Deposit”, and the active right is then used for spending.

🧪 Typical approval phishing schemes: how you are led to the “right” signature

These schemes use familiar interfaces and standard workflows, which makes the grant of permissions look like an ordinary service step.

Almost all attacks follow the same logic: first the user is brought to a page that looks like a dApp interface, then the page requests a signature that grants a spending right or operator right, and after that the active permission is used to withdraw assets without new confirmations.

The key feature is the absence of a direct request to send a transfer. Instead of a transfer, the site requests approve/permit or setApprovalForAll: a contract-state change that creates the right to manage the owner’s assets.

1. Clone of a popular service
   • A fake domain or advertising link leads to a visually similar copy of a DEX or marketplace.
   • The interface requests approve “for swap” or setApprovalForAll “for NFT listing”.
   • The signature parameters contain a spender/operator that does not belong to the real service.
2. Compromise of official channels
   • A link is posted in Discord, Telegram or X on behalf of the project or a moderator.
   • Urgency triggers are used: “contract bug”, “mint migration”, “last chance”.
   • The link leads to a page that requests approve/permit for the attacker’s address.
3. Social engineering through “support”
   • The attacker sends a private message pretending to be service support.
   • A signature is requested under the pretext of “canceling a stuck transaction”.
   • In practice, the user signs a permit or grants approve to a third-party address.
4. Substitution of the signature meaning
   • The wallet window displays a technical call without clear explanation from the interface.
   • The user confirms without checking the spender/operator address and the limit.
   • The risk is highest when the interface does not show the spender, limit or permission type.

Typical approval phishing schemes disguise a grant of rights as familiar actions. While allowance or operator status is active, the attacker can use it at any moment without new owner confirmations.

Allowance and setApprovalForAll do not have an expiration date: the rights record remains in the contract until the owner sends a transaction that resets the allowance or disables the operator.

🧯 Common user mistakes: why approvals accumulate and become a threat

The danger of approvals is rarely felt at the moment of signing because approve usually does not change the balance. The risk appears later, when an active permission is used for spending, and becomes stronger if such permissions remain across several networks and several tokens.

The same logic applies to setApprovalForAll for NFTs. The user treats it as a one-time action for listing or minting, but an active operator status remains in the collection contract and allows NFT transfer without new owner confirmations.

A separate class of mistakes comes from trusting the brand and visual design. The user focuses on the domain, logo or layout, but permission is always granted to a specific address — spender or operator. If the interface is substituted, the design does not change the address in the signature parameters.

Another common mistake is considering the issue closed after revoke in one network. Approvals are isolated by network: allowance in Ethereum and allowance in Arbitrum are different records in different contracts, so a permission may remain active on another network.

Gasless signatures create additional confusion. Permit and similar mechanics are perceived as “soft” confirmations, but the result is the same: the application receives the ability to install a permission that is then used for spending.

Mistakes become more dangerous when one wallet is used at the same time for storage, active trading and experiments. In that mode, one unnecessary spender/operator creates access to assets that were not part of the original operation.

The main threat of approvals is active permissions that remain in contracts after a task is complete. Unlimited allowance, an enabled NFT operator and permissions across several networks increase the amount of assets available for spending without new confirmations.

Permissions must be checked separately for each network: allowance and operator lists in Ethereum do not match Arbitrum, Optimism, Polygon or BSC, because rights records are stored in contracts on the specific network.

🔎 Where to check permissions: what exactly to inspect and in what order

Permission review is a sequence of steps by network and asset type. ERC-20 tokens and NFTs use different access mechanics, so they must be analyzed separately and closed in priority order: unknown addresses and broad limits first, then the remaining working permissions.

1. Identify the network with the most activity
   • Permissions are not “global”: Ethereum, Arbitrum, Optimism, Polygon and BSC have separate approval lists.
   • Start with the network where liquidity is concentrated and where the latest transactions happened.
2. Check ERC-20 approvals and reduce what is unnecessary
   • Priority goes to unknown spenders and unlimited allowance on stablecoins and liquid tokens.
   • Remove unused permissions and reduce limits to the amount needed for the current operation.
3. Check NFT approvals separately
   • Pay special attention to setApprovalForAll for marketplaces and gaming dApps.
   • Keep an operator active only for the period when it is truly needed.
4. Verify addresses you leave active
   • Match spender/operator addresses with trusted services by the address in the signature or explorer.
   • If an address is not recognizable, reset the allowance or disable the operator and grant a new permission only when necessary.

What to look for in a permission list

Permission review should match how permissions are stored: separate networks, separate tokens, separate spenders/operators. Prioritizing unknown and unlimited permissions closes the main scenarios for spending without new confirmations.

Revoke is a transaction that sets allowance to 0 for the owner→spender→token pair or switches setApprovalForAll(operator) to false; after network confirmation, the spender/operator address loses the spending right.

🧹 How to revoke permissions correctly: tokens, NFTs and common mistakes

Revoke is an on-chain transaction that changes allowance or disables an NFT operator. As a result, the contract records a new state: a specific address no longer has the right to manage your assets. Revoke stops future spending, but does not reverse transactions that have already been executed.

Step-by-step revoke algorithm for ERC-20

1. Identify the network. Approvals are isolated by network: Ethereum, Arbitrum, Optimism and other L2s have separate permission lists.
2. Find the token and spender. Check the token contract address, token name and current allowance limit, especially for stablecoins and liquid assets.
3. Perform revoke. The standard option is setting allowance to 0 through approve(spender, 0) or using a revoke button in a service.
4. Check the result. Make sure the allowance became 0 and the permission is no longer displayed as active.

Step-by-step revoke algorithm for NFTs

1. Open the collection operator list. Look for active setApprovalForAll entries and related operator addresses.
2. Disable the operator. The status must be switched to false.
3. Repeat for key collections. Check collections with the highest value and liquidity first.

Revoke changes the rights record in the contract: allowance becomes 0 or the operator is disabled. For revoke to really close access, it must be performed in the correct network and for the correct token→spender or collection→operator pair.

If you granted approve/permit or setApprovalForAll to an attacker, spending can happen later, including after you top up the balance. A clear action order helps first move assets out of the scope of active permissions, then reset allowance and disable operator to close spending access.

🚨 If you already granted a dangerous approve: a quick damage-reduction plan

In this situation, the order of actions matters: first move assets away from active permissions, then reset allowance and disable operator, and only after that investigate the source of the signature.

If approval phishing is suspected, the critical point is that the granted permissions may already be usable. While allowance is above zero or operator is enabled, spending can be initiated at any moment, including after new funds arrive on the address.

After a dangerous permission has been granted, the priority is to reduce the amount of assets reachable through allowance/operator and then reset those rights with revoke transactions. While the rights remain active, spending can happen without new confirmations.

Preventing approval phishing comes down to controlling two parameters: who receives the right (spender/operator) and how large or broad that right is (allowance or setApprovalForAll).

🛡️ Prevention: how to grant permissions without becoming an easy target

Approval phishing prevention is built around permission management: separating wallet roles, limiting allowance and disabling operator after the task is complete.

Most losses are tied to active permissions that remain in contracts after an operation is finished: unlimited allowance, an enabled NFT operator and the habit of confirming signatures without checking the address. These rights records allow spending without new confirmations until revoke.

Separating wallet roles

Using one address for storage, trading and experiments makes any approve critical for the entire balance on that address. Separating addresses limits the amount of assets exposed through allowance or operator. If you choose a “storage” wallet for the long term, start with a hardware crypto wallet review and set up cold storage before active DeFi work.

Reducing the scope of every permission

Even when working with trusted services, consider the scenario of a spender/operator error or compromise. For ERC-20, the scope of the right is defined by allowance; for NFTs, the scope is defined by setApprovalForAll status.

Review mode: when to check approvals

1. After a one-off operation. If the service is not used regularly, reset allowance or disable operator after the operation is complete.
2. For an operational DeFi address. With constant activity, review approvals once every one to two weeks and remove unnecessary permissions.
3. For an experimental address. For new dApps and airdrops, check and close permissions after every session.

Approval prevention is active permission management: address separation, exact allowance limits and disabling operator after the task reduce the amount of assets available for spending without new confirmations.

Approve lets protocols call transferFrom without a signature for every operation; the same mechanism means an active permission can be used for spending later if it was granted to an unnecessary address.

⚖️ Approve as a mechanism: strengths and built-in risks

Approve is a foundation of DeFi infrastructure: it lets protocols perform operations through transferFrom based on allowance, but makes the owner responsible for the spender address and allowance limit.

The approve mechanism is a trade-off between keeping assets on your own address and automating protocol actions. Assets remain on your address, but the contract receives the right to spend them within the allowance set in approve.

Approve is an infrastructure mechanism for managing rights. It is convenient because transfer is executed through allowance without repeated signatures, and risky because an active permission works until revoke and can be used for spending later.

📚 Cases and lessons: why a “correct contract” can still become a problem

Even when working with legitimate services, active approvals create risk: a vulnerability, upgrade or frontend substitution becomes dangerous if allowance is already recorded or operator is enabled in the contract.

The key property of approvals is the absence of a “lifetime”. If a permission has been granted, the contract does not need to request approve again: it uses the rights already recorded. Therefore the risk depends not only on the current service, but also on the list of approvals accumulated on the address.

In practice, incidents happen because permissions remain after completed operations. Regular review and disabling unnecessary allowances and operators limit the amount of assets available for spending without a new signature.

One mistaken approve/permit or setApprovalForAll gives an external address the right to spend tokens through allowance or transfer NFTs as an operator; while the permission is active, the wallet will not request a new signature for the spending itself.

✅ How to protect yourself from approval phishing and keep permissions under control

Permissions are the basis of DeFi mechanics, but allowance and operator status are exactly what allow assets to be withdrawn without a repeated signature if the right was granted to an unnecessary address.