Good decisions around Create & Backup start with context: which account is active, which network is selected, what request is being made, and how the result can be independently checked. Start with wallet creation and wallet import, then use seed phrases and private keys to understand what the wallet is asking you to do. imtoken presents these topics as practical guidance; a website should never require your seed phrase, private key, or verification code to explain them.
Start with wallet creation and wallet import
Wallet Creation provides the first layer of context for Create & Backup. Before acting, confirm the active account, the selected network, and the asset or contract involved. Wallet Import matters because the same-looking address can participate in very different network environments, and a familiar address format does not prove that the destination network is correct. When needed, compare the network name, chain information, asset contract, and block-explorer record rather than relying on a logo or page label alone.
A connection request, signature request, token approval, and transfer are separate decisions. Connecting to a site does not make every later request trustworthy. Treat each prompt as a new action that deserves its own review.
Working with seed phrases
When dealing with seed phrases, first identify why the action was initiated. Review the network, address, amount, contract, fee, or permission details that are relevant to the request. Once an on-chain transaction is broadcast, a wallet generally cannot reverse it on its own, which makes pre-confirmation checks more valuable than after-the-fact recovery attempts. After submission, keep the transaction hash and use the appropriate block explorer to see whether the network has received, included, and confirmed the transaction.
Wallet interfaces can occasionally lag behind the chain because of RPC delays, congestion, or temporary indexing issues. In those cases, the public on-chain record is an important reference point for distinguishing a display delay from a transaction that has not actually progressed.
Review private keys and offline backups carefully
Private Keys and offline backups are common places for users to miss important context. Confirm that you intentionally opened the site, check the domain, and read the wallet prompt rather than approving it by habit. For token permissions, review the approval target, amount, and scope. For cross-layer or cross-network actions, verify the destination network, transfer path, expected fees, and any waiting period before you proceed.
Never send a seed phrase, private key, or verification code to another person or enter it into a third-party website. Public computers, unsecured Wi-Fi, remote-control sessions, and unknown software add avoidable risk to sensitive wallet operations.
Verify recovery checks with evidence you can revisit
The strongest checks use information that can be independently revisited: network name, chain ID, transaction hash, contract address, block height, confirmation count, or approval record. A screenshot or chat message by itself is not reliable evidence of an on-chain state. If something looks wrong, stop signing or transferring and return through a trusted entry point before continuing.
For a large transfer, a smaller test transfer can help verify the address and network before more value is moved. It does not remove every risk, but it can catch simple errors early.
Review the result after you finish
After completing a Create & Backup flow, do not rely only on a success message. Reopen the transaction record or the relevant block explorer and compare wallet creation, seed phrases, and recovery checks with what you intended. If a DApp was involved, disconnect sessions you no longer need and review whether any broad approval remains. Transaction hashes are useful for troubleshooting, but seed phrases, private keys, and verification codes should never be included in screenshots or support notes.