What this product area is for

The Wallet Overview area supports everyday workflows around Multi-chain assets, Addresses and networks, Transaction history, while keeping network, address, transaction and approval details visible for review.

Download imtoken

Multi-chain assets

A single wallet interface may display assets from several networks, but identical token names do not mean those assets live on the same chain. Always verify the network, address format, token contract and transaction status together.

When working with multi-chain assets, separate what the interface displays from what the blockchain actually records. The wallet helps you review and initiate actions, while the final state depends on the target network, transaction data and block confirmations. Before any asset movement or permission change, confirm the counterparty, network and intended result before signing.

A durable habit around multi-chain assets matters more than memorizing where a button sits. Interfaces may change across devices or versions, but addresses, networks, transaction hashes, contract addresses and approval targets remain verifiable. When something looks wrong, use those facts to distinguish a display issue from network congestion or a contract interaction problem.

Risk around multi-chain assets often comes from incomplete information or confusing one object for another. Lookalike domains, same-name tokens, the wrong network or an unnecessarily broad approval can all produce a normal-looking screen while leading to an unintended action. Reduce that risk by checking critical fields one by one instead of relying on a single badge or visual cue.

How to verify information about Multi-chain assets

Prioritize fields that can be independently checked for Multi-chain assets. Compare the state before and after the action; if the result differs from what you expected, verify the network and transaction state before taking further action.

Addresses and networks

An address identifies an account on-chain while the selected network determines which nodes and consensus system process the transaction. Recheck the first and last characters after pasting and confirm the network before signing.

A durable habit around addresses and networks matters more than memorizing where a button sits. Interfaces may change across devices or versions, but addresses, networks, transaction hashes, contract addresses and approval targets remain verifiable. When something looks wrong, use those facts to distinguish a display issue from network congestion or a contract interaction problem.

Risk around addresses and networks often comes from incomplete information or confusing one object for another. Lookalike domains, same-name tokens, the wrong network or an unnecessarily broad approval can all produce a normal-looking screen while leading to an unintended action. Reduce that risk by checking critical fields one by one instead of relying on a single badge or visual cue.

From a learning perspective, addresses and networks is not isolated. It connects to account control, network selection, gas, confirmations, DApp permissions and block explorer data. Seeing those relationships makes it easier to understand the full lifecycle of an on-chain action from creation and signing to broadcast and confirmation.

How to verify information about Addresses and networks

Prioritize fields that can be independently checked for Addresses and networks. Compare the state before and after the action; if the result differs from what you expected, verify the network and transaction state before taking further action.

  • Confirm the network or counterparty relevant to Addresses and networks
  • Keep the transaction hash or contract address related to Addresses and networks
  • Never send a seed phrase, private key or verification code

Transaction history

Use the transaction hash, block height, status and actual network to interpret activity. A wallet showing “sent” does not always mean the transaction has already received enough on-chain confirmations.

Risk around transaction history often comes from incomplete information or confusing one object for another. Lookalike domains, same-name tokens, the wrong network or an unnecessarily broad approval can all produce a normal-looking screen while leading to an unintended action. Reduce that risk by checking critical fields one by one instead of relying on a single badge or visual cue.

From a learning perspective, transaction history is not isolated. It connects to account control, network selection, gas, confirmations, DApp permissions and block explorer data. Seeing those relationships makes it easier to understand the full lifecycle of an on-chain action from creation and signing to broadcast and confirmation.

When troubleshooting transaction history, keep verifiable details such as the transaction hash, destination address, selected network and contract address. Do not send a seed phrase or private key. On-chain transactions generally cannot be reversed by the wallet alone, so careful checks before submission are more reliable than hoping for recovery later.

How to verify information about Transaction history

Prioritize fields that can be independently checked for Transaction history. Compare the state before and after the action; if the result differs from what you expected, verify the network and transaction state before taking further action.

Security boundaries

In a self-custody wallet, control depends on the private key and seed phrase. No website, support agent or third-party DApp should ask you to send those secrets.

From a learning perspective, security boundaries is not isolated. It connects to account control, network selection, gas, confirmations, DApp permissions and block explorer data. Seeing those relationships makes it easier to understand the full lifecycle of an on-chain action from creation and signing to broadcast and confirmation.

When troubleshooting security boundaries, keep verifiable details such as the transaction hash, destination address, selected network and contract address. Do not send a seed phrase or private key. On-chain transactions generally cannot be reversed by the wallet alone, so careful checks before submission are more reliable than hoping for recovery later.

When working with security boundaries, separate what the interface displays from what the blockchain actually records. The wallet helps you review and initiate actions, while the final state depends on the target network, transaction data and block confirmations. Before any asset movement or permission change, confirm the counterparty, network and intended result before signing.

How to verify information about Security boundaries

Prioritize fields that can be independently checked for Security boundaries. Compare the state before and after the action; if the result differs from what you expected, verify the network and transaction state before taking further action.

  • Confirm the network or counterparty relevant to Security boundaries
  • Keep the transaction hash or contract address related to Security boundaries
  • Never send a seed phrase, private key or verification code