Common questions
A digital wallet manages keys, addresses, and transaction requests associated with blockchain accounts. The assets themselves are recorded on the relevant blockchain network rather than stored inside the app.
A seed phrase can derive a set of wallet keys, while a private key directly controls a specific account. Both are highly sensitive and should never be sent to another person or entered into an untrusted website.
No. imtoken staff will never ask for your seed phrase, private key, or verification code. Requests using support, verification, airdrops, or account unlocking as a reason to collect them should be treated as high risk.
Tokens may exist on multiple blockchains or through bridging and wrapped-asset systems. Always make sure the sending network matches a network supported by the recipient.
Gas measures the computation and storage consumed by an on-chain action. Network fees are typically related to gas usage and the fee rate required by the network.
A transaction hash is a key identifier for locating an on-chain transaction. It can be used with the relevant block explorer to verify status, block inclusion, and confirmations.
No. A connection usually establishes account interaction. Signatures, transactions, and token approvals are separate requests and should be reviewed independently.
Not exactly. A message signature may be used for login or proof of account control, while a transaction signature usually authorizes an on-chain state change. Review both the source and the content.
Token Approval grants a smart contract permission to use a specified amount of a token. Review the target, scope, and purpose, and consider revoking approvals you no longer need.
Many EVM-compatible networks share similar account formats, but they are still different networks. A familiar-looking address does not remove the need to check the active network.
Layer 2 systems generally improve throughput and cost efficiency while relying on a mainnet settlement or security model. Cross-layer transfers can require specific bridge steps and waiting periods.
Check the transaction hash and on-chain status first, then confirm the receiving service supports the same network and determine how many confirmations it requires. Avoid sending the transaction again just because the interface is slow to update.
No. If a private key is exposed, anyone who has it may control the account. Evaluate the situation from a trusted environment and focus on protecting assets you can still control.
No. Reward rates can change, exits may take time, validators can face network penalties, and smart-contract and market risks remain.
A PoS validator stakes assets and participates in block proposal or attestation according to protocol rules. Its status, rewards, and penalties are determined by the network.
Public networks can increase exposure to traffic interception, phishing redirects, or compromised environments. Prefer a trusted device and connection for high-value actions.
Review the approval target, purpose, amount, and recent usage. If an approval is no longer needed or has an unknown origin, consider revoking it after understanding the effect.
At minimum, verify the address, network, amount, and fee, and confirm that the recipient explicitly supports that network. A small test transfer may be appropriate for a high-value transfer.
Checking networks before you act
A useful review of networks has three layers: source, content, and result. Confirm that the site, DApp, or service is the one you intentionally opened; read the amount, network, approval target, gas information, or signature summary; then verify the final state with the transaction hash, block explorer, or wallet history. If these layers do not agree, stop and investigate instead of repeating the action in the hope that it will fix itself.
How DApp fits into an on-chain flow
DApp is often an important clue when deciding whether an on-chain action behaved as expected. A typical transaction is prepared and signed by the wallet, broadcast to the selected network, validated by nodes, and eventually included in a block. A wallet status such as “sent” may only mean the request was submitted. Final completion should be judged against the on-chain transaction status and the number of confirmations required by the receiving service.
Common mistakes and Ethereum risk
A common mistake around Ethereum is assuming that anything shown inside a wallet is fully controlled by the wallet itself. Smart contracts, third-party DApps, network congestion, and token-issuer rules can all affect outcomes. A wallet can help construct requests and display information, but it cannot guarantee third-party contract behavior or unilaterally reverse a confirmed blockchain transaction. Understanding those boundaries is more useful than relying on one-click claims.
Build a repeatable review routine
Before each on-chain action, ask the same small set of questions: Which network am I using? Is the destination address or contract correct? Are the amount and gas reasonable? Is this signature sending a transaction, proving account control, or granting token permissions? Where will I verify the result? If a seed phrase or private key is involved in wallet recovery, has it remained private and offline rather than being sent to another person or website?
Related learning and security boundaries
To go deeper into FAQ, connect this topic with network selection, confirmations, DApp approvals, and wallet security. Third-party sites, contracts, and services introduce their own risks, and connecting a wallet does not mean every request should be accepted. imtoken staff will never ask for your seed phrase, private key, or verification code. Consider revoking approvals you no longer need, and rely on deliberate user confirmation plus verifiable on-chain results for asset transfers.