Protect irreplaceable secrets first
Phishing & Scams is easiest to understand when its boundaries are explicit. Scams often create urgency through fake support, imitation domains, unexpected airdrops, or alarming account messages that push users to act quickly. Check the full domain before opening or connecting; ads, shortened links, and chat messages can all lead to imitation sites. A label in the interface should never replace the network, address, contract, or transaction evidence that identifies what is actually happening.
Recognize fake sites, fake support, fraudulent airdrops, malicious signing requests, and social engineering. After suspicious activity, preserve evidence such as transaction hashes and domains, then review account approvals and device security. Scam resistance improves when urgency is treated as a warning sign and domains, identities, requested secrets, and on-chain actions are verified before any response. If the interface and on-chain evidence disagree, pause the workflow and keep verifiable references such as the transaction hash, network name, or contract address before taking another action.
Move verification before confirmation
In a real Phishing & Scams workflow, ask three questions in order: what object is involved, what authority is being requested, and where the result should appear. Any support conversation asking for a seed phrase, private key, or verification code should be ended regardless of profile pictures or group size. Scams often create urgency through fake support, imitation domains, unexpected airdrops, or alarming account messages that push users to act quickly. If one answer is unclear, urgency from a pop-up, countdown, or stranger is not a reason to continue.
A “free claim” that requires an unusual signature, approval, or prior transfer deserves contract and purpose verification before any action. For actions that can change blockchain state, review the address, network, asset, amount, or permission scope again at the final confirmation step. Afterward, verify the outcome with transaction history or on-chain data instead of immediately repeating the action.
Recognize common attack paths
On-chain evidence should be used to cross-check what Phishing & Scams shows in the interface. After suspicious activity, preserve evidence such as transaction hashes and domains, then review account approvals and device security. Check the full domain before opening or connecting; ads, shortened links, and chat messages can all lead to imitation sites. A trustworthy block explorer can expose transaction status, blocks, addresses, and contract information, while the explorer itself should also be reached from a dependable source.
Any support conversation asking for a seed phrase, private key, or verification code should be ended regardless of profile pictures or group size. This helps distinguish an interface delay from a genuine network, contract, or permission problem. The distinction matters because the correct response to a delayed display is very different from the response to a failed or malicious request.
What to do after something looks wrong
Risk review around Phishing & Scams is not only about technical vocabulary; request origin and user pressure matter too. Check the full domain before opening or connecting; ads, shortened links, and chat messages can all lead to imitation sites. Scams often create urgency through fake support, imitation domains, unexpected airdrops, or alarming account messages that push users to act quickly. Look-alike domains, fake support, airdrop traps, excessive approvals, clipboard substitution, and shared devices can all turn an ordinary workflow into a dangerous one.
A “free claim” that requires an unusual signature, approval, or prior transfer deserves contract and purpose verification before any action. imtoken will never ask for a seed phrase, private key, or verification code. Third-party DApps and smart contracts must be assessed independently, and a wallet connection should never be treated as proof that the third party is safe.
Build durable security habits
A durable Phishing & Scams routine is simple: confirm context, review the request, and verify the result. After suspicious activity, preserve evidence such as transaction hashes and domains, then review account approvals and device security. Any support conversation asking for a seed phrase, private key, or verification code should be ended regardless of profile pictures or group size. Connections and permissions that are no longer needed should be reviewed and removed when appropriate.
A “free claim” that requires an unusual signature, approval, or prior transfer deserves contract and purpose verification before any action. Blockchain actions generally cannot be reversed unilaterally by a wallet, so checking the address, network, amount, authority, and intended outcome before confirmation is more reliable than trying to recover from a preventable mistake afterward. Scam resistance improves when urgency is treated as a warning sign and domains, identities, requested secrets, and on-chain actions are verified before any response.
- Confirm that the request really belongs to the Phishing & Scams context rather than assuming rules from another network or permission model.
- Verify the relevant address, network, asset, amount, or approval scope against the intended outcome.
- Do not provide a seed phrase, private key, recovery phrase, or verification code to another person or website.
- Use a transaction hash, contract address, or block explorer when on-chain verification is needed.
- If the source, domain, or expected result cannot be explained clearly, stop before confirming.