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 / Staking & Services / Frequently Asked Questions

Frequently Asked Questions

Answers to common questions about wallets, networks, gas, transaction hashes, DApps, approvals, EVM, Layer 2, Ethereum and validators.

On this pageMechanics rather than return claimsValidator states and network conditionsWaiting, exits and penalty riskThird-party and smart-contract riskIndependent judgment before participation

Staking and validator topics should be understood through protocol mechanics and risk. Rewards can change, exits can take time, validators can face penalties, and contracts or third-party services can introduce technical risk.

Mechanics rather than return claims

Staking and validator topics should be understood through protocol mechanics and risk. Rewards can change, exits can take time, validators can face penalties, and contracts or third-party services can introduce technical risk. In this section, mechanics rather than return claims is treated as part of a complete workflow. The key habit is to verify the network, request scope and expected outcome with independent evidence before committing an irreversible action. The practical question is what information is visible before an action, what can change on-chain, and what independent evidence can be checked afterward.

A reliable review separates interface labels from protocol facts. Confirm the active network, account, asset or contract involved, then compare the request with the outcome you actually expect. This page focuses on Frequently Asked Questions as a practical decision-making topic rather than a set of interface clicks. This approach is especially useful when different networks use similar address formats or when a DApp asks for permissions that remain active beyond one session.

Do not use urgency as a substitute for understanding. If a signature, approval, bridge, validator action or transfer cannot be explained in plain language, stop and verify the destination, network and permission scope before continuing. On-chain transactions are often not reversible by a wallet provider, so the strongest control is review before confirmation rather than recovery afterward.

Validator states and network conditions

Staking and validator topics should be understood through protocol mechanics and risk. Rewards can change, exits can take time, validators can face penalties, and contracts or third-party services can introduce technical risk. In this section, validator states and network conditions is treated as part of a complete workflow. This page focuses on Frequently Asked Questions as a practical decision-making topic rather than a set of interface clicks. The practical question is what information is visible before an action, what can change on-chain, and what independent evidence can be checked afterward.

A reliable review separates interface labels from protocol facts. Confirm the active network, account, asset or contract involved, then compare the request with the outcome you actually expect. The key habit is to verify the network, request scope and expected outcome with independent evidence before committing an irreversible action. This approach is especially useful when different networks use similar address formats or when a DApp asks for permissions that remain active beyond one session.

Do not use urgency as a substitute for understanding. If a signature, approval, bridge, validator action or transfer cannot be explained in plain language, stop and verify the destination, network and permission scope before continuing. On-chain transactions are often not reversible by a wallet provider, so the strongest control is review before confirmation rather than recovery afterward.

Practical checks

  • Verify the active network and destination before confirming.
  • Treat every signature or approval as a separate decision.
  • Use transaction hashes and explorers to check on-chain state when relevant.
  • Keep seed phrases, private keys and verification codes private.

Waiting, exits and penalty risk

Staking and validator topics should be understood through protocol mechanics and risk. Rewards can change, exits can take time, validators can face penalties, and contracts or third-party services can introduce technical risk. In this section, waiting, exits and penalty risk is treated as part of a complete workflow. The key habit is to verify the network, request scope and expected outcome with independent evidence before committing an irreversible action. The practical question is what information is visible before an action, what can change on-chain, and what independent evidence can be checked afterward.

A reliable review separates interface labels from protocol facts. Confirm the active network, account, asset or contract involved, then compare the request with the outcome you actually expect. This page focuses on Frequently Asked Questions as a practical decision-making topic rather than a set of interface clicks. This approach is especially useful when different networks use similar address formats or when a DApp asks for permissions that remain active beyond one session.

Do not use urgency as a substitute for understanding. If a signature, approval, bridge, validator action or transfer cannot be explained in plain language, stop and verify the destination, network and permission scope before continuing. On-chain transactions are often not reversible by a wallet provider, so the strongest control is review before confirmation rather than recovery afterward.

Security note

imtoken staff will never ask for your seed phrase or private key. Do not send seed phrases, private keys or verification codes to anyone.

Third-party and smart-contract risk

Staking and validator topics should be understood through protocol mechanics and risk. Rewards can change, exits can take time, validators can face penalties, and contracts or third-party services can introduce technical risk. In this section, third-party and smart-contract risk is treated as part of a complete workflow. This page focuses on Frequently Asked Questions as a practical decision-making topic rather than a set of interface clicks. The practical question is what information is visible before an action, what can change on-chain, and what independent evidence can be checked afterward.

A reliable review separates interface labels from protocol facts. Confirm the active network, account, asset or contract involved, then compare the request with the outcome you actually expect. The key habit is to verify the network, request scope and expected outcome with independent evidence before committing an irreversible action. This approach is especially useful when different networks use similar address formats or when a DApp asks for permissions that remain active beyond one session.

Do not use urgency as a substitute for understanding. If a signature, approval, bridge, validator action or transfer cannot be explained in plain language, stop and verify the destination, network and permission scope before continuing. On-chain transactions are often not reversible by a wallet provider, so the strongest control is review before confirmation rather than recovery afterward.

Practical checks

  • Verify the active network and destination before confirming.
  • Treat every signature or approval as a separate decision.
  • Use transaction hashes and explorers to check on-chain state when relevant.
  • Keep seed phrases, private keys and verification codes private.

Independent judgment before participation

Staking and validator topics should be understood through protocol mechanics and risk. Rewards can change, exits can take time, validators can face penalties, and contracts or third-party services can introduce technical risk. In this section, independent judgment before participation is treated as part of a complete workflow. The key habit is to verify the network, request scope and expected outcome with independent evidence before committing an irreversible action. The practical question is what information is visible before an action, what can change on-chain, and what independent evidence can be checked afterward.

A reliable review separates interface labels from protocol facts. Confirm the active network, account, asset or contract involved, then compare the request with the outcome you actually expect. This page focuses on Frequently Asked Questions as a practical decision-making topic rather than a set of interface clicks. This approach is especially useful when different networks use similar address formats or when a DApp asks for permissions that remain active beyond one session.

Do not use urgency as a substitute for understanding. If a signature, approval, bridge, validator action or transfer cannot be explained in plain language, stop and verify the destination, network and permission scope before continuing. On-chain transactions are often not reversible by a wallet provider, so the strongest control is review before confirmation rather than recovery afterward.

Full FAQ

A wallet manages key-based control and presents on-chain data, while asset state is recorded by the relevant blockchain network.

A seed phrase can often restore control over wallet keys, so disclosure may let another person control related assets.

No. Support should never require a private key, seed phrase or verification code.

Address formats can look similar across networks, while balances and transactions remain network-specific.

Verify destination, network, asset, amount and fee; for complex interactions also review the contract and approval scope.

Gas is the network fee mechanism for execution, separate from the amount of the asset being transferred.

It can reveal on-chain status, block inclusion, confirmations, contract interaction and failure details.

A normal connection does not require your private key or seed phrase. Stop if a website asks you to enter either.

No. A message signature can represent login or authorization even when it does not pay gas.

Some approvals remain active, and broad or long-lived permissions can increase exposure.

Many EVM-compatible networks share address conventions, but chain IDs, gas assets and state are independent.

A Layer 2 can rely on a base chain for security or settlement while maintaining separate execution, fees and transfer paths.

Stop signing or sending, return through a trusted entry point, verify the domain, and review recent approvals and transactions.

No. Rewards can change, exits can take time, and validator, contract and market risks exist.

Validator state, uptime, protocol rules and network conditions can affect rewards or penalties.

Avoid sensitive wallet operations on uncontrolled networks or shared devices, and consider remote-control, clipboard and browser risks.

Usually not unilaterally, which is why address, network and amount checks matter before confirmation.

On many networks, revocation is itself an on-chain transaction and can require a network fee.

Continue with imtoken

Review the relevant network and security guidance before moving into asset or DApp operations.

Download imtoken