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

imtoken

After connecting a DApp, a wallet may receive login, message-signing, transaction or approval requests. Review every request independently.

Connection is only the beginning

A wallet connection usually establishes a session between an account and a DApp, but later requests can include message signatures, transaction signatures, token approvals or network switches. Each has different permissions and consequences. Before moving on, make sure the fields related to connection is only the beginning match the intended task. If an important field cannot be explained, stop and verify the source.

The domain is the first check

A DApp’s interface can be copied onto a lookalike domain. Verify the site source first and avoid starting a wallet connection from unsolicited messages, search ads or time-pressured claim pages. If the interface does not match expectations, record the network, address or transaction hash and troubleshoot the domain is the first check one variable at a time.

A signature may not transfer funds

A message signature can be used for login or proof of account control without creating an immediate blockchain transaction. Malicious signatures can still have harmful consequences, so “no gas required” should never be equated with “no risk.” In practice, place “a signature may not transfer funds” back into the context of the active account, network and intended target instead of judging the action from interface styling or button labels alone.

Approvals can persist on-chain

A token approval allows a specified contract to use assets within a defined scope, and the permission can remain after the DApp session ends. Check the spender, allowance, network and whether the permission is actually necessary. This is rarely solved safely by clicking through again. A repeatable verification order for approvals can persist on-chain is more reliable than trial and error.

Understand the purpose of contract calls

Complex DApps can request several transactions. For each one, identify whether it is a deposit, swap, approval, mint or another function call and check for value transfer or additional permissions. Treating understand the purpose of contract calls as its own decision point helps prevent rapid click-through mistakes across multiple accounts, networks or DApp steps.

Clean up after use

After completing a task, disconnect sessions that are no longer needed and review historical approvals separately. Disconnecting a session does not automatically remove on-chain permissions, so the two should be managed independently. The practical goal of clean up after use is to separate on-chain facts from interface presentation; if the two disagree, verify public blockchain state first.

Practical checklist

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

  • Verify the DApp domain before connecting
  • Identify whether a request is a connection, signature, transaction or approval
  • Check spender and allowance for approvals
  • Review the purpose of each contract step
  • Manage sessions and approvals separately after use
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.