imtoken
Phishing & Scams
Recognize common warning signs in lookalike domains, fake support, fake airdrops, remote assistance and urgency-based scams.
Phishing often begins with the entry point
You do not need every protocol detail to handle Phishing often begins with the entry point well, but you do need to know which facts determine the outcome. Phishing pages often rely on lookalike domains, search ads, direct messages or fake promotions. Use a trusted entry point and verify the domain. A familiar logo, polished design or urgent warning does not make a site legitimate.
An address identifies an on-chain account or contract. Before sending assets, verify both the destination network and the address, including the beginning, ending and trusted source. Recheck anything copied from chat or the clipboard in case it was altered. When the page does not match what you expected, canceling is usually safer than pushing through. Then verify the transaction hash, contract address or explorer record independently.
A DApp connection usually begins by requesting an account address or session, then may ask for signatures, transactions or approvals. Connecting is not the same as revealing a private key, but users should still verify the domain, session and network and disconnect when finished. Security is not a one-time setting; it is the repetition of the same checks before each transfer, signature and approval.
What is easy to miss
- Verify the network, address or contract source relevant to phishing often begins with the entry point.
- Confirm that the request matches the intended action instead of relying on a familiar label.
- Keep public identifiers such as transaction hashes for verification while keeping private credentials under your own control.
Unsolicited support messages need independent verification
In practice, Unsolicited support messages need independent verification connects to several steps before and after the action itself. Fake support commonly arrives through unsolicited messages, remote-control requests, recovery-phrase demands or instructions to install unknown software. A legitimate security process does not require sending seed phrases, private keys or verification codes to anyone. Verify contact through an independent official entry point.
A seed phrase can usually recreate wallet control on another device, so exposure can compromise the account. Keep it offline, do not send it to support, avoid long-term photo storage, and verify the word order and legibility after creating the backup. The same button label can produce very different results on a different network, contract or permission context, which is why labels alone are not enough.
A private key directly represents signing authority and should never be treated as a routine identity check. If a webpage, chat window, remote-support tool or supposed sync service asks for it, stop and independently verify the source. Turning these checks into a routine helps reduce errors caused by the wrong network, copied addresses, oversized permissions or misunderstood transaction state.
Before you confirm
- Verify the network, address or contract source relevant to unsolicited support messages need independent verification.
- Confirm that the request matches the intended action instead of relying on a familiar label.
- Keep public identifiers such as transaction hashes for verification while keeping private credentials under your own control.
Claim pages can hide approvals
Breaking Claim pages can hide approvals into smaller decisions is more reliable than accepting a single page-level conclusion. Malicious contracts or front ends can disguise approvals and signatures as claims, airdrops or account verification. Risk assessment should focus on the actual contract, permission scope and transaction effect rather than the marketing label shown on the page.
A token approval allows a contract to spend a token under defined conditions. Excessive allowance or approval to the wrong contract increases exposure. Verify the spender, token, amount and purpose, and periodically revoke permissions that are no longer needed. These questions are best resolved through public on-chain records, trusted sources and the wallet’s local information rather than explanations from an unknown person.
A signature proves that an account approved a message or transaction. Some message signatures do not transfer funds directly but can still authorize login or later actions. Before signing, review the recognizable domain, target, amount, permissions and any expiry. Security is not a one-time setting; it is the repetition of the same checks before each transfer, signature and approval.
Make the checks repeatable
- Verify the network, address or contract source relevant to claim pages can hide approvals.
- Confirm that the request matches the intended action instead of relying on a familiar label.
- Keep public identifiers such as transaction hashes for verification while keeping private credentials under your own control.
Stop when remote control or urgency appears
The easiest way to understand Stop when remote control or urgency appears is to place it inside a real wallet workflow. Remote-control tools can expose the screen, keyboard, mouse and clipboard to another person. Do not continue wallet, backup or signing tasks under remote direction from an unknown party, and never reveal seed phrases, private keys or verification codes.
Device security includes system updates, screen locks, application provenance, malware protection and physical access control. A wallet cannot replace device-level protection. If the device shows suspicious popups, unknown software or remote-control activity, stop sensitive actions first. When the page does not match what you expected, canceling is usually safer than pushing through. Then verify the transaction hash, contract address or explorer record independently.
Public Wi-Fi and shared computers increase exposure to session theft, malicious software and account compromise. For wallet login, signing or backup work, prefer devices and networks you control and avoid leaving sensitive sessions on shared machines. Turning these checks into a routine helps reduce errors caused by the wrong network, copied addresses, oversized permissions or misunderstood transaction state.
Practical checks
- Verify the network, address or contract source relevant to stop when remote control or urgency appears.
- Confirm that the request matches the intended action instead of relying on a familiar label.
- Keep public identifiers such as transaction hashes for verification while keeping private credentials under your own control.
Security statement
Seed phrases and private keys remain under the user’s control. Official personnel will not ask for them or for verification codes; on-chain transactions generally cannot be reversed by a wallet alone; third-party DApps and smart contracts may carry risk.
imtoken
Ready to get started?
The download entry always goes through the dedicated download page. Keep verifying networks, addresses and request details before acting.