Create & Backup

Start with a clear model of creating a wallet

When working with creating a wallet, separate the wallet interface from the network record and any third-party service involved. imtoken can help present information or initiate an action, but the final result depends on the relevant network and contract state. Details such as importing an existing wallet and offline seed phrase backup should be checked in context rather than trusted because a screen looks familiar.

A useful workflow is prepare, verify, execute, and review. Prepare by identifying the intended network and outcome. Verify private-key protection and and safe recovery preparation before proceeding. Execute only a request you understand, then review the transaction hash, explorer record, or permission state afterward. This creates several opportunities to catch a mismatch before it becomes costly.

What to check

• Confirm creating a wallet matches your intended task
• Review the source and scope of importing an existing wallet and offline seed phrase backup
• Verify private-key protection and and safe recovery preparation after the action

Handle importing an existing wallet and offline seed phrase backup as separate decisions

A prompt involving importing an existing wallet may represent simple account visibility, a wallet connection, a transaction signature, or a lasting token permission. Those requests do not carry the same consequence. The same is true for offline seed phrase backup: its meaning depends on the selected network, contract, and the exact action being requested.

If the request is hard to understand, the source does not match what you intended, the domain looks unusual, or the permission is broader than necessary, reject it and restart from a trusted entry point. There is rarely a good reason to rush an on-chain action, especially when a large value, unlimited approval, or unfamiliar contract is involved.

Useful boundaries

• Do not treat importing an existing wallet as a generic confirmation
• Check whether offline seed phrase backup belongs to the intended network
• Reject requests you cannot explain

Verify the outcome of private-key protection

After the action completes, confirm that private-key protection reached the expected state. A success message in the interface may only indicate that the front-end flow progressed. For transfers, review the transaction hash, sender and recipient, network, amount, and confirmations. For approvals, check the spender and allowance that remain on-chain.

If something looks wrong, avoid repeatedly submitting the same action without understanding the cause. Check whether the network is correct, the transaction is still pending, gas was sufficient, the contract reverted, or the asset exists on another network. Blind retries can create additional fees or duplicate outcomes if the original action later confirms.

Post-action review

• Use verifiable records to check private-key protection
• Confirm and safe recovery preparation did not change unexpectedly
• Investigate before retrying

Make and safe recovery preparation part of routine security

and safe recovery preparation should not be reviewed only after a problem. Build it into regular wallet maintenance by checking active networks, DApp connections, and token permissions, removing access you no longer use, and keeping devices and browsers updated. Sensitive actions should be avoided on shared computers or untrusted networks.

Keep seed phrases and private keys under your own control. Official staff will not ask for them, and they should not be sent to anyone. Check the address, network, and amount before a transfer; review each DApp signature independently; and consider revoking permissions that are no longer needed. On-chain transactions usually cannot be unilaterally reversed by a wallet, so prevention matters more than recovery.

Routine checklist

• Keep seed phrases and private keys offline and private
• Check address, network, and amount before sending
• Review every signature and approval on its own merits
• Remove connections and permissions you no longer need

Common misconceptions and safer alternatives

A familiar interface, a lookalike domain, or a high search ranking does not prove authenticity. Another common misconception is that a successful screen means creating a wallet or importing an existing wallet cannot create later risk. Network state, contract permissions, and asset prices can continue to change, so the right verification method depends on the operation.

A stronger default is to perform only actions you understand, sign only after checking the source and network, grant only the permissions required for the current task, and keep the transaction hash or on-chain record available for review. When a situation cannot be explained, stop creating new actions and investigate the network, address, contract, and approval state first.