Frequently Asked Questions
Practical answers on backups, network selection, DApp permissions, and Ethereum PoS, built around checks users can perform themselves. This page never asks for a seed phrase, private key, or verification code.
Keep recovery secrets under your own control, verify the address and network before an on-chain action, and do not approve a signature or permission you cannot explain.
Wallets, networks, and on-chain actions
Asset state is recorded on the relevant blockchain network. A wallet uses keys to control addresses, create signatures, and read on-chain data. Moving to another device does not move the ledger entry; secure custody of recovery material is what preserves access.
A seed phrase can generally derive a set of accounts and private keys, while a private key directly controls a particular account. Both are highly sensitive secrets and should never be sent to another person or entered into an untrusted webpage, chat, or support tool.
No. A request to send a seed phrase, private key, or verification code—whether framed as support, security verification, or an airdrop—should be treated as a serious warning sign.
Record recovery material accurately in a trusted environment and prefer offline storage. Avoid screenshots, public cloud drives, chat apps, or notes that other people can access. A useful backup reduces exposure while remaining readable when recovery is genuinely needed.
Each network maintains an independent ledger state. Even when EVM networks use the same address format, balances, token contracts, and transaction histories are not automatically shared.
Confirm the receiving address, the network the sender will use, and the asset type. For tokens, also confirm the network on which the relevant contract exists rather than relying only on the token name or ticker.
Review the full destination address, target network, and amount, and make sure enough native gas is available. For more complex actions, also inspect the contract address, approval target, and request details.
Gas is the fee mechanism used to pay for network execution. It is commonly paid in the network's native asset, so an account can hold tokens while still lacking enough native balance to submit a transaction.
A transaction hash is a public identifier for an on-chain transaction. On the correct block explorer it can be used to inspect status, block inclusion, sender, recipient, value, and contract interaction details.
Once confirmed, an on-chain transaction generally cannot be reversed unilaterally by a wallet. Replacement or fee-bumping may be possible for some pending transactions depending on the network, but that should not be treated as a guaranteed undo function.
A connection usually establishes a session and allows the DApp to request account or network information; it does not automatically authorize every asset action. However, any signature, approval, or transaction requested after connection must be reviewed independently.
No. A message signature can be used for authentication or agreement to structured data, while a transaction signature commonly authorizes an on-chain state change. Both can have meaningful consequences even when no transfer amount is displayed.
A token approval allows a specified spender contract or address to use a token up to a defined allowance. Review the spender and scope, be cautious with unlimited allowances, and consider revoking permissions that are no longer needed.
No. Session connections and on-chain permissions are separate. Disconnecting can end the current session, but an allowance or operator permission already recorded on-chain normally requires a separate revocation transaction.
Many EVM networks share an account-address representation and execution model, but they have separate chain IDs, nodes, native gas assets, and contract states. Similar formatting is not a substitute for checking the active network.
Confirm the source layer, destination layer, bridge, supported asset, and expected confirmation and withdrawal flow. Some exit paths involve waiting periods, and third-party bridges may add separate smart-contract or operational risks.
No. Rewards can change with network conditions, validator performance, and protocol mechanics. Validator penalties, exit queues, smart-contract risk, third-party service risk, and digital-asset price volatility can also affect outcomes.
Not necessarily. Under Ethereum PoS, exit and withdrawal timing can depend on protocol state and network queues. Treat exiting and becoming withdrawable as related but distinct stages.
What if a request looks suspicious?
Stop if a page, chat message, or person claiming to be support asks for a seed phrase, private key, verification code, unexplained signature, or broad unlimited approval. Verify the source, domain, network, and contract details, then return through a trusted entry point you control.
Where should I go next?
Continue with Getting Started, Security, Web3 & DApps, or Support. Support content is designed around public information and does not require secret recovery material.
A final check before an on-chain action
Whether the question is about wallets, networks, or Web3, return to the request that is actually on screen. Confirm the account, network, address or contract, amount, gas, signature details, and approval scope against the outcome you intended. If you cannot explain a request, do not confirm it until the relevant concept is clear.
