Wallets, Keys & Transactions

Blockchain & Web3 Fundamentals
Course 1 · Chapter 7 · Wallets, Keys & Transactions

Every earlier chapter has referred to "your private key" or "your address" as if using one were obvious. This chapter makes it concrete: what a wallet actually is, how it's backed up and recovered, the real, meaningful difference between custodial and non-custodial control, and exactly how a transaction gets built, signed, and sent — tying Chapter 2's signatures, Chapter 5's UTXOs, and Chapter 6's accounts together into one real, end-to-end process.

What a Wallet Actually Is (and Isn't)

A common, genuinely misleading intuition is that a crypto "wallet" holds your coins, the way a physical wallet holds cash. It doesn't. The coins — whether tracked as Bitcoin's own scattered UTXOs (Chapter 5) or an Ethereum account balance (Chapter 6) — live entirely on the blockchain itself, replicated across every node on the network. A wallet's real job is narrower and more specific: it generates, stores, and uses the private key that proves you're allowed to spend or move whatever balance is associated with your public address.

Put plainly: losing your wallet doesn't destroy your coins — they're still sitting on the ledger, exactly where they always were. What losing your wallet destroys is your own ability to prove ownership and produce a valid signature (Chapter 2) for them, which in practice is just as final for you personally.

Seed Phrases: One Backup for Every Key You'll Ever Need

Modern wallets don't ask you to separately back up every individual private key you might ever generate. Instead, they use a real, standardized system: a single seed phrase, typically a randomly generated list of 12 to 24 ordinary dictionary words, from which every key pair the wallet ever uses can be deterministically regenerated.

A representative (illustrative, not a real usable seed) 12-word example:
1. crane2. velvet 3. copper4. orbit 5. gentle6. mango 7. ripple8. tunnel 9. finch10. glacier 11. brave12. stove

This is possible because most modern wallets are what's called hierarchical deterministic (HD) wallets: the seed acts as the single root input to a deterministic process that can generate an entire tree of key pairs — one for every address you ever use — all reproducible from that one seed alone. Write the seed phrase down correctly (on paper, or a comparably durable medium), and every key the wallet ever derives can be regenerated on a brand-new device, even if the original wallet is lost, stolen, or destroyed.

Why This Cuts Both Ways The seed phrase's own convenience is also its single biggest real risk: anyone who obtains your seed phrase can regenerate every one of your keys and take everything associated with them, permanently, with no recovery process to appeal to — there's no bank or company to call. A seed phrase is, functionally, the single most sensitive piece of information in the entire system.

Hot vs. Cold, Custodial vs. Non-Custodial

Two genuinely separate spectrums are worth keeping distinct:

  • Hot wallet — keys are generated or stored on an internet-connected device (a phone app, a browser extension). Convenient, but exposed to online attack.
  • Cold wallet — keys are generated and kept entirely offline (a dedicated hardware device, or even a paper printout), reducing exposure to remote hacking, though not eliminating risk entirely — offline devices themselves can still have real, documented vulnerabilities of their own.
  • Custodial — a third party (an exchange, an online service) holds your private keys on your behalf. You're trusting that party completely to keep the keys safe and to actually let you withdraw when you ask to.
  • Non-custodial — you generate and hold your own private keys directly, with no third party able to freeze or move your funds without your own signature.
"Not Your Keys, Not Your Coins" This widely repeated phrase in the crypto community captures the custodial/non-custodial distinction precisely: if a third party holds the private keys, your real, practical claim on those coins depends entirely on that party's own honesty, solvency, and continued operation — not on cryptography alone.

Mt. Gox: A Real, Documented Case of Custodial Risk

This isn't a hypothetical concern. Mt. Gox, a Tokyo-based exchange that at its peak handled over 70% of all bitcoin trading worldwide, halted trading on 24 February 2014 and filed for bankruptcy days later, after revealing that roughly 850,000 bitcoins belonging to its customers were missing (around 200,000 were later recovered, leaving a real net loss of roughly 650,000 BTC). Investigators concluded most of the missing coins had actually been stolen gradually from Mt. Gox's own hot wallet, beginning as early as late 2011 — years before customers ever found out.

Every affected customer had done everything "right" from their own perspective — they held an account with a real, major exchange. But because Mt. Gox itself, not its customers, held the actual private keys, those customers had no independent ability to move or protect their own funds once the exchange's own security had already failed. This real, documented event is exactly what "not your keys, not your coins" is warning against.

How a Transaction Is Actually Built, Signed, and Sent

1
Construct the transaction. On Bitcoin, this means selecting one or more existing UTXOs as inputs and specifying the new outputs (Chapter 5). On Ethereum, this means specifying the recipient account, the amount, and (for a contract call) the data to send (Chapter 6).
2
Sign it. The wallet uses your private key to produce a digital signature over the transaction data (Chapter 2's own ECDSA/secp256k1 signing process) — proving you authorized it, without ever revealing the private key itself.
3
Broadcast it. The signed transaction is sent out to nodes on the network, which independently verify the signature against your public key before relaying it further.
4
Get included in a block. A miner (Chapter 4's proof-of-work) or validator (proof-of-stake) includes the transaction in a new block, which propagates across the network.
5
Confirm. As more blocks are added on top, the transaction becomes increasingly final, per Chapter 3 and Chapter 4's own "buried deeper is more secure" reasoning.
QuestionAnswer for This Chapter
Does a wallet store coins? No — it stores the private key(s) that control coins living on the ledger itself
What does a seed phrase let you do? Deterministically regenerate every key pair a wallet ever derived, from one 12–24-word backup
Who actually controls your funds in a custodial wallet? The custodian, not you directly — a real risk Mt. Gox's own 2014 collapse illustrates concretely

Hands-On Exercises

Three exercises reinforcing wallet mechanics and custodial risk before Chapter 8 turns to tokens and NFTs — a different category of asset built on top of everything this chapter has assembled.

Exercise 1
A friend says: "I keep all my crypto in my phone's wallet app, so if I lose my phone, I lose my crypto forever." Using this chapter's own seed-phrase mechanics, explain whether this is actually true, and what it depends on.
Exercise 2
Using the real Mt. Gox case, explain specifically why holding coins on an exchange is structurally different from holding them in a non-custodial wallet, even if the exchange itself has excellent security practices.
Exercise 3
Walk through this chapter's own five-step transaction flow for a real Bitcoin payment, naming specifically which earlier chapter's own material each step relies on (Chapter 2, 3, 4, or 5).

Quick Reference

  • A wallet stores keys, not coins — the balance lives on the blockchain itself.
  • Seed phrase — a 12–24-word backup that deterministically regenerates every key an HD wallet derives.
  • Hot vs. cold — online-connected vs. offline key storage.
  • Custodial vs. non-custodial — a third party holds your keys vs. you hold them directly; "not your keys, not your coins."
  • Mt. Gox — a real 2014 exchange collapse, roughly 650,000 BTC net lost after theft from its own hot wallet, the classic real illustration of custodial risk.
  • Transaction flow — construct → sign (Ch.2) → broadcast → included in a block (Ch.4) → confirmed as more blocks build on top (Ch.3, Ch.4).