Live prices are currently unavailable — the exchange feed could not be reached and no recent cached reading is held.

Bitcoin Data GuideBitcoin Reference

Wallet Architecture

How a wallet is actually put together

A Bitcoin wallet is often pictured as a container that holds coins. It is better understood as a rule for deriving keys and a description of the scripts those keys can spend. This hub collects the pages that explain that machinery: how a single seed expands into a tree of keys, how a descriptor states exactly which outputs the wallet controls, how a watch-only arrangement tracks a balance without holding a spending key, and what a backup must preserve for any of it to be recoverable.

The word "wallet" does a lot of quiet work in most explanations. It suggests a place where something is kept, and it invites the reader to think of the seed phrase as the key to that place. The reality is more precise and, once understood, more reassuring: the coins never leave the ledger, and what a wallet holds is the ability to produce a signature that satisfies a spending condition. Everything else — the addresses, the balances, the transaction history — is derived from public data and a set of rules.

Read in that order, the design decisions inside a wallet stop looking arbitrary. A derivation path is a convention for naming keys. A descriptor is a precise statement of which scripts those keys control. A watch-only wallet is the same structure with the signing half removed. And a backup is only complete when it preserves enough to reconstruct all of it. Each page here names the standard it relies on and states what the arrangement does and does not protect against.

Keys & Derivation

Where do a wallet's keys actually come from?

A modern Bitcoin wallet does not store a list of addresses. It stores one seed and derives every key it will ever need from that seed along a deterministic path, which is what makes a single backup sufficient to restore an entire wallet. This strand sets out how that tree is built. It explains the BIP 32 hierarchy, what a derivation path such as m/84'/0'/0'/0/0 selects, and why two wallets given the same seed can still show different addresses if they follow different path conventions. The point is that the seed is the wallet, and everything else is a rule for expanding it.

Start with HD Wallets & Derivation

Backup & Recovery

What has to survive for a wallet to be restorable?

A backup is only as good as the information it preserves, and the common assumption that a seed phrase is always enough is not quite right. A seed restores the keys, but a wallet also needs to know which scripts those keys are meant to control — the descriptor, in other words — and a multisig or a wallet with a non-standard path may need more than the words alone. This strand works through what a complete backup contains, how a restore actually proceeds, and the failure modes that leave a holder with the right seed and no way to spend. It is the strand to read before trusting a backup you have never tested.

Start with Wallet Backup & Recovery

Every page in this section

The strands above are the way in. This is the full contents of the section, grouped by whether the page describes how the keys are built or how the wallet is recovered.

Getting the Wallet Back

What a backup has to preserve, how a restore reconstructs the wallet from it, and the key material the process depends on.

The reference pages behind the strands

The strands above explain the design. These pages hold the underlying standards and the methodology, for when you want to check a claim or follow a source.

Where the wallet meets the protocol

A wallet is a user of the protocol's spending rules. These pages carry the underlying mechanics that a wallet has to satisfy.