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.
imtoken · Practical Guide

imtoken

Practical wallet guides should follow preparation, action, verification, common mistakes and security reminders.

01

Start with setup and recovery

A wallet guide should first distinguish creating a new wallet from importing an existing one and protect seed phrases and private keys in both flows. Recovery material should only be used on trusted devices. In practice, place “start with setup and recovery” back into the context of the active account, network and intended target instead of judging the action from interface styling or button labels alone.

02

Treat backup as an ongoing responsibility

A backup is not finished after one transcription. Consider whether the medium remains readable, can be lost, is being cloud-synced and can actually restore the wallet after device failure. This is rarely solved safely by clicking through again. A repeatable verification order for treat backup as an ongoing responsibility is more reliable than trial and error.

03

Receiving guides should emphasize network matching

Receiving instructions must cover both the address and the destination network and token. A guide should not treat “copy the address” as the whole process because cross-network mistakes are a common operational risk. Treating receiving guides should emphasize network matching as its own decision point helps prevent rapid click-through mistakes across multiple accounts, networks or DApp steps.

04

Sending guides need a pre-submit review

A sending workflow should standardize checks for address, network, amount, token and gas, and teach users to keep the transaction hash. That allows independent on-chain verification even when the interface is delayed. The practical goal of sending guides need a pre-submit review is to separate on-chain facts from interface presentation; if the two disagree, verify public blockchain state first.

05

Use transaction history for review

Guides should show how to move from wallet history to a block explorer and inspect status, block height and contract events instead of only explaining what a success or failure label means. Because blockchain actions can create persistent or irreversible state, understanding use transaction history for review should come before signing, approving or submitting.

06

Troubleshoot fundamentals first

When a balance is missing, a transaction is pending or sending fails, check the account, network, gas, transaction hash and token contract before assuming an interface problem. Repeated submission is not a safe troubleshooting method. Reviewing troubleshoot fundamentals first never requires giving anyone a seed phrase or private key; public state can be checked with addresses, transaction hashes and contract information.

Practical checklist

Use this list as a final review before you submit a transaction, signature or approval related to this topic.

  • Treat creation and import as separate workflows
  • Confirm that backups remain usable
  • Specify the network when receiving
  • Keep transaction hashes after sending
  • Troubleshoot account, network and gas first
Security boundary

Never share a seed phrase, private key or verification code. A wallet provider generally cannot reverse a confirmed on-chain transaction, and third-party DApps or smart contracts can carry independent risk.