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

imtoken Web

This guide connects the practical decisions behind browser connections, account connections, and DApp access. It focuses on verifiable on-chain information, clear user actions, and security habits that remain useful even when interfaces change.

Download imtokenSecurity guide →
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 browser connections with account connections
  3. Checking DApp access and signature review 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

imtoken Web 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 imtoken Web, read this specifically alongside “How the wallet experience is organized” and browser connections. Do not treat an interface success message as the final answer for imtoken Web. Use browser connections, account connections and DApp access to confirm that the expected change occurred on the intended network.

Using browser connections with account connections

browser connections and account connections 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 imtoken Web, read this specifically alongside “Using browser connections with account connections” and account connections. EVM addresses may look the same across several networks, but that visual similarity does not mean assets move between those networks automatically; in imtoken Web, read this specifically alongside “Using browser connections with account connections” and account connections. If “Using browser connections with account connections” is unclear, stop before approving and return to the basics of account connections and DApp access, then verify the result with a transaction hash, contract address or block record where applicable.

Checking DApp access and signature review against the chain

DApp access and signature review 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 imtoken Web, read this specifically alongside “Checking DApp access and signature review against the chain” and DApp access. 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 imtoken Web, read this specifically alongside “Checking DApp access and signature review against the chain” and DApp access. A durable routine for imtoken Web is to make DApp access a first-pass check, use signature review as a second check, and rely on verifiable information related to approval checks rather than interface assumptions.

Web3 connections and permission boundaries

For Web3 activity, a wallet connection only establishes an interaction channel; in imtoken Web, read this specifically alongside “Web3 connections and permission boundaries” and signature review. Each signature, token approval, and contract transaction has its own effect and should be reviewed separately; in imtoken Web, read this specifically alongside “Web3 connections and permission boundaries” and signature review. Activities involving approval checks deserve particular attention to the requester, approval scope, and contract address. This part of imtoken Web should be read together with the surrounding workflow: signature review affects how you interpret approval checks, while disconnecting sessions helps confirm the state after the action.

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 imtoken Web, read this specifically alongside “A practical everyday workflow” and approval checks. When a session is no longer needed, disconnect and consider revoking permissions that should not remain active; in imtoken Web, read this specifically alongside “A practical everyday workflow” and approval checks. For imtoken Web, connect approval checks with disconnecting sessions and browser connections; the important part is the relationship between those concepts and the on-chain evidence you can verify afterward.

Security and product boundaries

imtoken Web 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 imtoken Web, read this specifically alongside “Security and product boundaries” and disconnecting sessions. For disconnecting sessions and other sensitive activity, use a trusted device and avoid public or remotely controlled environments. When working through “Security and product boundaries,” check the source, network, request details and resulting state in that order, with extra attention to disconnecting sessions and browser connections.

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.