imtoken will never ask for your seed phrase, private key or verification code. Always review the address, network and request details before transferring, signing or approving.
imtoken

Phishing & Scams

Recognize fake support, fake airdrops, look-alike domains, malicious signatures, remote-control scams and clipboard replacement, then use an independent verification routine.

On this pageCore security principlesHow high-risk situations developHow to recognize abnormal requestsWhat to do when risk appearsA long-term security checklist

Core security principles

With Phishing & Scams, start by separating what the wallet displays from what the active network and request actually mean. Scams often use urgency and borrowed authority to shorten decision time. Requests for recovery secrets, rushed signatures or remote access are reasons to stop immediately. Before doing anything consequential, identify look-alike domains and fake support, then check how fake airdrops applies in the active network. A wallet can organize information and prepare requests, but the network, contract and signature details remain facts that the user should verify independently.

A useful mental model separates the environment from the action. Start with look-alike domains, establish the context through fake support, and use fake airdrops together with malicious signatures to understand the result. Similar labels, familiar icons or matching address formats do not prove that two assets or networks are equivalent. If key details conflict, stop and resolve the mismatch before submitting anything.

How high-risk situations develop

When evaluating fake support, avoid relying on one visual cue. Confirm the active account and network in the wallet, then compare that information with public chain data when available. If a transaction already exists, malicious signatures becomes an important verification anchor. For DApps and smart contracts, also inspect the target contract, requested permission and whether the request is proportionate to the intended action.

A repeatable sequence is more dependable than memory: identify look-alike domains, verify fake support, inspect fake airdrops, review the destination or permission immediately before approval, and finally use malicious signatures or another public record to confirm what happened. If one stage cannot be explained, do not use a later transaction as an experiment. On-chain actions are generally not something a wallet can simply reverse for the user.

Key points

look-alike domains
Verify this item in its current network and action context.
fake support
Verify this item in its current network and action context.
fake airdrops
Verify this item in its current network and action context.
malicious signatures
Verify this item in its current network and action context.

How to recognize abnormal requests

One recurring mistake is providing recovery words in direct messages; another is skipping checks because an offer is urgent. Both tend to happen when a familiar interface creates confidence while the network, contract or permission has changed underneath. A source–network–target–request–result checklist shifts attention away from appearance and toward facts that can be independently checked.

It is also important to avoid allowing a stranger to control the device remotely. When an outcome looks wrong, inspect chain state and malicious signatures before deciding on another action. Repeated submissions can create extra fees, new transactions and a more confusing troubleshooting trail. One request followed by one explicit verification step is easier to reason about.

Verification sequence

01 look-alike domains
02 fake support
03 fake airdrops
04 malicious signatures
05 remote access

What to do when risk appears

The security boundary for Phishing & Scams is constant: seed phrases and private keys remain under the user’s control and should never be sent to another person. Verification codes should not be shared either. Third-party DApps and smart contracts can introduce risk, so signatures and approvals deserve their own review. Old approvals should be reconsidered, and shared devices, public networks and remote-control sessions warrant extra caution.

For Phishing & Scams, turn remote access into a routine instead of treating it as a one-time lesson. Begin by stating the active network and intended target, reread critical fields immediately before approval, and verify the result with public on-chain information afterward. Experience can make this faster, but it should not remove independent checks of addresses, networks, amounts, contracts and permissions.

Avoid these shortcuts

  • providing recovery words in direct messages
  • skipping checks because an offer is urgent
  • allowing a stranger to control the device remotely

A long-term security checklist

For an unfamiliar network, asset or DApp, start with a limited action that can be verified. Learn the relevant rule, perform one controlled step, then compare the outcome with what you expected. That approach makes Phishing & Scams evidence-driven rather than dependent on prompts and also helps isolate whether a problem belongs to an account, network, transaction or third-party request.

Good judgment around Phishing & Scams comes from independently checking the important facts rather than relying on promises about risk. The practical objective is clarity: know where look-alike domains is shown, how fake support is confirmed, what fake airdrops can change and how malicious signatures can be used for verification. Consistently applying those checks reduces avoidable errors caused by haste, misunderstanding or risky third-party behavior.

Security reminder
Never send a seed phrase, private key or verification code to anyone. Review the network, destination and request before transferring, signing or approving. Third-party DApps and smart contracts can carry risk.