Understand the mechanism before rewards

A content-first feed of product notes, network reminders, security notices and service updates. In real use, product update, network notice and security notice often intersect. A wallet screen is only one layer of information, so start by identifying the account, the active network and the task you intend to complete. Then verify the result against on-chain data instead of treating one button or balance as proof that everything is correct.

It helps to separate interface display from blockchain state. Information related to network notice can depend on the selected network, node data, a block explorer or a token contract, while security notice may need a transaction hash and confirmation status. If something looks wrong, inspect the network and address first, then the contract or transaction, rather than repeatedly retrying the same action.

How network state can change outcomes

It helps to separate interface display from blockchain state. Information related to network notice can depend on the selected network, node data, a block explorer or a token contract, while security notice may need a transaction hash and confirmation status. If something looks wrong, inspect the network and address first, then the contract or transaction, rather than repeatedly retrying the same action.

Before an action involving service update, break the decision into smaller questions: who is the target, which network is involved, what permission is being requested, what fee can be incurred and whether the outcome is reversible. For verification, read the confirmation details carefully. If you cannot explain the target or consequence, exit the flow and verify the source before continuing.

  • Review network notice and security notice before submitting.
  • Keep verifiable references such as a transaction hash, contract address or network name.
  • Stop if a request is unclear and verify the source and permission scope again.
  • Confirm how the active network relates to product update.

Exits, waiting periods and technical risk

Before an action involving service update, break the decision into smaller questions: who is the target, which network is involved, what permission is being requested, what fee can be incurred and whether the outcome is reversible. For verification, read the confirmation details carefully. If you cannot explain the target or consequence, exit the flow and verify the source before continuing.

A reliable routine is “check before, record after, verify when uncertain.” Before submitting, confirm the address, network and amount. After submitting, keep the transaction hash. During a delay, use an appropriate block explorer to check confirmations. This gives you verifiable evidence when a balance is slow to refresh or a third-party page behaves unexpectedly.

Evaluate third-party services separately

A reliable routine is “check before, record after, verify when uncertain.” Before submitting, confirm the address, network and amount. After submitting, keep the transaction hash. During a delay, use an appropriate block explorer to check confirmations. This gives you verifiable evidence when a balance is slow to refresh or a third-party page behaves unexpectedly.

Security is not a separate final step; it should run through the entire Product & Security Updates workflow. Keep seed phrases and private keys under your own control, and never send them in chat or to someone claiming to be support. Treat every DApp connection, signature and approval as a separate decision, and periodically review permissions you no longer need.

  • Review network notice and security notice before submitting.
  • Keep verifiable references such as a transaction hash, contract address or network name.
  • Stop if a request is unclear and verify the source and permission scope again.
  • Confirm how the active network relates to product update.

Checks to complete before participating

Security is not a separate final step; it should run through the entire Product & Security Updates workflow. Keep seed phrases and private keys under your own control, and never send them in chat or to someone claiming to be support. Treat every DApp connection, signature and approval as a separate decision, and periodically review permissions you no longer need.

A content-first feed of product notes, network reminders, security notices and service updates. In real use, product update, network notice and security notice often intersect. A wallet screen is only one layer of information, so start by identifying the account, the active network and the task you intend to complete. Then verify the result against on-chain data instead of treating one button or balance as proof that everything is correct.

Updates and notices

Recent Update

Product note: clearer network and asset paths

Network selection, asset display and transaction-history guidance has been reorganized around verifiable information.

Security Notice

Review signatures and approvals separately

A DApp connection is not blanket consent. Review each signature, approval and transaction independently.

Network Notice

Verify the destination network before moving assets

Similar address formats do not make networks interchangeable. Confirm source, destination and bridge path.

Service Notice

Ethereum and PoS guidance refreshed

The knowledge pages now emphasize exit queues, validator status, penalties and third-party service risk without fixed-return claims.

Security reminder

imtoken staff will never ask for your seed phrase or private key. Do not send seed phrases, private keys or verification codes to anyone. Before transferring, signing or approving, verify the address, network, target and scope. Third-party DApps and smart contracts may introduce independent risks.