imtoken
Support
Use publicly verifiable information to troubleshoot wallet, network, transaction and DApp issues while making clear that support never needs seed phrases, private keys or verification codes.
Use publicly verifiable information to troubleshoot wallet, network, transaction and DApp issues while making clear that support never needs seed phrases, private keys or verification codes.
Prepare public information before asking for help
Breaking Prepare public information before asking for help into smaller decisions is more reliable than accepting a single page-level conclusion. Support should help users verify public information, workflows and security principles rather than request sensitive credentials. Transaction troubleshooting can usually use the network name, transaction hash and public address; it does not require a seed phrase or private key.
A transaction hash is one of the main identifiers for locating an on-chain transaction. Use it with the correct network explorer to check broadcast status, block inclusion, execution result and fees. When a transfer is delayed, verify the hash before deciding whether to try again. The same button label can produce very different results on a different network, contract or permission context, which is why labels alone are not enough.
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. 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 prepare public information before asking for help.
- 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.
Use the transaction hash first for transfer issues
The easiest way to understand Use the transaction hash first for transfer issues is to place it inside a real wallet workflow. A transaction hash is one of the main identifiers for locating an on-chain transaction. Use it with the correct network explorer to check broadcast status, block inclusion, execution result and fees. When a transfer is delayed, verify the hash before deciding whether to try again.
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. These questions are best resolved through public on-chain records, trusted sources and the wallet’s local information rather than explanations from an unknown person.
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.
Practical checks
- Verify the network, address or contract source relevant to use the transaction hash first for transfer issues.
- 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.
Support never needs recovery credentials
With Support never needs recovery credentials, one common mistake is treating interface text as the final on-chain truth. Fake support commonly arrives through unsolicited messages, remote-control requests, recovery-phrase demands or instructions to install unknown software. A legitimate security process does not require sending seed phrases, private keys or verification codes to anyone. Verify contact through an independent official entry point.
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. When the page does not match what you expected, canceling is usually safer than pushing through. Then verify the transaction hash, contract address or explorer record independently.
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. 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 support never needs recovery credentials.
- 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.
Independently verify suspicious contact
For Independently verify suspicious contact, start with information that can be independently verified. 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.
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. The same button label can produce very different results on a different network, contract or permission context, which is why labels alone are not enough.
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. 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 independently verify suspicious contact.
- 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.
imtoken
Ready to get started?
The download entry always goes through the dedicated download page. Keep verifying networks, addresses and request details before acting.