On this page
Understand look-alike sites and fake support
Recognize fake sites, fake support, fake airdrops and deceptive signatures. The purpose of this Phishing & Scams guide is not to memorize an interface. It is to understand what look-alike sites, fake support, and fake airdrops each tell you, and how those signals fit together during an on-chain action.
When using imtoken for this topic, begin with the network and the origin of the request. Look-alike sites gives one part of the picture, fake support defines an important boundary, and fake airdrops helps explain whether the result matches what you intended.
A durable workflow is to start with information you can verify: when a reward, support message, or security warning appears, verify the source through a known entry point, avoid unknown links, and never submit secret recovery information. This keeps the decision grounded even when an app layout, DApp interface, or network condition changes.
It is also useful to separate what a wallet interface displays from what the blockchain records. A wallet can organize requests and show status, while network rules, contract execution, and block inclusion determine the on-chain result. This is also an important part of keeping the Phishing & Scams workflow clear and reviewable.
Practical checklist
- Confirm the network and purpose of the Phishing & Scams action.
- Distinguish look-alike sites, fake support, and fake airdrops.
- Prefer verifiable fields over names or icons.
- Define the expected result before acting and verify it afterward.
Put fake airdrops into a real workflow
For Phishing & Scams, think in four stages: prepare, review, act, and verify. During preparation, define the goal and relevant look-alike sites; during review, check fake support and fake airdrops; act only on a request you understand; then use urgency tactics or another on-chain record to verify the outcome.
If a prompt contains an address, network, contract, fee, signature, or approval, do not collapse those fields into one generic “confirm” step. Reading them separately makes unexpected network switches, changed recipients, or broader permissions easier to spot. This is also an important part of keeping the Phishing & Scams workflow clear and reviewable.
When the network needs time to process a request, a temporarily unchanged interface is not proof of failure and is not a reason to submit the same action again immediately. Check fake airdrops, transaction history, or an appropriate block explorer first.
A fixed review order is more reliable than memory. Repeating the same checks for Phishing & Scams creates a traceable workflow and makes troubleshooting easier because you can return to the last step that has a verifiable result.
Practical checklist
- Check look-alike sites during preparation.
- Review fake support and fake airdrops before approval.
- Approve only a request you understand.
- Use urgency tactics to verify the outcome.
Recognize risks around deceptive signatures
Scams often use urgency, authority, or oversized rewards to push users past verification and then request secrets or high-impact signatures. The broader lesson is that a familiar page does not prove a request is correct; review the network, address, contract, signature content, or permission scope that actually defines the action.
Names alone are weak evidence. Look-alike sites, fake support, or deceptive signatures may look familiar across networks and applications while representing different underlying objects. For important actions, prefer complete addresses, contracts, and transaction identifiers.
If the observed state differs from your expectation, avoid repeated confirmations or broadcasts while the situation is unclear. Record the active network and public transaction information, then determine whether the issue is pending network state, display behavior, permission scope, or the request itself. This is also an important part of keeping the Phishing & Scams workflow clear and reviewable.
The security boundary remains consistent: never send a seed phrase, private key, or verification code to anyone, and never enter those secrets into an ordinary webpage. imtoken staff will not ask for them, while third-party DApps and contracts require independent review. This is also an important part of keeping the Phishing & Scams workflow clear and reviewable.
Practical checklist
- Risk to remember: Scams often use urgency, authority, or oversized rewards to push users past verification and then request secrets or high-impact signatures.
- Do not skip network, address, or contract checks because a page looks familiar.
- Stop adding new actions if the state is unclear.
- Never provide a seed phrase, private key, or verification code.
Use urgency tactics to close the loop
After the action, use a short Phishing & Scams checklist and review domain spelling, message origin, request content, requests for secrets, remote-control demands, and unusual transfers. Together these fields answer four practical questions: where the action occurred, who or what it targeted, what authority or value moved, and what the network recorded.
Verification is not a promise of absolute safety. Its value is that avoidable mistakes can be detected before the next action. In particular, make sure urgency tactics is consistent with the active network, account, and intended outcome.
Over time, include deceptive signatures in periodic reviews rather than waiting for a problem. Remove connections or permissions that no longer serve a purpose, keep useful public transaction records, and maintain clear boundaries between accounts, networks, and DApps.
The goal of learning Phishing & Scams is to make decisions that remain understandable when interfaces change or networks are busy. Establish the facts first, approve only what you understand, and use on-chain information to verify what happened.
Practical checklist
- Review: domain spelling, message origin, request content, requests for secrets, remote-control demands, and unusual transfers.
- Confirm the result matches the active network and intended target.
- Consider removing connections or permissions you no longer need.
- Evaluate third-party DApps and smart contracts independently.
Keep seed phrases and private keys under your own control. imtoken staff will never ask for them. Verify address, network and request details before a transfer, signature or approval. On-chain transactions generally cannot be reversed unilaterally by a wallet.