Start with non-negotiable security principles
Phishing & Scams is easier to use when phishing and domain verification are understood in the same operational context. Phishing uses look-alike domains, copied interfaces, and urgency to persuade users to reveal secrets or authorize unwanted actions. Impersonation sites often use look-alike characters, subdomains, or advertising redirects to create familiarity. Similar visual design does not prove that a domain is genuine. Understanding the boundary is more important than rushing to completion because on-chain actions can create difficult-to-reverse outcomes.
Do not treat a familiar interface as proof that a request is trustworthy. Around phishing and domain verification, identify the source of the request, the permission being granted, and whether an on-chain result may follow. imtoken will never ask for a seed phrase, private key, or verification code. Blockchain transactions also generally cannot be unilaterally reversed by a wallet, so review before confirmation matters more than recovery attempts afterward.
Practical checkpoint
- Avoid entering a signing flow directly from unsolicited messages, ads, or group chats.
- Use a known route to reach a DApp, recheck the address bar before signing, and avoid unsolicited links.
- Before any transfer, signature, or approval, confirm that the network, address, and request details match the action you intended.
Recognize common risk scenarios
Phishing & Scams is easier to use when fake support and signature are understood in the same operational context. Fake support commonly asks for seed phrases, private keys, verification codes, or remote-control access under the pretext of account verification, recovery, or troubleshooting. A signature proves that an account authorized a message or transaction payload. Even when no transfer is shown, a signature can still have meaningful consequences. Putting these concepts together is more useful than memorizing vocabulary without knowing when a check matters.
Do not treat a familiar interface as proof that a request is trustworthy. Around fake support and signature, identify the source of the request, the permission being granted, and whether an on-chain result may follow. imtoken will never ask for a seed phrase, private key, or verification code. Blockchain transactions also generally cannot be unilaterally reversed by a wallet, so review before confirmation matters more than recovery attempts afterward.
Practical checkpoint
- Official personnel will not ask for a seed phrase or private key; any such request is a high-risk signal.
- Check the source, text, domain, and purpose; do not relax review merely because a request is described as “just a signature.”
- Before any transfer, signature, or approval, confirm that the network, address, and request details match the action you intended.
What to do when something looks wrong
Phishing & Scams is easier to use when remote access and seed phrase are understood in the same operational context. Remote-control software can expose the screen, inputs, and clicks to another party. Avoid letting an unknown person control a device during key, signature, or transfer operations. A seed phrase can commonly restore a set of wallet accounts, making it more sensitive than an ordinary login password. If exposed, another party may be able to restore the wallet elsewhere. In practice, the useful habit is to match what the interface shows against the network, address, and actual request details.
Do not treat a familiar interface as proof that a request is trustworthy. Around remote access and seed phrase, identify the source of the request, the permission being granted, and whether an on-chain result may follow. imtoken will never ask for a seed phrase, private key, or verification code. Blockchain transactions also generally cannot be unilaterally reversed by a wallet, so review before confirmation matters more than recovery attempts afterward.
Practical checkpoint
- If supposed support asks you to install a remote-access tool, stop the session and verify the source independently.
- Prefer offline backup, avoid screenshots and messaging apps, and never hand it to someone claiming to be support.
- Before any transfer, signature, or approval, confirm that the network, address, and request details match the action you intended.
Turn security into a repeatable habit
Phishing & Scams is easier to use when phishing and domain verification are understood in the same operational context. Phishing uses look-alike domains, copied interfaces, and urgency to persuade users to reveal secrets or authorize unwanted actions. Impersonation sites often use look-alike characters, subdomains, or advertising redirects to create familiarity. Similar visual design does not prove that a domain is genuine. If two information sources disagree, stop before confirming and compare details that can be independently verified.
Do not treat a familiar interface as proof that a request is trustworthy. Around phishing and domain verification, identify the source of the request, the permission being granted, and whether an on-chain result may follow. imtoken will never ask for a seed phrase, private key, or verification code. Blockchain transactions also generally cannot be unilaterally reversed by a wallet, so review before confirmation matters more than recovery attempts afterward.
Practical checkpoint
- Avoid entering a signing flow directly from unsolicited messages, ads, or group chats.
- Use a known route to reach a DApp, recheck the address bar before signing, and avoid unsolicited links.
- Before any transfer, signature, or approval, confirm that the network, address, and request details match the action you intended.
Keep seed phrases and private keys under your own control. Do not send them to anyone. Review the address, network, amount, signature text, and approval scope before confirming. Third-party DApps and smart contracts can introduce independent risk.