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

Send & Receive

Sending and receiving are not just about pressing a transfer button. The address, network, asset, amount, gas, and on-chain result must remain consistent, and the transaction hash should be preserved as the reference for later verification.

01

Prepare before you begin

Focus: recipient addresses, destination network, and transfer amount

Sending and receiving are not just about pressing a transfer button. The address, network, asset, amount, gas, and on-chain result must remain consistent, and the transaction hash should be preserved as the reference for later verification.

Before making a decision, prepare information you can verify independently and confirm the intended account and network. When recipient addresses, destination network, or transfer amount 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: transfer amount, gas fees, and confirmations

When something is unfamiliar, execute the workflow in small steps. Start with recipient addresses, then check destination network and transfer amount; 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.

After completing an action, 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: confirmations, transaction hashes, and block explorers

After the primary step, use details related to gas fees, confirmations, or transaction hashes 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.

To reduce misinterpretation, 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: block explorers, small test transfers, and recipient addresses

When several pieces of information appear together, common errors often come from the wrong network, the wrong object, a request that was not fully read, or confusing block explorers with small test transfers. 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: recipient addresses, destination network, and transfer amount

When checking an on-chain result, 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 recipient addresses
  • Cross-check destination network and transfer amount
  • Understand the request involving gas fees
  • Keep a verifiable record related to transaction hashes
  • Review third-party DApp requests individually
  • Never send a seed phrase, private key, or verification code to anyone