What is a crypto wallet?

In brief

A crypto wallet does not literally store your coins, in the same way that a bank app does not literally contain the cash in your account. Assets exist as entries on a blockchain's shared ledger; a wallet is the software (and sometimes hardware) that holds the private keys able to authorize changes to those entries, and that lets you construct, sign, and send transactions. Losing a wallet does not necessarily destroy the underlying assets, and having a wallet does not necessarily mean the assets are "in" it; both facts follow from separating the wallet as a tool from the account it controls.

Private keys, accounts, and addresses

Exactly what "the account" means, and how a private key controls it, differs by blockchain design, though a wallet's basic job is the same in each case: generate and protect key material, and use it to sign transactions when you approve them, rather than to hold a balance the way a physical wallet holds banknotes.

On account-based chains such as Ethereum, a private key directly controls an account identified by a public address, derived from a cryptographic key pair; whoever can produce a valid signature for that address effectively controls whatever the network's ledger associates with it. Ethereum's own developer documentation draws a further distinction worth knowing here: an externally-owned account (EOA) is exactly this private-key-controlled kind of account, while a separate kind of account, a contract account, is instead a deployed smart contract controlled by its own code rather than by a private key, and can only send a transaction in response to first receiving one. A wallet, in the everyday consumer sense used in this article, manages the private keys behind EOAs; interacting with a contract account happens by sending it a transaction, not by holding a key for it.

Bitcoin and other UTXO-based systems do not use this kind of running-balance account model at all. Rather than one address holding a balance that goes up and down, Bitcoin's ledger tracks discrete unspent transaction outputs (UTXOs), each one locked by spending conditions that, in the common case, require a valid signature from a specific private key to spend. A Bitcoin wallet's private keys authorize spending the UTXOs they control, and the wallet software adds those UTXOs up to display something that looks, to the user, like a single account balance, even though the ledger itself does not store a balance in the way Ethereum's account model does.

Newer programmable-account designs complicate the single-private-key picture further: smart-contract wallets and account-abstraction schemes can let more than one key, or a different authorization mechanism entirely, approve transactions for a single account. This article uses the common, single-private-key case, whether EOA-style or UTXO-style, to explain the core ideas; treat "one private key controls one account" as the widely applicable default rather than a universal law that holds for every account on every chain.

Do not conflate the wallet application with the on-chain account or UTXOs it controls. Reinstalling a wallet app, or trying a different wallet product, does not create a new account or move funds anywhere, as long as the same private key (or the seed material that derives it) is loaded into it; conversely, permanently losing that key material, with no other copy, generally means permanently losing the ability to use whatever it controlled, even though that balance still technically exists on the ledger.

Seed phrases, briefly

Most modern wallets do not ask a user to manage individual private keys directly. Instead, they generate a single, human-readable "seed phrase," commonly 12 or 24 words, following the BIP-39 standard, and use it with the hierarchical deterministic derivation scheme defined in BIP-32 to generate an entire tree of key pairs and accounts from that one phrase. This means a single backup can restore many accounts and, on many wallets, works across multiple blockchains, not just one. Seed phrases and their specific risks (backup, exposure, and recovery) are broad enough to deserve their own dedicated article; this one only introduces the concept so the account model above makes sense. Not every wallet or every blockchain uses BIP-39 specifically, and a general key-management standard such as NIST's SP 800-57 is a source for cryptographic key-protection principles in general, not a specification written for consumer crypto wallets.

Software versus hardware wallets

A software wallet (sometimes called a "hot" wallet when connected to the internet) keeps private key material on an internet-connected device: a phone, browser extension, or desktop application. It is generally convenient and free, but the key material is exposed to whatever risks affect that device and its software, including malware.

A hardware wallet keeps private key material on a dedicated, purpose-built device that is not directly connected to the internet, and signs transactions internally, only exporting the finished signature rather than the key itself. This reduces exposure to many remote software attacks. It does not make a wallet immune to all risk: physical access to the device, supply-chain tampering, and low-level hardware attacks have all been demonstrated as areas of active security research. A 2017 DEF CON presentation, for example, showed that a microcontroller used in some hardware wallets of that era was susceptible to fault-injection ("glitching") attacks under laboratory conditions with physical access to the device; this is a historical finding about specific 2017-era hardware, not a claim about the current security of any particular product, and it illustrates a general principle: hardware wallets reduce some categories of risk without eliminating physical-access or implementation risk entirely.

Custodial versus self-custodial

A custodial wallet is one where a third party, typically an exchange, holds the private keys on the user's behalf; the user's practical control depends on that provider's own security, solvency, and policies, and the private key never passes through the user's hands.

A self-custodial (or non-custodial) wallet is one where the user, not a company, holds the private key material directly. This removes dependence on a specific company's continued honesty and solvency, but it also removes any built-in recovery mechanism: there is generally no password-reset process if key material or its backup is lost, and no institution to appeal to if a transaction was sent to the wrong address or authorized under false pretenses. Neither model is universally safer; each shifts risk to a different place, and the IMF's 2016 discussion of virtual currencies flagged this loss-of-recourse property specifically as a meaningful difference from conventional custodial financial accounts. A full comparison of custody models, including hybrid and smart-contract-based approaches, is the subject of the dedicated self-custody article.

Hot versus cold storage

"Hot" and "cold" describe internet connectivity rather than custody. A hot wallet's keys are generated, stored, or used on an internet-connected device, which is convenient for frequent transactions but keeps the keys within reach of remote attacks. A cold wallet's keys are generated and stored on a device that is kept offline, such as most hardware wallets in their normal operating mode, which reduces remote attack surface at the cost of convenience. A wallet can be both self-custodial and hot, both self-custodial and cold, or, in principle, custodial with the provider using cold storage internally; hot/cold and custodial/self-custodial are two independent classifications, not synonyms for each other.

Connecting a wallet to an application

When a decentralized application asks a user to "connect wallet," it is typically requesting the account's public address so the application can read that account's public on-chain data, and asking the wallet to be ready to present future transactions for the user's signature. Connecting a wallet, by itself, does not hand over private keys or grant blanket authority to move funds. In the ordinary case, each new transaction still requires an explicit approval from the user before the wallet will sign it, but this is not a universal invariant: many wallets and applications also support narrower standing permissions, such as a prior token approval, a time-limited session key, or a programmable account's own spending rules, that let further actions proceed without a fresh prompt every time. What actually authorizes a transfer, a token approval, or a smart-contract interaction is whichever of these mechanisms grants the permission, not the act of connecting itself, which is why reviewing what a transaction or a permission request actually grants matters more than reviewing what "connecting" a site claims to need.

Multi-chain wallets

Because many blockchains use similar underlying cryptography and, often, compatible key-derivation schemes, a single wallet application can generate and manage separate accounts for several different blockchains from one seed phrase, presenting them as a unified interface even though each chain's accounts, balances, and transaction rules remain entirely separate and are tracked by each chain's own independent network. A multi-chain wallet is a convenience layer over several distinct account systems, not evidence that the underlying blockchains are connected to each other.

Security basics, briefly

Wallet security failures are, in practice, one of the more common ways crypto users actually lose funds; Chainalysis's 2026 Crypto Crime Report estimated that over $3.4 billion in cryptocurrency was stolen in 2025 across hacks and compromises, a figure the firm typically revises upward over time as more incidents are identified, separate from its much larger figures for scams and fraud. Given that, a few structural points are worth stating plainly: a legitimate service will not ask a user to type a seed phrase or private key into a website, support chat, or "wallet checker" tool; approving a transaction or a permission request is a security-relevant decision each time, not a one-off setup step; and a hardware wallet, while it reduces several categories of risk, does not make a malicious or mistaken transaction, a compromised interface, or a lost backup impossible to happen. This article intentionally keeps security guidance brief and general; the mechanics of specific threats such as phishing, malicious approvals, and transaction simulation are outside its scope.

What to learn next

From here, the private key and seed phrase articles cover key generation and backup in more depth, the self-custody article covers custody trade-offs and failure modes more fully, and the cryptocurrency and blockchain articles cover what, exactly, the ledger behind a wallet's accounts is actually recording.