On this page
Wallets and backupNetworks and transactionsDApps, signatures and approvalsEthereum, PoS and validatorsWallets and backup
For wallets and backup, the goal is not to memorize labels but to build a repeatable decision sequence: confirm the current network and account context, understand what the requested action changes, and then verify the resulting state on-chain. Service information should explain the mechanism before discussing potential outcomes. For PoS, validators or staking, rewards come from network rules and validation activity. Results can vary with network conditions, validator performance, service fees, exit queues and market prices, so they should never be presented as fixed or guaranteed returns. Wallets and backup also connects to other wallet tasks. Network choice affects fees and transaction visibility, contract interaction can affect approvals and asset state, and security habits apply across creation, backup, transfers and Web3 use. This page focuses specifically on frequently asked questions so the guidance can be applied to a real task rather than treated as a generic feature list. The key is to verify network context, understand what the requested action changes, and keep sensitive credentials outside webpages and support conversations.
Networks and transactions
For networks and transactions, the goal is not to memorize labels but to build a repeatable decision sequence: confirm the current network and account context, understand what the requested action changes, and then verify the resulting state on-chain. Before participating, users should understand how their assets change state on-chain, what exit conditions apply, whether waiting periods may occur and what role any third-party service plays. Unverified claims about partnerships, licenses, rankings, user counts or guaranteed yields should not be used as decision criteria. When something looks wrong, break networks and transactions into four questions: what address or contract is involved, which network is active, what action is being requested, and what result should be visible on-chain. This is usually more reliable than repeating the same click. This page focuses specifically on frequently asked questions so the guidance can be applied to a real task rather than treated as a generic feature list. The key is to verify network context, understand what the requested action changes, and keep sensitive credentials outside webpages and support conversations.
A practical review sequence
- Confirm the active network and the intended account
- Verify the address, contract or DApp source
- Read the exact action, amount and permission scope
- Verify the public on-chain result after completion
DApps, signatures and approvals
For dapps, signatures and approvals, the goal is not to memorize labels but to build a repeatable decision sequence: confirm the current network and account context, understand what the requested action changes, and then verify the resulting state on-chain. Support and update content should follow a minimum-information principle. Troubleshooting normally requires only non-sensitive data such as the network name, public address, transaction hash, visible error message and approximate action time. Seed phrases, private keys and verification codes should never be provided to another person. For an unfamiliar dapps, signatures and approvals issue, keep verifiable non-sensitive evidence such as a public address, network name, transaction hash and visible error text. Sensitive credentials are not troubleshooting material and should not be given to support staff. This page focuses specifically on frequently asked questions so the guidance can be applied to a real task rather than treated as a generic feature list. The key is to verify network context, understand what the requested action changes, and keep sensitive credentials outside webpages and support conversations.
Ethereum, PoS and validators
For ethereum, pos and validators, the goal is not to memorize labels but to build a repeatable decision sequence: confirm the current network and account context, understand what the requested action changes, and then verify the resulting state on-chain. Service information should explain the mechanism before discussing potential outcomes. For PoS, validators or staking, rewards come from network rules and validation activity. Results can vary with network conditions, validator performance, service fees, exit queues and market prices, so they should never be presented as fixed or guaranteed returns. Ethereum, PoS and validators also connects to other wallet tasks. Network choice affects fees and transaction visibility, contract interaction can affect approvals and asset state, and security habits apply across creation, backup, transfers and Web3 use. This page focuses specifically on frequently asked questions so the guidance can be applied to a real task rather than treated as a generic feature list. The key is to verify network context, understand what the requested action changes, and keep sensitive credentials outside webpages and support conversations.
Final checklist
Complete FAQ
Will imtoken ask for my seed phrase?
No. Seed phrases and private keys should remain under the user’s control and should not be sent to websites, support agents or third parties.
Why can the same address show different balances on different networks?
Each network maintains its own ledger. Even when the address format is the same, balances and transaction histories belong to separate networks.
What should I verify before receiving assets?
Confirm the recipient address, asset and network, and make sure the sender is using the same intended destination network.
What is gas?
Gas is the fee mechanism used to execute transactions or contract operations. The calculation and amount vary by network.
What is a transaction hash for?
A transaction hash is a public identifier used to inspect whether a transaction was broadcast, included, confirmed or failed.
Does connecting a DApp approve my assets?
No. Connection, signing, token approval and sending a transaction are separate actions and should be reviewed independently.
Are message signatures safe?
A signature can carry authorization meaning. Its safety depends on the content and purpose. Do not approve a signature you do not understand.
What is a token approval?
A token approval lets a specified contract spend up to an allowed amount. Review the spender, allowance and continuing need for that permission.
Why do EVM addresses look the same across networks?
Many EVM networks use similar account derivation and address formats, but chain IDs, assets and contract state remain independent.
How do assets move between Layer 2 and the base layer?
They usually use a bridge or protocol-defined cross-layer process and may require additional confirmations or waiting time.
What should I do if a transaction stays pending?
Check the relevant block explorer first to confirm broadcast status, fee parameters and current state, then decide whether to wait or use a wallet-supported replacement method.
How can I reduce phishing risk?
Use trusted entry points, verify domains, avoid links from unsolicited messages and never disclose sensitive credentials.
Does losing a phone mean the assets are lost?
Not necessarily. The key questions are whether the private key or seed phrase was exposed and whether a reliable backup exists. Secure related accounts and devices promptly.
Does Ethereum staking guarantee returns?
No. Rewards can change with network conditions and rules, and service fees, exit delays, validator penalties and asset-price volatility may apply.
What does a PoS validator do?
A validator follows protocol rules to propose or attest to blocks and helps the network reach consensus while meeting availability and behavior requirements.
Can official staff restore my private key?
No. Private keys and seed phrases are controlled by the user; without them, official staff cannot restore access on the user’s behalf.
What should I do about a suspicious approval?
Stop further signing or transfers, inspect the spender and asset activity, and consider revoking permissions that are no longer needed.
What information is useful for troubleshooting?
Usually the network name, public address, transaction hash, error text and steps taken are enough. Seed phrases, private keys and verification codes are never required.