What Is a Crypto Wallet? Keys, Addresses, and Signing

The short answer

A crypto wallet is a tool. It holds private keys, and it signs transactions with them. The funds it appears to hold sit somewhere else entirely, on the blockchain itself.

Ethereum’s developer documentation states the relationship in one line. An account is not a wallet. A wallet is an interface or application that lets you interact with your account ^[1]. The same documentation sharpens the point. You never really hold cryptocurrency, you hold private keys. The funds are always on the ledger ^[1].

That inversion is the whole idea. A wallet that stopped working has not lost anything by itself. The keys it held can be re-entered elsewhere, and the funds reappear, because they never left the chain. Lose the keys, and the funds become unreachable while still existing. The wallet is the handle. The chain is the store.

This page explains the machinery underneath that handle: what the keys are, where addresses come from, what signing actually is, and how one short recovery phrase can rebuild an entire wallet. Every claim is sourced to protocol documentation or to the specification texts themselves.

An account is a pair of keys

An account is made up of a pair of cryptographic keys, public and private ^[1]. The private key is the secret. The public key is derived from it, and the derivation runs one way. It is possible to derive new public keys from your private key, but you cannot derive a private key from public keys ^[1].

That one-way street is why the system works at all. Addresses, which come from public keys, can be handed to anyone. Somebody watching every transaction on the chain cannot work backwards from them to the spending key. On Ethereum, an address is the last 20 bytes of the Keccak-256 hash of the public key, the familiar 0x string ^[1]. Other networks derive addresses by their own schemes. This page does not detail those, because its sources do not.

The practical consequence deserves its own sentence. Sharing a receive address is safe by construction. Sharing a private key, or a recovery phrase that encodes one, is handing over the funds.

Signing is how spending works

Nothing moves until something proves it was authorized. You need a private key to sign messages and transactions, which output a signature. Others can then take the signature to derive your public key, proving the author of the message ^[1].

This is the step beginners most often picture wrongly. Signing is not sending coins out of the wallet. It is the authorization act. The signature lets the network verify two things. The transaction was actually signed by the sender, and it has not been forged. You can always verify the sender of a transaction ^[1]. The funds move on the chain after the network checks the signature against the address. The wallet’s job was to produce that signature without leaking the key while doing it.

One seed, many addresses

Modern wallets do not generate keys one at a time. They derive an ordered tree from a single seed. BIP-32, the Bitcoin Improvement Proposal from 2012 that defined this, describes wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins, as a standard that can be interchanged between different clients ^[2].

The derivation is deterministic. The master key comes from a fixed calculation on the seed, keyed with the string “Bitcoin seed”, and child keys derive down the tree from the master extended key ^[2]. Determinism is what makes restoration possible. The same seed always regrows the same tree.

Extended keys, the nodes of that tree, serialize to strings beginning xprv or xpub. The public form can generate receiving addresses without exposing private keys. There is a documented caveat. Knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key ^[2]. Hardened derivation exists to cut that path at the account level. The honest summary: an xpub is safe to share for receiving, conditionally, and the condition is why hardened levels exist.

BIP-44 standardizes the tree’s shape, a path of purpose, coin type, account, change, and address index, with coin types registered publicly ^[4]. This is why one seed can manage many coins, many accounts, and fresh addresses, and why a wallet that expects a different path can look at the same funds and see nothing. Wallets discover accounts by scanning the chain for history, stopping after 20 unused addresses in a row ^[4]. An account with no balance but with history still gets found. The algorithm keeps going.

The empty-looking restore, then, usually has a mechanical explanation. The seed is fine. The wallet is looking down a different branch of the tree.

The recovery phrase

The seed needs a form a human can write down. BIP-39 defines it. The guide is meant to be a way to transport computer-generated randomness with a human-readable transcription, explicitly not a way to process user-created sentences, which the specification names brainwallets and excludes ^[3].

The lengths are fixed by entropy, not by wallet brand. 128 bits of entropy becomes 12 words, 256 bits becomes 24, with the steps between at 15, 18, and 21 ^[3]. The English wordlist holds 2048 words, sorted so that the first four letters unambiguously identify each one ^[3]. The error-tolerance is designed in.

A recovery phrase is not a password somebody can guess at. It is a transcription of randomness, and the same randomness regrows the same keys. The handling rules for that transcription live on this site’s seed-phrase page, with their own sourcing.

Where wallets differ

Wallets differ less in what they are than in where keys live at rest. bitcoin.org’s wallet pages frame the cautions per type. Mobile: damage or loss of device can potentially lead to loss of funds. Desktop: susceptible to bitcoin-stealing malware. Hardware: loss of device without proper backup can make funds unrecoverable ^[5]. Notably, that chooser page carries no definition of what a wallet is at all. The definition burden sits with the protocol documentation cited above.

Two orientation axes cover the differences, and both belong to this site’s custody pages rather than here: who controls the keys, and where the keys live at rest. The cold versus hot comparison runs the second axis on sourced criteria. The custody glossary entry fixes the vocabulary. This page sits underneath both, at the definition layer.

How this page was checked

Five sources, all protocol or specification tier. Ethereum’s account documentation carries the definition and the signing mechanics. The three BIP texts carry derivation, recovery, and account structure, read at their canonical specification source. bitcoin.org’s chooser contributes the per-type cautions, quoted, and one negative finding: it defines nothing, which is itself recorded. No manufacturer pages, no product names, no review material. Every claim above carries its marker, and the markers resolve to the sources list.

What would change the answer

The definition layer is stable. The BIP texts are deployed standards, dated 2012, 2013, and 2014, and the account model they serve has not moved. What changes is the software built above them. New address formats, new default derivation paths, and new custody forms appear over time, and the comparison page tracks those. If a protocol changed its account model, this page would change with it, on the protocol’s own documentation.

Where this page sits

This page defines the tool. The cold versus hot comparison and the seed phrase safety page carry the security decisions built on it. The cryptocurrency introduction defines the assets being controlled. The cryptocurrency hub frames the cluster this page hangs from. The custody glossary entry holds the shortest form of the vocabulary.