What is a crypto wallet?
A crypto wallet is a system that helps a person or service interact with blockchain accounts and assets. Depending on its design, it may discover addresses, display blockchain data, construct transactions, request or create signatures and broadcast signed data to a network.
The crypto assets are not coin files stored inside the wallet. Balances, spendable outputs and account state are recorded under a blockchain's rules. What a wallet stores or connects to is the information and authority needed to read that state or request changes to it. Control of that authorization does not, by itself, settle every legal or contractual ownership question.
The functions hidden behind one wallet screen
Several components can sit behind a single interface:
- Network or data access obtains blocks, account state, transaction history, token metadata or fee information from a node or indexing service.
- Account discovery derives or imports addresses and determines which accounts the interface should monitor.
- Transaction construction converts a requested action into the exact data required by a network, including destination, amount, nonce, fees and contract instructions where applicable.
- Authorization creates or collects the signatures, approvals or account-specific proofs required by the network.
- Broadcast and status tracking submits the signed transaction and follows its inclusion or failure.
These functions do not need to run in the same application or device. Software can build a transaction while a hardware device signs it. A watch-only wallet can display an address without any signing authority. A custodial service can expose a wallet-like interface while keeping the signing process in systems the user never sees. Bitcoin's wallet documentation describes separate full-service, signing-only and distribution-only arrangements. Bitcoin Developer Guide: wallets
Because the data layer and authorization layer are separate, an incorrect or unavailable data provider can produce an incomplete display even while the blockchain record remains unchanged. Conversely, an interface displaying an address and balance does not prove that it can authorize a transaction.
Keys, seed phrases and accounts are related but not identical
In a conventional key-controlled account, a private key creates a signature and the matching public key enables verification. A hierarchical deterministic wallet may use root material to derive many key pairs rather than store one unrelated key for every address. BIP-32 specifies extended keys and derivation trees; BIP-39 specifies one mnemonic-to-seed process commonly used by wallets. Neither standard says every blockchain account or wallet must use that architecture. BIP-32 and BIP-39
Ethereum illustrates why “wallet equals private key” is too narrow. Externally owned accounts are controlled through key pairs, while contract accounts are controlled by code and do not have private keys of their own. Smart-account systems can apply several signers, spending policies or recovery rules. The interface is still called a wallet even when authorization does not reduce to one locally stored key. Ethereum accounts and ERC-4337
A seed phrase, where used, can reconstruct deterministic root material. A wallet password or PIN usually controls local access or decrypts local storage. Resetting a service login, entering a PIN and restoring a seed phrase are therefore different operations with different consequences.
Custody, connectivity and product format describe different axes
Wallet labels often mix three separate questions:
- Who controls authorization? In a custodial arrangement, a provider controls the relevant signing process or account permissions. In self-custody, the user controls the keys or authorization arrangement.
- How connected is the signer? A hot signing system is readily available to online software. A cold process keeps signing material or devices more isolated from online systems for longer periods.
- How is the interface delivered? Mobile, browser, desktop and hardware describe product format. They do not, by themselves, establish who ultimately controls an account.
A mobile wallet can be self-custodial or custodial. A hardware wallet can protect a self-custody key, but a hardware device could also be one component in a managed custody system. “Hardware,” “cold” and “non-custodial” are therefore not synonyms.
What a wallet signs
A wallet does not simply sign the sentence a user sees on screen. It signs network-specific encoded data. The data may represent a transfer, a contract call, a typed message, an approval or an account operation. Before signing, wallet software may simulate the result or decode some fields, but the quality and completeness of that presentation vary.
A valid signature proves that the applicable authorization condition was met for the signed data; it does not prove that the action was beneficial, that the destination was intended or that the interface explained every consequence. Malicious software can substitute an address, a contract can behave unexpectedly and a broad token approval can authorize later actions. Keeping a key secret and understanding the requested authorization are separate controls.
For Ethereum applications, EIP-1193 standardizes an interface through which a provider can expose RPC methods and events. The provider may connect an application to an account, but the standard does not require the application itself to hold the private key. EIP-1193
Recovery depends on the wallet architecture
There is no universal wallet recovery method:
- a custodial service may offer an account-recovery process under its terms;
- an HD wallet may rely on a seed phrase, passphrase and compatible derivation settings;
- a standalone-key wallet needs a backup of the applicable key;
- a multisignature or smart account may use remaining signers, guardians or contract-defined recovery; and
- a device-backed key may be non-exportable and depend on a separate recovery arrangement.
Restoring keys does not necessarily restore labels, contacts, imported accounts, multisignature configuration or other application metadata. Similarly, changing wallet software does not move blockchain assets by itself: compatible software can sometimes access the same account, while incompatible derivation paths or network settings can initially show different addresses.
Display and transaction failures
Common failures occur at different layers:
- a wallet connected to the wrong network can show another account state or construct an unusable transaction;
- an RPC or indexer outage can hide recent activity without removing it from the blockchain;
- unsupported token metadata can prevent an asset from appearing automatically;
- an incorrect destination or contract instruction can still be signed successfully;
- insufficient fees, nonce conflicts or contract reverts can prevent the intended state change; and
- lost authorization material can make an account inaccessible even though its balance remains visible publicly.
The appropriate diagnosis therefore depends on whether the problem is data display, transaction construction, signing, network acceptance or recovery.
FAQ
Can one wallet support every blockchain?
Not necessarily. Networks use different address formats, transaction encodings, signature schemes and application interfaces. Support must be verified for the specific wallet, network and asset.
Does importing an address give control of it?
No. An address alone can support monitoring. Control requires the private key or other authorization mechanism accepted by the account's rules.
Is a wallet provider always the custodian?
No. A company may publish wallet software without controlling user keys, while another service may control signing behind a hosted interface. The practical question is who can authorize transactions and recover or change that authority.
Related reading
Explore private keys, public keys, seed phrases, non-custodial wallets and crypto custody, or return to the Crypto Glossary.
For a broader beginner-oriented overview, see the existing OKX Learn article What is a crypto wallet?. It is further reading, not a primary technical source for this entry.
Sources
- Bitcoin Developer Guide: wallets — wallet functions, deterministic derivation and separation of networking and signing.
- Ethereum: wallets — wallet interfaces, account access and common product formats.
- Ethereum: accounts — externally owned and contract-account control.
- BIP-32 — hierarchical deterministic key trees and extended keys.
- BIP-39 — one mnemonic-to-seed scheme used by compatible wallets.
- EIP-1193 — Ethereum provider interface between applications and wallet capabilities.
- ERC-4337 — smart-account operations, validation and extensible authorization.
© 2025 OKX. Niniejszy artykuł może być powielany lub rozpowszechniany w całości, a także można wykorzystywać jego fragmenty liczące do 100 słów, pod warunkiem że takie wykorzystanie ma charakter niekomercyjny. Każde powielanie lub rozpowszechnianie całego artykułu musi również zawierać wyraźne stwierdzenie: „Ten artykuł jest © 2025 OKX i jest używany za zgodą”. Dozwolone fragmenty muszą odnosić się do nazwy artykułu i zawierać przypis, na przykład „Nazwa artykułu, [nazwisko autora, jeśli dotyczy], © 2025 OKX”. Niektóre treści mogą być generowane lub wspierane przez narzędzia sztucznej inteligencji (AI). Nie są dozwolone żadne prace pochodne ani inne sposoby wykorzystania tego artykułu.
