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

Wallet & Assets

Understand how this capability fits into a multi-chain wallet through practical use cases, operating boundaries and security principles.

Server-rendered HTMLOn-chain verifiableSecurity-first education

Wallet and on-chain assets

A wallet manages keys and reads blockchain state; the asset record itself remains on the relevant network. This topic should be understood through both user workflow and verifiable on-chain results. The wallet interface helps with context, but the network, address, contract and transaction state remain the source of truth.

In practice, combine interface information with data you can verify on-chain. If anything is unclear, stop before a high-value action and confirm the network, address, contract or transaction state.

Address and network

When receiving, verify both the address and the network rather than relying on the token name alone. This topic should be understood through both user workflow and verifiable on-chain results. The wallet interface helps with context, but the network, address, contract and transaction state remain the source of truth.

In a multi-chain environment, the network name, native gas asset, block explorer and contract address create the decision context. Icons, symbols and screenshots are only supporting cues.

Send checks

Review destination, network, amount and gas before sending, then keep the transaction hash. This topic should be understood through both user workflow and verifiable on-chain results. The wallet interface helps with context, but the network, address, contract and transaction state remain the source of truth.

Seed phrases and private keys remain under user control, and official staff will never request them. Any website or person asking for recovery material or verification codes should not be trusted.

Transaction records

Use block height, confirmation count and the transaction hash to verify on-chain results. This topic should be understood through both user workflow and verifiable on-chain results. The wallet interface helps with context, but the network, address, contract and transaction state remain the source of truth.

When a third-party DApp, bridge or smart contract is involved, consider permission scope, contract risk, congestion and service dependencies. Confirmed on-chain transactions usually cannot be reversed by a wallet.

DApp boundaries

Connection, signing, approval and transaction submission are separate permission layers. This topic should be understood through both user workflow and verifiable on-chain results. The wallet interface helps with context, but the network, address, contract and transaction state remain the source of truth.

After the action, keep the transaction hash and review confirmations to build independent verification habits. Revisit persistent connections and approvals when they are no longer needed.

Review after the action

After completing the task, compare the on-chain state with what you expected. Network, transaction hash, block height, confirmation count and approval status can reveal display delays, network mistakes or permissions that remain active longer than intended. Security is an ongoing review process, not a one-time setting.

Continue with imtoken

The download entry points to download.html. Back up first and verify the network before acting.

Download imtoken