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.
Security

Approval Security & Malicious Contracts

This guide connects the practical decisions behind approval spenders, permission scope, and malicious contracts. It focuses on verifiable on-chain information, clear user actions, and security habits that remain useful even when interfaces change.

Before you act

Confirm the network, address, request details and expected on-chain result.

On this page
  1. Build a repeatable security routine
  2. Recognize risks around approval spenders
  3. Review permission scope and malicious contracts before acting
  4. What to do when something looks wrong
  5. A practical security checklist
  6. The boundaries that should not change

Build a repeatable security routine

Approval Security & Malicious Contracts is best approached as a sequence of checks rather than a promise that any wallet can remove all risk. Identify who is asking you to act, what permission is being requested, which network or contract is involved, and what will change if you approve. imtoken staff will not ask for a seed phrase, private key, or verification code. Those credentials remain under the user’s control and should never be uploaded, pasted into chat, or shown through remote-access software.

Recognize risks around approval spenders

Problems involving approval spenders often begin with a misleading page, an urgent message, or a request that does not match the task you intended to perform. Re-check the domain, the connected account, and the reason for the request. Promises of rewards, account “verification,” urgent upgrades, or support assistance should never be used as a reason to skip basic checks.

Quick check
  • Is this the network you intended to use?
  • Can you verify the address or contract independently?
  • Do you understand what will change after approval?

Review permission scope and malicious contracts before acting

When reviewing permission scope and malicious contracts, separate the object, the scope, and the consequence. The object may be an address, contract, device, or account; the scope may be a single transaction or a continuing approval; the consequence is what can happen after confirmation. If the interface does not give enough context, stop and verify the address, transaction, or contract through the correct blockchain explorer.

What to do when something looks wrong

If activity appears suspicious, avoid repeated clicks in the same session. Disconnect unnecessary DApps, review recent transactions and token approvals, and move to a trusted device if the current environment may be compromised. Blockchain transactions are generally not something a wallet provider can unilaterally reverse, so the useful goal is to limit further exposure rather than trust anyone promising a guaranteed recovery.

A practical security checklist

A consistent routine can cover unlimited allowances, revoking approvals, and most other Web3 interactions: use a trusted device, confirm the site, verify the network and destination, read each signature or approval, check the amount and fee, then review the transaction hash afterwards. Remove permissions that are no longer needed and keep recovery credentials offline.

The boundaries that should not change

The durable rules are simple: never share a seed phrase or private key, treat third-party DApps and smart contracts as independent risk sources, verify the address/network/amount before a transfer, and review approval scope before granting access. imtoken provides wallet tools and educational material; it does not guarantee the security of third-party contracts, network availability, or asset prices.

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.