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.
Home / FAQ
imtoken

FAQ

imtoken FAQ: clear product guidance, practical steps and risk-aware explanations covering wallets, networks, Web3, security, validators.

Wallets and networks

FAQ makes more sense when wallets, networks, Web3, security, validators are considered as parts of one on-chain workflow. The same address format can appear across different network contexts, so appearance alone is not enough to confirm the correct destination.

No. Official personnel will not ask for a seed phrase, private key or verification code. Recovery secrets remain under the user’s custody.

Make an offline backup and verify that it is readable, in the correct order and not exposed to other people or online storage.

Similar address formats do not mean the asset state is shared. Confirm that sender and recipient are using the intended network.

Gas represents the network cost of executing a transaction or smart-contract action. The cost can vary with network conditions and transaction complexity.

It is a reference used on the relevant block explorer to locate a transaction and verify inclusion, confirmations and execution status.

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

Verify the domain, account, request type and full message. Reject requests whose purpose or origin you cannot explain.

Confirm the spender, token, allowance and intended use. Consider revoking approvals that are no longer needed.

No. EVM compatibility does not mean shared state. Each network has independent balances, transactions and contract deployments.

A Layer 2 processes activity with a specific scaling design and maintains a defined data or security relationship with mainnet. Cross-layer transfers can use dedicated processes and waiting periods.

Check the network, contract address, token ID, recipient and any additional approval or contract call involved.

Use caution. Prefer trusted devices and networks for sensitive actions, and never handle recovery secrets on public or remotely controlled computers.

Generally not unilaterally. Re-check the address, network, asset, amount and fee details before broadcasting.

No. Rewards can change and are not guaranteed. Validator, network, contract, waiting-time and asset-price risks also apply.

Yes. Validator behavior and availability can affect rewards and, in some conditions, may result in protocol penalties.

Stop connecting, signing or transferring. Re-open the service through a trusted path, verify the domain and review recent approvals and transactions. Never share recovery secrets with supposed support staff.

Security principles

For security, retain the transaction hash or other useful reference when appropriate. On-chain transactions generally cannot be reversed unilaterally by a wallet, which makes pre-broadcast checks of the address, network, amount and permissions especially important.

Web3 and approvals

For networks, prefer information that can be independently checked: the wallet transaction summary, the relevant network explorer, an explicit contract address or an official product page. A wallet interface is only the entry point; the important checks concern the network, address, contract and on-chain state.

Ethereum and validators

Finally, consider validators. Third-party DApps, smart contracts and network services can introduce technical, operational and market risk. Unclear signatures, unnecessarily broad approvals, or any page asking for a seed phrase or private key are reasons to stop and re-check the request.