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

Phishing & Scams is a core topic in the imtoken security and action system. This page connects fake sites, fake support, fake airdrops and remote access so that concepts, actions and verifiable on-chain state can be understood together.

On this pageCore principlesCommon risk scenariosHow to identify and respondVerification checklist

Core principles

Good fake sites security begins with a clear custody boundary: your seed phrase and private key stay with you. Legitimate support, staff or partners should not ask you to send these secrets, and verification codes should not be shared either. Most troubleshooting can be done with public information such as an address, network name and transaction hash.

When working with Phishing & Scams, keep verifiable public information separate from secret credentials. Details such as lookalike domains, fake support, fake airdrops, malicious signatures, clipboard replacement, and social engineering can support troubleshooting, but a seed phrase, private key, or verification code should never become part of a support or diagnostic request.

Common risk scenarios

Risks involving fake airdrops often create urgency with messages such as “verify now,” “claim immediately,” or “your assets will expire.” When a new domain, unexpected airdrop, unusual approval or remote-access request appears, stop and re-check the source. A polished site or a sender who knows public transaction details is not proof of legitimacy.

How to verify in practice

Place fake sites back into the real action flow: confirm the entry point and network, then the account and target, and finally use on-chain evidence to determine the result. Do not rely on a button state or interface message alone.

Before acting on Phishing & Scams, build a short verification path: confirm the network, confirm the intended account or contract, check the origin of the request, and decide which public evidence will prove the result. Reading lookalike domains, fake support, fake airdrops, malicious signatures, clipboard replacement, and social engineering together is more reliable than trusting a single interface status.

How to identify and respond

If a Phishing & Scams result differs from what you expected, start with public on-chain evidence. Use the network name, address, transaction hash, contract address, or confirmation state to narrow the cause, then interpret lookalike domains, fake support, fake airdrops, malicious signatures, clipboard replacement, and social engineering to distinguish waiting, parameter errors, display differences, or third-party service issues.

Verification checklist

fake airdrops is the final verification layer. Check the address, network and amount before transferring; check the domain, account and request details before signing; and be cautious on shared devices or public networks. On-chain transactions generally cannot be unilaterally reversed by a wallet, so careful review before confirmation matters more than recovery attempts afterward.

After a Phishing & Scams action, review the outcome instead of treating the confirmation click as the end of the process. Recheck lookalike domains, fake support, fake airdrops, malicious signatures, clipboard replacement, and social engineering, look for unnecessary permissions or an unexpected network state, and make periodic review part of normal wallet maintenance.

Important: Seed phrases and private keys remain under the user’s control. Legitimate staff should never ask for a seed phrase, private key or verification code. Verify address, network and amount before transfers, and remember that third-party DApps and smart contracts can carry risk.