On this page
  1. Core principles
  2. Common risk scenarios
  3. How to identify and respond
  4. Everyday checklist

Core principles

Phishing commonly uses look-alike domains, search ads, direct messages, fake support and fake airdrops to push users toward wallet connections or secret disclosure. To understand Phishing & Scams, place the concept inside a real on-chain workflow: where the information comes from, what the user confirms, how the network records the result, and which outcomes cannot normally be reversed by a wallet provider. This makes inconsistencies easier to spot across different apps and networks.

Common risk scenarios

No legitimate safety procedure requires sending a seed phrase, private key or verification code to another person. Requests framed as “sync,” “unlock” or “verify” should be rejected. In practice, start with the intended outcome and then verify the relevant fields. If an address, network, contract or permission connected to Phishing & Scams cannot be explained, stop rather than accepting the default button. Public blockchain data can often be used as a second source of verification.

A practical way to check

Separate what you can verify publicly from what must remain secret. Network names, public addresses, transaction hashes and contract addresses can be checked against public blockchain data. Seed phrases and private keys should never be disclosed for this purpose.

How to identify and respond

When a link looks suspicious, do not use the page’s own “fix” or “claim” buttons. Reopen the service from a trusted bookmark or known entry point. Security is not a single “perfect protection” switch. It comes from repeatable habits: trusted entry points, independent checks, least-necessary permissions, offline protection of secret credentials, and a willingness to reject abnormal requests.

Security reminder
imtoken staff will not ask for your seed phrase or private key. Review the address, network and request before any transfer, signature or approval.

Everyday checklist

If a suspicious approval has already been signed, inspect allowances and balances on the relevant network and stop interacting with the questionable page. After an action, verify that the result matches the intention. Save non-secret references such as the transaction hash, network and public address for troubleshooting, while keeping seed phrases, private keys and verification codes private.

Before you continueIf a request is unclear, stop and verify it independently. Blockchain transactions and contract permissions can carry irreversible consequences.