The word wallet bundles six different objects into one, and most losses in this market come from mistaking what one layer guarantees for what another does. A seed phrase is a backup of a number, a key is authority, an address is a destination, a signature is an instruction whose meaning is defined elsewhere, a ledger is a permanent record, and custody is a legal arrangement that happens to have a technical face. Read as a single object, a wallet looks like a bank account with bad customer service. Read as six layers, each with a boundary around what it protects, it becomes possible to say precisely what can go wrong and which layer is responsible.
The layers are ordered from the inside out: randomness, then words, then keys and addresses, then signatures, then contract permissions, then the ledger, and finally the institutional layer that decides who answers for a balance. Each one is standardised, each one has a specific security property, and no layer in the stack protects the one above it. That last statement is the whole difficulty of custody, and the rest of this article is one layer at a time.

Layer one: randomness, the part nothing upstream can fix
Every wallet begins with an unpredictable number. The device collects entropy, uses it to seed the wallet, and from that moment the entire security of the account is a function of how good that randomness was. There is no later step that can repair a bad start: a key generated from a predictable source is a key that somebody else can reproduce, however well the rest of the pipeline is built.
This is not a theoretical concern. The historical failures in this layer have been real and boring: an operating system that returned the same value twice under specific circumstances, a service that generated wallets on a server with a weak random source, an early convention of deriving a key from a passphrase a human chose. None of those involved breaking cryptography. All of them reduced the set of possible keys to something that could be searched.
What this layer guarantees: that a key pair generated by a modern device is not practically reproducible by anyone else. What it does not guarantee: anything at all about the backup, the device, or the person using it. The boundary here is sharp, and it is the only layer where the correct answer to a concern is to distrust the first implementation you find rather than to add another step on top.
Layer two: words, a backup format that trades secrecy for durability
The seed phrase exists because a 256-bit number cannot be written down by a human without errors. The standard takes the entropy, appends a checksum, slices the result into 11-bit groups, and maps each group to a word from a fixed list of 2,048. Twelve words carry 128 bits, twenty-four words carry 256, and the checksum is why a wallet can reject a mistyped phrase before doing anything else.

Two engineering decisions inside this layer are worth understanding because they create most of the operational risk. The first is that the phrase is not encrypted. It is an encoding, so anyone who reads the words has the number, which is why the disclosure of a phrase is a complete transfer of control rather than a step toward one. The second is that the words are stretched into a seed through a deliberately slow function, and an optional passphrase can be mixed in as an additional factor. That passphrase protects a backup which has already leaked, and it has no recovery path of its own, so an unrecorded passphrase converts a protected wallet into a lost one.
What this layer guarantees: that a correctly transcribed phrase restores the account on any compatible software, and that the same phrase always produces the same addresses. What it does not guarantee: that the phrase stays secret, or that the person who finds it later understands what it is. The layer converts a key into a human-transcribable object and hands the secrecy problem to the physical world.
Layer three: keys and addresses, one-way by construction
The phrase produces a tree of key pairs rather than a single key, and the path taken through that tree decides which account a wallet is looking at. A private key is a 256-bit number, a public key is that number multiplied by a fixed point on a curve called secp256k1, and an address is a hash of the public key plus an encoding step, which is why addresses look like bc1q… or 0x…. Multiplication on that curve is fast and division is not, and that asymmetry is the entire reason a public key can be published without revealing the private one.

The derived path is the layer’s most underrated failure point. Because the same words can generate an unlimited family of addresses, software that assumes a different convention produces a wallet that appears empty while the funds sit untouched under a path it did not look at. Recovering a phrase into a wallet that uses a different derivation convention is one of the few ways to conclude incorrectly that everything was stolen.
Addresses carry one more property worth stating precisely: they are single-use by convention rather than by rule. Reusing one is not a security failure in the cryptographic sense, because the key is not weakened by reuse, and it is a substantial privacy failure, because a chain with a permanent public record allows every payment to one address to be linked together. On a chain with an unspent-output model the practice also leaks change: a payment that spends part of an output must create a second output back to the sender, and that output is the fingerprint analysts follow.
What this layer guarantees: that publishing an address does not reveal a private key, and that a key produces an address deterministically. What it does not guarantee: that a balance at that address belongs to the person who holds the key, because a balance can also be locked by a contract or by the terms of a custodian. The cryptographic boundary is firm; the operational boundary is not defined here at all.
Layer four: signatures, proof of authority rather than proof of intent
A signature proves that the holder of a key authorised a specific message. It proves nothing about whether the holder understood the message, and this gap is where the largest share of permanent losses lives. Traditional schemes sign a hash of the transaction with an elliptic curve algorithm, and newer ones use Schnorr signatures, which allow several keys to produce one signature and make complex spending conditions cheaper to express. Both answer the same question, and neither answers the one users actually care about.

Two design decisions sit inside this layer. The first is that signing happens locally in a self-custody wallet and remotely in a custodial account, which is what makes the same gesture mean different things depending on where it happens. The second is that some chains allow a signature to commit to nothing except a counter, a fee and a destination, and others allow a signature to carry the terms of an agreement. The second category is more expressive and more dangerous, because a wallet displaying an amount is not displaying the whole instruction.
The device that asks for confirmation is a presentation layer over this one. A hardware wallet removes the general-purpose computer from the signing path, defeating malware that builds a different transaction than the one on screen. It does not remove the person from the decision, and it does not translate a contract call into a statement about consequences, because the meaning of the message lives outside the device that signs it.
What this layer guarantees: that a valid signature could only have been produced by the holder of the key, and that anyone can verify it against the public key. What it does not guarantee: that the signer knew what they were approving. Anything a signature can be made to mean is a thing a signature can be tricked into meaning, which is why this layer is where phishing succeeds and where no amount of key hygiene helps.
Layer five: permissions, the layer that was never in the mental model
The permission layer does not exist on every chain, and where it exists it is the least understood part of the stack. On an account-based network running programmable contracts, a holder can authorise a contract to move a specific token from their balance, up to a limit, at a future time of the contract’s choosing. That authorisation is a transaction like any other, and it displays an amount near zero, because no tokens move at the moment of signing.

| Signature type | What it authorises | What the interface usually shows |
|---|---|---|
| Transfer | Move this amount now, to this address | The amount and the destination |
| Approval | Let a contract move this token up to a limit, later | A zero amount, because nothing moves yet |
| Unlimited approval | The same, with no ceiling | Often indistinguishable from a small approval |
| Collection-wide approval | Let a contract move every item in a collection | One confirmation for an entire set of assets |
| Off-chain signature | Agreement to terms that someone else later submits | A text prompt, with no network fee |
This layer is also where gasless signatures appear, and they are the most confusing of the group. A message that costs no network fee and moves nothing can authorise a later transfer, which means the standard warning signals a user relies on, a fee and a visible amount, both disappear precisely when the authorisation is broadest.
What this layer guarantees: that a contract can only move what its permissions allow, and that permissions can be revoked by the holder. What it does not guarantee: that the holder understood what they were granting, or that a grant will be used at a time and in a manner they expect. Permissions do not expire on their own and do not care whether the site that requested them still exists.
Layer six: the ledger, where finality is a feature and a hazard
Below all of it sits the record. The same structure that makes a chain auditable makes a balance uneditable: an append-only log, with each entry linked to the previous one, where undoing an entry means redoing the work of everything after it. The immediate consequence is that a signed instruction which the network has accepted is permanent, and the permanent portion includes mistakes.
The ledger is also the layer that decides what a balance even is, and the two dominant designs produce different everyday behaviour. A chain with unspent outputs keeps discrete amounts locked by conditions, so a wallet spending part of one must return the rest to itself, and address reuse degrades privacy quickly. A chain with per-account state keeps one balance and one transaction counter per address, so a payment is a subtraction and an addition, and history is permanently attached to the address rather than being scattered across outputs. Neither model is more forgiving of a mistake; they differ in what a wallet has to do correctly on the user’s behalf.
Confirmation, finally, is a measure of cost rather than a switch. A transaction is reversible in principle by rewriting the block that contains it and every block after it, which is why venues wait for several confirmations before crediting a deposit and why the number they choose is a commercial risk decision rather than a rule. On networks with explicit finality the equivalent is a checkpoint the protocol will not revert without penalising a large fraction of validators.
What this layer guarantees: that everyone processing the chain sees the same history, and that a confirmed change becomes expensive to reverse. What it does not guarantee: any mechanism for correcting a mistake, or any notion of a balance belonging to somebody in particular. The ledger records what the rules allow, and the rules do not include sympathy.
Layer seven: the institutional layer, which is not technical
Above the cryptography there is a choice that most holders make once and rarely revisit: who holds the keys, and therefore who answers for the balance. Four arrangements cover nearly every real setup, and they differ less in technology than in what a loss means.

Self-custody with a single key removes every counterparty and makes every mistake final. Multi-signature arrangements or threshold schemes split the authority so that one stolen key is not enough and one lost key is not fatal, at the price of a recovery procedure that has to be rehearsed rather than written down. Smart contract accounts move the rules of authorisation onto the chain, which is the first design where replacing a lost key is a feature of the account rather than a hope. And a custodial account transfers the technical problem to a company, which substitutes a legal claim for a key and makes the quality of that company the entire question.
The boundary at this layer is drawn in documents rather than in code: whether reserves are segregated, what a holder’s claim looks like in an insolvency, what happens to an account when its owner dies without leaving instructions, and whether a professional is willing to hold part of a recovery arrangement. Those questions have answers, they are written down somewhere, and they are almost never the thing a signup flow asks about.
What this layer guarantees: that somebody is accountable for the arrangement, whether that somebody is the holder or a company. What it does not guarantee: that the accountability survives a failure. A key is a fact about mathematics; a custody arrangement is a set of promises by institutions, and the two fail in completely different ways.
Where the layers get mistaken for one another
Almost every durable misunderstanding in this market is a claim that is true of one layer and false of another, repeated as though the layers were the same object.
| The claim | True at | Applied to | What that produces |
|---|---|---|---|
| “My balance is in my wallet” | Never | The device | Faith that a lost backup is a lost balance, which it is, and that a lost device is a lost balance, which it is not |
| “The signature protects me” | Layer four | Layer five | Confidence that approving a contract is safer than it is |
| “It is my money” | Layers one to six | Layer seven | A claim on a company treated as a key |
| “Blockchains are private” | Nowhere | Layer three | Reused addresses and a permanent public history |
| “Self-custody is safer” | Layer seven | Layer four | Immunity from counterparties assumed to be immunity from mistakes |
| “The seed phrase is a password” | Layer two, partly | The person | Resetting it, retyping it, pasting it into a support chat |
The pattern in that table is uniform. Each error takes a property that holds in one layer and credits it to the whole stack. The cryptographic layers are strong, the presentation and permission layers are weak, and the institutional layer is not a technical layer at all. Most of the discipline of holding crypto is the habit of asking which layer a statement belongs to before believing it.
What the boundaries mean in practice
Read layer by layer, the operational rules stop looking like folklore. Randomness means trusting the device that generated the wallet and not the channel that delivered it. Words mean the backup is a physical object with a secrecy requirement and a durability requirement that pull in different directions. Keys and addresses mean verifying a destination from a source you chose, because nothing in the stack will catch a well-formed address that belongs to somebody else. Signatures mean treating the confirmation screen as a description of authority rather than of cost, since the fee and the amount are the two least informative numbers on it.
Permissions mean that a balance can be moved by a contract that is not the holder, which is why the list of outstanding approvals is a document worth reading once a quarter. The ledger means there is no reversal, so the only recovery in the system is the prevention that happened earlier. And the institutional layer means that the question “who answers if this goes wrong” has an answer in every arrangement, and that in self-custody the answer is the holder, which is the price of removing the counterparty rather than a defect in the tooling.
The six sentences worth carrying
A wallet holds keys rather than coins, and the balance it displays is a query rather than a possession. A seed phrase is an encoding, so reading it is enough. An address is a destination that reveals nothing about the key, and reusing one is a privacy decision rather than a security one. A signature proves authority and says nothing about understanding. A permission is a transfer that has not happened yet, and it does not expire. The ledger keeps every instruction and forgets none of them, which is exactly why the layers above it are where the care belongs.
None of that requires trusting the interfaces that taught the opposite model. The interfaces are modelled on banking because banking is what people know, and the stack underneath is not a bank: there is no reversal, no recovery desk, no password reset, and no institution whose job is to make a mistake whole. A balance you can see and do not control is a claim on somebody, and the entire difference between a claim and a key is decided by which layer the holder thought they were operating in.







[…] This is also why a wallet never stores coins. It stores keys, and it scans the ledger for the balances those keys control. A wallet with the right key and no network connection is still the owner in every sense the protocol cares about; a wallet with a polished interface and the wrong key is a window onto somebody else’s money. For a longer treatment of that idea, see our explainer on what a crypto wallet actually holds. […]
[…] ranking cannot do for you. For self-custody, see the explainer on private keys and seed phrases and what a crypto wallet actually holds. The distinction between a claim and a coin runs through why a stablecoin is a […]
[…] The custody and failure mechanics referenced here are set out in our explainer on exchange failure and the order of claims, and the general checklist for judging a venue is in ten checks a ranking cannot do for you. For what it means to hold keys yourself, see the explainer on private keys and seed phrases, and for why a wallet is not a container of coins, see what a crypto wallet actually holds. […]