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

Security

Build a layered security routine across seed phrases, private keys, devices, networks, transfers, signatures and approvals.

Verify the networkReview the requestKeep verifiable records
Check 1

Protect the credentials that control the account

The easiest way to understand Protect the credentials that control the account is to place it inside a real wallet workflow. A seed phrase can usually recreate wallet control on another device, so exposure can compromise the account. Keep it offline, do not send it to support, avoid long-term photo storage, and verify the word order and legibility after creating the backup.

A private key directly represents signing authority and should never be treated as a routine identity check. If a webpage, chat window, remote-support tool or supposed sync service asks for it, stop and independently verify the source. Before confirming, compare the active network, target and intended outcome together. If one of them does not match, stop and recheck rather than continuing out of habit.

A backup exists so account control can be restored after device loss or app-data failure. A useful backup should stay offline, readable, correctly ordered and stored in a controlled place while avoiding a single point of failure or unnecessary digital copies. Turning these checks into a routine helps reduce errors caused by the wrong network, copied addresses, oversized permissions or misunderstood transaction state.

Before you confirm

  • Verify the network, address or contract source relevant to protect the credentials that control the account.
  • Confirm that the request matches the intended action instead of relying on a familiar label.
  • Keep public identifiers such as transaction hashes for verification while keeping private credentials under your own control.
Check 2

Include devices and networks in the security boundary

With Include devices and networks in the security boundary, one common mistake is treating interface text as the final on-chain truth. Device security includes system updates, screen locks, application provenance, malware protection and physical access control. A wallet cannot replace device-level protection. If the device shows suspicious popups, unknown software or remote-control activity, stop sensitive actions first.

Public Wi-Fi and shared computers increase exposure to session theft, malicious software and account compromise. For wallet login, signing or backup work, prefer devices and networks you control and avoid leaving sensitive sessions on shared machines. Order matters: verify the source and network first, then the address or contract, and only then review amounts, fees, signatures or permissions.

Remote-control tools can expose the screen, keyboard, mouse and clipboard to another person. Do not continue wallet, backup or signing tasks under remote direction from an unknown party, and never reveal seed phrases, private keys or verification codes. Security is not a one-time setting; it is the repetition of the same checks before each transfer, signature and approval.

Make the checks repeatable

  • Verify the network, address or contract source relevant to include devices and networks in the security boundary.
  • Confirm that the request matches the intended action instead of relying on a familiar label.
  • Keep public identifiers such as transaction hashes for verification while keeping private credentials under your own control.
Check 3

Actively verify before sending or signing

For Actively verify before sending or signing, start with information that can be independently verified. Before sending, verify the destination address, network, asset, amount and gas. For higher-value transfers, a small test can reduce operational mistakes. If the page unexpectedly asks to switch networks, add an approval or sign something unrelated, cancel and review before continuing.

A signature proves that an account approved a message or transaction. Some message signatures do not transfer funds directly but can still authorize login or later actions. Before signing, review the recognizable domain, target, amount, permissions and any expiry. Higher-value or higher-permission actions deserve an extra independent check, such as a second device, trusted bookmark or small test transaction.

Clipboard malware can replace long addresses in ways that are hard to notice. After copying an address, compare the beginning, ending and key characters again. For important transfers, consider an address book, small test or second-device verification. Turning these checks into a routine helps reduce errors caused by the wrong network, copied addresses, oversized permissions or misunderstood transaction state.

Practical checks

  • Verify the network, address or contract source relevant to actively verify before sending or signing.
  • Confirm that the request matches the intended action instead of relying on a familiar label.
  • Keep public identifiers such as transaction hashes for verification while keeping private credentials under your own control.
Check 4

DApp approvals need ongoing management

You do not need every protocol detail to handle DApp approvals need ongoing management well, but you do need to know which facts determine the outcome. A token approval allows a contract to spend a token under defined conditions. Excessive allowance or approval to the wrong contract increases exposure. Verify the spender, token, amount and purpose, and periodically revoke permissions that are no longer needed.

Revoking an approval requires a new on-chain transaction that updates existing permissions, so network fees may apply. Verify the network, token and approved contract before revoking. Disconnecting a website session is not a substitute for an on-chain revocation. Before confirming, compare the active network, target and intended outcome together. If one of them does not match, stop and recheck rather than continuing out of habit.

Disconnecting a DApp ends the current session but usually does not revoke token approvals already recorded on-chain. After an interaction, close sessions you no longer need and separately review any approvals that remain active. Security is not a one-time setting; it is the repetition of the same checks before each transfer, signature and approval.

What is easy to miss

  • Verify the network, address or contract source relevant to dapp approvals need ongoing management.
  • Confirm that the request matches the intended action instead of relying on a familiar label.
  • Keep public identifiers such as transaction hashes for verification while keeping private credentials under your own control.

Security statement

Seed phrases and private keys remain under the user’s control. Official personnel will not ask for them or for verification codes; on-chain transactions generally cannot be reversed by a wallet alone; third-party DApps and smart contracts may carry risk.

imtoken

Ready to get started?

The download entry always goes through the dedicated download page. Keep verifying networks, addresses and request details before acting.

Download imtoken