Look-alike domains and fake pages
Practical checks for look-alike domains and fake pages
“Look-alike domains and fake pages” is easier to reason about when it is broken into concrete checks: spelling, search ads, short links, fake login forms. A wallet interface can summarize an action, but the network, contract and permission context determine what the action actually means.
For look-alike domains and fake pages within Phishing & Scams, For irreversible actions or changes in permission, speed is not the priority. Read the recipient, network, amount, gas, signature text or approval target before continuing, because prevention is usually more effective than remediation.
Security decisions depend on control, permissions and verifiable records rather than promises of absolute protection. Because this section focuses on look-alike domains and fake pages, verification should return to the concrete objects named above. If something looks suspicious, protect control first: stop signing, leave the questionable site, review approvals and the device, and verify public chain state from a trusted environment. Do not expose sensitive material through remote-control sessions.
Impersonated support
Practical checks for impersonated support
Before acting on “Impersonated support”, identify the active network, the account in use and the purpose of the request, then review unsolicited DMs, seed-phrase requests, remote control, test transfers. This separates interface wording from facts that can be checked independently.
For impersonated support within Phishing & Scams, If a webpage, wallet prompt and public chain record disagree, avoid repeated submissions. Repeating an action can create extra fees, duplicate transactions or additional permissions without fixing the underlying mismatch.
Security decisions depend on control, permissions and verifiable records rather than promises of absolute protection. Because this section focuses on impersonated support, verification should return to the concrete objects named above. For repeated use, turn these checks into a personal routine. A consistent review process survives changes in network, device or DApp better than relying on a one-time warning banner.
- Check: unsolicited DMs
- Check: seed-phrase requests
- Check: remote control
Fake airdrops and malicious tokens
Practical checks for fake airdrops and malicious tokens
A repeatable workflow matters more than memorizing a definition for “Fake airdrops and malicious tokens”. Use claim prompts, signatures, approvals, spam NFTs as anchors for deciding whether the request matches what you intended to do and whether the result can be verified afterward.
A signature proves consent to a particular message or transaction, so the domain, target and exact request should be understood before signing. For fake airdrops and malicious tokens within Phishing & Scams, For irreversible actions or changes in permission, speed is not the priority. Read the recipient, network, amount, gas, signature text or approval target before continuing, because prevention is usually more effective than remediation. A token approval lets a designated spender act up to an allowance, and that permission can remain after the immediate interaction ends.
Security decisions depend on control, permissions and verifiable records rather than promises of absolute protection. Because this section focuses on fake airdrops and malicious tokens, verification should return to the concrete objects named above. If something looks suspicious, protect control first: stop signing, leave the questionable site, review approvals and the device, and verify public chain state from a trusted environment. Do not expose sensitive material through remote-control sessions.
Clipboard and address replacement
Practical checks for clipboard and address replacement
From a wallet user’s perspective, “Clipboard and address replacement” matters because copy-paste, full address checks, small tests, malware can change the meaning or risk of the same-looking action. If one of those details is unexpected, stop and resolve the mismatch first.
A public address can be shared for receiving and lookup, but a recipient address should still be fully checked before a transfer, including after copy and paste. For clipboard and address replacement within Phishing & Scams, A normal troubleshooting flow should not require a seed phrase, private key or verification code. Public addresses, network names, transaction hashes and public contract data are usually enough to diagnose chain-state questions. A small test on a new address, network or service path can validate the route, but it does not replace the full review of the transaction.
Security decisions depend on control, permissions and verifiable records rather than promises of absolute protection. Because this section focuses on clipboard and address replacement, verification should return to the concrete objects named above. For repeated use, turn these checks into a personal routine. A consistent review process survives changes in network, device or DApp better than relying on a one-time warning banner.
- Check: copy-paste
- Check: full address checks
- Check: small tests
When a request is suspicious
Practical checks for when a request is suspicious
Treat “When a request is suspicious” as a decision point rather than a label. The useful details are stop, do not sign, end remote access, review approvals and device. Together they explain what the wallet is being asked to do, what changes on-chain, and which public record can be used to verify the outcome.
A token approval lets a designated spender act up to an allowance, and that permission can remain after the immediate interaction ends. For when a request is suspicious within Phishing & Scams, A useful final review is purpose, target and result: confirm why you are acting, confirm the exact network or contract involved, and confirm that the outcome can be checked through a transaction hash, block explorer or wallet record. Remote-control software exposes screen and input to another party and should be closed during wallet creation, recovery and signing.
Security decisions depend on control, permissions and verifiable records rather than promises of absolute protection. Because this section focuses on when a request is suspicious, verification should return to the concrete objects named above. Afterward, keep the public record needed for verification and review any connection or approval that is no longer required. Blockchain transactions are generally not reversible by the wallet alone, so the goal is a process you can explain, verify and review.