Use a trusted device and network
Base each step on verifiable information, and never send a seed phrase, private key, or verification code to anyone.
imtoken
Send & Receive
A practical guide to receiving addresses, network matching, gas, amounts, transaction hashes, and confirmations, with clear decision points and risk boundaries.
Before you begin
A practical guide to receiving addresses, network matching, gas, amounts, transaction hashes, and confirmations, with clear decision points and risk boundaries.
On-chain actions usually cannot be reversed by a wallet alone. Review the address, network, amount, and requested permissions before proceeding.
Confirm the target network and address
Base each step on verifiable information, and never send a seed phrase, private key, or verification code to anyone.
Read every transaction, signature, or approval request
Base each step on verifiable information, and never send a seed phrase, private key, or verification code to anyone.
Keep the transaction hash and verify the result
Base each step on verifiable information, and never send a seed phrase, private key, or verification code to anyone.
Review old connections and approvals
Base each step on verifiable information, and never send a seed phrase, private key, or verification code to anyone.
Understand the core idea first
The practical value of Send & Receive comes from understanding how receiving addresses, network matching, gas, amounts, transaction hashes, and confirmations relate to one another. Before an on-chain action, confirm the network, destination, request content, and any fee or permission that may be involved. Do not rely on appearance or naming alone when something is uncertain.
Practical check
Apply this to a real action: verify the target and network, read the request details, then confirm the result with on-chain information. Familiar interfaces should not replace verification.
How to evaluate a real action
When working with receiving addresses, network matching, gas, amounts, transaction hashes, and confirmations, break the task into four checks: identify the counterparty or target, verify the network, read the request, and verify the result afterward. Transfers require address, network, and amount checks; signatures and approvals require careful review of the requester and scope.
Practical check
Apply this to a real action: verify the target and network, read the request details, then confirm the result with on-chain information. Familiar interfaces should not replace verification.
Common mistakes and risk boundaries
Typical mistakes include assuming matching address formats mean matching networks, treating a DApp connection as permission to approve everything, and assuming a submitted transaction is already final. On-chain actions usually cannot be reversed by a wallet provider alone, so pre-action review matters.
Practical check
Apply this to a real action: verify the target and network, read the request details, then confirm the result with on-chain information. Familiar interfaces should not replace verification.
Build a repeatable safety routine
For receiving addresses, network matching, gas, amounts, transaction hashes, and confirmations, use a routine you can repeat: keep recovery material offline, never send seed phrases or private keys to anyone, use trusted devices, verify domains, review each signature or approval, and remove connections or approvals you no longer need.
Practical check
Apply this to a real action: verify the target and network, read the request details, then confirm the result with on-chain information. Familiar interfaces should not replace verification.