Build the security baseline first
For Phishing & Scams, the first useful question is not “which button should I press?” but “which network, address or contract am I dealing with, and what change am I trying to make?” That framing makes later checks more reliable.
When an action spans networks or a Layer 2 environment, distinguish the source network, destination network and the route used to move the asset. Similar token names do not mean the assets exist on the same network. After a cross-layer or cross-network action, verify balances and transaction status on each relevant network and account for any waiting window.
With a DApp or smart contract, treat connecting, signing, approving and sending a transaction as separate actions. A connection usually creates a session. A message signature may prove control of an address or confirm intent. A token approval grants a contract permission within a defined allowance, while a transaction can change balances or contract state. Each request deserves its own review.
How common risk scenarios arise
In practice, fake domains, impersonated support, fake airdrops, clipboard attacks and social engineering often appears alongside balances, fees, transaction state or permission changes. Reviewing those pieces separately is more reliable than trusting a single success or failure message in an interface.
Do not rely on a single wallet status message when interpreting an on-chain event. A transaction hash is a durable lookup reference, and a block explorer can show whether a transaction was broadcast, included in a block and how many confirmations it has received. If the interface and explorer disagree, first verify the network and hash before attempting the action again.
Network fees and confirmation times change with congestion. A lower fee may mean a longer wait, while paying more does not guarantee success because contract conditions, balances, nonces or network state may still prevent execution. The purpose of understanding fees is to make informed choices, not to chase a fixed number.
- Use trusted bookmarks or verified entry points for sites you revisit
- Do not trust support messages that request a seed phrase
- Treat airdrop pages as normal DApp interactions that require review
- Re-check pasted addresses before sending assets
A practical review and response method
When something is unclear, stop creating new signatures or transactions, keep public information such as the address, network name and transaction hash, and verify each item through an explorer. Never provide a seed phrase or private key to obtain “support.”
Backup and recovery have a different security boundary. A seed phrase and private key can provide control of a wallet, so they should be kept offline where practical and should not be photographed, uploaded to an ordinary cloud drive or sent through chat. imtoken staff will not request them. If exposure is suspected, prioritize asset migration and permission review rather than repeatedly testing the same compromised environment.
Start by defining the boundary of fake domains, impersonated support, fake airdrops, clipboard attacks and social engineering. Labels in a wallet are only the interface; the actual on-chain result is determined by the network, addresses, transaction parameters and contract state. Before acting, confirm that the current network matches the asset, verify the recipient or contract address, and then review the amount, gas or permission scope. This order catches many errors before a transaction is submitted.
A practical decision method
Break fake domains, impersonated support, fake airdrops, clipboard attacks and social engineering into three layers: information, permission impact and on-chain result. First verify the network and object, then decide whether the request can move assets or expand permissions, and finally verify the result with the transaction hash and on-chain state.
What to prioritize after something looks wrong
For long-term use, make “verify the source, understand the request, review parameters, verify the result, and remove unnecessary permissions” a repeatable routine. The same routine applies to Phishing & Scams and to more advanced Web3 activity.
When an action spans networks or a Layer 2 environment, distinguish the source network, destination network and the route used to move the asset. Similar token names do not mean the assets exist on the same network. After a cross-layer or cross-network action, verify balances and transaction status on each relevant network and account for any waiting window.
With a DApp or smart contract, treat connecting, signing, approving and sending a transaction as separate actions. A connection usually creates a session. A message signature may prove control of an address or confirm intent. A token approval grants a contract permission within a defined allowance, while a transaction can change balances or contract state. Each request deserves its own review.
Never share a seed phrase, private key or verification code. Review the address, network, amount and permission scope before you confirm an action. On-chain transactions generally cannot be reversed by a wallet on its own.