imtoken will never ask for your seed phrase, private key or verification code. Always review the address, network and request details before transferring, signing or approving.
A wallet overview should answer three practical questions first: which network holds the asset, whether the active address is correct, and where the result can be verified after an action. imtoken connects asset views, transfers, transaction history, and token contracts into that verifiable workflow.
Focus: multi-chain assets, network selection, and address verification
A wallet overview should answer three practical questions first: which network holds the asset, whether the active address is correct, and where the result can be verified after an action. imtoken connects asset views, transfers, transaction history, and token contracts into that verifiable workflow.
Before making a decision, treat multi-chain assets, network selection, and address verification as separate pieces of information. They can appear in one product flow, but they do different jobs; separating the network, account, and current request makes inconsistencies easier to spot than relying on a balance or button state alone.
When something is unfamiliar, information shown by Wallet & Assets should lead back to something verifiable. The interface can support understanding and action, but an on-chain outcome should still be checked against the address, selected network, transaction record, or contract information rather than a single visual message.
02
Place capabilities in real workflows
Focus: address verification, receiving, and sending
After completing an action, begin with frequent tasks such as receiving and sending: identify the object, verify the network and request, and only then execute. Afterward, review transaction records so the action you intended can be compared with what the network recorded.
Wallet & Assets should also make the difference between viewing information and authorizing a state-changing action clear. Looking at multi-chain assets does not grant a third party permission, while sending, signing, or contract interaction can change assets or permissions.
To reduce misinterpretation, do not assume the risk is identical just because the same account is used in several contexts. A mobile device, a browser session, and a third-party DApp differ in source, permission scope, and device exposure.
03
Verify outcomes with network data and records
Focus: sending, transaction records, and transaction hashes
When several pieces of information appear together, transaction hashes can be a useful result reference, while token contracts helps identify a specific asset or contract object. Reading those details together with the active network reduces the chance of treating identically named items as the same object.
If an expected result has not appeared in the interface, check public records and the active network before deciding whether to refresh, reload, or wait. Repeated submissions while the state is unclear can create extra fees or additional transactions.
When checking an on-chain result, keep only the public information needed for troubleshooting, such as an address, network, transaction hash, or contract address. A product-support check does not require a seed phrase, private key, or verification code.
04
Keep permission boundaries clear in Web3
Focus: transaction hashes, token contracts, and multi-chain assets
Before moving to the next step, treat a DApp connection as the beginning of a session, not permanent consent to later requests. Every signature, approval, and transaction deserves a separate review of the domain, account, network, contract, and request details.
Stop if a third-party page asks you to enter a recovery phrase or private key. Ordinary wallet connection does not require giving secret material to a website, and official personnel will not ask for it.
The Wallet & Assets experience should make permission boundaries understandable rather than use urgency to encourage confirmation. Declining a request you do not understand is a valid security decision.
05
Build a repeatable wallet routine
Focus: multi-chain assets, network selection, and address verification
From a beginner's perspective, use a repeatable sequence: verify the entry point, account, and network; read the request; execute only after understanding it; then verify the result. The same sequence can support multi-chain assets, receiving, and sending while making troubleshooting more structured.
Periodically reviewing transaction records together with DApp sessions or approvals you no longer use can reduce forgotten permissions. This cannot remove every risk, but it makes account state easier to understand and manage.
Users keep control of their seed phrases and private keys. imtoken will never ask for a seed phrase, private key, or verification code. Verify the address, network, and amount before sending because an on-chain transaction generally cannot be reversed by a wallet provider alone.
Operation and security checklist
Confirm the context for multi-chain assets
Cross-check network selection and address verification
Understand the request involving receiving
Keep a verifiable record related to transaction records
Review third-party DApp requests individually
Never send a seed phrase, private key, or verification code to anyone
