How crypto wallets work: keys, signatures, and seed phrases

How crypto wallets work comes down to one job: generating and protecting secrets that can produce valid cryptographic signatures to move funds recorded on a blockchain. Modern wallets industrialize that job by turning one master backup (a seed phrase) into a whole tree of keys and wallet addresses you can rotate without creating new backups.

Key Takeaways

• Wallets don’t store coins. The blockchain records ownership, and the wallet stores secrets that can sign transactions to spend.
• A private key produces the signature that authorizes spending, while a public key and wallet address are what others use to pay you.
• A seed phrase can fully restore a wallet, so anyone who gets it can take the funds.
• Most modern wallets are a hierarchical deterministic wallet that derives many accounts and addresses from one seed using standardized derivation paths.

Wallets as keys, not coin storage

On a screen, a wallet looks like an account: balance at the top, a “Receive” button, a “Send” button. Under the hood, it behaves more like a signing machine on a trading desk. The chain keeps the ledger. The wallet’s job is to prove to the network that the person pressing “Send” is allowed to move specific funds.

That’s why “how wallets store crypto” is a misleading phrase. The coins are not sitting inside the app or the device. Bitcoin’s ledger tracks spendable pieces of value, and a wallet controls them by holding the secrets needed to authorize spending. Bitcoin.org’s vocabulary is blunt about the primitive: a wallet contains private key(s) that let it spend bitcoins allocated to it on the blockchain, show balances, and create payments.

Three identifiers get mixed up constantly, so it helps to separate them cleanly. A wallet address is the string you share to receive funds, and Bitcoin.org notes it should ideally be used only once for privacy. A public key is the non-secret counterpart that can be used to verify signatures. A private key is the secret data used to prove the right to spend via a cryptographic signature, and if it is revealed, it allows spending from the associated wallet.

The last piece is the backup. A seed phrase is not an app login and not a “resettable password.” Bitcoin.org defines a recovery phrase as a sequence of words from which a wallet can be fully restored, and it warns that anyone who obtains it can access the corresponding bitcoins. That single fact explains most wallet horror stories: the real risk is losing, or leaking, the ability to sign.

How a wallet sends and receives

Receiving is the easy half because it requires no secrets. The wallet generates a fresh wallet address, the sender pays it, and the network records that payment on-chain. The wallet then scans the blockchain (directly or through a service) to detect outputs that belong to its addresses and updates the balance display.

Sending is where wallet mechanics matter. On Bitcoin, balances are represented as UTXOs, and Bitcoin.org defines them as unspent transaction outputs that can be spent in future transactions. A spend consumes one or more UTXOs as inputs and creates new UTXOs as outputs. The wallet selects which UTXOs to spend, constructs a transaction that specifies the recipient output and usually a “change” output back to the sender, then signs the transaction with the appropriate private key(s). The network can verify those signatures without learning the private keys.

A simple way to think about the flow is:

1. The wallet gathers spendable UTXOs associated with its addresses and builds a draft transaction. 2. The wallet signs the transaction with the relevant private key material, producing cryptographic signatures. 3. The signed transaction is broadcast to the network and waits for inclusion in a block.

Fees are not a “tax” the wallet charges. Bitcoin.org defines the transaction fee as chosen by the sender to incentivize miners, and it notes that higher-fee transactions tend to confirm faster, especially when the network is busy. That turns the fee slider into a priority knob: urgency determines fee choice more than the amount being sent.

Confirmations are the settlement clock. Bitcoin.org defines a confirmation as the transaction being included in a block, with each subsequent block reducing reversal risk. Wallets surface this as “0 conf, 1 conf, 6 conf,” but the mechanism is the same: the chain, not the wallet, finalizes the transfer.

Seed phrases and deterministic recovery

A seed phrase exists because raw keys are not human-manageable. BIP39 standardized a way for wallets to represent the master recovery material as a list of words, then convert those words into a binary seed used to generate encryption keys. Vault12’s overview emphasizes the operational point: BIP39 is meant to make key management less error-prone for humans, while keeping the underlying cryptography strong.

Randomness is the make-or-break detail. Vault12 flags that the numbers used to create a BIP39 seed phrase must be random, because predictability collapses the security model. With proper randomness, brute forcing is not the realistic threat. Vault12 quantifies the search space for a 24-word BIP39 phrase as 2048^24, about 3 × 10^79 combinations, and describes it as effectively unguessable with today’s technology.

The recovery implication is absolute: the seed phrase can fully restore the wallet. Bitcoin.org’s vocabulary makes the consequence explicit, and it is the reason seed handling is treated like bearer cash. If someone gets the words, they can restore the wallet elsewhere and produce valid signatures. If the words are lost and there is no other backup, the chain has no “forgot password” function.

BIP39 also defines an optional passphrase. Vault12 frames it as additive protection if the seed phrase is exposed, but it also adds complexity and increases the risk of loss. Operationally, enabling it means the recovery set is no longer “the 12 or 24 words.” It becomes “the words plus the passphrase,” and forgetting either one can strand funds just as effectively as losing the seed.

HD wallets and derivation paths

February 2012 is the quiet turning point most wallet explainers skip. Trezor’s BIP32 write-up credits Pieter Wuille with proposing BIP32 and notes it was released in February 2012 to fix a nasty usability problem in older non-deterministic wallets: every new address could require a new backup.

BIP32’s fix is deterministic key derivation organized as a tree. All keys and addresses stem from a master private key, and child private and public keys are derived deterministically, meaning the same master always regenerates the same set. Trezor also highlights the hierarchical structure: child and grandchild keys can be organized into branches, which is how wallets separate accounts and purposes while still being recoverable from one root.

This is where the “wallet compatibility” headaches come from. A hierarchical deterministic wallet can derive many different branches from the same seed, so two apps can show different balances if they are looking at different branches. BIP44 standardized the map. Both Trezor and Vault12 describe BIP44 as a BIP32-based structure with the familiar derivation path format: m / purpose' / coin_type' / account' / change / address_index. That derivation path is the file path the wallet follows through the key tree.

Trezor ties the standards together in the way users actually experience them: when a Trezor device is initialized, it generates a 12, 18, or 24-word recovery seed using BIP39, and that seed becomes the master input for BIP32 key derivation. From there, the wallet can generate new receiving addresses for privacy without creating a new backup each time.

This also explains a common troubleshooting pattern. When “funds are missing,” the first check is often not the blockchain. It is whether the wallet is using the same derivation path, coin type, and account branch as the wallet that originally generated the addresses.

Choosing a wallet type and tradeoffs

Wallet type is just a different answer to one question: where does the signing happen, and who can touch the secrets. Bitcoin.org’s wallet guide lays out the tradeoffs in plain terms across mobile, desktop, web, and hardware wallets.

Hardware wallets are described as one of the most secure methods to store funds, with the obvious cost that they are less convenient on mobile and not designed around quick QR workflows. Web wallets are accessible from anywhere with a browser, but Bitcoin.org warns that if the platform is hacked, funds are at risk. Desktop wallets offer control, and Bitcoin.org flags the environment risk directly: general-purpose computers can be vulnerable to malware that targets wallets.

Two criteria matter more than marketing labels. The first is control: Bitcoin.org notes that some wallets give full control so no third party can freeze or take funds, but that shifts responsibility for securing and backing up the wallet onto the user. The second is validation. Some wallets can operate as a full node, independently verifying blocks and transactions without trusting third parties, and Bitcoin.org notes this requires substantial memory and resources.

Privacy is where HD design meets behavior. Bitcoin.org’s vocabulary says an address should ideally be used only once, and Bitcoin.org’s wallet guide points out that some wallets rotate addresses and can use Tor to reduce linkage to an IP address. BIP32-style derivation makes address rotation operationally cheap because it does not create a backup nightmare.

Near the end of the decision tree, the broader crypto wallet concept snaps back into focus: the wallet is a key-derivation-and-signing system. The UI can be slick or clunky, but the only thing that matters is who can produce valid signatures, and how hard it is to lose that capability by accident.

Common misconceptions

“My wallet stores my crypto.” The chain stores the ledger. Bitcoin.org’s vocabulary defines a wallet as containing private keys that allow spending and creating payments, which is why deleting an app does not delete coins and why restoring from a seed phrase brings balances back.

“A seed phrase is like a login you can reset.” Bitcoin.org defines a recovery phrase as sufficient to fully restore a wallet, and it warns that anyone who obtains it can access the corresponding bitcoins. There is no on-chain reset, and the only “support ticket” is whether the seed phrase still exists and is still secret.

“More addresses means more things to back up.” BIP32 was released specifically to eliminate the need for a new backup for each new address, and Trezor explains that all keys and addresses stem from a master private key in a deterministic tree. The backup burden does not scale with address count, but the consequence is concentration: one seed phrase becomes the recovery material for everything derived from it.

“If two wallets show different balances, the funds are gone.” BIP44’s standardized derivation path structure is why the same seed can legitimately map to different branches. A mismatch in purpose, coin type, account, or change path can make a wallet look empty while the chain still holds the UTXOs tied to addresses in a different branch.

“Fees are fixed and wallets overcharge.” Bitcoin.org defines fees as chosen by users, and it notes higher-fee transactions tend to confirm faster when the network is busy. Wallets can estimate, but the mechanism is still a market for block space.

The Take

I’ve watched people treat a wallet like a bank app and then get wrecked by the one thing the bank normally does for them: key custody. The expensive misconception is thinking the seed phrase is just a setup step. It’s the master signing capability in word form, and Bitcoin.org is explicit that anyone who gets it can restore the wallet and access the funds.

I’ve also seen “missing funds” panic that turned out to be derivation path hygiene. Two apps can look at different BIP44 branches off the same seed and show different accounts. If the wallet is a signing machine fed by a BIP39 seed into a BIP32 tree, the calm move is to verify which branch the software is scanning before assuming the chain lost your money.

Sources

• Bitcoin.org
• Trezor
• Vault12
• Bitcoin.org