Lookalike entry points often begin with search or messages
Phishing sites can use paid lookalike ads, copied interfaces or unsolicited links; prefer a verified bookmark or a carefully typed domain for wallet-related sites. This determines how interface state should be interpreted and where verification should begin. Do not rely on a button label alone; compare what the interface shows with the active account, network and available on-chain evidence.
Fake support creates reasons to act immediately
Common claims include frozen accounts, wallet synchronization, compensation or urgent security upgrades; any request for a seed phrase, private key or verification code should end the interaction. Before acting, define the intended input, output and prerequisites, then inspect the relevant address, network, permission or fee fields. If a field is unclear, understanding it first is safer than repeating clicks or copying someone else’s steps.
A practical way to verify
Pause before confirmation and explain the key fields in your own words. If the account, network, contract, amount, fee or permission does not match the intended task, return to the previous step rather than forcing the flow to continue.
Fake airdrops use free assets to trigger risky signatures
Unsolicited airdrops may direct users to a site, request a wallet connection, signature or token approval; an unclear reward is not worth granting unexplained permissions. Separate interface status from on-chain facts and retain non-secret references such as transaction hashes or contract addresses for later verification. Networks, protocols and DApps can implement similar ideas differently, so one prior experience should not be treated as a universal rule.
Clipboard and remote-control scams operate at the device layer
Malware can replace copied addresses and scammers can pressure users to install remote-access tools; re-check pasted addresses and never let an unknown person control the wallet device remotely. Common failures come from the wrong target, wrong network, excessive permission or misunderstood request details. Stop when a domain, contract, amount or authorization falls outside the intended action rather than allowing urgency to weaken verification.
Keep seed phrases and private keys under your own control. imtoken support will not ask for them or for verification codes. Review address, network and amount before sending; on-chain transactions are usually not reversible by a wallet provider.
After a scam, stop further authorization first
If fraud is suspected, stop signing and transferring, disconnect suspicious pages, inspect recent transactions and approvals, and do not share recovery secrets with supposed recovery services. Over time, turn the important checks into a repeatable routine and periodically review transaction history, approvals and device conditions. This cannot remove every risk, but it makes important decisions easier to explain and verify.
Keep the principle reusable
Interfaces and network conditions change, so a durable workflow focuses on understanding the object, permission and on-chain consequence rather than memorizing a single screen.
Applying Phishing & Scams in a real workflow
Phishing sites can use paid lookalike ads, copied interfaces or unsolicited links; prefer a verified bookmark or a carefully typed domain for wallet-related sites. In practice, begin by naming the active account, intended target and operating context rather than searching for the fastest button. Then use the idea behind “Fake support creates reasons to act immediately” to verify prerequisites and make sure the visible fields match the task you actually intend to complete. This approach remains useful even when an interface changes.
Unsolicited airdrops may direct users to a site, request a wallet connection, signature or token approval; an unclear reward is not worth granting unexplained permissions. During the workflow, treat “Clipboard and remote-control scams operate at the device layer” as a separate verification checkpoint. A web page, a wallet prompt and the final on-chain result are different layers of evidence. If the network changes unexpectedly, the contract is unfamiliar, the permission is broader than expected or an amount cannot be explained, stop and verify before continuing.
A complete check can follow this sequence
- Before starting, identify the object, network or control boundary behind “Lookalike entry points often begin with search or messages”.
- During the action, verify the conditions described by “Fake support creates reasons to act immediately” and “Fake airdrops use free assets to trigger risky signatures”.
- Before confirmation, review the target, permission or risk represented by “Clipboard and remote-control scams operate at the device layer”.
- After completion, use “After a scam, stop further authorization first” to review public chain records, approvals or device state.
If fraud is suspected, stop signing and transferring, disconnect suspicious pages, inspect recent transactions and approvals, and do not share recovery secrets with supposed recovery services. If a field still cannot be explained, learn what it means before proceeding or use a lower-value, lower-permission and independently verifiable test. Never give seed phrases, private keys or verification codes to another person. Third-party DApps, contracts, bridges and services can carry their own risks, so a repeatable verification process is more durable than speed.