A crypto wallet holds or derives the private keys used to sign transactions; the coins and tokens remain recorded on their blockchains.
What the wallet actually controls
An address is a public identifier, not a container. On Ethereum, the chain records an account's native balance, token balances, nonce, and contract permissions. An ERC-20 token balance is simply an entry in the token contract's ledger. The wallet reads that information through an RPC connection and displays it in a usable form.
The secret is the private key. Whoever can produce a valid signature from that key can usually authorize transactions from the corresponding address. The wallet therefore manages credentials and signing operations, while the network enforces the result. Copying an address does not move funds; signing with its private key does.
Most software wallets use a hierarchical deterministic design. A recovery phrase is converted into a seed, and standards such as BIP-32 and BIP-44 define how many account keys can be derived from it. One phrase can therefore produce several accounts and addresses without storing each private key separately. A hardware wallet follows the same general idea but keeps the signing key inside the device. A custodial exchange works differently: it controls the keys on the customer's behalf.
The fastest path from decision to completed transaction
Suppose you want to move a token to another wallet or network. The efficient workflow is short, but each step answers a different question.
- Choose the account and network. Confirm the sending address, the token contract, and the destination chain. A token called USDC can exist at different contract addresses, and a balance on one network is not automatically a balance on another.
- Check the spendable balance and fees. The wallet queries the chain for the token balance, then estimates the transaction fee. You normally need the network's native asset for gas even when sending a token. Congestion, calldata size, the selected gas limit, and the fee market move the cost.
- Authorize the token, if required. A token transfer through a smart contract may require an allowance. The approval gives a specified contract permission to move up to a specified amount. It is a separate on-chain transaction, so it has its own gas cost and confirmation.
- Review and sign. The wallet assembles fields such as the chain ID, destination contract, nonce, amount, calldata, gas limit, and fee settings. It shows a human-readable summary when it can. The private key signs the transaction or its typed-data equivalent; the secret itself should not be sent to the website.
- Broadcast and verify. The signed transaction is sent to an RPC endpoint and enters the network's transaction pool. After inclusion and the required finality or confirmations, check the destination address on the relevant explorer. A successful signature only proves authorization; it does not prove that the intended token, amount, or network was selected.
That last distinction is especially important on a cross-chain route such as a Manta Bridge transfer, where the wallet signs instructions but the cross-network coordination happens elsewhere. The wallet may show one pending action while the route waits for source-chain finality, a relayer, liquidity, or a destination-chain transaction.
Why timing, limits, and fees vary
A normal transfer has one chain, one transaction, and one confirmation path. A cross-chain operation can have several independent stages. The source transaction may need enough confirmations before a message or proof is accepted. A relayer may then submit a destination transaction, which needs its own inclusion. Congestion on either chain can extend the wait.
The mechanism also changes what the wallet is signing. On a smart-contract route, the transaction may call a bridge contract rather than sending tokens directly to the recipient. The contract can lock an asset, burn a representation, release liquidity, or trigger a message. The visible amount may be reduced by a bridge fee, relayer fee, or price movement. Limits can come from contract capacity, available liquidity, per-transaction policy, or the amount of gas the destination transaction needs.
Different systems make different trade-offs. Orbiter Finance and Meson Finance are examples of cross-chain infrastructure where route selection and settlement affect the quoted result. In the Polkadot ecosystem, Cross-Consensus Messaging (XCM) carries instructions between consensus systems. These are not different kinds of wallets: they are different ways of coordinating what happens after a wallet has authorized an action.
The key edge case: smart-contract wallets
A smart-contract wallet makes the separation between keys and coins even clearer. The account is code deployed on a blockchain, and its validation rules determine which signatures count. It might require two of three owners, impose spending limits, support recovery, or allow a sponsored transaction. The owner keys still authorize actions, but no single private key necessarily has complete control.
The practical rule is simple: protect the recovery material, verify the chain and contract before signing, and leave enough native currency for gas. The wallet is the tool that proves authorization. The blockchain, token contract, and any bridge or messaging system are what record and execute the resulting state change.