Control sensitive information and verify every request
A legitimate workflow should not require a seed phrase, private key or verification code. Treat signatures, approvals and transfers as separate decisions with separate consequences.
Core ideas behind Phishing & Scam Awareness
Phishing & Scam Awareness brings together phishing domains, fake support, fake airdrops, malicious links, clipboard risk and remote access. Security decisions depend on identifying who is requesting access, what permission is being requested and what on-chain effect the action can create. The practical goal is to understand which fields are informational and which steps can create a signature, approval or transaction that changes on-chain state.
Start with phishing domains by identifying the intended destination and context. Then verify fake support and fake airdrops before interpreting malicious links, clipboard risk or remote access. The point of learning these concepts is not to add friction, but to reduce blind spots around addresses, networks, permissions and transaction state.
What to verify first when risk appears
- Confirm the scope of phishing domains
- Check that fake support matches the intended destination
- Understand the role of fake airdrops before confirming
A practical decision sequence
A consistent operating sequence helps: identify the destination, verify the network and address, review the fee or permission details, and only then confirm. When malicious links is involved, do not rely on a single number or button label; determine which network produced it, what request it belongs to and whether it creates ongoing permission. On-chain actions are often public, verifiable and difficult to reverse, so verification before an action is more useful than trying to repair a mistake afterward.
If the action produces clipboard risk or another public record, keep the transaction hash or public status needed for verification rather than storing sensitive key material. For remote access, distinguish wallet-local status, blockchain state and third-party service status because they can change independently.
- Verify fake support and fake airdrops first
- Review the cost or permission around malicious links separately
- Use public on-chain data to validate clipboard risk
How phishing domains and fake support fit together
phishing domains and fake support often appear in the same workflow, but they answer different questions. One identifies the object or usage context while the other helps locate identity, routing or chain context. Read them together with fake airdrops and malicious links instead of assuming that a familiar name means the network is correct.
clipboard risk helps show whether an action has entered the on-chain lifecycle, while remote access can affect what remains possible afterward. Connect the stages from request, to signing or submission, to confirmation and permission maintenance. The guidance assumes that users keep control of their own keys and never submit a seed phrase, private key or verification code to a website or support agent.
- Review phishing domains and fake support in the same workflow
- Do not ignore network differences in fake airdrops and malicious links
- Check clipboard risk and remote access after completion
Recognizing common risks and mistakes
Common failures tend to come from three patterns: similar names on different networks, confirming a long request without reading it, and treating a third-party display as final blockchain truth. Requests involving phishing domains, fake airdrops or remote access deserve extra checks of the domain, network identifier, contract address, spender and transaction details. When a label or icon conflicts with on-chain parameters, verify the network, contract address and transaction details rather than trusting the visual label alone.
Also separate connection from authorization. A wallet connection may expose a public account to a DApp, but it does not justify every later signature. Approvals, signatures and transfers can have real consequences. imtoken staff will not ask for a seed phrase or private key, and users should never send verification codes to another person.
- Stop when a request looks inconsistent
- Do not approve sensitive actions from screenshots or chat instructions
- Reject any request for a seed phrase or private key
Checks after the action is complete
After the action, verify the outcome. Use the transaction hash, block explorer or wallet history to review clipboard risk and confirm that the target network, address and status are consistent. If remote access represents an ongoing approval or relationship, review it periodically and consider revoking access that is no longer needed.
Phishing & Scam Awareness is better understood as a repeatable verification method than as a one-time button sequence. Check the destination, network, address, fee or permission, signature details and final state as separate decisions. If the available information is not enough to make a confident decision, stop the signature or transfer and verify the source and parameters before continuing.
- Keep public information needed for verification
- Review approvals that remain active
- Stop further actions when the observed result is unexpected
Practical checklist
- Never enter a seed phrase, private key or recovery phrase into a website
- imtoken staff will not ask for a seed phrase, private key or verification code
- Verify the address, network and amount before a transfer
- Review each DApp signature request separately
- Periodically review and revoke approvals that are no longer needed
