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
中文Download

imtoken Practical Guide

Create & Back Up a Wallet

When creating or importing a wallet, recovery-material management comes first. If a seed phrase or private key is exposed, changing an interface password later does not replace secret protection, so offline backup and verification should happen before meaningful asset use.

01

Prepare before you begin

Focus: wallet creation, wallet import, and seed phrases

When creating or importing a wallet, recovery-material management comes first. If a seed phrase or private key is exposed, changing an interface password later does not replace secret protection, so offline backup and verification should happen before meaningful asset use.

When permissions may change, prepare information you can verify independently and confirm the intended account and network. When wallet creation, wallet import, or seed phrases is involved, keep recovery material, public addresses, and interface credentials conceptually separate.

Read the whole procedure before beginning, especially where a step changes from local viewing to signing, approval, or an on-chain transaction. Actions that can be irreversible or consume network fees deserve an additional review point.

02

Follow the operation in order

Focus: seed phrases, private keys, and offline backups

When deciding whether a result is final, execute the workflow in small steps. Start with wallet creation, then check wallet import and seed phrases; before moving on, confirm that the displayed account, network, and target have not unexpectedly changed.

Whenever information must be entered, copied, or shown, decide first whether it is supposed to be public. A wallet address can normally be shared for receiving, while a seed phrase, private key, or verification code should never be handed to a site or support contact.

When building a repeatable routine, if the flow includes signing or a transaction, expand the request instead of relying on a short confirmation label. Review the object, network, amount, gas, contract, or permission scope and continue only after the effect is understood.

03

Verify the account or transaction result

Focus: offline backups, backup verification, and recovery rehearsal

After the primary step, use details related to private keys, offline backups, or backup verification to verify the outcome. For on-chain work, prioritize the transaction hash and network record; for local account tasks, verify that the local state matches the intended result.

From a risk-boundary perspective, do not repeat an action merely because the interface has not refreshed. Determine whether the original request was submitted, is still pending, or failed before deciding what to do next.

Verification should rely on public or locally controlled information. Troubleshooting never requires sending a seed phrase or private key to another party.

04

Recognize common mistakes and troubleshoot them

Focus: recovery rehearsal, device separation, and wallet creation

In practical use, common errors often come from the wrong network, the wrong object, a request that was not fully read, or confusing recovery rehearsal with device separation. When something looks wrong, stop creating new requests and reconstruct what already happened in chronological order.

For a third-party DApp, re-check the domain and contract. For a transfer, re-check the address, network, and transaction hash. For recovery material, stop all sharing and protect the current device.

A useful tutorial is not designed to make confirmation faster. It makes every step explainable and reviewable, and it treats exiting an unclear request as a normal option.

05

Finish with a security check

Focus: wallet creation, wallet import, and seed phrases

Before making a decision, finish with an independent security check: secret material stayed private, the address and network match, the request came from the intended source, and the result has been verified with a reliable record.

For sessions or approvals that can remain active, decide whether they still need to exist after the task. Disconnect unused sessions and consider revoking permissions that are no longer necessary.

On-chain transactions generally cannot be reversed by a wallet provider alone. imtoken will never ask for a seed phrase, private key, or verification code, and a guide or support request asking for those secrets should not be followed.

Operation and security checklist

  • Confirm the context for wallet creation
  • Cross-check wallet import and seed phrases
  • Understand the request involving private keys
  • Keep a verifiable record related to backup verification
  • Review third-party DApp requests individually
  • Never send a seed phrase, private key, or verification code to anyone

Continue learning

Wallet GuidesTransaction ChecksSecurityFAQ