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 · Product Guide

imtoken

Browser wallet connections are not just about connecting. Review the domain, account request, signature details and approval scope.

01

What a browser connection means

A web connection generally lets a site request an account address and initiate later signatures or transactions. Connecting is not itself a transfer and is not an endorsement of the site’s safety; every later request still needs separate review. Reviewing what a browser connection means never requires giving anyone a seed phrase or private key; public state can be checked with addresses, transaction hashes and contract information.

02

Verify the domain first

Phishing sites often use lookalike domains, search ads or unsolicited links to prompt a wallet connection. Verify the domain before interacting with a Web3 page and do not lower your guard just because the interface looks familiar. Before moving on, make sure the fields related to verify the domain first match the intended task. If an important field cannot be explained, stop and verify the source.

03

Account exposure and privacy

After a site is connected, it can see the account addresses that were shared and may correlate them with public on-chain activity. If an account is not needed for the task, select an appropriate account before connecting to reduce unnecessary linkage. If the interface does not match expectations, record the network, address or transaction hash and troubleshoot account exposure and privacy one variable at a time.

04

Signatures and approvals differ

Message signatures, transaction signatures and token approvals have different consequences. When a request appears after connecting, identify its type first and then inspect the network, contract, amount, spender and visible fields. In practice, place “signatures and approvals differ” back into the context of the active account, network and intended target instead of judging the action from interface styling or button labels alone.

05

Disconnecting versus revoking

Disconnecting a web session ends the current connection but does not necessarily remove token approvals already recorded on-chain. After leaving a DApp, review both session state and blockchain permissions and revoke only what is no longer needed. This is rarely solved safely by clicking through again. A repeatable verification order for disconnecting versus revoking is more reliable than trial and error.

06

Good use cases for Web

The web interface is well suited to reading information, connecting to known DApps and reviewing transaction details on a larger screen. A web flow that asks for a seed phrase or private key should not be treated as a normal DApp interaction. Treating good use cases for web as its own decision point helps prevent rapid click-through mistakes across multiple accounts, networks or DApp steps.

Practical checklist

Use this list as a final review before you submit a transaction, signature or approval related to this topic.

  • Verify the domain from a trusted entry point
  • Select the correct account before connecting
  • Distinguish message signatures, transactions and approvals
  • Disconnect sessions that are no longer needed
  • Review on-chain approvals separately
Security boundary

Never share a seed phrase, private key or verification code. A wallet provider generally cannot reverse a confirmed on-chain transaction, and third-party DApps or smart contracts can carry independent risk.