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

FAQ

Find concise answers to common questions about wallets, recovery, networks, gas, DApps, approvals, EVM, Layer 2, Ethereum, proof of stake and validators.

Help center

Common questions, explained with practical checks

The answers below focus on observable wallet and network behavior. They do not require recovery secrets, and they avoid promises that a wallet can reverse confirmed on-chain activity.

A digital wallet helps manage addresses, display on-chain assets, initiate transactions and interact with DApps. The authoritative state of an asset still comes from the relevant blockchain network.

A seed phrase can often restore wallet control. Keeping it in cloud storage, chat history or other connected systems can increase exposure, so an offline backup under the user’s control is generally safer.

No. Legitimate support should not request a private key, seed phrase or verification code. Public transaction hashes and network details are usually enough to examine on-chain state.

Verify the receiving address and make sure the sender will use the intended network. For tokens, a contract address is a stronger identifier than a name or icon alone.

Review the recipient, network, amount, estimated fee and final signing details. On-chain transactions generally cannot be reversed by the wallet alone.

Gas is a mechanism used by some blockchains to measure resources required for transactions or contract execution. Actual fees vary with network rules, complexity and demand.

A transaction hash identifies an on-chain transaction and can be used with a trusted block explorer to review sender, recipient, block, status and confirmations.

Network congestion, fee settings, propagation or chain conditions can delay processing. Check the transaction hash before assuming failure or sending the same transfer again.

No. Connection, message signing, transaction signing and token approval are separate requests and should be reviewed independently.

No. Review the domain, request type, readable content, contract identity and expected consequence. Stop if the request cannot be explained.

A token approval gives a specific spender contract authority over a token up to an allowance. Permissions can persist and may be revoked when they are no longer needed.

Do not assume so. EVM-compatible networks maintain separate state, fee assets and token contracts. Cross-network movement normally requires a supported bridging or transfer path.

Layer 2 systems extend a base chain but may use their own transaction processing and bridging rules. Moving assets between layers can involve specific routes and waiting periods.

Use saved trusted entry points, check domains carefully, ignore anyone asking for recovery secrets, and do not let fake airdrops, countdowns or urgent warnings bypass normal review.

No. Rewards can change, exits can involve waiting, validators may face protocol penalties, and smart-contract, third-party and market risks may apply.

Proof of stake is a family of consensus mechanisms in which validators participate according to protocol rules and may receive rewards or incur penalties.

Not necessarily. Exit and withdrawal can involve protocol queues and processing periods that vary with network conditions.

Stop further signatures or approvals, keep non-sensitive on-chain references, inspect transaction and permission state, and re-check the device, network and contract from a trusted entry point.

Need a structured troubleshooting path?

Use Support for self-service checks without sharing seed phrases or private keys.

Open Support