Home
Tools
Education
Account

Security

What to Do After a Crypto Scam, Wallet Hack, or Unauthorized Transfer

Spot the edge. Swoop in.

A step-by-step incident-response sequence for the period right after a crypto scam, wallet compromise, or unauthorized transfer — what to do first, what to preserve, and how far recovery realistically goes.

See the first 15 minutes Security Center

By Swoopr Editorial Team

Published · Updated

AI-assisted content · Swoopr is responsible for the final published article.

What to Do After a Crypto Scam

This guide is a sequence, not a menu — the order matters because early actions (moving remaining funds, revoking approvals) can still limit the damage, while later actions (reporting, documentation) mostly affect whether the incident is ever traceable or recoverable at all. Work through it in order rather than jumping straight to whichever step feels most urgent.

Direct answer: Disconnect from suspicious sites, stop communicating with the attacker, secure email and exchange accounts, and record transaction identifiers. The strongest approach contains the incident first, protects everything not yet touched, and only then moves to documentation, reporting, and expectation-setting.

Key Takeaways

First 15 Minutes

The first 15 minutes decide how much damage stops here versus keeps compounding. If a seed phrase, private key, or wallet-connect session was exposed, assume every asset reachable by that key is at risk until proven otherwise — don't wait to confirm the scam is "real" before acting. Prioritize in this order: disconnect the compromised device or browser tab from the malicious site, end any wallet connection to it, and stop replying to the attacker, since continued contact is often used to extract more information or stall you while remaining balances are drained.

Practical checklist

Common mistake

The common mistake in the first 15 minutes is spending them trying to understand exactly how the attacker got in. Diagnosing the exact phishing vector can wait; every extra minute spent investigating is a minute a still-connected approval or session can be used to drain additional funds.

Protect Unaffected Assets

Before moving anything, confirm the device you're using now is not the compromised one — malware or a malicious browser extension on the original device can capture a new seed phrase just as easily as the old one. Generate a brand-new wallet on a clean device, then transfer any surviving assets from wallets that were never connected to the incident, using addresses you type or scan fresh rather than a copied link from chat history or email.

Practical checklist

Common mistake

The common mistake is rushing to "save" remaining funds by sending them from the same compromised device, which can hand the attacker the credentials for the new wallet too if active malware or a malicious extension is still installed.

Revoke Approvals

Many crypto scams work by tricking a wallet into approving a malicious smart contract to spend tokens, rather than by taking the seed phrase directly. Use a token-approval checker for the specific network the wallet operates on — approvals are per-chain, so a contract approved on one network won't show up when checking another — and revoke anything unrecognized or unlimited in scope, not just the approval tied to this incident.

Auditing approvals before there's an incident

Approval reviews are usually treated as something to do only after a compromise, but the same check on a routine schedule closes off an entire category of scam before it starts. Every dApp connection, NFT mint, or DeFi deposit that ever asked for token spending permission leaves a standing approval behind, and most wallets never surface those permissions unless someone goes looking. The distinction that matters most is unlimited versus capped allowances — many dApps request approval for an effectively infinite amount rather than the specific amount needed for that one interaction, and an unlimited approval to an abandoned or since-compromised contract is a standing liability with no expiration date. Reviewing and revoking these quarterly, independent of whether anything has gone wrong, is one of the few genuinely preventative habits in crypto security.

Practical checklist

Common mistake

The common mistake is revoking only the one approval tied to the immediate incident and assuming the wallet is now safe, while other unrelated approvals granted months earlier stay active and exploitable.

Contact Platforms

Contact any exchange or custodian the stolen funds passed through, or that the compromised wallet is linked to, as soon as possible — some exchanges can freeze funds that land in an account before they're withdrawn or converted, but only within a narrow window. Lead with the transaction hash, sending and receiving addresses, and the approximate time of the transfer rather than a general description; support teams can act faster on specific identifiers than on a narrative.

Practical checklist

Common mistake

The common mistake is contacting only the platform where the theft occurred and skipping the destination platform the funds moved to, which is often the only party with any actual ability to freeze or flag them.

Preserve Evidence

Evidence collected in the first day is far more complete than what you'll be able to reconstruct later — phishing sites get taken down, chat histories get deleted, and exact wording fades from memory. Capture full-page screenshots, not just crops, of the malicious site, wallet transaction confirmations, and any attacker messages, and export the raw transaction data from a block explorer rather than relying on a wallet app's summary view.

Organizing evidence so it holds up across multiple reports

The same evidence typically gets submitted to several recipients over the following weeks — a police report, an exchange fraud team, possibly a tax preparer — and each asks for it differently. Organize the raw material once into a single folder, with unedited originals kept separate from any cropped or annotated copies made for readability; some intake forms explicitly ask for unedited files because metadata can matter to their verification process. It's also worth keeping a dated log of every report filed, since the same evidence often needs resubmitting weeks later.

Practical checklist

Common mistake

The common mistake is paraphrasing what happened from memory a few days later instead of preserving the original screenshots and transaction data, which weakens every report filed afterward and can't be reconstructed once a phishing site goes offline.

Report the Incident

Filing a report rarely returns funds directly, but it feeds databases that exchanges and investigators use to flag addresses and connect related cases — a report that seems to go nowhere can still matter months later if the same address resurfaces elsewhere. In the US this generally means a report to the FBI's Internet Crime Complaint Center (IC3) and, for larger losses, a local police report that some platforms require before they'll act.

What law enforcement and exchange fraud teams actually need

Reports that move fastest lead with structured identifiers instead of a narrative account of what happened. An intake officer or fraud analyst working through a queue of cases can act on a transaction hash, a pair of wallet addresses, and a timestamp far more quickly than on a paragraph describing the scam's backstory — the narrative still matters, but it belongs after the identifiers, not instead of them. Concretely, that means having the transaction hash and a block explorer link ready before starting the report; the sending and receiving addresses written out in full rather than truncated; the exact date and time with timezone, since blockchain timestamps are typically UTC; and the USD (or local currency) value of the loss at the time it occurred. A short, factual description of the scam mechanism — phishing site impersonating a known platform, fake customer support, a malicious airdrop — helps investigators recognize a pattern faster than a blow-by-blow account of the conversation that led up to it.

Practical checklist

Common mistake

The common mistake is skipping the report because the loss feels too small or recovery feels unlikely — reports are cumulative evidence, and an address linked to dozens of small reports is far more likely to get flagged than one linked to none.

Set Realistic Expectations

Blockchain transactions are designed to be irreversible — there is no equivalent of a card-network chargeback, and no company, including Swoopr, can reach into a wallet or contract and pull funds back. The realistic paths to recovery are narrow: an exchange freezing funds before withdrawal, a law-enforcement seizure following an investigation, or, rarely, a smart-contract exploit where the protocol itself can intervene. Most scam losses are never recovered, and that outcome doesn't mean the earlier steps were wasted effort.

Practical checklist

Common mistake

The common mistake is treating "recovery is possible" as "recovery is likely" and delaying other steps — securing remaining accounts, revoking approvals, reporting to platforms — while waiting on a resolution that may never come.

Avoid Secondary Scams

Being the victim of a scam makes someone a target for a second one — "recovery agents" and "blockchain investigators" who contact victims directly, often within days of a loss becoming visible on-chain or after a public report, are overwhelmingly fraudulent. No legitimate recovery process requires an upfront fee, a seed phrase, or remote access to a device, and no legitimate law-enforcement or exchange contact reaches out first through social media or a comment on a forum post.

Practical checklist

Common mistake

The common mistake is that someone already stressed about losing money is primed to accept an offer that demands acting fast and paying a fee "to unlock the recovery" — that urgency-plus-fee combination is the reliable tell of a fraudulent recovery scheme, not a sign it's legitimate.

Worked Decision Example

Hypothetical example — for education only.

Assume a reader controls three wallets and discovers Wallet A was compromised through a phishing site that captured its seed phrase.

Situation

Reasoning

Wallet A's seed phrase is exposed, so any asset still sitting in it should be assumed reachable by the attacker at any moment — moving what's left is urgent, but only from a known-clean device. Wallet C's seed phrase was never exposed; its risk is a malicious contract approval, not a compromised key, so the priority there is revoking the approval, not migrating to a new wallet. Wallet B was never connected to the incident at all and needs no action beyond normal security hygiene.

Resulting priority order

  1. Revoke Wallet C's approval to the malicious contract — lowest effort, closes an active risk.
  2. Move any remaining balance out of Wallet A from a known-clean device — highest urgency, the seed phrase is burned.
  3. Leave Wallet B alone; monitor it as part of normal account hygiene.

The example shows why "protect unaffected assets" and "revoke approvals" are treated as parallel first steps rather than a single instruction — the correct action depends on which failure mode, an exposed key or a malicious approval, applies to each wallet.

Misconceptions Versus Reality

MisconceptionReality
A paid "recovery service" can reliably get stolen crypto backNearly all unsolicited recovery services are secondary scams; legitimate recovery happens through exchange freezes or law enforcement, not a paid third party
Reporting to police is pointless because crypto is anonymousReports are cumulative evidence used to flag addresses and connect cases; many transactions are traceable on a public blockchain even when identities aren't obvious
If the transaction already confirmed, nothing more can be doneConfirmed transactions can't be reversed, but funds sitting in an identifiable destination wallet can sometimes still be frozen before they're moved again
Only large losses are worth reportingSmall reports still contribute to the pattern data that gets an address or scam operation flagged
Revoking one malicious approval makes the wallet safe againOther unrelated approvals granted earlier can remain active and exploitable; a full review across every network is needed
A hardware wallet makes this guide unnecessaryHardware wallets block remote seed-phrase theft, but still sign a malicious approval if the owner confirms without reading what it authorizes
The incident is over once the wallet is securedBeing visibly victimized can make someone a repeat target; staying alert to unsolicited "recovery" contact matters for weeks afterward, not just the first day

Risks, Limitations, and Exceptions

Practical Implementation Checklist

  1. Disconnect the compromised device or wallet session immediately.
  2. Move any funds still reachable by the compromised key to a new wallet from a clean device.
  3. Revoke malicious and unfamiliar contract approvals across every network the wallet has used.
  4. Secure email, exchange, and any other accounts that share credentials with the compromised wallet.
  5. Preserve screenshots, transaction hashes, and attacker communications before they disappear.
  6. Identify the destination platform the funds moved to, if any, and contact its fraud team.
  7. File reports with the relevant cybercrime authority and local police.
  8. Report the phishing site or malicious contract so it can be flagged for others.
  9. Treat any unsolicited recovery offer as a scam and verify independently before engaging with one.
  10. Set a realistic timeline for any follow-up and continue securing unaffected assets in the meantime.

Tool Opportunity

A dedicated Swoopr tool should convert this framework into a guided incident-response workflow.

Recommended inputs: which wallets and accounts were affected, whether a seed phrase or only an approval was exposed, transaction hashes, the platform funds moved to if known, and the date and time discovered.

Expected outputs: a prioritized action checklist (contain, protect, revoke, report), a pre-filled evidence summary formatted for platform and law-enforcement reports, and links to the relevant per-network approval checkers.

Validation requirements: never claim a transaction can be reversed, never recommend a named third-party recovery service, distinguish confirmed on-chain data from user-supplied claims, and flag unsolicited recovery contacts as high-risk by default.

Frequently Asked Questions

What should a beginner understand about what to do after a crypto scam?

Speed matters more than completeness in the first hour: securing what wasn't taken — unaffected wallets, connected accounts, remaining balances — comes before documenting exactly how the scam happened. A beginner's biggest risk is freezing up trying to understand the attack instead of containing it; the order in this guide (contain, protect, revoke, document, report) works even without a full picture of what went wrong.

What are the largest risks after a crypto scam?

The two largest risks are continued exposure — an active malicious approval or a compromised seed phrase left unaddressed while attention shifts to reporting — and secondary scams from people posing as recovery agents who contact victims directly. Both are more damaging than the original incident because they're preventable and often overlooked while attention is on documentation.

Which detail matters most when deciding what to do first?

Whether a seed phrase or private key was exposed versus only a contract approval determines almost everything that follows: an exposed key means the wallet is permanently compromised and should be abandoned, while an exposed approval means the wallet can stay in use once the approval is revoked. Getting this distinction right early avoids overreacting to a wallet that's actually fine or underreacting by continuing to use a burned one.

Is this a process to repeat, like reviewing a portfolio?

This isn't a recurring review the way a portfolio strategy is — it's a one-time sequence to work through immediately after an incident. The one habit worth repeating afterward is periodically checking token approvals across all wallets and networks, since a forgotten approval from an unrelated incident can resurface as a new compromise later.

Which Swoopr tool supports this process?

A planned incident-response workflow tool is intended to turn this page's checklist into a guided process — capturing the exposure type, generating a pre-filled evidence summary for reports, and surfacing the right per-network approval checkers, rather than requiring the reader to reconstruct each step manually while under stress.

Does owning a hardware wallet make this guide unnecessary?

No. A hardware wallet substantially reduces the risk of a stolen seed phrase, since private keys never leave the device, but it doesn't prevent a malicious approval — the device still signs whatever transaction the owner confirms, and a rushed or unread confirmation can approve a draining contract just as easily as a software wallet can. The revoke-approvals and audit-approvals steps apply regardless of wallet type; only the seed-phrase steps are specific to software or custodial wallets.

Conclusion

Disconnect from suspicious sites, stop communicating with the attacker, secure email and exchange accounts, and record transaction identifiers. Use this page as part of the larger Swoopr learning architecture. Move to the parent hub when broader orientation is needed and to a supporting guide or tool when a specific calculation, comparison, or workflow is required.

Related Reading