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.
Home/Phishing & Scams

Security

Phishing & Scams

Recognize fake sites, fake support, fraudulent airdrops, malicious signing requests, and social engineering.

Start with verifiable facts and the intended outcome before committing an on-chain action.

01

Understanding the boundaries of Phishing & Scams

Phishing & Scams becomes easier to use when every on-chain action is broken into verifiable parts. Start with 钓鱼网站, then confirm 假客服 and 假空投 before relying on what a wallet interface appears to show. Recognize fake sites, fake support, fraudulent airdrops, malicious signing requests, and social engineering. A familiar-looking address is not a substitute for checking the selected network, and a token name is not a substitute for checking a relevant contract when that distinction matters. This sequence helps separate presentation from blockchain state and reduces mistakes caused by assumptions made too early in the flow. For security topics, apply a least-exposure mindset: keep 钓鱼网站 and 假客服 available only where necessary, prefer offline backups, avoid screenshots or messaging apps for secrets, and remain cautious on shared devices or public networks. Security is risk reduction, not a promise of zero loss.

A further check around 假客服 is to compare the interface with available on-chain evidence and use a block explorer when necessary. If a request is unclear, stop before confirmation, retain verifiable details such as a transaction hash, network name, or contract address, and resolve the uncertainty instead of responding to urgency created by a pop-up or third-party message.

02

Putting Phishing & Scams into a real workflow

In a practical workflow, treat 假客服 and 恶意签名 as separate checkpoints. Confirm the network and destination context first, then review the status, record, request, or permission represented by 恶意签名. For transfers, verify the recipient address, asset, amount, and network fee before broadcasting. For signatures or approvals, read the request and ask whether the requested authority is actually necessary. A connected wallet should never be treated as blanket permission for every later request from a DApp or contract.

A further check around 假空投 is to compare the interface with available on-chain evidence and use a block explorer when necessary. If a request is unclear, stop before confirmation, retain verifiable details such as a transaction hash, network name, or contract address, and resolve the uncertainty instead of responding to urgency created by a pop-up or third-party message.

Practical checkConfirm the network, address, request details, and expected result before committing an on-chain action.
03

Risk checks around Phishing & Scams

Risk management around Phishing & Scams also depends on understanding 社交工程. Similar domains, fake support accounts, misleading airdrops, malicious signature prompts, incorrect network cues, and excessive approval allowances can pressure users into actions they did not intend. imtoken will never ask for a seed phrase, private key, or verification code. Those secrets should not be entered into websites, support chats, or forms. Connections and token approvals that are no longer needed should be reviewed and, where appropriate, revoked.

A further check around 恶意签名 is to compare the interface with available on-chain evidence and use a block explorer when necessary. If a request is unclear, stop before confirmation, retain verifiable details such as a transaction hash, network name, or contract address, and resolve the uncertainty instead of responding to urgency created by a pop-up or third-party message.

04

What to learn next about Phishing & Scams

A useful way to continue learning is to map 钓鱼网站, 假空投, and 社交工程 to three questions: what object is involved, what action is being requested, and what state change may follow. If any one of those questions cannot be answered clearly, do not rush the confirmation step. A block explorer and transaction hash can help distinguish interface delays from actual on-chain results. Blockchain transactions are generally not something a wallet can unilaterally reverse, so review before signing or sending is more reliable than trying to recover from a preventable mistake afterward.

A further check around 社交工程 is to compare the interface with available on-chain evidence and use a block explorer when necessary. If a request is unclear, stop before confirmation, retain verifiable details such as a transaction hash, network name, or contract address, and resolve the uncertainty instead of responding to urgency created by a pop-up or third-party message.