Signed a Suspicious Permit2 Approval? Find Which Authority the Signature Created

Permit2 is not itself a scam. It is Uniswap's approval system for ERC-20 tokens, and legitimate apps use it to reduce repeated approval transactions. The dangerous case is a malicious Permit2 signature. A phishing page can use the real Permit2 contract and still ask you to authorize an attacker-controlled spender. If you signed something suspicious, do not judge the incident only by whether a transaction appeared in your wallet. Map both permission layers, check whether the signature can still be used, and contain the exposed token authority.

If you signed Permit2 on a suspicious site, stop interacting first

Close the site, reject remaining wallet prompts and do not follow a 'revoke' link offered by the same page, Discord message, ad or support account. Preserve the domain, wallet address, chain, timestamp, screenshots and any typed-data details you can still view. If assets are already moving, prioritize containment of the exposed tokens rather than investigating the site's branding.

Permit2 has two permission layers

A useful investigation starts by separating authority that many wallet UIs compress into one idea called approval.

• Layer 1 — Token → Permit2: the ERC-20 token contract allows the Permit2 contract to call transferFrom for some amount, often through a long-lived on-chain allowance.
• Layer 2 — Permit2 → Spender: a Permit2 signature or stored Permit2 allowance defines which application or spender can use that token authority, for how much and for how long.
• Execution — a spender or relayer uses the valid Permit2 authority to move tokens according to the signed terms.

The canonical Permit2 address is not a safety verdict

Uniswap's current Permit2 SDK and deployments use the canonical address 0x000000000022D473030F116dDEE9F6B43aC78BA3 on multiple supported EVM chains. Seeing that legitimate address as the EIP-712 verifying contract can therefore be normal. It does not validate the website or the spender encoded in the permission. A phishing signature can deliberately use the genuine Permit2 system and authorize a malicious spender.

The field to distrust first is the spender

For a suspicious Permit2 message, record the spender address before signing anything else. Then record the token, permitted amount, expiration or deadline, nonce, chain ID and verifying contract. Compare the spender with documentation from the protocol you intentionally meant to use. A familiar token and canonical Permit2 contract do not make an unfamiliar spender legitimate.

Permit2 is not one authorization mechanism

The official Permit2 repository describes two components: AllowanceTransfer and SignatureTransfer. They have different persistence and different emergency controls. You need to know which mechanism the malicious message used before assuming that a normal token-approval revocation is the whole solution.

Branch A — AllowanceTransfer creates spender-specific permission

AllowanceTransfer stores an allowance for the combination of owner, token and spender. A signed PermitSingle or PermitBatch can set the permitted amount and expiration for that spender, while a nonce prevents replay of old allowance-setting signatures. The Permit2 contract exposes the resulting allowance state publicly, so a suspicious active spender permission can be checked on-chain.

PermitBatch can expose several tokens in one signature

Permit2 supports batched approvals. That means a single typed-data signature can contain permissions for several ERC-20 tokens for one spender. Incident response must inspect every token in the signed batch rather than assuming that only the token visible in the phishing page's headline was affected.

Branch B — SignatureTransfer can move tokens with a one-time signed permit

SignatureTransfer uses a signed permit for a token transfer rather than establishing the same kind of reusable spender allowance. The official Permit2 implementation uses unordered nonces to prevent replay. A valid unused signature can therefore remain dangerous until it expires, its nonce is invalidated or it is consumed, provided the required underlying token approval to Permit2 still exists.

No approval transaction after the phishing click does not mean no authority

Uniswap and MetaMask both warn that Permit2 can rely on an off-chain signature. Signing does not itself have to produce a new blockchain transaction. The attacker can later submit the signed authorization and pay the gas from another account. This is why searching only for a transaction sent by the victim immediately after the phishing page can miss the dangerous step.

Build the Permit2 Incident Card

Before revoking random contracts, collect the authority that actually matters.

• Wallet address that signed
• Exact EVM network and chain ID
• Permit2 verifying-contract address
• Permit type: PermitSingle, PermitBatch, PermitTransferFrom, PermitBatchTransferFrom or unknown
• Token contract or contracts
• Spender address
• Maximum permitted amount
• Allowance expiration and/or signature deadline
• Nonce
• Whether the signature has already been used
• Current ERC-20 allowance from each affected token to Permit2
• Current Permit2 allowance from owner/token to the suspicious spender

Verdict 1 — you only connected the wallet

If you never signed typed data, never sent an approval and no later wallet action occurred, this is not yet a Permit2 approval incident. Disconnect the site, preserve the domain and review activity. Do not send a revocation transaction merely because the page displayed the word Permit2.

Verdict 2 — you approved the real Permit2 contract but signed no spender permit

An ERC-20 approval to the canonical Permit2 contract is Layer 1. By itself, it does not identify a malicious Layer-2 spender. Verify whether any suspicious Permit2 permit or transfer signature followed. If the approval was created only for a legitimate workflow and no hostile signature exists, classify the risk based on your trust and allowance policy rather than calling the canonical contract a scam.

Why a long-lived token-to-Permit2 approval still deserves review

Uniswap's current support documentation explains that users can make a one-time on-chain token approval to Permit2 and then authorize specific protocols by signature. The convenience means the Layer-1 approval can remain available for later Permit2 use. After a phishing incident, reducing or revoking unnecessary Layer-1 allowances can act as a broader containment measure for the affected token, but it can also interrupt legitimate Permit2-based apps.

Verdict 3 — you signed a suspicious AllowanceTransfer permit

Treat the token/spender pair as exposed until you prove that the permit is expired, invalidated or otherwise unusable. If it has already been submitted, inspect the Permit2 allowance(owner, token, spender) state. Permit2's AllowanceTransfer supports setting spender allowance to zero through its lockdown function and supports nonce invalidation for a token/spender pair.

A suspicious PermitSingle can be invalidated before it is used

AllowanceTransfer uses an ordered nonce for each owner/token/spender permission. The official contract exposes invalidateNonces, which advances the nonce and invalidates older signed permits for that pair. This is a technical mechanism, not a reason to call an unfamiliar contract manually. Prefer a reputable permission-management interface that explicitly handles Permit2, or verified contract tooling if you understand the calldata.

Verdict 4 — you signed a suspicious SignatureTransfer permit

SignatureTransfer uses an unordered nonce bitmap. Permit2 exposes invalidateUnorderedNonces so the signer can mark selected nonce bits as used, preventing a still-unspent signature with those nonces from being accepted later. A normal ERC-20 approval dashboard may not explain this signature state clearly, so verify that the cleanup tool supports Permit2 signatures rather than only conventional allowances.

Revoking the underlying token allowance is the broader token-level brake

Permit2's transfer functions ultimately rely on the ERC-20 token having approved Permit2. Removing the token's allowance to Permit2 can block Permit2 from pulling that token from the account through that Layer-1 path. This can be useful as emergency containment when you cannot yet reconstruct a suspicious signature, but it affects legitimate Permit2 workflows for the same token and network as well.

Do not confuse three different revocations

A complete cleanup can involve different controls, and they are not interchangeable.

• Disconnect dapp — removes the browser or wallet session; it does not erase on-chain allowances or signed permits.
• Revoke token → Permit2 allowance — removes or reduces Layer-1 ERC-20 authority for that token.
• Revoke/invalidate Permit2 spender authority or nonce — targets Layer-2 permissions or an unspent Permit2 signature.

If the malicious signature already moved tokens, revocation cannot reverse that transfer

Once the attacker has successfully used the signature and a token transfer is confirmed, the transfer itself is not undone by revoking future authority. Preserve the transaction hash, recipient, token, amount, chain and signature context. Continue containment because a PermitBatch or remaining allowance may expose additional tokens or future deposits.

Do not deposit more of the exposed token until authority is closed

A wallet can look safe after the attacker empties the current balance while a reusable allowance remains active. Depositing more of that token into the same account before revocation can create a second loss. Check both Layer 1 and Layer 2 and verify the resulting on-chain state before treating the account as safe for that asset.

A July 2026 incident shows why signatures deserve transaction-level urgency

In July 2026, crypto security reporting described a trader losing roughly $1 million after signing a malicious Permit2 authorization. The reported incident was phishing rather than a newly disclosed vulnerability in the Permit2 protocol itself. The practical lesson is that a 'Sign' prompt can create asset-moving authority even when the user is trained to look only for an 'Approve' transaction.

The official Uniswap app uses a bounded second-layer permission

Uniswap currently explains that its normal Permit2 flow starts with a token approval to Permit2 and then uses a signature approval for the protocol. Its support documentation says the Uniswap app uses a limited-time signature approval of 30 days. This is useful context when comparing a suspicious request: an unexpected unlimited-looking amount, strange spender, unrelated domain or excessive deadline should not be excused merely because Permit2 itself is legitimate.

Permit2 signatures can have both amount and time boundaries

Current Uniswap developer documentation says Permit2 messages can be time-limited and optionally amount-limited. Read those fields. A request to authorize substantially more than the intended swap or to remain valid long after the intended action deserves scrutiny even on a known dapp.

A signature from an old quote should not be reused

For Uniswap's current swapping API, the Permit2 signature belongs to the quote that produced it and may expire. Uniswap advises using the signature from the current quote rather than reusing an earlier one. A phishing site that asks you to paste or re-sign an old permit outside the intended transaction flow is therefore not following the normal swap lifecycle.

Check chain ID as well as addresses

Permit2's EIP-712 domain includes chain ID and verifying contract, giving signatures chain context. Investigate the network where the signature was requested and review approvals on that network. Do not revoke only Ethereum permissions if the suspicious signature was produced on Base, Arbitrum, Optimism or another EVM chain.

Smart accounts can use EIP-1271 signatures too

Permit2 supports contract-wallet signature verification through EIP-1271. If the affected account is a smart contract wallet rather than a normal EOA, do not assume that an ECDSA recovery tool tells the whole story. Use the smart account's own security controls and verify the Permit2 state for that account and network.

Use trusted cleanup paths, not search-ad revoke sites

MetaMask's current signature-phishing guidance explicitly points users to permission-management services such as revoke.cash and advises revoking malicious permissions. MetaMask also offers approval-management features for conventional allowances on supported networks. Navigate to such tools from a trusted bookmark or independently verified source. A fake 'revoke checker' can simply ask for another malicious signature.

If you cannot decode the signature, use a broad-but-bounded emergency response

If you know which token and network were involved but cannot determine the Permit2 subtype, stop interacting, revoke the suspicious token's allowance to Permit2 through a trusted interface, avoid depositing more of that token, and preserve the signed-message evidence for further analysis. This is broader than spender-specific invalidation but narrower than assuming the entire recovery phrase is compromised.

Do not rotate the seed phrase solely because of one Permit2 signature

A malicious Permit2 signature is serious authority over specified token permissions, but it is not automatically proof that the private key or recovery phrase was disclosed. If there is no evidence of key compromise, target the exposed approvals and tokens first. Migrate the wallet when separate evidence shows that the recovery secret, device or signing environment cannot be trusted.

Move exposed tokens when revocation cannot be completed safely in time

If a valuable token remains at immediate risk and you cannot confidently invalidate the malicious authority before it can be used, transferring the at-risk assets to a fresh trusted account can reduce exposure. This is an incident decision, not a substitute for revocation: an active permission on the old address can still affect tokens later deposited there.

Do not feed a sweeper by repeatedly adding gas

If native gas disappears immediately after every top-up, the incident may have progressed beyond a Permit2-only authorization into key compromise, a sweeper or another active mechanism. Stop repeated top-ups and move to the compromised-wallet workflow. A normal Permit2 ERC-20 authority does not by itself grant arbitrary control over the account's native ETH.

The five-minute Permit2 containment sequence

Use this order to avoid fixing the wrong permission.

• 1. Close the suspicious site and reject every new prompt.
• 2. Record wallet address, network, domain, time and the typed-data fields if available.
• 3. Identify token(s), spender, amount, deadline/expiration, nonce and Permit2 verifying contract.
• 4. Check whether the suspicious signature has already been consumed or created an active Permit2 allowance.
• 5. Review the underlying ERC-20 allowance from each exposed token to Permit2.
• 6. Use a trusted Permit2-aware permission tool or verified contract path to revoke/invalidate the relevant spender authority or nonce.
• 7. If the signature cannot be reconstructed quickly, consider revoking token → Permit2 for the exposed token as a broader brake.
• 8. Verify the resulting on-chain state before depositing that token into the account again.
• 9. Escalate to wallet migration only if key/device compromise or continuing unauthorized activity exists.

Use a six-verdict incident result

Finish with a concrete state rather than 'I revoked something.'

• NO PERMIT2 AUTHORITY — connection only; no relevant signature or allowance was created.
• LAYER 1 ONLY — token approved Permit2, but no hostile spender authorization was found.
• ACTIVE ALLOWANCE — suspicious Permit2 owner/token/spender allowance exists and must be zeroed or otherwise invalidated.
• UNSPENT SIGNATURE — malicious signed permit can still be actionable until expired or its nonce is invalidated.
• CONSUMED SIGNATURE — the permit was used; inspect transfers and remaining allowances for further exposure.
• KEY/DEVICE COMPROMISE — evidence exceeds Permit2 and requires full wallet incident recovery.

Why this page is separate from the normal approve guide

A normal ERC-20 approve transaction puts the spender directly into the token contract's allowance mapping. Permit2 adds an intermediate contract and can add off-chain EIP-712 authority, batch permissions and separate nonce systems. The existing approve-popup guide should teach what an approval means; this page begins after Permit2 is specifically suspected or signed and the user needs incident containment.

What can change after August 8, 2026

Wallet rendering, approval-manager support and dapp Permit2 policies can change. The durable security model is the Two-Layer Permit2 Authority Map: identify the token's allowance to Permit2, identify Permit2's spender or signed transfer authority, then determine whether the relevant signature is unused, consumed, invalidated or expired. Never treat the verifying-contract name alone as a trust decision.

Sources checked on August 8, 2026

Primary Permit2 code and current Uniswap and MetaMask security documentation were used for the authority model and containment steps; recent reporting was used only to illustrate current phishing activity.

• Uniswap Permit2 repository — architecture, AllowanceTransfer, SignatureTransfer and revocation mechanisms — https://github.com/Uniswap/permit2
• Uniswap Developers — Permit2 approval and current signing flow — https://developers.uniswap.org/docs/trading/swapping-api/concepts/permit2
• Uniswap Labs Support — What is a Permit2 approval? — https://support.uniswap.org/hc/en-us/articles/39683402190733
• Uniswap Labs Support — Crypto Wallet Signature Scams — https://support.uniswap.org/hc/en-us/articles/40050562560781-Crypto-Wallet-Signature-Scams
• MetaMask Help Center — Signature phishing and Permit2 — https://support.metamask.io/stay-safe/protect-yourself/wallet-and-hardware/signature-phishing/
• MetaMask Help Center — How to revoke smart contract allowances/token approvals — https://support.metamask.io/more-web3/learn/how-to-revoke-smart-contract-allowances-token-approvals/
• Crypto Briefing — July 2026 Permit2 phishing incident — https://cryptobriefing.com/trader-loses-1m-phishing-token-approval/

FAQ