Key Takeaways
Every guide in Swoopr's phishing sub-group describes a different disguise an attack wears — a look-alike domain, a fake extension, a cloned support account, a swapped clipboard address, a malicious QR code. Underneath all of them is the same weak point: a moment where the victim trusted a source without checking it independently, because checking felt unnecessary, slow, or paranoid in that moment. This page collapses every one of those disguises into one habit that generalizes across all of them, rather than requiring a reader to memorize thirteen separate sets of red flags.
Direct answer: Verify a crypto site or service by reaching it only through a bookmark or a URL you typed yourself, reading its domain character-by-character against a known-good reference, confirming the same information through a second independent channel, checking that channel is consistent with the project's other official presence, never entering a seed phrase or private key anywhere, using a password manager that only autofills on the exact correct domain, and reading exactly what any wallet-connection or signature request actually authorizes before approving it.
- Seven checklist steps, run together, close off the specific gap each of the thirteen other attack types in this sub-group depends on.
- No single step is sufficient alone; the checklist works because it stacks independent checks that don't all fail the same way at once.
- The checklist takes under a minute to run and doesn't require deep technical knowledge, only the habit of running it every time.
- Technical tools — domain-locked password managers, transaction simulation, bookmark managers — turn parts of the checklist into something that happens automatically instead of relying on memory alone.
- Experience and caution are not a substitute for the checklist; sophisticated attacks are specifically designed to bypass the instincts of confident users under time pressure.
The Seven-Step Verification Checklist
Each step below closes a specific gap an attacker relies on. Run all seven, in order, any time you're about to enter credentials, connect a wallet, or sign a transaction on a site or service you haven't already verified and bookmarked.
Step 1 — Navigate via a bookmark or a typed URL, never a shared link
Reach every service you use regularly through a bookmark you saved after verifying it once, or by typing the known address directly into the address bar. Never rely on a search engine result, a link pasted in a DM, a comment reply, an email, or a QR code as your first path to a site that will touch your wallet or credentials. Search ads in particular are routinely purchased by attackers to outrank the real site for its own brand name, and a compromised or cloned comment thread can post a malicious link underneath a completely genuine, unrelated post. A bookmark you created once, from a source you verified once, removes this entire category of risk permanently for that service.
Step 2 — Check the exact domain character-by-character
Before entering anything, read the full domain in the address bar one character at a time against your bookmark or a known-good reference, rather than glancing at the overall page design. Look specifically for a swapped letter, an inserted hyphen, an extra word, a different top-level domain, or a subdomain trick that pushes the real-looking part of the address earlier in the string while the actual controlling domain sits at the end. This is the single check that catches typosquatting, and it's the one most people skip because a cloned page's design looks so convincing that the domain feels like a formality.
Step 3 — Verify through a second independent channel
Before trusting an unexpected link, message, or announcement, confirm it through a channel the sender doesn't control — the project's official website (reached via Step 1), its verified X/Twitter bio link, or a pinned message in its official Discord, not a reply to your DM or a link the same contact provides. The point of a second channel is that it can't be spoofed by the same attacker who compromised or impersonated the first one; an independent source has to be independently compromised too, which is a much higher bar.
Step 4 — Check consistency across official channels
Compare what you were told against what the project's other official presences say. Does the site linked in a DM match the link in the project's official bio? Does an announced deadline, address, or claim process match what's pinned in the official community server? A single channel saying something none of the others confirm is the tell that channel has been compromised or impersonated, even if it otherwise looks completely authentic.
Step 5 — Never enter a seed phrase or private key anywhere
No legitimate site, wallet provider, exchange, or support agent will ever ask you to type your seed phrase or private key into a website, a form, a chat window, or a screen-share session, for any reason — not to "verify" your wallet, not to "sync" a new device, not to "unlock" a stuck transaction. A seed phrase only ever belongs inside your own wallet software, entered once during setup or recovery. Treat any request for it, framed any way, as a scam with certainty, not just suspicion.
Step 6 — Use a password manager with domain-locked autofill
A password manager that only offers saved credentials on the exact domain it was saved against is a mechanical backstop for the moments Step 2 fails under time pressure or fatigue. Where a rushed human glance can miss one swapped character, a domain-locked autofill simply won't populate anything on a domain string that doesn't match precisely, silently flagging a look-alike site before you've typed a single character into it.
Step 7 — Read what you're actually signing
Before approving any wallet connection or signature request, read the wallet's own plain-language description of what it authorizes, not the label the website chose to display. A button labeled "Verify," "Claim," or "Mint" can be wired to an unlimited token approval or an ownership transfer, and the only place that gets exposed clearly is the wallet's own confirmation screen, ideally one that includes transaction simulation. If a wallet only shows raw, unreadable transaction data, treat that as a reason for extra caution rather than a reason to skip reading it.
Common mistake
The common mistake is treating this checklist as something to run once per project and then relax about permanently. Official accounts get compromised, domains get typosquatted freshly for a specific campaign, and legitimate sites occasionally serve a malicious version of themselves temporarily through a supply-chain compromise. Re-running the fast checks — domain and channel consistency — every time you're about to sign something meaningfully sized costs seconds and catches attacks that a one-time verification wouldn't.
Worked Example: The "Official Migration" Link
Realistic scenario — for education only.
Assume a Swoopr reader follows a mid-sized DeFi project on X and sees a reply, posted underneath the project's own genuine announcement tweet, from an account with a nearly identical name and profile picture, reading: "Reminder: token migration closes in 6 hours — migrate now to avoid losing your allocation: [link]." The reply has dozens of likes and several replies thanking the account, all fabricated by bots.
Applying Step 1. The reader does not click the reply's link. Instead, they navigate to the project's official site through their own saved bookmark, created when they first researched the project weeks earlier. This alone would have prevented any exposure to whatever domain the reply link actually points to.
Applying Step 2. Out of curiosity, the reader also examines the reply's link without clicking it (hovering to preview the URL) and finds it differs from the real project domain by one added character — a domain a careless glance would read as identical. Step 2 alone would have caught this even without Step 1.
Applying Step 3. The reader checks the project's official X bio, which links to the same bookmarked domain from Step 1 and makes no mention of a migration deadline. A migration significant enough to justify urgency would be announced through the project's main account and pinned, not left to a reply from a lookalike account.
Applying Step 4. The reader also checks the project's official Discord announcements channel, which is silent on any migration. The complete absence of the same "urgent" news anywhere else the project posts officially is the clearest possible signal that the reply is not legitimate.
Applying Step 5. Even if the reader had clicked through, the fake migration site's form asks only for a wallet connection, not a seed phrase, so this step doesn't directly trigger in this scenario — a reminder that Step 5 is a hard rule for a specific attack pattern, not something every scam attempts.
Applying Step 6. Because the reader uses a password manager with domain-locked autofill for the (unrelated) exchange account linked to this project, the manager would have silently declined to offer any saved credentials had the reader mistakenly reached the fake domain and attempted a login — an extra layer that doesn't depend on the reader noticing anything themselves.
Applying Step 7. Had the reader connected a wallet to the fake site anyway, the transaction it requests, once decoded by a wallet with simulation, would show an unlimited token approval to an unfamiliar contract rather than any actual "migration" action — a decisive final stop point even after every earlier step was skipped.
The outcome. Any single step in this scenario would have been sufficient to prevent a loss; running all seven, as intended, makes the outcome certain rather than probable. The reply's manufactured urgency ("6 hours") existed specifically to discourage the reader from doing exactly this multi-step check, which is precisely why the checklist is designed to take under a minute — slow enough to work, fast enough that time pressure isn't a credible excuse to skip it.
Which Checklist Step Defends Against Which Attack
Every attack type covered elsewhere in the Phishing & Wallet Drainers sub-group exploits a gap in one or more of the seven steps above. The table below maps each one, so you can see this checklist not as a separate topic but as the connective layer underneath everything else in this sub-group.
| Attack Vector | Defended By | Why |
|---|---|---|
| How Phishing Works | All seven steps | The general five-stage phishing lifecycle described in that guide is interrupted by this entire checklist; it's the foundational attack pattern every other page specializes. |
| Typosquatting & Fake Domains | Step 2 | A character-by-character domain check is the direct, purpose-built defense against a swapped letter, added hyphen, or different top-level domain. |
| Wallet-Drainer Scripts Explained | Step 7 | A drainer script's entire function depends on a victim signing an approval or transfer without reading what it actually authorizes. |
| Malicious dApp Connections | Step 7 | A malicious dApp relies on a "Connect Wallet" flow leading into a disguised signature request that Step 7's read-before-signing habit exposes. |
| Fake Airdrop Phishing | Steps 1 and 5 | Fake claim sites are reached through unsolicited links rather than a bookmark, and some variants push toward entering wallet recovery data directly. |
| Discord & Telegram Phishing | Steps 3 and 4 | Impersonated moderator and support accounts are exposed by confirming any claim through the project's official channels rather than the DM itself. |
| Fake Customer Support Scams | Steps 3 and 4 | A fake support agent's authority claim only survives if it goes unverified against the organization's real, official support channel. |
| Fake Browser Extensions | Step 1 | Malicious extensions are typically found via browser-store search rather than a link from the wallet provider's own official site, which Step 1 rules out. |
| Fake Wallet Apps | Step 1 | Fake mobile apps rely on app-store search ranking; reaching the download link only through the provider's official site avoids them entirely. |
| QR Code Phishing | Step 2 | A QR code hides its destination until scanned; the domain it resolves to still needs the same character-by-character review before proceeding. |
| Clipboard-Hijacking Malware | Step 7 | Malware that silently swaps a copied wallet address is only caught by reading the exact destination address shown in the final confirmation screen before sending. |
| SIM-Swap Attacks | Steps 3 and 6 | Once an attacker controls a victim's phone number, SMS stops being an independent channel; a domain-locked password manager and non-SMS verification limit the damage. |
| Social Media Impersonation | Step 4 | A cloned or lookalike account is exposed by checking that its claims match the project's verified, consistently-linked official presence elsewhere. |
Notice that Steps 2 and 7 each defend against the largest number of distinct attack types. That isn't a coincidence: the domain a site is served from and the exact content of a transaction a wallet is asked to sign are the two points every version of these attacks eventually has to pass through, no matter what story or channel got the victim there.
Tooling That Makes This Automatic
The checklist works manually, but several categories of tooling turn parts of it into something that happens by default instead of relying on remembering to do it every time.
Transaction simulation
Many modern wallets and browser extensions include a simulation layer that runs a proposed transaction against current blockchain state before you sign it and shows the actual result in plain language: which assets leave your wallet, which contract receives them, and what ongoing permissions, if any, you're granting. This is the direct technical backbone of Step 7, replacing an unreadable hexadecimal payload with something a non-technical reader can evaluate in seconds.
Bookmark managers
A dedicated bookmark folder for financial and crypto services, built the first time you verify each site through independent research, operationalizes Step 1 by removing the temptation to search or follow a link out of convenience later. Some browsers and password managers support syncing bookmarks across devices, which matters since the habit only holds if it's equally easy to follow on a phone as on a desktop.
Password managers with domain-locked autofill
As described in Step 6, a password manager that checks the exact domain string before offering saved credentials functions as an automatic, fatigue-proof version of Step 2. This is meaningfully different from a password manager that merely stores credentials; the domain-matching behavior specifically is the security property that matters here, and it's worth confirming a chosen manager actually enforces it rather than offering credentials on any similarly-named domain.
Approval-checking and revocation tools
Reputable, well-known approval-checking tools let a wallet holder review every standing token approval they've ever granted and revoke the ones no longer needed. This doesn't prevent an attack but limits the damage of a Step 7 failure, and used periodically as routine maintenance, it also surfaces forgotten approvals from legitimate services that no longer need standing access.
Hardware wallets with on-device confirmation
A hardware wallet that displays transaction details on its own separate screen, rather than trusting whatever a connected computer or phone shows, adds a layer of protection against malware that could otherwise alter what's displayed on the main device between the moment you review a transaction and the moment you approve it. This is a meaningfully different guarantee than a software wallet's on-screen preview alone.
Common mistake
The common mistake is treating any one of these tools as a complete substitute for the checklist rather than as automation for a specific step. Transaction simulation doesn't stop you from being lured to a fake site in the first place, and a password manager doesn't protect a purchase made after typing a domain by hand, from memory, into an unfamiliar browser. Tools reduce reliance on memory and attention for the specific step they cover; they don't replace running the full sequence.
Misconceptions Versus Reality
| Misconception | Reality |
|---|---|
| If I'm careful and experienced, I don't need a checklist | Sophisticated, personalized attacks are specifically designed to bypass the instincts of confident, experienced users, often through manufactured time pressure; a checklist habit is a structural defense, not a beginner crutch |
| Checking the domain once when I first bookmark a site is enough forever | Official accounts and even legitimate sites can be compromised later; re-running the fast checks before any meaningfully sized action costs seconds and catches attacks a one-time check wouldn't |
| A site that looks professional and error-free is probably legitimate | Modern phishing kits are professionally built, widely resold, and visually indistinguishable from the real thing; design quality stopped being a reliable signal years ago |
| Using a hardware wallet means I don't need to read what I'm signing | A hardware wallet protects the private key and confirms transaction details on a separate screen, but it will still sign whatever transaction you approve, including a malicious one, if you don't read the confirmation |
| This checklist is only useful for avoiding phishing sites | The same seven steps apply to verifying dApps, browser extensions, mobile apps, support contacts, QR codes, and social accounts, which is why it's presented as one unified habit rather than one per attack type |
Common Mistakes
Two patterns account for the majority of preventable losses among readers who otherwise know this checklist exists.
Skipping verification "just this once" under time pressure
Every category of attack covered in this sub-group relies on manufactured urgency for exactly this reason: a deadline, a limited claim window, a threat of suspension, or a request from someone posing as already-trusted support. The moment a message creates pressure to skip the normal process is the moment the checklist is most necessary, not least. Treat the urgency itself as a signal to slow down rather than as a valid reason to move faster; a genuinely time-limited legitimate opportunity can still be verified independently within a realistic window, and an offer that can't tolerate a minute of checking was never going to reward patience anyway.
Relying on memory of what a site "usually looks like"
A cloned site is built specifically to match visual memory: the same layout, the same colors, the same logo placement. Recognizing that "this looks like the site I remember" is not the same as verifying "this is the domain I bookmarked," and the two get conflated constantly because visual familiarity feels like a form of verification when it isn't. Actively checking the domain string and cross-referencing an independent channel, every time, closes this gap; passive recognition does not.
Other frequent mistakes
- Verifying the domain once at the top of a session but not re-checking after clicking through additional links or a wallet-connect redirect within the same visit.
- Treating a verified badge, follower count, or account age on social media as sufficient proof of authenticity without checking channel consistency.
- Assuming a mobile app is safe because it appears in an official app store's search results, rather than confirming the download link from the provider's own site.
- Approving a wallet connection or signature quickly because the same site was safe on a previous visit, without re-checking the domain that day.
Risks, Limitations, and Exceptions
- No checklist eliminates risk entirely; it reduces the probability of falling for verification failures without guaranteeing an outcome against every future technique.
- A legitimate site can be compromised temporarily through a supply-chain, DNS, or server-side attack, serving malicious content from the correct domain; domain checks alone won't catch this rare case.
- Second-channel verification (Step 3) assumes the second channel itself hasn't also been compromised; Step 4's cross-channel consistency check is the mitigation for that specific edge case, not a guarantee.
- Transaction simulation and approval-checking tools depend on accurate, timely on-chain data and can lag behind newly deployed malicious contracts.
- None of these steps recover funds after a signed, confirmed transaction; treat this checklist as prevention, not remediation.
- The worked example is illustrative; real attacks vary in pretext, platform, and the specific step where they'd be caught.
Practical Implementation Checklist
- Build a dedicated bookmark folder for every crypto site, exchange, and service you use, adding each one only after verifying it independently the first time.
- Install a password manager that enforces domain-locked autofill, and confirm it declines to offer credentials on a mismatched domain before relying on it.
- Choose a wallet or browser extension that includes transaction simulation, and make a habit of reading the plain-language preview before every approval.
- Before entering credentials or connecting a wallet on any site, read the full domain character-by-character against your bookmark.
- Before acting on an unexpected link, DM, or announcement, confirm it through the project's official site or verified social bio, not the source that sent it.
- Cross-check that any urgent claim is echoed consistently across a project's other official channels before treating it as real.
- Set a personal rule that no site, support agent, or wallet feature is ever a legitimate reason to type a seed phrase or private key anywhere.
- Periodically review and revoke unused token approvals with a reputable checking tool as routine maintenance, independent of any specific incident.
- Treat manufactured urgency in any message as a signal to run the full checklist more carefully, not a reason to skip it.
- Re-run the domain and channel checks each time you return to a site for a meaningfully sized action, not only the first time you use it.
Frequently Asked Questions
What's the single most reliable way to confirm a crypto site is legitimate?
There isn't one signal that works alone; reliability comes from stacking several independent checks. Navigating only through a saved bookmark or a typed known URL, reading the domain character-by-character, and confirming the same URL through a second channel such as the project's official X bio together close off the paths a single check would miss. Treat the checklist as a set, not a menu to pick one item from.
Is checking for the padlock or https in the address bar enough to confirm a site is safe?
No. An SSL certificate only encrypts the connection between a browser and whatever server is on the other end; it says nothing about who controls that server. Free certificates are available to anyone, including the operator of a cloned phishing domain, so a padlock and a legitimate-looking design prove a connection is private, not that the destination is genuine.
What should I do if I only have a link, not a bookmark, for a new service?
Don't click it directly. Search for the project by name through a search engine or, better, find it referenced from a source you already trust, such as a well-known crypto news outlet or an account you've previously verified, then compare that independently-found URL against the one you were sent. If they match character-by-character, save it as a bookmark immediately so you never have to repeat this process for that service again.
Why does a password manager help verify legitimacy if I'm careful about domains myself?
A password manager with domain-locked autofill checks the exact domain string mechanically, every time, without fatigue, distraction, or urgency affecting the outcome. A human reading a URL under time pressure can miss a single swapped character; a password manager simply will not offer credentials on a domain that doesn't exactly match what it has stored, which makes it a structural backstop for the moments manual review fails.
Can experienced crypto users skip this checklist since they already know what to look for?
No. Experience reduces the odds of falling for an obviously crude scam, but sophisticated, personalized attacks are specifically built to bypass the instincts of confident, experienced users, often by adding time pressure that suppresses the habit of checking. A checklist that runs the same way regardless of confidence level or how rushed someone feels is a structural defense that experience alone doesn't replace.
What if the "official" social media account posting a link has itself been compromised?
This is why Step 4, checking consistency across multiple official channels, matters as much as Step 3. A single compromised account can post a malicious link that looks authoritative, but it's far less likely that a project's official site, its other social accounts, and its community moderators all echo the same bad link at the same time. When one channel says something no other channel confirms, treat the outlier as the compromised one.
What is transaction simulation and why does it matter for Step 7?
Transaction simulation is a feature in some wallets and browser extensions that runs a proposed transaction against a copy of current blockchain state before you sign it, then shows the actual, plain-language result: which tokens leave your wallet, which arrive, and what permissions you're granting. It replaces a raw, unreadable hexadecimal signature request with a preview a non-technical user can actually evaluate before approving.
Where can I read about the specific attack types this checklist is designed to defend against?
See the Phishing & Wallet Drainers hub, which links to dedicated guides on typosquatting, fake browser extensions, malicious dApp connections, wallet-drainer scripts, and every other attack vector referenced in this checklist's mapping table.
Sources and Methodology
This guide synthesizes verification practices drawn from publicly available law-enforcement, industry, and standards guidance as of mid-2026. Key sources include:
- Cybersecurity and Infrastructure Security Agency (CISA): CISA's phishing and social-engineering guidance documents general domain-verification, multi-channel confirmation, and credential-hygiene practices that this checklist adapts for a crypto-specific context.
- FBI Internet Crime Complaint Center (IC3): IC3's public service announcements on cryptocurrency fraud recommend independent verification of unsolicited investment and account-related communications through official channels, consistent with Steps 3 and 4 of this checklist.
- National Institute of Standards and Technology (NIST) Digital Identity Guidelines: NIST's guidance on authentication and phishing-resistant practices informs the recommendation to use domain-bound credential tools such as password managers with strict origin matching.
The worked example in this guide is a hypothetical, illustrative scenario constructed for educational purposes and does not describe a specific real incident, project, or account.
This content was reviewed by the Swoopr Editorial Team in August 2026 and reflects publicly available information at that time. Verification tooling and attacker techniques both evolve; treat this guide as a durable framework rather than an exhaustive or permanently current list of every available tool.
Conclusion
Every attack described across this sub-group — typosquatted domains, fake extensions, malicious dApps, drainer scripts, hijacked clipboards, impersonated support, cloned social accounts, SIM swaps, and everything else — ultimately depends on a victim skipping independent verification at some specific, identifiable point. This checklist is the generalized answer to all of them at once: reach services only through a bookmark or typed URL, check the domain character-by-character, verify through a second independent channel, confirm consistency across official channels, never type a seed phrase anywhere, use a password manager that enforces the domain check mechanically, and read exactly what any signature request authorizes before approving it. None of these steps require technical expertise, only the habit of running them every time, especially in the exact moments an attacker is trying hardest to make that feel unnecessary.
Related Reading
- Scam & Security Center — the top-level hub for every scam and security topic Swoopr covers.
- Phishing & Wallet Drainers — the parent hub for this content group, covering the full range of phishing and drainer threats.
- How Phishing Works — the general anatomy and psychology behind the attacks this checklist defends against.
- Wallet-Drainer Scripts Explained — the malicious code behind Step 7's read-what-you're-signing defense.
- Fake Airdrop Phishing — how fake claim sites exploit unsolicited links and urgency.
- Discord and Telegram Phishing — impersonated moderators and support accounts on community platforms.
- Fake Browser Extensions — malicious wallet-clone extensions found through browser-store search.
- Malicious dApp Connections — disguised signature requests behind a "Connect Wallet" flow.
- Typosquatting and Fake Domains — the look-alike domain techniques Step 2 is built to catch.
- Fake Customer Support Scams — impersonated support agents and the channels that expose them.
- SIM-Swap Attacks — how phone-number takeovers undermine SMS-based verification.
- Clipboard-Hijacking Malware — malware that silently swaps a copied wallet address before you paste it.
- Fake Wallet Apps — fraudulent mobile apps found through app-store search rather than an official link.
- QR Code Phishing — malicious destinations hidden behind a scanned code.
- Social Media Impersonation — cloned and lookalike accounts distributing scam links.
- Common Crypto Scams — the broader scam landscape beyond phishing, including rug pulls and recovery fraud.