The Blockchain Story · Start with the problem
Why did people build blockchains, and why did the next wave keep changing the design? Follow the questions that connect digital money, programmable applications, DeFi, failures and today's experiments. You do not need to buy a token, install a wallet or know how to code.
Your complete 12-lesson route
Read in order, one lesson per visit. Lessons 6, 7, 10 and 11 expand existing guides; the other eight are new historical and synthesis chapters. The sequence follows questions as well as dates: lesson 9 returns to the September 2022 Merge to separate consensus changes from the failures discussed in lesson 8.
- Before Bitcoin: Why Digital Cash Was Hard — Beginner, with optional deeper reading
- Bitcoin’s First Chapter: Shared Rules and Remaining Trade-offs — Beginner, with optional deeper reading
- From Payments to Programs: Why Ethereum Was Built — Beginner, with optional deeper reading
- The DAO and the Governance Question — Beginner, with optional deeper reading
- Tokens and the ICO Era: Code, Claims and Incentives — Beginner, with optional deeper reading
- Why stablecoins became a DeFi building block — Beginner, with optional deeper reading
- DeFi Summer: usage, liquidity and subsidies — Beginner, with optional deeper reading
- Two Different Failures: Terra’s Reflexivity and FTX’s Custody — Beginner, with optional deeper reading
- The Merge: What Changed and What Did Not — Intermediate
- From congestion to rollups: the scaling story — Intermediate
- From seed phrases to smart wallets — Beginner → Advanced
- Three Blockchain Futures and the Evidence That Would Change Them — Intermediate
Already know the basics? Use the level-based paths or jump to the chapter introductions below.
Prologue · A digital copy is easy. A digital payment is harder.
Imagine sending a photograph to two friends. Both can keep a copy. Now imagine sending the same digital coin to two shops. Both shops cannot be paid with the same spendable balance. This is the double-spending problem: deciding which payment counts.
A conventional ledger can let one operator decide. The question behind Bitcoin was whether participants could agree on a payment history without relying on one financial institution to maintain that history. Cryptography helps verify authorization; it does not, by itself, decide which of two conflicting payments happened first.
Start with a shared-ledger example (Beginner). Then ask when a shared blockchain is actually useful (Beginner).
Read the full lesson: Before Bitcoin: Why Digital Cash Was Hard.
Can you explain why copying a photograph and spending a coin are different problems?
Chapter 1 · 2008–2013: Who gets to decide which payment counts?
The Bitcoin whitepaper proposed combining signed transactions with a network that orders them using proof of work. A useful first distinction is between authorization (a valid signature), validity (the transaction obeys the rules) and ordering (which accepted history to follow). A signature alone cannot settle conflicting spends.
Think of several people checking copies of a shared ledger. Agreement requires rules for resolving competing histories, as well as a way to make rewriting history costly. This does not make every intermediary disappear: a person can still choose an exchange to hold assets, introducing a separate custody relationship.
Go deeper: wallets, nodes, miners and UTXOs (Intermediate), then proof of work and chain selection (Intermediate).
Read the historical chapter: Bitcoin’s First Chapter: Shared Rules and Remaining Trade-offs.
The next question: if a network can agree on transfers, what other shared rules could it execute?
Chapter 2 · 2013–2017: From recording transfers to running shared rules
Ethereum's Frontier network launched on July 30, 2015. The learning shift is from a payment history to programs that update shared state. A smart contract is code executed under a network's rules. The word “contract” does not mean a court guarantees the result, and the word “smart” does not mean the code understands your intentions.
A fictional shared escrow illustrates the change: a program might hold an asset and release it when its coded condition is met. But it needs a way to learn about anything outside the chain. Who supplies the evidence that a package arrived? This brings a new dependency into the design.
Explore Bitcoin and Ethereum account models (Intermediate), Ethereum architecture (Advanced) and oracles and external data (Intermediate).
Follow this period: Why Ethereum was built → The DAO and governance → Tokens and the ICO era.
Can you separate what the code enforces from what an outside person or data provider must supply?
Chapter 3 · 2018–2020: Can shared programs become markets?
Programmability made it possible to connect assets with exchange and lending rules. For a learner, two questions organize this period: who supplies the assets needed for a trade, and who can borrow those assets? An AMM trades against a pool using a pricing rule. A lending pool makes a different promise, with collateral, liquidity and liquidation conditions.
Uniswap's founder dates its first deployment to November 2, 2018. Its history is one example of AMM development, not the origin of every decentralized exchange. Rewards added another question: did deposits arrive because people wanted the service, or because someone was subsidizing participation? The Sushi case helps make that distinction concrete.
Bridge into this chapter: Why stablecoins became a DeFi building block.
Lesson 7 · DeFi Summer: usage, liquidity and subsidies
The stablecoin chapter explained why a reference-value asset can be useful in markets and loans. DeFi Summer adds the participation question: what attracts assets and users, and what remains when a reward ends? “More money deposited” and “a better service” are claims that require different evidence.
Read the dates according to what actually happened
- March 23, 2020 — design overview: Uniswap's v2 post described token-to-token pools and a future deployment target. It was not a mainnet-launch announcement.
- June 15, 2020 — reward distribution: the Compound Digest records the start of COMP distribution to protocol users. The dated event is distinct from the newsletter's publication date and from the lending protocol's original creation.
- September 18, 2020 — announced program start: Introducing UNI specifies 00:00 UTC for its initial liquidity-mining program. This does not mean Uniswap itself began on that day.
- Sushi's 2020 migration — a connected case: the existing case study traces how incentives and liquidity migration interact. Read its event sources separately from the terminology used to describe the competition.
These are selected records, not a complete timeline of every protocol. They show why deployments, announcements and rewards should have separate date fields in your notes.
| Metric | What to record | What it does not prove |
|---|---|---|
| Deposits or TVL | Valuation method, assets included, time and double-counting boundaries. | Revenue, unique users or immediately withdrawable cash. |
| Trading volume | Executed notional over a defined period. | Profit or the number of independent customers. |
| User fees | Fees actually paid and who receives them. | That all fees accrue to a protocol treasury or token holder. |
| Token rewards | Distribution amount, valuation time and funding source. | Organic customer demand or sustainable net income. |
A fictional pool: growth without proven sustainability
During one week, a fictional pool has $100,000 in deposits and processes $50,000 in trading volume. At a simplified 0.3% fee, traders pay $150. The program also distributes rewards valued at $800. Participants may receive $950 before other costs and changes in their positions, but only $150 came from the assumed trading fees. The $800 is a separate incentive. This is not a historical observation or a promised return.
If deposits double next week, do not assume that fees doubled. Asset prices may have risen, reward-seeking deposits may have arrived, or the same funds may be counted in several representations. Ask what happened to actual trades and the available withdrawal liquidity.
Check your reasoning: rewards stop and deposits leave. Did the exchange mechanism stop working?
Not necessarily. The pricing rule may still execute correctly while lower liquidity worsens prices for a given trade. Mechanism correctness, liquidity depth and economic sustainability are separate questions. Compare before-and-after observations using the same method.
Now apply the framework: follow the five existing lessons below—DEX design, lending, Sushi, incidents and custody. Then read Terra and FTX as two different failure mechanisms.
1 · Build a market: orders or a pool?
Read how decentralized exchanges developed
Practice: use the two pool sizes in the article to explain why the same trade gets a different average price. Bridge: a pool can support trading, but lending needs different rules.
2 · Lend assets: available cash is not the same as deposits
Read the programmable-lending story
Practice: explain why a pool with 100,000 supplied and 70,000 borrowed cannot immediately pay a 40,000 withdrawal from 30,000 cash. Bridge: useful rules still need participants and liquidity.
3 · Attract liquidity: incentives can move deposits
Read Sushi’s 2020 liquidity migration
Practice: distinguish a reward for depositing from a fee paid by someone using a service. Bridge: growth makes the consequences of design and control failures more visible.
4 · Test the promises: what can fail?
Read the 2021 DeFi incident case study
Practice: name the mechanism that failed and the evidence supporting that explanation. Avoid calling every loss the same kind of “hack.” Bridge: contract failures and exchange custody failures are different problems.
5 · Separate risks: the lesson after FTX
Read custody, DEX settlement and trading risk after FTX
Practice: trace who can move assets, how a trade settles and what allows withdrawal. Explain why changing the venue does not remove every risk. Finish by applying these questions to today's designs.
Vocabulary for this sequence
- Liquidity
- The ability to trade or withdraw in the intended size and conditions; a headline balance alone does not establish it.
- AMM
- An automated market maker: a system that uses a pricing rule and available liquidity to quote trades.
- Collateral
- Assets backing a borrowing position under specified rules; their value and liquidation conditions matter.
- Custody
- Who controls the ability to move an asset, including the permissions and parties involved.
- Incentive
- A reward meant to change behavior. It can attract participation without proving the service is profitable without that reward.
Chapter 4 · 2021–2022: Growth does not answer the trust question
As a learning lens, separate a service's mechanism from its promises. Contract code can behave incorrectly; a price feed can be unsuitable; an intermediary can control customer assets. These are different failure paths and need different evidence.
The incident and FTX lessons above are selected case studies, not a complete history of this period. Use them to build a risk map: asset control → transaction rules → outside dependencies → exit conditions. An audit or a successful transaction is one piece of evidence, not a guarantee of the whole route.
Supporting guide: keys, approvals, backups and wallet incident checks (Beginner to Intermediate).
Compare the failure paths: Terra's reflexivity and FTX's custody.
If one failure is fixed, which dependencies still remain?
A parallel development · The Merge
On a separate infrastructure track, The Merge: What Changed and What Did Not explains the September 2022 consensus transition, the later withdrawal upgrade and why execution cost remained a different question. Read it before the scaling guide.
Chapter 5 · 2023–today: Cost, usability and real-world claims
The current reading map follows three practical questions. Can users complete the whole journey at an acceptable cost? Can they understand and recover their permissions? If a token represents an outside asset, what rights and exit process does its holder actually have?
Scale the journey
Layer 1, Layer 2 and total cost (Intermediate). Count settlement and withdrawal assumptions as well as transaction fees.
Make permissions understandable
Smart-wallet requests and recovery (Advanced). Ask who authorizes execution and who pays, rather than assuming every wallet feature works the same way.
Connect tokens to outside rights
Tokenized claims, cash flows and exit risk (Intermediate). Distinguish a token transfer from a change in legal or economic rights.
Test a useful outcome
The stablecoin exit-cost calculator (Beginner). Use hypothetical inputs to compare what reaches the destination after costs.
“Today” is a reading category, not a claim that every linked article was verified today. Check each article's review date and the date of its evidence.
Epilogue · What would have to be true for the next promise to work?
The future is not a single scheduled destination. Use conditional scenarios and ask what evidence would change your mind:
- Cheaper useful payments: look for lower end-to-end costs, accessible redemption and reliable completion. A cheaper on-chain transfer alone would not establish this.
- Easier self-custody: look for understandable permissions and recoverability under stated assumptions. Hiding complexity while adding an opaque controller is a counterexample.
- Useful tokenization: look for enforceable rights, usable exits and a clear improvement over the existing process. More issued tokens alone would not establish adoption or better outcomes.
Complete the story: Three Blockchain Futures and the Evidence That Would Change Them adds worked comparisons, evidence stages and a worksheet you can revisit.
These are evaluation scenarios, not forecasts or investment recommendations. Write down the claim, its conditions, the evidence and a possible counterexample before comparing projects.
Try it: explain the story in one minute
“First we needed a way to agree on digital payments. Shared programs expanded what those networks could do. Markets and lending then made liquidity and incentives central. Failures forced closer attention to control and dependencies. Today's experiments still have to prove useful outcomes after costs and risks.”
This is an editorial summary. Improve it by adding one documented example and one limitation from the guides you read.
Where to go next
Choose a Beginner, Intermediate or Advanced learning path. Bookmark this chapter map and return to the next question when you are ready.
Source notes
- Bitcoin whitepaper: the original payment and double-spending proposal; read its assumptions, not just its headline.
- Ethereum's July 30, 2015 Frontier launch announcement: evidence of the network launch.
- A Short History of Uniswap: the founder's account, published February 11, 2019; evidence about that project, not an independent history of the entire market.
- The linked case-study guides provide their own dated evidence and worked examples. Chapter boundaries and the learning sequence are Blockchain808's editorial choices.