Overview — The Ecosystem: DeFi, NFTs & DAOs

For nine parts you have been building a machine, not using it. You built accounts and a world state, a gas-metered EVM that runs arbitrary code safely, a fee market that prices the scarce blockspace, and finally smart contracts — inert code plus storage sitting at an address that every node executes identically. That last part ended with a promise: a contract is the first thing you can build on the world computer that a stranger can trust without trusting you.

This part collects on that promise. A smart-contract chain is a substrate — accounts, the EVM, gas, and persistent storage are the raw materials. What people actually build on it is an economy: fungible tokens, exchanges that hold pools of assets and re-price on every trade, loans that accrue interest block by block, stable money pegged to a dollar, feeds that carry off-chain facts on-chain, and organizations governed by token votes. Those are DeFi, NFTs, and DAOs. This part is a guided tour of them, built strictly from the primitives you already have.

Specializing the book’s one question

The throughline has not changed: how do untrusting strangers agree on the state of a shared world computer — and what does it cost to run one? Until now, the “state” they agreed on was mostly balances — who owns how much ETH. From here on, the state they agree on is far richer:

• a market — the exact price at which two assets trade right now, set by a formula, not a person;
• a debt — who has borrowed what, against what collateral, and when they can be liquidated;
• a peg — a claim that one on-chain token is worth one off-chain dollar;
• a vote — who controls a treasury of millions, decided by token-weighted governance.

Every application in this part re-answers the same two-part question in a new setting: who do you actually have to trust, and what does it cost? The magic of DeFi is not that trust disappears — it is that trust gets relocated from a company you can’t audit to something you can: a public contract, a pile of collateral, a price oracle, a multisig, a bridge. The whole discipline of reading this part is learning to point at exactly where the trust moved to — because that is exactly where the money gets stolen when it fails.

   THE SUBSTRATE (parts 0–8)                 THE ECONOMY (this part)
   ─────────────────────────                 ───────────────────────
   accounts + world state          ┐         ERC-20 / 721 / 1155 tokens
   the EVM (runs code)             ├──────►  AMMs (Uniswap)   lending (Aave)
   gas (prices computation)        │         stablecoins  oracles  DAOs  bridges
   storage (contracts remember)    ┘             │
                                                 ▼
                          each app moves TRUST somewhere new:
                          code · collateral · oracle · multisig · bridge

The recurring test for this part

Everything below is measured against one question. Whenever an application claims to be “trustless” or “decentralized,” stop and ask:

Where does the trust actually live — in the contract code, in posted collateral, in a price oracle, in a multisig key, or in a bridge — and what breaks the instant that one thing fails?

A protocol that keeps every guarantee inside on-chain code you can read is trusting the code and the chain — the same trust you already extended to Ethereum itself. But almost every real application leans on something outside pure code: a stablecoin trusts collateral (or an algorithm), a lending market trusts an oracle’s price, a DAO trusts a multisig or a quorum of voters, a cross-chain bridge trusts whoever guards the locked funds on the other side. Those out-of-code trust anchors are not automatically bad — but they are where the incidents happen. Most of the largest losses in this space were not EVM bugs; they were a trusted oracle fed a bad price, a bridge whose keys were compromised, or an “algorithmic” peg that had nothing real behind it. Keep the test live and every page below reads as a different honest answer to where did the trust go?

These are composable money legos

One more thing to expect before the roadmap: these applications are not islands. They are deliberately composable — later pages reuse the primitives from earlier pages the way you snap Lego bricks together. A token is the atom. An AMM is two tokens in a pool. A lending market hands you a token that represents your deposit, which you can then supply to another protocol. A stablecoin is a token backed by collateral that may itself be earning yield somewhere else. Because every one of them is just a contract with a public interface, any contract can call any other in the same atomic transaction — no permission, no integration meeting, no API key.

That composability is the ecosystem’s superpower and its sharpest danger: a bug or a bad price in one brick can cascade through every protocol built on top of it in a single block. So we teach the bricks in dependency order — you cannot understand an AMM until you understand a token, and you cannot understand a lending liquidation until you understand both a token and a price.

Roadmap for this part

Read these in order. Each page introduces exactly one primitive and names the place it hides its trust. The last column shows what earlier ideas it reuses — and, from page 3 on, which sibling pages it snaps onto.

#	Page	Primitive it introduces	Where the trust lives / what breaks
2	Token Standards: ERC-20, ERC-721 & ERC-1155	A token: a shared interface over a balances mapping in contract storage	The token contract’s own code — a malicious or buggy transfer/approve is the whole risk
3	AMMs & Uniswap’s x·y = k	An automated market: two tokens in a pool priced by a constant-product formula	The formula and the pool code; price is only as honest as the pool is deep (slippage, MEV)
4	Lending: Aave & Compound	Over-collateralized loans: supply, borrow, and liquidation of positions	An oracle price + the liquidation logic — a wrong price liquidates (or fails to liquidate) real debt
5	Stablecoins: Collateralized vs Algorithmic	Stable money: a token engineered to hold a $1 peg	The collateral (or, for algorithmic coins, nothing but confidence) — the peg breaks when backing does
6	Oracles: Chainlink & Bringing the World On-Chain	An oracle: the bridge that carries off-chain facts (prices) on-chain	The oracle network / reporters — a manipulated feed is the single point that poisons pages 4 and 5
7	DAOs, Governance & Cross-Chain Bridges	Governance (token-weighted votes over a treasury) and bridges (moving assets across chains)	A multisig / quorum and a bridge’s locked funds — historically the biggest thefts of all
900	Revision · The Ecosystem	— a one-page recap for self-testing	—

The order is not arbitrary. Tokens (page 2) come first because everything else is built out of them. AMMs (page 3) come next because they are the simplest thing you can build from two tokens, and because they turn out to be a tempting but dangerous source of prices. That danger is exactly why lending (page 4) needs a trustworthy price — which forces the oracle problem into the open (page 6). Stablecoins (page 5) sit between them because a collateralized stablecoin is itself a lending position with a peg target. Governance and bridges (page 7) close the tour with the two trust anchors that live furthest from pure code — and have lost the most money.

Where the money actually goes when trust fails

It is worth naming, up front, that the failures in this part are rarely failures of the EVM. The chain does exactly what it was told; the loss comes from what it was told to trust. Two dated examples set the tone for the whole part.

It actually happened — Terra/UST, May 2022

Terra’s UST was an algorithmic stablecoin: its $1 peg was defended not by collateral but by a mint-and-burn relationship with a sister token, LUNA. As long as the market believed the mechanism, it held. In May 2022, a wave of redemptions broke that belief, the arbitrage that was supposed to restore the peg instead minted LUNA into oblivion (hyperinflating its supply), and roughly $40 billion+ of value evaporated in days. The lesson, which page 5 develops: an algorithmic peg’s “trust” lives in confidence itself, and confidence is the one collateral that can vanish all at once.

It actually happened — the Ronin bridge, March 2022

The Ronin bridge (behind the game Axie Infinity) locked assets on Ethereum and minted representations on its own chain — a design that is only as safe as the keys guarding the locked funds. Those funds were controlled by a small validator set. In March 2022, an attacker compromised five of the nine validator keys — exactly the five-of-nine threshold needed to approve a transfer — and used them to forge withdrawals and drain roughly $600 million — one of the largest crypto thefts on record. No EVM bug, no clever exploit of a contract’s logic: the bridge’s multisig was the trust anchor, and it fell. Page 7 returns to why bridges concentrate risk this way.

Neither of these was Ethereum breaking. Both were the trust an application relocated breaking. That distinction — chain-trust versus application-trust — is the single most useful lens you can carry through this part.

The thread

Tie it back to the one question. The world computer’s job has never changed: let untrusting strangers agree on one shared state, and make the cost of that agreement explicit. What this part adds is what that shared state now describes. It is no longer just balances — it is markets, debts, pegs, and votes, each of them a contract that thousands of nodes re-execute to the same result. That is why they can be trusted at all: the same convergence guarantee that made ETH work makes a Uniswap trade or an Aave liquidation work.

But every application also reaches outside the chain for something — a price, a peg, a key, a bridge — and that reach is where trust quietly re-enters. So read this part with two questions in each hand: what did the strangers agree on, and where — off the chain — did they have to trust something after all? Every page is a different, honest answer.

Start with the atom everything else is built from: Token Standards: ERC-20, ERC-721 & ERC-1155 →

Check your understanding

1. This part calls a smart-contract chain a “substrate.” Name the four substrate pieces from earlier parts, and explain what it means to say the applications in this part are built on top of them rather than being new features of the chain.
2. Restate the book’s throughline as it applies to this part specifically. What richer kinds of “state” do untrusting strangers now agree on, beyond plain balances?
3. State the recurring test for this part. Give three different places trust can live in a DeFi application, and for each, name one thing that breaks when that trust fails.
4. The roadmap is in dependency order. Explain why tokens must come before AMMs, and why lending forces the oracle problem into the open.
5. “These are composable money legos.” Explain what composability buys you and what danger it introduces, using one concrete example of one primitive being reused inside another.

Show answers

1. The four substrate pieces are the account model / world state (the address→record map that lets contracts persist and remember), the EVM (the engine that runs arbitrary contract code), gas (the meter that makes running untrusted code safe and prices every operation), and persistent contract storage (the key/value memory a contract reads and rewrites). Saying the applications are built on top of them means DeFi, NFTs, and DAOs are ordinary smart contracts — they add no new opcodes or chain features; a token, an AMM, or a DAO is just code + storage that every node already knows how to execute. The chain doesn’t “know” what a stablecoin is; it only knows how to run contracts.
2. The throughline is how do untrusting strangers agree on the state of a shared world computer — and what does it cost to run one? Specialized to this part: the “state” is no longer just who owns how much ETH. It is now markets (the price at which two assets trade, set by a formula), debts (who borrowed what against what collateral), pegs (claims that a token equals a dollar), and votes (who controls a treasury). Every application re-answers who must I trust, and what does it cost? in a new setting.
3. The test: where does the trust actually live — code, collateral, oracle, multisig, or bridge — and what breaks the instant that one thing fails? Three examples: (a) oracle — a lending market trusts a price feed; a manipulated feed triggers wrongful liquidations or lets bad debt accrue. (b) collateral / confidence — a stablecoin trusts its backing; an algorithmic peg trusts confidence, and when confidence goes (Terra/UST, 2022) the peg collapses. (c) multisig / bridge keys — a bridge trusts whoever guards the locked funds; compromised keys (Ronin, 2022) let an attacker forge withdrawals and drain the reserve. (Also acceptable: the token contract’s own code; a DAO’s voting quorum.)
4. Tokens come first because every other primitive is built out of tokens — an AMM pool holds two tokens, a lending deposit is represented by a token, a stablecoin is a token — so you cannot reason about any of them without first knowing what a token is and how transfer/approve work. Lending forces the oracle problem into the open because deciding whether a loan is under-collateralized requires knowing the current price of the collateral; that price must come from somewhere, and a naive answer (read it from an AMM pool) is manipulable — so lending makes the need for a trustworthy price source unavoidable, which is exactly what the oracle page addresses.
5. Composability means any contract can call any other contract in the same atomic transaction with no permission, integration, or API key — so primitives snap together like Lego. Example: a deposit into a lending market hands you a token representing your position, which you can then supply as collateral or trade on an AMM — one primitive reused inside another. The danger is that this coupling makes failures cascade: a bug or a manipulated price in one brick (say, an AMM used as an oracle) can propagate through every protocol built on top of it within a single block, before anyone can react.