A wallet controls keys, not a balance stored on a screen
A digital wallet is an interface for using keys and addresses against public blockchain state. The balance shown in the interface is read from the active network; it is not stored inside the website, phone, or browser. That distinction explains why changing devices does not move the underlying assets.
The same-looking address can have different balances and histories across networks. When reviewing an asset, treat the address, network, token contract, and current chain state as one context rather than isolated fields.
Account, address, and network belong together
A correct address is only one part of a correct transaction. The active chain, native gas asset, and target contract must also match the intended operation. EVM networks can share an address format while keeping separate chain IDs, balances, contracts, and transaction histories.
For multi-chain use, make “account + network + asset” the minimum review unit. If one of those changes, re-check the rest before trusting the displayed balance or submitting a request.
Creating, importing, and backing up solve different problems
Creating a wallet produces new key material. Importing or restoring uses existing recovery material so the current device can sign for an existing account. Neither process rewrites the blockchain history.
Seed phrases and private keys should remain under the user’s control. A backup exists so access can be recovered after device loss or failure; it is not a reason to upload the secret to a support service or an online form.
Receiving and sending require a preflight check
Before receiving, confirm which network the sender will use and provide the matching address. Before sending, review the complete destination, network, asset, amount, and expected gas. For an unfamiliar path or a large amount, a small test transfer can help validate the route.
Once an on-chain transaction is confirmed, a wallet generally cannot reverse it unilaterally. Contact names, QR codes, and clipboard history are input aids, not substitutes for checking the destination itself.
Transaction history should be grounded in on-chain evidence
A transaction hash is a public identifier that can be checked on a block explorer for the correct network. It can show status, block inclusion, sender, recipient, fees, and contract execution details.
Wallet labels such as “pending” or “complete” may depend on node and indexing updates. When the interface and your expectation disagree, verify the network and transaction hash before repeating the action.
Long-term wallet use includes permissions and device hygiene
Risk does not begin and end with transfers. DApp connections, message signatures, token approvals, network changes, extensions, and device access all affect the security boundary. Old connections and approvals deserve periodic review.
Keep the operating system and browser current, use a reliable screen lock, and avoid sensitive wallet actions on shared computers, public networks, or remote-access sessions whenever possible.
imtoken will not ask for your seed phrase, private key, or verification code. A page or support flow that requests those secrets should not be trusted.
A repeatable wallet review sequence
A useful sequence is: confirm the account, confirm the network, confirm the counterparty or contract, read the request, then verify the result after submission. This prevents familiar interface elements from replacing an actual review of the fields that determine the on-chain outcome.
When the interface looks wrong, verify the chain first
If you cannot explain a field, stop and identify what it represents before continuing. After an action, retain public evidence such as the transaction hash and check whether any unnecessary DApp session or approval remains.
- Keep seed phrases and private keys under your own control.
- Verify full addresses, networks, assets, amounts, and gas before sending.
- Treat connection, signing, approval, and transaction requests as separate decisions.
- Use the correct network’s public chain data to verify submitted transactions.