A wallet mainly manages keys and helps you read or submit on-chain actions; the asset state itself is recorded by the relevant blockchain network. This distinction helps separate what the interface happens to display from what the chain actually records. If an asset is temporarily missing from the interface, verify the network, token contract, and public transaction record before assuming the asset is gone.
FAQ
Frequently Asked Questions
Answers about wallets, seed phrases, networks, gas, transactions, DApps, approvals, EVM, Layer 2, security, Ethereum staking, PoS and validators.
Never provide a seed phrase, private key or verification code to solve a support issue. Public transaction data is enough for most on-chain checks.
16 essential questions
Wallet, network, Web3 and staking questions
Answers are expanded by default so the content remains readable without JavaScript. Use the question buttons to collapse or reopen individual answers.
No. Keep seed phrases and private keys under your own control. Official staff should never request them, and they are not required to inspect a public transaction. A legitimate troubleshooting process can usually work with a transaction hash, public address, and network name. Stop if anyone asks you to copy, upload, screenshot, or read out your recovery credentials.
Both relate to account control. Some wallet designs use a seed phrase to derive multiple private keys, so each should be protected at the highest sensitivity level. Keep seed phrases offline rather than in ordinary chats, email, cloud photo storage, or unfamiliar web forms. A private key should likewise never be provided as a form of identity verification.
The same asset name can appear on different networks, and addresses can look similar across compatible systems. Before sending, confirm the sending network, the network supported by the recipient, the destination address, and the asset type together. A transaction can succeed on-chain yet still fail to appear where you expected if the receiving service does not support that network path.
Gas measures network resources consumed by an on-chain operation. The actual fee depends on network rules, current demand, and transaction complexity. When preparing a transaction, check not only the quoted fee but also which asset pays gas on the active network. If the fee looks unexpectedly large, re-check the network, contract method, and request origin before proceeding.
A transaction hash is a key identifier for looking up an on-chain transaction. A block explorer can use it to show whether the transaction was broadcast, included in a block, confirmed, or failed, along with the public addresses involved. When a wallet interface is delayed, the hash is usually more useful for troubleshooting than a screenshot and does not expose your seed phrase or private key.
Connection usually establishes account visibility or a session; it does not mean every later request should be approved. Actions that change on-chain state generally still require a signature, transaction confirmation, or token approval. Treat each request independently and review the contract target, permission scope, amount, and network rather than clicking through because the wallet is already connected.
Not exactly. A message signature can be used to prove account control or sign in, while some structured messages can also carry authorization meaning. A transaction signature generally authorizes an on-chain state change. In both cases, verify the domain, readable intent, and expected outcome. Reject blind-signing requests you cannot understand and return to the source to investigate.
Review the approval target, contract address, allowance amount, and purpose. Pay particular attention to unlimited allowances or permissions that remain active for a long time. An approval is not just a login step; it can give a contract permission to use tokens under specified conditions. Periodically review permissions and revoke those you no longer need.
EVM-compatible networks often use similar account, contract, and gas models, so addresses and interaction patterns can look familiar. Chain IDs, gas assets, bridge paths, explorers, and security assumptions can still differ. When adding or switching networks, verify network parameters from a reliable source rather than relying only on the displayed network name.
Layer 2 systems use different data-publication, proof, and exit designs, so cross-layer settlement can behave differently from an ordinary base-layer transfer. Before using a bridge, identify the source layer, destination layer, form of the received asset, required confirmations, and any waiting period on the exit path. Those details are part of the transfer, not an afterthought.
Verify the domain source and avoid entering sensitive workflows from unsolicited messages. Do not let phrases such as “support,” “airdrop,” or “urgent upgrade” replace normal checks. Review the active domain, network, signature text, and approval target. Any request for a seed phrase, private key, or verification code is a strong reason to stop the interaction.
No. Staking rewards can change with network rules, validator performance, and overall conditions, while exits may involve waiting. Validators can also face network penalties. Digital asset prices fluctuate, and third-party services or smart contracts introduce separate risks. Staking should not be treated as a fixed-yield, principal-protected, or risk-free product.
Validators participate in consensus tasks such as proposing or attesting to blocks and are responsible for following network rules. A validator is not simply an interest-bearing account: validator state, effective balance, network participation, rewards, and penalties can all affect outcomes. Understanding those mechanics makes it easier to evaluate staking information without relying on promotional claims.
Once confirmed, an on-chain transaction generally cannot be unilaterally reversed by the wallet. Some unconfirmed transactions may support network-specific replacement or acceleration techniques, but that is not a guaranteed cancellation mechanism. The most reliable control happens before signing: verify the address, network, amount, gas, contract, and transaction summary first.
Stop signing, approving, or sending until you understand what happened. Keep the transaction hash, public address, network name, and the request details you can safely record, then review the network, destination, contract, permissions, and device environment step by step. If you believe key material has been exposed, prioritize protecting remaining assets and rebuilding control in a safer environment.
imtoken
Check first, then act
Review the address, network, amount, signature and approval scope before important actions.
