imtoken
imtoken Web
Understand the difference between browser connection, account visibility, signing, approvals and disconnecting a session.
What happens during a browser connection
For What happens during a browser connection, start with information that can be independently verified. Web connections usually create a session between the browser and the wallet. A site receives the account information the user allows and can then request signatures or transactions. Connecting does not hand over the private key, and it does not make every later request trustworthy.
A DApp connection usually begins by requesting an account address or session, then may ask for signatures, transactions or approvals. Connecting is not the same as revealing a private key, but users should still verify the domain, session and network and disconnect when finished. Order matters: verify the source and network first, then the address or contract, and only then review amounts, fees, signatures or permissions.
A wallet account is anchored by an on-chain address, signing authority and locally controlled key material. The app helps present state, but control ultimately depends on the keys and the ability to sign. Before changing devices, verify the backup rather than relying on local app data alone. 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 what happens during a browser connection.
- 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.
Confirm the active network and intended outcome first. The interface is the entry point; on-chain state is the final record you can verify.
Connection is not signing or approval
You do not need every protocol detail to handle Connection is not signing or approval 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.
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.
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. 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 connection is not signing or approval.
- 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.
Confirm the active network and intended outcome first. The interface is the entry point; on-chain state is the final record you can verify.
Networks and contracts still need verification
In practice, Networks and contracts still need verification connects to several steps before and after the action itself. The same-looking address format can exist on different networks, while balances, gas assets, contracts and transaction histories remain separate. Choose the network based on where the asset actually exists and what the recipient supports, not just the token name shown in the interface.
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. 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.
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. 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 networks and contracts still need verification.
- 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.
Confirm the active network and intended outcome first. The interface is the entry point; on-chain state is the final record you can verify.
What to clean up after a session
Breaking What to clean up after a session into smaller decisions is more reliable than accepting a single page-level conclusion. 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. Order matters: verify the source and network first, then the address or contract, and only then review amounts, fees, signatures or permissions.
Phishing pages often rely on lookalike domains, search ads, direct messages or fake promotions. Use a trusted entry point and verify the domain. A familiar logo, polished design or urgent warning does not make a site legitimate. 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 what to clean up after a session.
- 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.
Confirm the active network and intended outcome first. The interface is the entry point; on-chain state is the final record you can verify.
imtoken
Ready to get started?
The download entry always goes through the dedicated download page. Keep verifying networks, addresses and request details before acting.