Crypto Wallet Drained: Find the Cause Before You Act

Before you revoke, move or report anything, find out who signed the transactions that emptied the wallet. If your own address sent them, the key behind that address is exposed and only a new wallet closes the hole. If a different address pulled the tokens out, you granted a permission, and cancelling it can stop the next withdrawal. Neither path reverses a transfer that has already confirmed: the FBI's Internet Crime Complaint Center (IC3) describes cryptocurrency transactions as irrevocable, "meaning they cannot be reversed."

The mechanics below apply to accounts on Ethereum and other EVM chains. Bitcoin has no token approvals, so on Bitcoin only the key-exposure, malware, poisoning and exchange branches apply. If you are mid-incident, sign nothing on any website and hold off topping the wallet up with gas until the tree below tells you which case you are in, because in one branch that gas is taken and in another it is exactly what you need.

The triage tree

Open the drained address in a block explorer (our guide to reading a transaction on a block explorer covers the screens). Find the first transaction in which an asset left that you did not authorize, and read two fields: who sent the transaction, and, for a token, whose balance the Transfer event debited. Ethereum.org defines the transaction "from" field as the address that signs it, so "sent by your address" means your private key signed it. The tree starts there.

The transaction was sent by your address, to destinations you do not recognize, and more than one asset or address was hit.

Treat the key as exposed. The attacker can sign anything you can, so revoking approvals does nothing useful. Go to the key-exposure section.

The transaction was sent by your address, it was a single call, and you remember clicking something on a site just before it (a "claim", "verify" or "security update" button).

You authorized a malicious call. The key may still be private, but a single transaction cannot prove that, so treat the wallet as exposed unless the evidence below clears it.

The transaction was sent by a different address, and the token's Transfer event shows your address as the sender of the tokens.

A spender pulled the tokens using permission you granted. Look at your own address history just before the first theft.

You sent an approval (or a setApprovalForAll for NFTs): a token approval. Revoke it.

You sent nothing, yet tokens were pulled: you signed an off-chain message, a permit or a Permit2 or marketplace order. Go to the signatures section.

The address now has code attached (an explorer may label it as delegated), the draining transaction was sent by someone else, and you granted no approval.

A delegation under EIP-7702. Go to the delegation heading in the key-exposure section.

The transaction was sent by your address, you did mean to send, but the recipient is not the address you intended.

Compare the recipient with the address on the screen you copied from, character by character.

Your history shows a tiny incoming transfer from a lookalike just before: address poisoning.

You copied from a verified source and the pasted address still differed: clipboard-altering malware.

No transaction left a wallet you control. Funds disappeared from an exchange or other custodial login.

Account takeover. The keys were never yours to protect; the account credentials were.

Two cautions apply to the whole tree. It assumes an ordinary key-controlled account, not a multi-signature or smart-contract wallet, which fail in different ways. And attackers combine methods, so a clean result in one branch does not clear the others: someone with your key can also create approvals, and someone who tricked you into one signature may try again.

A hypothetical history, read four ways

The numbers below are invented for illustration. Suppose your account had sent 40 transactions before you sent one approval, so its account nonce (the counter ethereum.org describes as "a sequentially incrementing counter which indicates the transaction number from the account") is 41 after the approval. Four different drains then look like this.

Case (hypothetical)	Who sent the draining transactions	Your account nonce afterward	What else the chain shows
Key exposed	Your address, 6 transactions	41 + 6 = 47	Outgoing transactions you did not make
Approval pull	The attacker's address, 3 transferFrom calls	Still 41	Your own earlier approve, then Transfer events debiting you
Permit pull	The attacker's address submits the permit, then transferFrom	Still 41	No approve from you at all; the token's own permit counter for your address moves from 0 to 1
EIP-7702 delegation	A sponsor submits your signed authorization	41 + 1 = 42	The address now has code beginning 0xef0100

The account nonce and the token's permit nonce are two different counters. The first is kept by the chain for the account and rises with each transaction your address sends. The second is a per-token value, nonces(owner) in the EIP-2612 interface, that rises when a permit signed by you is used. Looking at only one of them is how people misread an approval pull as a stolen seed phrase, and the reverse.

Three things that make it worse

Three responses to a drain can add to the loss, and each is pushed by someone other than you.

Typing the recovery phrase anywhere. Ethereum.org says that "no legitimate service, support agent, or website will ever ask you for" a recovery phrase or private key. MetaMask's help centre goes further: never share it with anyone, "not even the MetaMask team, even though we will never ask you for this information," and report anyone who claims otherwise through its official support channels. A "wallet validation", "rectification" or "recovery" form that asks for the phrase is the same attack again, aimed at whatever you still hold.

Paying someone who promises the funds back. IC3's cryptocurrency page tells victims to "be wary of cryptocurrency recovery services, especially those charging an up-front fee," and the home page says IC3 "does not work with any non-law enforcement entity, such as law firms or crypto services, to recuperate lost funds" and "will never directly contact you for information or money." Canada's anti-fraud centre posts a similar warning: fraudsters "promise to help get your money back from a previous incident" and then ask for personal and financial information, and the centre states that it "does not contact individuals to request money." Our piece on crypto recovery scams walks through how these approaches are built. No page on this site, and no official page we read, names a service that can reverse an on-chain transfer.

Signing a "fix". A message or site that offers to cancel the damage, claim a refund, or "re-secure" the wallet wants a signature. After a drain, every signature request for the affected address is suspect until you know which branch you are in.

Token approvals: the one case where acting quickly can help

An ERC-20 approval is a standing permission recorded in the token's own contract. The EIP-20 standard defines approve as allowing a spender "to withdraw from your account multiple times, up to the _value amount," and says that calling it again "overwrites the current allowance." It defines transferFrom as the call a spender uses to move tokens, which "SHOULD throw unless the _from account has deliberately authorized the sender of the message via some mechanism." A drainer's whole trick is to get you to supply that deliberate authorization, often for the largest value the field allows.

That largest value is 2^256 minus 1, which is 115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,935 (about 1.158 times 10^77) in the token's smallest units. For a token with 6 decimals that is about 1.158 times 10^71 whole tokens, a number no balance can reach. An allowance set that high does not run down with use. It lasts until you overwrite it.

Revoking is therefore the same call with a zero in the amount field: approve(spender, 0). Four properties of that fix decide what it does and does not accomplish.

1.It is per token, per spender, per chain. The allowance mapping lives in each token's contract, and EIP-20 exposes it as allowance(owner, spender) on that contract. An approval on one chain says nothing about the same spender on another, so a revoke on one chain leaves the others as they were. If the drainer was active on several chains, repeat the check on each chain where you hold or held tokens.

2.It is an ordinary transaction. It needs gas in the chain's native currency, and until it confirms the allowance stands. Where the draining sender was another address, you can safely top up gas, because an allowance covers a token's balance and ether is not an EIP-20 token. The spender cannot pull it.

3.It closes one spender. If you granted three approvals on the same bad site, there are three to revoke.

4.It returns nothing. The tokens already moved stay moved.

Our token approvals and revoke guide has the step-by-step for finding and revoking allowances, including what it costs, so this page does not repeat it. The one thing to carry from there is order: check the sender first. If your own address signed the draining transactions, skip revoking and go to the key-exposure section, because the attacker can create a fresh approval the moment you clear the old one.

Signatures: the permission with no transaction to find

Some drains leave no approval transaction in your history because you never sent one. You signed a message, and the attacker's address submitted it.

EIP-2612 adds a permit function to a token. The standard says it "allows users to modify the allowance mapping using a signed message, instead of through msg.sender." The signed fields are the owner, the spender, a value, a nonce and a deadline. Three lines in the standard matter to a victim:

"The caller of the permit function can be any address." The attacker, not you, pays the gas and sends the transaction. That is why your own history stays clean.

The permit succeeds only if "the current blocktime is less than or equal to deadline" and the nonce matches your current permit nonce, which is then incremented. A deadline can be set to the maximum value so that a permit "effectively never" expires.

The standard calls the relayer's position "a free option to submit or withhold the Permit." A signature in an attacker's hands can sit unused and be played when your balance looks best.

Two consequences follow, and each is easy to get wrong.

Revoking does not cancel a signature that has not been used. The permit sets the allowance when it is submitted. If you run approve(spender, 0) first and the attacker later submits a still-valid permit, the allowance comes back, because a revoke does not touch the permit nonce. The route that works is to consume the nonce. You sign your own permit for the current nonce (for example for a value of 0, naming a spender you control) and submit it, which raises the nonce and makes the older signature fail the nonce check. The sentence in the standard that "if the signing party holds ETH they can also just submit the Permit themselves, which can render previously signed Permits invalid" describes the same mechanism from the other side, and applying it against a scammer's permit means submitting your own, never theirs. Handing a scammer's signed permit to the contract yourself would grant them the allowance.

That route has limits. It only works for a token that implements permit. It works only if the key is not exposed, since an attacker who holds the key can consume or reuse nonces too. It is a race against the attacker, who may submit first. And the standard notes that some tokens deployed before it, naming DAI, use a field called expiry in place of deadline, "not just a syntactic change" because it alters the signed message, so a generic tool will not fit them all. An unused permit is also invisible: it is an off-chain message, and no explorer can list signatures that were never submitted.

Moving the balance out only protects what is there now. A permit is a permission over the token, not a claim on a particular balance. If you move the tokens to a new address, the permit no longer matters for them, but any tokens of that type that arrive back in the old address before the deadline can be taken.

Permit2, Uniswap's shared approval contract, adds another layer. Its documentation says a user makes "a one-time standard ERC-20 approval of the Permit2 contract on that token, commonly for the maximum uint256 amount," after which spenders receive permissions through signatures. It has two modules: AllowanceTransfer, a standing time-bound allowance, and SignatureTransfer, a single nonce-scoped transfer that leaves no standing allowance. The interface code shows what a victim can cancel. AllowanceTransfer has lockdown, to batch-revoke approvals, and invalidateNonces, which invalidates every nonce lower than the value you set, with a documented cap of 2^16 (65,536) nonces per transaction. SignatureTransfer has invalidateUnorderedNonces, which spends nonce bits in a bitmap. Cutting off all Permit2 access for a token means revoking the underlying approval of the Permit2 contract on that token.

Revoke.cash, a third-party tool (a secondary source, and the maker of a revoke dashboard), makes the same observation about visibility. It says it cannot know which off-chain signatures you signed, so what its signatures tab lists is only potential signatures, and cancelling without being sure costs gas for nothing.

Key exposure: the case where the wallet itself is the problem

A recovery phrase is the key to every account derived from it. MetaMask's help centre calls it "the master key to your wallet," says "whoever controls the SRP controls the wallet," and says each account's private key is "derived from the SRP." Ledger's educational page makes the same point for a hardware wallet: "Anyone with access to your seed phrase can access all of your accounts." If your own address sent the draining transactions and you cannot name the transaction you signed, the safest reading is that the phrase or key is in someone else's hands.

What follows from that:

Every account from the same phrase is exposed, not only the one that was hit first. Anyone holding the phrase can also take whatever arrives later.

A hardware wallet does not change this if the phrase was typed or stored elsewhere. Ledger notes that if you have already typed a phrase onto an internet-connected device, or uploaded a copy, doing so "immediately compromises the security of your device." The phrase is the key, whatever device it was created on. Check that the device itself is real with our guide to verifying a hardware wallet is genuine.

Wiping the computer does not make the phrase private again. Wiping removes whatever is running on the machine. The attacker already holds a copy of the words. Revoke.cash, a secondary source, says the same: the phrase "is permanently compromised."

The replacement must have a new phrase, generated on a device you trust, and stored in the offline way MetaMask and Ledger both describe. Our seed phrase recovery checklist covers setting that up, so this page stops there.

The hard part is moving what is left. Every transfer out of the old address needs gas paid from that address, and the attacker can sign from it too. The nonce counts transactions in sequence, so only one transaction per nonce can be included, and your move and the attacker's can compete for the same slot. Any native currency you deposit to pay for the move can be spent by whoever holds the key. Revoke.cash says that attackers often run an automated "sweeper bot" that drains what arrives. That claim comes from a secondary source, and we found no primary source for how often such races are lost, so we cannot say any sequence of steps is safe. What the standards do support is limited: do not treat a small top-up as harmless, prepare the new address first, and expect that anything which cannot be moved in one step may not be recoverable by you. For a large balance, seek help from a qualified security professional you reached yourself rather than one who contacted you, and read the previous section first.

Delegation under EIP-7702, a newer route to the same account

EIP-7702 lets an ordinary account point at contract code. The authorization is a signed tuple of chain ID, address, nonce and signature. When it is processed, the account's code is set to 0xef0100 followed by the delegate address. The standard warns that "a poorly implemented delegate can allow a malicious actor to take near complete control over a signer's EOA." We did not fetch any data on which networks have activated the EIP, so check the chain you use before relying on this branch.

Three properties from the standard matter after a drain:

The chain ID can be 0. The standard says "the chain ID is 0 or the ID of the current chain," and "when universal deployment is preferred, simply set chain ID to 0." A signed authorization with chain ID 0 is not tied to the chain where you signed it, so check each chain you use for code on your address.

An unused authorization expires when the account nonce passes it. A tuple is valid only if the account's nonce "is equal to nonce." Sending any transaction from the account raises the nonce and invalidates one signed for the old value. This helps only if the attacker lacks your key.

Delegation can be cleared. If the delegated address is the zero address, the standard says not to write the indicator and to "clear the account's code." So the fix is to sign a new authorization naming the zero address, then confirm on each affected chain that the address shows no code.

Malware and clipboard swaps

MITRE ATT&CK, a public catalogue of attacker techniques, records the clipboard swap under Transmitted Data Manipulation. It says Melcoz "can monitor the clipboard for cryptocurrency addresses and change the intended address to one controlled by the adversary," and that Metamorfo watches for valid bitcoin addresses and "overwrites with the attacker's address." A separate entry says GlassWorm "can intercept and modify transaction details associated with hardware wallet applications before signing." The page was last modified May 12, 2026.

In a swap, you signed the transaction yourself and the key may be untouched. The loss is the transfer. Two practical facts follow from the entries above. First, a swap changes what is shown to you, so the check that catches it is comparing the recipient with the source you copied from, and, for a hardware wallet, the recipient the device itself displays, not only the computer screen. Second, clipboard malware can also read what you copy. MITRE's separate Clipboard Data entry notes that adversaries "may collect data stored in the clipboard," which includes anything you copied, such as a phrase, and Revoke.cash (secondary) describes fake apps that both scan for wallet data and replace copied addresses. If the phrase was ever copied, typed or photographed on that machine, move to the key-exposure branch. If it never was, the remaining job is cleaning or replacing the device before you use it for anything valuable, and changing the passwords of exchange and email accounts that were open on it.

Revoke.cash lists the entry points it sees most: fake apps sent through social media, and prompts to paste text into a terminal or a Run window. We cite that as a secondary description rather than a measured share.

Address poisoning and exchange takeovers

Two branches have no on-chain repair, which is why the table below shows nothing to revoke for them.

Address poisoning copies the first and last characters of an address you use, then plants it in your history with a tiny transfer so that you copy the wrong one later. Your key was not touched, your other balances are safe, and the loss is the transfer you made. The address poisoning explainer covers how to verify an address and what to do if funds went to a lookalike.

Exchange account takeover is a credentials problem. IC3's account takeover page lists the routes: brute-forcing a weak password, phishing emails and domains, social engineering that impersonates support, data breaches, malware, and search-engine ads that lead to a fake login page where "cyber criminals then capture victims' credentials." For the response it lists contacting the institution involved, resetting every credential that may have been exposed, and filing a detailed IC3 complaint using the key words "account takeover." The FTC's cryptocurrency page adds the exchange company you used to the list of places to report to. We cannot describe what a given exchange does with such a report, and no page we read says any exchange will reverse a withdrawal.

What each fix closes and what it leaves open

This table is organized by the type of compromise, not by tool, so you can see what remains after the step you just took. The first six rows cover cases that revoke-only advice does not reach. The last three are the more familiar ones.

Compromise	A step that helps	Still open afterward	What closes the rest
Clipboard-swap malware	Clean or replace the device	The transfer already sent; any phrase, password or file that was on the device	Treat any secret that touched the device as exposed
Address poisoning	Nothing to revoke	The transfer already sent; the next lookalike	Verify the full address against the source each time
Exchange account takeover	Reset credentials and enable two-factor authentication on the account	Withdrawals already made; the email account or reused password that opened the door	Contact the platform; file with IC3 using the key words "account takeover"
EIP-7702 delegation	Re-delegate to the zero address	Delegations on other chains; an unused chain-ID-0 authorization until your nonce passes it	Check each chain for code on the address
Allowance on a different chain	Revoke on the chain you checked	The same spender on every other chain	Repeat per token, per spender, per chain
Later deposits of the same token	Revoke the approval	A still-valid permit signature, or a Permit2 allowance, can take new deposits	Cancel the nonce or lock down Permit2 before depositing again
Approval pull	Revoke that spender	Tokens already moved; other approvals	Review every approval, then report
Unused permit signature	Consume the nonce with your own permit	An attacker who submits first; any attacker who holds your key	Move the balance and stop depositing that token
Exposed phrase or key	A new wallet with a new phrase	Everything still in the old accounts	Move it, knowing the gas problem above

What the chain can show you, and what it cannot

The ledger is public, and that cuts two ways. The FTC's cryptocurrency page says transactions "will typically be recorded on a public ledger," and that "it's sometimes possible to use transaction and wallet information to identify the people involved." IC3 says law enforcement "can trace cryptocurrency transactions to follow money in ways not possible with other financial systems," and also that following funds into other jurisdictions, "especially those with lax anti-money laundering laws or regulations," is hard.

For a victim that means three things.

You can see where the funds went, one hop at a time, by reading outgoing transactions from the destination address on the explorer. That produces a list of addresses, not a name.

An address is not an identity. A destination may be the attacker's own wallet, an intermediate address, or a deposit address at an exchange where it belongs to an account holder only that exchange can identify. Identification is the job of investigators with legal process, not of an explorer.

The explorer shows only what was submitted. Unused signatures, including permits, never appear. An unauthorized approval does appear, as an Approval event, because EIP-20 says the event "MUST trigger on any successful call" to approve, in tokens that follow the standard.

How a stablecoin issuer handles a stolen balance is a separate question, covered in whether Tether and Circle can freeze stablecoins. It is a decision by the issuer, and nothing on this page assumes any outcome.

Where to report, and what to record first

IC3 asks for the cryptocurrency details that the chain already holds. Its page lists "cryptocurrency addresses; the amounts and types of cryptocurrencies; transaction hashes; and the dates and times of the transactions," along with how you met the scammer, platforms used, and any domains or phone numbers involved. The FBI's 2023 guidance for crypto scam victims adds the exchanges you used, any one-time passcodes you gave, and a timeline, and says "Do not wait."

IC3's FAQ adds the practical limits. It does not accept attachments or collect evidence, so keep the originals. A complaint cannot be cancelled once filed, and new information goes in a new complaint. You will not receive a copy by email: "save or print a copy of your report before closing this window." The FBI says it cannot respond to every complaint, and, because investigation is at the discretion of the receiving agencies, to "contact local law enforcement directly if you believe your matter is time sensitive." Elder victims aged 60 or over can call the National Elder Fraud Hotline at 833-372-8311 for help filing.

The FTC's cryptocurrency page lists where to report: ReportFraud.ftc.gov, the CFTC, the SEC, IC3 and the exchange company used. It also states the limit plainly: if a wallet is "stolen or compromised," you are "likely to find that no one can step in to help you recover your funds." Both of those statements are reasons to report for the record, not promises about the outcome.

In Canada, the anti-fraud centre says it "collects information on fraud and identity theft," and its reporting system is at reportcyberandfraud.canada.ca. Reports in the UK and other countries, and the evidence pack in detail, are in our guide to how to report a crypto scam.

Records for the reports and for tax

Whatever you file, keep one dated record with each transaction hash, the sending and receiving addresses, the token and amount, and a UTC timestamp. A short list is enough: the explorer link for each draining transaction, the approval or signature that enabled it if you found one, the site or message that preceded it, and the date you first noticed.

The same record serves a tax question in the United States, where the rules are narrow. IRS Topic 515, reviewed September 24, 2026, defines theft as "the taking and removal of money or property with the intent to deprive the owner of it," which must be illegal under state law and done with criminal intent. It says that since 2018 individuals can deduct a personal casualty or theft loss only if it is attributable to a federally declared disaster, while individuals "may also be able to deduct theft losses incurred in a trade or business or a transaction entered into for profit." Publication 547 (2025 edition) says victims of certain financial scams may claim a theft loss under section 165 if three conditions apply: the loss results from criminal conduct classified as theft under state law, the taxpayer has "no reasonable prospect of recovering the stolen funds," and the loss arises from a transaction entered into for profit. It points to IRS advice memorandum 202511015 for more. Topic 515 adds that a theft loss is generally deductible in the year you discover it, unless a reimbursement claim has a reasonable prospect of recovery, in which case the deduction waits until you can determine that "with reasonable certainty." Losses are reported on Form 4684.

None of that text says how it applies to a particular wallet drain, and we do not claim it does. Which category a loss falls into depends on facts only you and a qualified tax professional can assess. Our United States crypto tax explainer covers the rest of the reporting rules. We did not research Canadian, UK or other tax treatment for this page.

When the immediate danger has passed, the replacement wallet is the next job, and the seed phrase recovery checklist shows how to build one whose phrase has never touched a connected device. The wider self-custody and security hub collects our other guides on keeping keys and signatures safe.

Frequently Asked Questions

Can I get my crypto back after my wallet is drained?

There is no mechanism that reverses a confirmed on-chain transfer. IC3 describes crypto transactions as irrevocable, and the FTC says that if a wallet is stolen or compromised no one can step in to help you recover your funds. Reporting creates a record and sometimes leads to action by law enforcement, but neither agency promises a return. Treat any party that guarantees recovery as a scam.

How do I tell whether my seed phrase was stolen or I approved something?

Check who sent the draining transactions. If your own address sent them and you did not, someone has your key, and a new wallet with a new phrase is the fix. If a different address sent them and your history shows an earlier approve, you granted a token approval. If it shows nothing from you at all, a signed permit or order is the likelier route.

Should I send ETH to my drained wallet to pay for a revoke?

Only if the draining transactions were sent by another address and your own address sent none. In that case a token approval cannot pull ether, so the gas is not exposed. If your own address sent them, whoever holds the key can sign a transaction that spends any gas you deposit. A secondary source reports automated bots doing this; we found no primary data on how often.

Does revoking an approval cancel a permit I already signed?

Not if the permit has not been submitted. A revoke sets the allowance to zero, but a valid permit sets it again when submitted, because revoking leaves the permit nonce alone. Cancelling means consuming that nonce with a permit or transaction of your own, which works only for tokens that support permit, and only if your key is not exposed. Once a permit has been used, it is an ordinary allowance and can be revoked.

Can a hardware wallet be drained?

The device keeps the key offline, but it cannot protect a phrase that was typed into a website or stored on a connected device, and it will sign whatever you approve on it. Ledger's educational page says that uploading a copy of the phrase to the internet compromises the device's security. MITRE also lists malware that modifies transaction details shown by hardware wallet applications before signing.

Someone messaged me offering to trace and recover my funds. Is that legitimate?

Assume not. IC3 says it does not work with law firms or crypto services to recuperate lost funds and will not contact you for money or information, and it warns against recovery services that charge up front. Canada's anti-fraud centre warns of fraudsters who promise to help get money back. Report the message to IC3 or the CAFC, and do not share a phrase, a screen or a payment.

Can I deduct a crypto theft on my US taxes?

IRS text allows a theft loss deduction in some cases, but for individuals it is limited to losses attributable to a federally declared disaster or incurred in a transaction entered into for profit. Publication 547 sets three conditions for financial scams, including no reasonable prospect of recovery. How that applies to a drain is a question for a qualified tax professional, and this page does not cover other countries.

Sources

EIP-20: Token Standard: approve, allowance and transferFrom semantics, the overwrite rule and the Approval and Transfer events. Checked October 23, 2026.

EIP-2612: Permit Extension for EIP-20 Signed Approvals: permit fields, nonce and deadline rules, relayer text and the DAI expiry note. Checked October 23, 2026.

EIP-7702: Set Code for EOAs: authorization tuple, chain ID 0, nonce check, code indicator and clearing with the zero address, and the security considerations. Checked October 23, 2026.

Ethereum.org: Transactions: the from field, signature and nonce definitions. Checked October 23, 2026.

Ethereum.org: Crypto security: recovery phrase guidance, unlimited spend limit warning. Page last updated June 6, 2026. Checked October 23, 2026.

Uniswap Permit2 documentation: the one-time approval, AllowanceTransfer and SignatureTransfer. Checked October 23, 2026.

Uniswap Permit2 IAllowanceTransfer.sol: lockdown and invalidateNonces, with the 2^16 cap. Checked October 23, 2026.

Uniswap Permit2 ISignatureTransfer.sol: invalidateUnorderedNonces. Checked October 23, 2026.

MetaMask Help Center: secure your Secret Recovery Phrase and password: the phrase as master key, per-account keys, sharing warnings. Checked October 23, 2026.

Ledger Academy: best ways to protect your recovery phrase: anyone with the phrase can access all accounts; internet exposure. Checked October 23, 2026.

MITRE ATT&CK T1565.002: Transmitted Data Manipulation: Melcoz, Metamorfo and GlassWorm entries. Version 1.1, modified May 12, 2026. Checked October 23, 2026.

MITRE ATT&CK T1115: Clipboard Data: clipboard collection and replacement. Checked October 23, 2026.

FBI IC3: Cryptocurrency: irrevocable transactions, tracing limits, what to report, recovery-service warning, elder fraud hotline. Checked October 23, 2026.

FBI IC3: home page: no work with firms to recuperate funds, impersonation warning, response limits. Checked October 23, 2026.

FBI IC3: FAQ: no attachments, saving a copy, no cancellation, local police for time-sensitive matters. Checked October 23, 2026.

FBI IC3 PSA I-082423-PSA: guidance for cryptocurrency scam victims: items to provide and "Do not wait". Checked October 23, 2026.

FBI IC3: Account Takeover Fraud: takeover methods and response steps. Checked October 23, 2026.

FTC: What To Know About Cryptocurrency and Scams: public ledger, no recovery help for compromised wallets, where to report. Checked October 23, 2026.

Canadian Anti-Fraud Centre: impersonation alert and the reporting-system link. Checked October 23, 2026.

IRS Topic no. 515: Casualty, disaster, and theft losses: theft definition, personal-loss limit, timing rule, Form 4684. Reviewed September 24, 2026; checked October 23, 2026.

IRS Publication 547 (2025): Casualties, Disasters, and Thefts: the three financial-scam conditions and the reference to advice memorandum 202511015. Checked October 23, 2026.

Revoke.cash: What to do when scammed, seed phrase compromise, and permit signatures: secondary source from a revoke tool, used only for the sweeper-bot description, the point that wiping a device does not restore a phrase, and that unused signatures cannot be listed. Checked October 23, 2026.

CryptosEyes publishes general educational research, not investment, legal, or tax advice. Nothing here can recover stolen assets or tells you how a particular loss is treated for tax; it describes how wallet permissions work and what official agencies publish. If you have lost funds, report it through the official channels above and consult a qualified professional about your own situation.