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.
Wallet & Assets

Wallet & Assets Overview

This guide connects the practical decisions behind multi-chain assets, network selection, and address verification. It focuses on verifiable on-chain information, clear user actions, and security habits that remain useful even when interfaces change.

Use case

Confirm the asset network first, then verify the address, request and on-chain result.

Product use

Start from the task, then verify the network

A wallet interface is useful when each action can be tied back to a network, an address, a permission request and a verifiable result.

On this page
  1. How the wallet experience is organized
  2. Using multi-chain assets with network selection
  3. Checking address verification and transaction history against the chain
  4. Web3 connections and permission boundaries
  5. A practical everyday workflow
  6. Security and product boundaries

How the wallet experience is organized

Wallet & Assets Overview is organized around user tasks: create or import a wallet, back up recovery information, choose a network, view assets, send or receive, inspect transactions, and connect to DApps. The objective is to help users understand what they are doing at each stage instead of presenting a wall of disconnected features; in Wallet & Assets Overview, read this specifically alongside “How the wallet experience is organized” and multi-chain assets. For Wallet & Assets Overview, connect multi-chain assets with network selection and address verification; the important part is the relationship between those concepts and the on-chain evidence you can verify afterward.

Using multi-chain assets with network selection

multi-chain assets and network selection are closely related in a multi-chain wallet. Assets belong to specific networks, so both parties should confirm the network and destination before a transfer; in Wallet & Assets Overview, read this specifically alongside “Using multi-chain assets with network selection” and network selection. EVM addresses may look the same across several networks, but that visual similarity does not mean assets move between those networks automatically; in Wallet & Assets Overview, read this specifically alongside “Using multi-chain assets with network selection” and network selection. When working through “Using multi-chain assets with network selection,” check the source, network, request details and resulting state in that order, with extra attention to network selection and address verification.

Checking address verification and transaction history against the chain

address verification and transaction history help reconcile the wallet interface with public on-chain data. A transaction hash can be used to verify status, sender, recipient, fee, and confirmations; in Wallet & Assets Overview, read this specifically alongside “Checking address verification and transaction history against the chain” and address verification. If an asset is missing from the interface, check the selected network and token contract before repeating a transfer or importing an unknown token; in Wallet & Assets Overview, read this specifically alongside “Checking address verification and transaction history against the chain” and address verification. Do not treat an interface success message as the final answer for Wallet & Assets Overview. Use address verification, transaction history and asset visibility to confirm that the expected change occurred on the intended network.

Web3 connections and permission boundaries

For Web3 activity, a wallet connection only establishes an interaction channel; in Wallet & Assets Overview, read this specifically alongside “Web3 connections and permission boundaries” and transaction history. Each signature, token approval, and contract transaction has its own effect and should be reviewed separately; in Wallet & Assets Overview, read this specifically alongside “Web3 connections and permission boundaries” and transaction history. Activities involving asset visibility deserve particular attention to the requester, approval scope, and contract address. If “Web3 connections and permission boundaries” is unclear, stop before approving and return to the basics of transaction history and asset visibility, then verify the result with a transaction hash, contract address or block record where applicable.

A practical everyday workflow

A useful everyday sequence is to confirm the device and site, check the wallet account and network, review the address/amount/gas before sending, verify the transaction afterwards, and read every DApp request before signing; in Wallet & Assets Overview, read this specifically alongside “A practical everyday workflow” and asset visibility. When a session is no longer needed, disconnect and consider revoking permissions that should not remain active; in Wallet & Assets Overview, read this specifically alongside “A practical everyday workflow” and asset visibility. A durable routine for Wallet & Assets Overview is to make asset visibility a first-pass check, use everyday security as a second check, and rely on verifiable information related to multi-chain assets rather than interface assumptions.

Security and product boundaries

Wallet & Assets Overview cannot remove the risks of blockchain networks, third-party DApps, smart contracts, or market volatility. Seed phrases and private keys remain under the user’s control, and imtoken will not ask for them; in Wallet & Assets Overview, read this specifically alongside “Security and product boundaries” and everyday security. For everyday security and other sensitive activity, use a trusted device and avoid public or remotely controlled environments. This part of Wallet & Assets Overview should be read together with the surrounding workflow: everyday security affects how you interpret multi-chain assets, while network selection helps confirm the state after the action.

Security and risk reminder

Seed phrases and private keys are controlled by the user. imtoken will never ask for them. Blockchain transactions are generally irreversible by a wallet provider, and third-party DApps, smart contracts, network conditions and digital-asset prices can introduce additional risk.