Support
Start with the category that matches the problem. imtoken support guidance never requires a seed phrase, private key, or verification code, and you should not send those secrets to anyone claiming to help.
Identify the type of issue first
Keep public diagnostic information, not secrets
For a transaction-status question, note the network, public address, transaction hash, and explorer status. For an asset-display issue, note the network and token contract address. For a DApp issue, record the DApp domain, active network, and request type. These public details normally provide useful context without revealing a seed phrase or private key.
Do not provide recovery secrets for “verification”
Legitimate help material does not need your seed phrase or private key. Verification codes, recovery phrases, private keys, and wallet-unlock secrets should not be shared through chat, email, forms, or remote-control tools. Stop the interaction if someone claims those secrets are required to synchronize an account, remove a restriction, or recover assets.
If you suspect phishing or an unusual approval
Stop creating new signatures and transactions, verify the domain and active network, and review DApp sessions and on-chain approvals from a trusted environment. Use public transaction hashes to verify actions that have already occurred. Avoid responding to uncertainty by signing additional requests you do not understand.
Useful help paths
A troubleshooting sequence that does not expose recovery secrets
Start by confirming the active network and public address. Next decide whether the problem is a wallet display issue, an on-chain transaction issue, or a third-party DApp issue. Keep public references such as a transaction hash, contract address, and visible error state, then repeat the check from a trusted entry point. If an asset is not displayed, verify its network and contract before considering any recovery action. If a transfer appears missing, inspect its on-chain status before sending again.
For permission issues, review the connection session separately from on-chain allowances or operator permissions because disconnecting a webpage does not necessarily revoke a blockchain approval. For device-related problems, make sure the operating system, browser, and wallet environment are trustworthy before continuing. None of these troubleshooting steps require you to give a seed phrase or private key to a third party.
The goal of troubleshooting is to identify verifiable facts without creating unnecessary new on-chain actions. Keeping the network, public address, transaction hash, and visible status for each step makes it easier to tell whether an issue is local display, network confirmation, contract execution, or a third-party service problem, and reduces the chance of paying additional fees by repeating the same action.
When in doubt, prefer one careful verification step over repeated retries. Repeated transactions or approvals can create additional fees and permissions without resolving the original issue.