What Authority Did the Airdrop Claim Obtain—and Which Assets Can Still Be Saved?

After a suspicious airdrop claim, forget the promised token and protect the wallet. Do not return to the claim page, do not sign its cancellation or verification prompt, and do not send gas into an address that may be swept. The correct response depends on the highest authority actually granted: connection, authentication signature, permit, token or NFT approval, contract transaction, or control of the recovery secret or device.

Run the First-30-Minute Survival Order

Do the containment work before trying to understand whether the airdrop was real.

• Minute 0–2 — close the site and reject every new prompt
• Minute 2–5 — record the address, network and suspicious domain
• Minute 5–10 — check outgoing transfers and approvals on-chain
• Minute 10–15 — identify the highest authority granted
• Minute 15–20 — disconnect or revoke only through trusted tools
• Minute 20–30 — migrate remaining assets if key or device control is uncertain
• After containment — preserve evidence, report and complete a device and account review

Step 1 — stop the claim sequence completely

Close the tab, reject pending wallet confirmations and do not use a Revoke, Cancel, Validate or Recover button supplied by the same page. A drainer can use a second request to expand the first permission or trick the user into signing the actual transfer.

Do not interact with the unsolicited token or NFT

Receiving an unfamiliar airdrop does not compromise a wallet by itself. The danger begins when the user visits a link, tries to sell the token, signs data or calls its contract. Hide or report the asset instead of following metadata instructions.

Step 2 — freeze the incident facts

Record the complete wallet address, selected network, suspicious domain, time, browser or app, transaction hashes, signature prompts, token contracts and assets present before the claim. Screenshots help, but on-chain addresses and hashes are the durable evidence.

Check every chain touched by the claim

A 0x account can hold assets and approvals across several EVM networks. Solana, TRON and other ecosystems use different permission models and tools. Do not inspect Ethereum only because the wallet address begins with 0x or the page advertised an Ethereum token.

Use the Seven-State Authority Board

Classify the highest confirmed state. The response is determined by the highest state, not by the first button clicked.

• State 1 — viewed the page or unsolicited token only
• State 2 — connected the wallet
• State 3 — signed a readable login message
• State 4 — signed a permit, Permit2 or unknown typed message
• State 5 — granted token or NFT approval
• State 6 — signed a transfer or malicious contract transaction
• State 7 — exposed seed, private key, recovery file or compromised device

State 1 — no wallet action occurred

Close the site, clear the phishing path and report the token or page. Confirm that no connection, signature or transaction exists in the wallet activity. No revocation or migration is required solely because an unsolicited token appeared.

State 2 — connection only

Remove the domain from the wallet’s active-session registry. A plain connection reveals the chosen public account and opens a channel for later requests, but it does not automatically write a token allowance or move an asset.

Disconnection is not revocation

Ending the browser or wallet session only closes that communication channel. Permissions already recorded on-chain survive it, and some signed typed data can remain usable. Audit allowances and signed actions even after the domain disappears from the session list.

State 3 — readable authentication signature

Inspect the exact domain, account, statement, nonce, chain and expiry. A normal sign-in message may create a web session rather than spending authority. Log out, revoke the site session where possible and change credentials if the signature authenticated an account the attacker can now use.

Treat unreadable or mismatched signatures as higher risk

A message described as login can contain structured data for an order, permit or delegated action. If the wallet preview was opaque or the domain and purpose did not match, classify it as State 4 until the signed data is decoded.

State 4 — permit or typed-data authority

ERC-2612 permits can change an ERC-20 allowance from signed data instead of a normal approval transaction. Decode the token contract, authorized spender, signed value, current nonce and expiration timestamp. A stolen signature may be relayed later even though the wallet showed no approval transaction when it was signed.

A permit response is token- and protocol-specific

Identify the verifying contract, token, spender, amount, nonce and deadline. Check whether an allowance has already been submitted on-chain. Use the token, wallet or protocol’s trusted allowance manager to invalidate or reduce authority where supported. If the scope cannot be bounded quickly, moving the affected assets to a fresh address can be safer than waiting for the signature to be used.

State 5 — ERC-20 approval

An approval lets the spender move the selected token up to the remaining allowance. Review the token contract, spender, network and amount through the wallet or a trusted block-explorer approval checker. Revoke suspicious authority on-chain and confirm that the remaining allowance is zero.

Check NFT approvals separately

A single-NFT approval covers one token ID, while an operator or Approve All permission can cover an entire collection. Remove the exact NFT authority and verify the operator status. An ERC-20 allowance review does not prove that NFT permissions are clean.

Prioritize assets inside the approval scope

A standard token approval is scoped to a token contract, spender, network and owner address. It does not automatically expose every coin or every account. Protect assets the spender can move first, while continuing to investigate signatures and key exposure that could broaden the incident.

State 6 — signed transaction or contract call

Inspect the transaction on the relevant explorer and decode transfers, approval events, swaps, delegations, NFT movements and ownership changes. Once the chain accepts the call, closing the page or ending the session cannot unwind its effects. The decoded execution—not the website button—defines the incident.

A failed claim transaction can still be a lure

Some airdropped tokens are designed so a transfer or swap fails and the explorer error points to another malicious site. A failed transaction can consume gas without moving the advertised token. Do not follow URLs embedded in token metadata, revert messages or explorer comments.

State 7 — seed phrase or private key exposure

Assume the root secret is burned. Every address generated from that phrase or key can be controlled by the attacker. Approval cleanup cannot remove key-level access. Generate an unrelated recovery secret in a trusted environment and move any assets that can still be saved.

A new account under the same seed is not a clean wallet

Adding another address inside the compromised recovery set changes the address, not the underlying authority. The replacement wallet must originate from unrelated key material that was never entered on the suspect page or stored on the affected device.

Treat malware or remote access as device-level compromise

If malware, a fake extension or remote-control software may be involved, isolate and clean the environment before generating replacement keys. Remove unknown software, update the system, scan it, and secure browser-sync, email and cloud accounts that could recreate the breach.

Recognize a sweeper before funding rescue gas

A sweeper monitors a compromised address and automatically transfers new native coins or uses them to extract other assets. MetaMask and Phantom both warn that depositing more funds can feed the bot. Repeated small top-ups are not a safe diagnostic test.

Private-bundle rescues are specialist operations

Some EVM rescues use private transaction bundles so a sponsor transaction and asset-removal transaction reach a block together without exposing the funding in the public mempool. This is network-specific, technically demanding and not guaranteed. Do not hand the recovery phrase to a stranger offering to run it.

Use the Asset-Scope Triage

List every remaining value and the authority that could move it.

• Native coins controlled by the account key
• ERC-20 or equivalent tokens with active allowances
• NFTs with single or collection approvals
• Staked, lent, bridged or liquidity-position assets
• Claimable rewards and vesting positions
• Other accounts under the same recovery secret
• Assets on chains not shown in the current wallet view

Choose revoke-first only when the key remains trusted

If the evidence shows one malicious approval and no unauthorized signatures, transfers, seed exposure or malware, disconnecting and revoking can be sufficient. Confirm the approval removal and monitor the affected token and address.

Choose migrate-first when key or device control is uncertain

When unauthorized native transfers, sweeper behavior, seed exposure or malware is present, a new wallet is the security boundary. Move safe assets from a clean environment using the least exposed route. The old wallet should not receive future funds.

Do not rescue the worthless airdrop before real assets

The suspicious token can remain hidden. Prioritize native coins, established tokens, NFTs and positions with verifiable value. Trying to sell or burn the scam token can trigger another contract call or phishing path.

Build the Drainer Evidence Packet

Save the claim URL, referral or social post, wallet prompts, signed message data, transaction hashes, token and spender contracts, attacker addresses, asset amounts, times and support conversations. Keep a plain-language timeline that links every action to its evidence.

Report without expecting reversal

Report the domain to the wallet provider, browser or host, label malicious addresses where explorers allow it, and send evidence to any exchange or authority that can investigate. Reporting may protect other users or flag later centralized deposits, but a finalized chain transfer normally cannot be rolled back.

Block the recovery-scam second wave

Scammers monitor public posts about drained wallets and send private offers to recover funds. Do not pay an upfront fee, install remote software, connect to a recovery dapp or share the seed phrase. No legitimate helper can guarantee reversal of a confirmed transfer.

Monitor the old wallet after containment

Watch for delayed permit use, remaining approvals, new outgoing transactions and attacker funding. Do not mistake inactivity for restored security. A compromised seed remains compromised even when the attacker stops moving funds.

Complete the device and account postmortem

Review browser history, extensions, downloads, clipboard tools, password reuse, cloud seed backups and social accounts that delivered the link. Rotate relevant passwords and sessions. Record the original attack path so it is not recreated on the replacement wallet.

Use a separate airdrop wallet in the future

Airdrop, mint and unfamiliar dapp activity should use a low-value wallet under a separate recovery boundary. Keep long-term assets and high-value NFTs in a wallet that never signs experimental claim transactions. Revoke permissions after the experiment ends.

Worked approval-only incident

The user connected to a fake claim page and granted unlimited USDC approval, but no other transaction or secret exposure exists. The user closes the site, disconnects, revokes the USDC spender on-chain, verifies zero allowance and monitors the wallet. Migration is optional based on the remaining evidence.

Worked permit-signature incident

The wallet shows no approve transaction, but the user signed typed data naming a token, spender, amount and deadline. The user treats it as live authority, checks whether the permit was submitted, invalidates or limits the allowance through the trusted token or protocol path and moves the exposed token when the scope cannot be confirmed.

Worked seed-and-sweeper incident

The claim page collected twelve recovery words. Later, each small ETH deposit is forwarded before the owner can act. The owner ends all top-ups, rebuilds the environment, generates unrelated keys and treats any remaining rescue as a specialist operation rather than continuing to use the old address.

The incident-response rule

Disconnect for a connection. Decode a signature. Revoke an approval. Analyze a transaction. Migrate after seed or device compromise. Never let the apparent value of an airdrop outrank the authority the claim obtained over the wallet.

Primary incident references — 30 July 2026

Wallet-provider, protocol and Ethereum documentation below supports the authority classification and containment sequence used in this response plan.

• Phantom drained-wallet response, disconnect, revoke and migrate: https://help.phantom.com/hc/en-us/articles/5487893286291-I-was-scammed-or-my-wallet-was-drained-What-can-I-do
• Phantom current scam-analysis tools: https://help.phantom.com/hc/en-us/articles/37416944587795-Tools-to-help-you-avoid-crypto-scams
• MetaMask unauthorized-transaction response: https://support.metamask.io/stay-safe/protect-yourself/ive-been-hacked-scammed-unauthorized-transactions-on-my-account/
• MetaMask sweeper-bot guidance: https://support.metamask.io/stay-safe/protect-yourself/fighting-back-against-sweeper-bots/
• MetaMask approval revocation: https://support.metamask.io/more-web3/learn/how-to-revoke-smart-contract-allowances-token-approvals/
• MetaMask failed-airdrop-token transaction scams: https://support.metamask.io/stay-safe/protect-yourself/tokens-and-transactions/failed-transaction-scams/
• Coinbase connection, ERC-20 and NFT approval distinctions: https://help.coinbase.com/en/prime/onchain-wallet/dapp-permissions-and-token-approvals
• ERC-20 allowance and transferFrom standard: https://eips.ethereum.org/EIPS/eip-20
• ERC-2612 permit, nonce and deadline model: https://eips.ethereum.org/EIPS/eip-2612
• Ethereum scam reporting and recovery-scam warning: https://ethereum.org/community/support/scams/

FAQ