Chapter 5 · Who Owns Crypto?
Where are your coins actually stored?
- Capabilities practiced
- Mental ModelOnchain Literacy
- Hands on
- Create a testnet wallet, write down its recovery phrase, uninstall and reinstall it, then restore it and verify the address is unchanged.
- AI Lab
- Have AI list ten ways to lose a private key. Identify the risks you actually face and turn them into a one-page self-checklist.
A Real-World Problem
A newcomer does the following.
They create an account in a wallet application, copy the words it asks them to record, and receive a transfer. Two weeks later, they change computers, install a wallet from a different provider, and enter those words.
The same balance appears.
They pause and ask a good question: which application stores my coins?
If the first stores them, how can the second see them? If the second stores them, what was the first doing? If both store them, are there now two copies?
Push further and everyday questions become difficult to answer:
- If the phone breaks, do the coins remain?
- If the application is uninstalled, do they disappear?
- If a computer gets a virus, can someone take them?
- What if someone glimpses those words?
All these questions rest on the same mistaken premise:
“Coins are in the wallet” is wrong from beginning to end.
This chapter replaces that statement with the correct one. Misunderstanding it is more expensive than misunderstanding anything else in the course.
Thought Experiment
Return to chapter 2's final proposal: the ledger hangs on the village wall.
Rows cover the wall, and anyone can inspect them. Three things differ from your intuition.
First: the wall does not show names.
Its records look like this:
7f3a9c... → 37 shells
b21e04... → 5 shells
9dd7f1... → 0 shellsThe left-hand strings are marks, not names. Nobody knows which person corresponds to a mark unless the person reveals it.
Second: changing your row requires a private seal, but you must never reveal that seal.
Everyone keeps a private seal hidden. Stamping a particular note produces an imprint.
That imprint has a remarkable property: anyone can verify that the correct seal produced it, but nobody can reconstruct the seal from the imprint. Change the note and the imprint changes too, so an old imprint cannot authorize something new.
Each person's mark derives from their seal: the seal produces the mark, but the mark cannot reveal the seal. It is one-way.
Third: a phrase can recreate the same seal.
A physical seal can be lost. The village invents a twelve-word phrase. Anyone remembering it can ask any engraver to recreate an identical seal.
Conversely, anyone obtaining the phrase can recreate the same seal. The engraver does not ask who they are.
Now answer four increasingly important questions:
Question one: where are your 37 shells?
On the wall. Not at home, in the seal, or in the phrase. They have always been on the wall.
Question two: a fire destroys your seal and the paper holding the phrase. Where do the 37 shells go?
Nowhere. The wall still clearly says 37, visible to everyone every day.
But nobody in the world can move them anymore, including you. They remain on that row until the wall ceases to exist.
Question three: another engraver makes a seal from the same phrase. Are your shells still there?
Yes. The mark depends on the seal, not the engraver. The same phrase creates the same seal, produces the same mark, and points to the same row.
That is what happened to the newcomer. They changed engravers, not safes.
Question four: someone secretly copies your phrase. Will you know?
No. You still hold the phrase, with identical handwriting. Nothing is missing.
One day you pass the wall and see your row says zero. The transfer is entirely valid: its correct imprint passes everyone's checks.
From the wall's perspective, you made the transfer yourself.
Your Decision
Decide how to keep the phrase safe.
What Happens
Every storage method trades off along three axes:
| Who can move assets | Recovery after loss | Detection after theft | |
|---|---|---|---|
| Shop custody | The shop and whoever can persuade it | Yes, through reset | Probably, with records and support |
| Locked drawer | You alone | No | No, until the balance reaches zero |
| Photo gallery | You and anyone with cloud access | Yes | No, until the balance reaches zero |
| Three shares | Anyone holding two shares | Yes, while two remain | No |
Focus on the last two columns. In fully self-managed key schemes, recovery and detection are mostly absent.
This follows from the structure, not poor product design. Chapter 2 explained why:
Real-world accounts offer password recovery because an administrator can change their ledger row.
A bank resets passwords because it can change that row, not because it knows your old password. Platforms restore accounts for the same reason.
The village wall has no administrator. Chapters 3 and 4 spent enormous effort achieving this. If nobody else can change your row, nobody can help when you cannot change it either.
The chapter comes down to this:
You never put coins into a wallet. On-chain state holds a record; the wallet holds only the keys that can change it.
Wallet software does three things: keep keys, read the wall, and create and stamp notes. It does not hold assets.
Build a Model
The first model is a one-way chain. Every step works rightward; none works leftward.
- A seed phrase
- A private key
- A public key
- An address
- A row in on-chain state
It explains every confusion from the opening:
| What you lose | Result |
|---|---|
| Phone, computer, or wallet software | Fine if the seed phrase remains; everything to the right can be derived again |
| Seed phrase, but the private key remains on a device | Dangerous: device failure makes loss permanent; back up again immediately |
| Both phrase and device | Permanent loss. Nobody can recover it; the assets remain on that row forever |
| What someone else obtains | Result |
|---|---|
| Your address | Fine; it is public, allowing them to send money and inspect activity |
| Your public key | Mostly fine, but it may reveal associations |
| Your private key or seed phrase | Complete loss of control without any notification |
Memorize the final row.
The second model is a scale. Between complete delegation and complete personal responsibility are several levels, not a binary choice.
| Level | Who controls keys | Benefit | Cost |
|---|---|---|---|
| Exchange account | Platform | Convenient, recoverable, tradable | You bear bankruptcy, freezing, and internal abuse risks |
| Custodial wallet | Provider, possibly holding shares | Recovery and app-like experience | Provider remains critical |
| Self-custodied hot wallet | You, on an online device | Full control and ready access | Device compromise can lose everything |
| Hardware wallet | You, in an offline device | Keys stay out of online environments | Seed exposure and bad signatures remain dangerous |
| Multisig | Multiple keys, requiring a subset | One failure is not fatal | Complexity, expense, and ongoing maintenance |
Three points must be clear.
First, no level is the correct answer for everyone. Amount, frequency, and your ability to execute the plan determine the choice. A hardware wallet for ten dollars of daily spending and a large long-term balance on an exchange are both mismatches.
Second, the far-right levels defend against different things. Hardware wallets defend against device compromise; multisig against single-point failure and individual abuse. Neither prevents you from reading the seed phrase to a scammer.
Third, most real losses are not technical. Someone disclosed a secret; a password was not brute-forced. The labs therefore focus on this.
What It Is Called
Now give the objects names.
The private seal: a number only you hold, capable of generating valid signatures for content.
Control of the key means control of the assets, with no exception or appeal. The chain recognizes signatures, not identity, intent, or claims of deception.
A publishable number derived one-way from the private key.
Anyone can verify that the matching private key generated a signature, but cannot recover the private key from it. The whole system rests on this one-way property.
A shorter string derived from the public key: the identifier of a row on the wall.
It is public. Someone with your address can send you money and inspect the address's full history.
Notice the latter point. Addresses have no names, but their entire transaction histories remain publicly visible. Once linked to your identity—through withdrawals from an identity-verified platform or a public post—the association is hard to undo. Chapter 23 covers both sides.
The imprint generated by a private key for particular transaction contents.
Two properties matter: it binds to those contents, so changing a character invalidates it, and it cannot be reused to forge a different transaction.
Connecting a wallet to a website does not itself transfer assets. Signing is the moment you authorize something. Understanding the contents before signing is the effective defense. Chapter 24 explains apparently harmless but dangerous requests.
The recovery phrase, usually twelve or twenty-four ordered words from a fixed list.
It is another representation of key information, equivalent in information content. Its purpose is to be readable and writable by people.
Treat this as a hard boundary: any person, software, support representative, or AI asking for your seed phrase is attacking you. No legitimate situation requires handing it to them.
You hold the keys, and no third party can move assets for you.
It is the opposite of chapter 2's reversibility: no support, appeal, recovery, or reversal. Complete control and complete responsibility are the same coin.
The provider holds the keys, while you use an account and password. The interface may look identical, but the structure differs completely.
You hold a record that the provider owes you assets, returning to chapter 2's first table row.
Bring it together:
Assets live in on-chain state. Wallets manage only the keys controlling them.
The real question is who holds the key able to move them, not where your coins are stored.
Hands-on
Use testnets throughout this lab. Put no real assets in this wallet—not a cent. The goal is to experience loss and recovery with no financial exposure.
Consider real assets only after completing the whole process and reproducing the steps from memory.
Create a new wallet and switch to a testnet.
Choose a supporting application, create an account, and switch networks in settings. Confirm the interface says testnet, not mainnet.
Write the seed phrase on paper with a pen.
Check three things: correct order, correct spelling, and checking every word afterward.
Now the real point of this step:
Do not screenshot, photograph, paste into any input, or save it in notes, chat history, or cloud storage.
Follow this even for testnets. You are practicing a habit, not protecting assets. Practice while the stakes are low so the habit works when they matter.
Write your address on the same paper too.
Obtain test tokens from a faucet and send a small transfer to another address of your own.
Find the testnet's faucet. Obtaining tokens is itself worth experiencing.
Then inspect the transfer in a block explorer to confirm it exists. This is your first trace on-chain.
Uninstall the wallet completely.
Really uninstall it. Feeling nervous means the lab is working: this is precisely the feeling you should experience in advance, when it costs nothing.
Reinstall and recover using the phrase.
The crucial detail: use a different wallet provider, not the original one.
Recover with your written phrase and compare the address on paper—
It should match exactly.
Now the chapter's key insight becomes something you have seen: the address belongs to the seed phrase, not any application. You changed only the engraver.
Finally, answer these questions in writing.
One: where exactly is my seed phrase now?
Two: if this paper disappears today, do I have a backup?
Three: if something happens to me today, who should obtain it, and do they know how to use it?
Four: if someone obtains the paper, how soon will I notice?
For self-custody, the fourth answer is usually “when the balance reaches zero.” Now you know what that means.
AI Lab
Use two steps. The second creates the actual deliverable.
First, ask for an exhaustive list:
List at least ten ways to permanently lose control of crypto assets, in two categories:
A: Assets remain on-chain, but nobody can move them anymore
B: Someone else transfers the assets away
For each, explain:
1. A typical scenario, down to an everyday action
2. How long it usually takes the owner to notice
3. Whether any remedy exists afterward
4. Effective prevention and what that prevention cannot stop
Do not recommend specific products or brands.Second, narrow it to your own page:
My actual situation is:
(Describe your usage: broadly where assets are held, devices used,
how the phrase is stored, whether backups exist, and whether another person knows.)
Select only the risks that actually apply to me and remove the rest.
Rank them from most to least likely for me.
Give each one a concrete action I can complete this week.The second output is the lab's product: one page, five to eight items, each with an action for this week.
Two reminders matter.
First, do not include specific addresses, amounts, or any seed-phrase word when describing your situation. “Written on paper at home” is enough; do not name the drawer. You are talking to a third-party service. Keep asset distribution and storage details private.
Second, this AI lab is Level 1: explanations and checklists. It touches none of your assets. One boundary never changes throughout this course:
Private keys and seed phrases never enter any AI system's context. Not once. Chapter 34 returns to this boundary with agent wallets and structural alternatives.
Verify these points yourself after using AI
- Most importantly, reject the entire output if it asks even once to type, paste, upload, read aloud, or provide a seed phrase for format checking; remember what that request looks like
- Check that it separates loss, where nobody can move assets, from disclosure, where others can; responses differ completely
- Check nontechnical paths: forgotten locations, relatives discarding backups, death without instructions, moving, and accidents; models often focus only on hackers
- Check for signature phishing, which can move assets without obtaining your phrase
- For each protection, identify the risk it prevents; do not count protections that cannot stop you disclosing secrets yourself
- Treat product and brand recommendations as unverified; the model cannot judge current trustworthiness, and recommendations themselves can carry attacks
Real-World Case
Many early participants lost keys when coins had almost no value: formatted drives, discarded computers, overwritten backups, or forgotten encryption passwords.
These assets have an unusual state: they visibly exist on-chain, with public balances and years of inactivity, but nobody can move them.
This is self-custody at its purest: no administrator means no exceptions. Identity, loss size, and extenuating circumstances do not make the rules waive their requirements.
Several centralized exchanges halted withdrawals or entered bankruptcy. App balances appeared normal until the withdrawal button stopped working.
The model explains why: users never held the keys controlling those assets. They held platform database records, the first row of chapter 2's table.
The lesson became not your keys, not your coins. After this chapter, you should explain its full meaning rather than repeat it as a slogan.
For balance, custody is not always wrong. Frequent trading, fiat access, small amounts, or inability to keep keys safely can make it more realistic. Know which level of the scale you occupy and its specific risks.
Getting you to sign can be more efficient than stealing your phrase.
A normal-looking page connects your wallet, then requests a signature. You see unreadable contents and a confirm button. Signing may not transfer anything immediately: it authorizes someone to move a class of assets later at any time.
Assets may move days later, when the page is long closed and you cannot recall the responsible action.
A related attack uses fake support. After you ask a question in a group, a supposed employee messages you and directs you to “verify your wallet” or “synchronize assets.”
Both attacks bypass key storage. Hardware wallets, paper backups, and multisig cannot protect you from your own confirmation.
The effective defense is understanding what you sign before signing. Chapter 24 teaches how and which requests to reject outright.
Change One Variable
Loss-related failures disappear overnight. This is a major user-experience improvement worth acknowledging.
The cost is predictable: phone-based recovery requires a role able to reassign assets. A carrier, issuer, or provider fills chapter 2's third column again.
It also introduces new attacks: stealing a phone number through replacement SIMs, social engineering, or insiders can steal assets without leaking a key.
This is why there is still no standard answer. Account abstraction and social recovery seek a compromise: make recovery possible while distributing, delaying, and protecting recovery authority against single-point compromise.
A single mistake is no longer fatal: losing one key leaves two, and stealing one cannot move funds. This is more robust for institutions, teams, and large long-term holdings.
Three costs follow. Operational cost: coordinating multiple people for every transaction. Collusion risk: two people together can still transfer. Human problems: relationships change, people disappear, die, or disagree, often without an exit mechanism.
Security moves from technology to governance. Risk changes category rather than disappearing. Many fund incidents arise from multisig personnel arrangements, not broken cryptography.
This interesting design partly restores chapter 2's reversibility, with cancellation power held by you rather than an institution.
After theft, you have 24 hours to detect and cancel it. Many victims discover theft within hours but can do nothing.
The costs are equally clear. Every ordinary transfer waits 24 hours, unsuitable for everyday payments. The backup key adds another powerful secret to protect. Attackers can use it too, canceling legitimate transfers if they obtain it first.
This is a real engineering direction, explored in several forms. The chapter does not rank them; it clarifies their common axis: recovery capability trades off against exclusive control.
The conclusion comes first: this is one of the course's few explicit never-do actions.
The reasons are structural, in three layers:
First, the phrase enters a system you cannot audit. It crosses networks, may be logged, used for training, or accessed by operators. You cannot establish that it did not leak, which is equivalent to possible disclosure for security purposes.
Second, text can manipulate the model. Webpages, documents, and messages may contain instructions aimed at it. A model able to sign, with externally influenced inputs, becomes a remotely controllable wallet.
Third, nobody can undo the consequences. Chapter 2's real-world protections rely on an accountable party able to edit the ledger. Neither condition holds here.
AI can participate in fund operations, but with another structure: models propose only, while constrained systems or people sign, with amount limits, address allowlists, prior simulation, and auditable logs. Chapter 34 covers this; AI Safety Stack provides the full diagram.
Remember the forbidden architecture: prompt → model → private key → transaction. Without constraints, these four steps form a remotely controlled cash machine.
Takeaway Questions
Choose three of the Eighteen Questions for this chapter.
For self-custody products, asking who the users are must include what execution capability the product assumes.
A scheme requiring twenty-four offline words, perfect handling, and inheritance planning has a smaller real audience than its marketing suggests. Many products fail because their assumed user does not exist, not because they are insecure.
Conversely, ask a wallet promising messaging-app simplicity who inherits the responsibility removed from the user. The answer usually hides in the terms.
This chapter takes the question to its limit.
Self-custody means you bear everything. No insurance, support, regulatory remedy, or court can restore transferred coins. Wrong addresses, bad signatures, lost backups, and scams all leave you with the consequences.
It is an explicit exchange: all remedies for exclusive control. Before deciding, calculate what you gain, what you surrender, and whether the amount is one you can bear.
The concrete question here is how much authority a program able to sign for you has.
Judge what it can do, not what it intends. A program holding a private key can transfer every asset at the address, even if its intended purpose is only checking balances or exchanging a little gas money.
For any automation tool, bot, or plugin, first ask whether it touches signing. If yes, assess it as capable of transferring everything. If not, the risk is an order of magnitude lower. This rule continues through chapter 34.
Chapter Check
Coins are in on-chain state. The wallet contains keys.
It keeps keys, displays on-chain state, and creates and signs transactions. It does not hold assets.
The cleanest verification is this lab: use a different wallet with the same phrase, and the identical address and balance appear. That would be impossible if coins lived in a particular application.
A one-way chain: seed phrase → private key → public key → address. Each step derives rightward, not leftward.
Three practical consequences follow:
Addresses can be public; others can send funds and inspect all history.
Seed phrases and private keys carry equivalent authority; obtaining either gives full control.
The right cannot reconstruct the left, so knowing an address does not compromise assets, while knowing the phrase compromises ownership.
Password recovery means someone can assign a ledger row to new credentials.
Banks can reset passwords because they can edit that row, not because they know the old password.
On-chain ledgers lack that role, deliberately achieved in chapters 3 and 4. Nobody can edit your row, so nobody can help you. These are the same fact.
It can prevent online key exposure, cutting off paths such as viruses, clipboard hijacking, and malware reading key files.
It cannot prevent copying the phrase into a computer or gallery, reading it to fake support, or confirming an authorization you do not understand on the device.
Emphasize the last point: signature phishing bypasses the hardware wallet completely. Nothing abnormal happens operationally; you make a valid signature with your own device.
It improves key-storage security, not decision-making security. Understanding signature contents remains necessary, as chapter 24 explains.
There is no answer key. Check five things:
One, does the plan match the amount? Large hot-wallet balances and elaborate multisig for tiny amounts are mismatches.
Two, how many backups exist and where? One copy cannot withstand physical accidents.
Three, can you execute it after six months untouched? A forgotten scheme is no scheme.
Four, do the right people know what to do if something happens to you today? This commonly skipped item contributes significantly to real losses.
Five, which attacks remain possible? If your answer omits being tricked into signing, it is incomplete.
Explaining where a scheme fails matters more than the scheme itself. The course has practiced this since chapter 1.
Key idea
Assets exist in on-chain state; the wallet only manages the keys that control them.