imtoken
Transaction Checks
Turn address, network, asset, amount, gas, signatures and transaction hash into a fixed pre- and post-transfer routine.
Recheck the address after copying
Breaking Recheck the address after copying into smaller decisions is more reliable than accepting a single page-level conclusion. 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.
Clipboard malware can replace long addresses in ways that are hard to notice. After copying an address, compare the beginning, ending and key characters again. For important transfers, consider an address book, small test or second-device verification. 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.
Receiving assets requires more than copying an address; the sender also needs the correct network. For similarly named or bridged assets, verify the contract and network support so funds are not sent to a network the recipient cannot properly recognize. If the purpose or target of a request cannot be understood, the safer next step is to stop rather than add permissions or repeatedly resubmit.
Make the checks repeatable
- Verify the network, address or contract source relevant to recheck the address after copying.
- 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.
The network and asset must match
The easiest way to understand The network and asset must match is to place it inside a real wallet workflow. The same-looking address format can exist on different networks, while balances, gas assets, contracts and transaction histories remain separate. Choose the network based on where the asset actually exists and what the recipient supports, not just the token name shown in the interface.
Token names and icons can be copied, so the contract address is a stronger identity check. When adding a custom token or handling an unfamiliar asset, verify the contract, network and token details from a trusted source rather than relying on a similar name. 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.
Before sending, verify the destination address, network, asset, amount and gas. For higher-value transfers, a small test can reduce operational mistakes. If the page unexpectedly asks to switch networks, add an approval or sign something unrelated, cancel and review before continuing. Even when the wallet interface shows a result, important actions are easier to verify later when you keep the relevant public identifiers.
Practical checks
- Verify the network, address or contract source relevant to the network and asset must match.
- 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.
Review amount, gas and signing content together
With Review amount, gas and signing content together, one common mistake is treating interface text as the final on-chain truth. Gas is the execution cost charged by the network for transactions or contract calls. It varies with network rules, congestion and operation complexity. Gas is not a fixed wallet price and does not indicate whether a request is safe; review the amount, network and request details as well.
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. 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.
Permission scope determines what a third party can do and how much value is exposed. Distinguishing account visibility, message signing, transaction submission and token approval helps users avoid treating a low-impact connection like a high-impact authorization and makes suspicious requests easier to spot. If the purpose or target of a request cannot be understood, the safer next step is to stop rather than add permissions or repeatedly resubmit.
What is easy to miss
- Verify the network, address or contract source relevant to review amount, gas and signing content together.
- 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.
Verify with on-chain records after submission
For Verify with on-chain records after submission, start with information that can be independently verified. A transaction hash is one of the main identifiers for locating an on-chain transaction. Use it with the correct network explorer to check broadcast status, block inclusion, execution result and fees. When a transfer is delayed, verify the hash before deciding whether to try again.
A block explorer lets users inspect addresses, transaction hashes, blocks and contract data. First make sure it matches the intended network, and be careful with ads, lookalike sites and unverified labels. Explorer data helps verify chain state but does not replace key security. 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.
Confirmation counts reflect how much additional block or finality progress has occurred after a transaction. More confirmations usually mean a more settled state, but finality works differently across consensus systems, so interpret it in the context of the target network. Even when the wallet interface shows a result, important actions are easier to verify later when you keep the relevant public identifiers.
Before you confirm
- Verify the network, address or contract source relevant to verify with on-chain records after submission.
- 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.