imtoken
Approval Security
Manage DApp permissions by reviewing the spender, allowance, contract source and revocation path.
Identify the approved spender first
For Identify the approved spender first, start with information that can be independently verified. 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.
An address identifies an on-chain account or contract. Before sending assets, verify both the destination network and the address, including the beginning, ending and trusted source. Recheck anything copied from chat or the clipboard in case it was altered. Order matters: verify the source and network first, then the address or contract, and only then review amounts, fees, signatures or permissions.
A smart contract executes rules deployed on-chain. Wallets may show a readable summary, but complex interactions can include nested calls. For unfamiliar contracts, high allowances or requests you cannot understand, stop and verify through an independent source. Even when the wallet interface shows a result, important actions are easier to verify later when you keep the relevant public identifiers.
Practical checks
- Verify the network, address or contract source relevant to identify the approved spender first.
- 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.
Avoid unnecessarily broad permissions
You do not need every protocol detail to handle Avoid unnecessarily broad permissions well, but you do need to know which facts determine the outcome. Permission scope determines what a third party can do and how much value is exposed. Distinguishing account visibility, message signing, transaction submission and token approval helps users avoid treating a low-impact connection like a high-impact authorization and makes suspicious requests easier to spot.
Token names and icons can be copied, so the contract address is a stronger identity check. When adding a custom token or handling an unfamiliar asset, verify the contract, network and token details from a trusted source rather than relying on a similar name. Higher-value or higher-permission actions deserve an extra independent check, such as a second device, trusted bookmark or small test transaction.
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. If the purpose or target of a request cannot be understood, the safer next step is to stop rather than add permissions or repeatedly resubmit.
What is easy to miss
- Verify the network, address or contract source relevant to avoid unnecessarily broad permissions.
- 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.
Disconnecting does not revoke on-chain approvals
In practice, Disconnecting does not revoke on-chain approvals connects to several steps before and after the action itself. 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.
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.
Transaction history should distinguish submitted, included in a block and further-confirmed states. A delayed interface update does not necessarily mean failure; the transaction hash and execution result on the correct network are the primary verification points. Even when the wallet interface shows a result, important actions are easier to verify later when you keep the relevant public identifiers.
Before you confirm
- Verify the network, address or contract source relevant to disconnecting does not revoke on-chain approvals.
- 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.
Review old approvals and unfamiliar contracts
Breaking Review old approvals and unfamiliar contracts into smaller decisions is more reliable than accepting a single page-level conclusion. 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.
A block explorer lets users inspect addresses, transaction hashes, blocks and contract data. First make sure it matches the intended network, and be careful with ads, lookalike sites and unverified labels. Explorer data helps verify chain state but does not replace key security. Order matters: verify the source and network first, then the address or contract, and only then review amounts, fees, signatures or permissions.
Malicious contracts or front ends can disguise approvals and signatures as claims, airdrops or account verification. Risk assessment should focus on the actual contract, permission scope and transaction effect rather than the marketing label shown on the page. If the purpose or target of a request cannot be understood, the safer next step is to stop rather than add permissions or repeatedly resubmit.
Make the checks repeatable
- Verify the network, address or contract source relevant to review old approvals and unfamiliar contracts.
- 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.