Receiving safely
Send & Receive is designed around clear network awareness. A wallet interface presents blockchain state and signing requests, while the assets themselves remain recorded on their respective networks.
Four checks before sending
Before receiving or sending, verify the network and address. Before broadcasting a transaction, also review the amount and estimated fee; after broadcast, keep the transaction hash for independent verification.
- Network matches the intended asset or service
- Address or contract has been independently checked
- No seed phrase, private key, or code is being requested
Broadcast and confirmation
Token visibility depends on network and contract information. Matching names or symbols are not enough to identify a token, so contract addresses should come from trusted sources.
When a transfer looks unusual
Seed phrases and private keys remain with the user. imtoken does not ask users to enter them into ordinary web pages, and on-chain transactions generally cannot be unilaterally reversed by the wallet.
Review after the action
Keep the transaction hash and confirm the network and final status after completing a transfer or contract interaction. After DApp use, also review whether a persistent approval remains. Breaking large operations into smaller verifiable steps can make problems easier to spot.
A non-negotiable security boundary
A normal wallet guide never requires you to send a seed phrase, private key, or verification code to another person. Public addresses and transaction hashes are enough for many support and troubleshooting questions.
Practical verification for Send & Receive
A practical way to work with Send & Receive is to separate preparation, review, execution, verification, and maintenance. Start by identifying the active network and account, then use Receiving safely, Four checks before sending, and Broadcast and confirmation as checkpoints for the address, asset, contract, fee, or permission involved. After an action is broadcast, keep the transaction hash and verify it on the correct network. When a DApp or smart contract is involved, also review persistent approvals after the session ends. Public addresses and transaction hashes are appropriate troubleshooting references; seed phrases, private keys, and verification codes are not. Any workflow that asks for those secrets should be stopped and independently rechecked.
On-chain transactions generally cannot be reversed by a wallet provider. Review the address, network, amount, contract, and requested permissions before signing.