Stage 4 — Ecosystem, Scaling, and Crypto-Economics

Stage 4 of 6 · Estimated 4–6 weeks

Stage Overview

What This Stage Builds

This stage expands your view from single-chain protocol mechanics to the full Ethereum ecosystem and the multi-chain landscape. You will develop rigorous technical understanding of Layer 2 scaling solutions (rollups, state channels, validiums), the DeFi primitive stack (AMMs, lending, stablecoins, derivatives), the cryptographic architecture of NFTs and DAOs, and the economic systems that make these protocols function over time. This is where protocol engineering meets economic design.

Why This Stage Is Critical

Most engineers understand individual components — they've deployed an ERC-20 or interacted with Uniswap. But understanding why rollups use merkle proofs for state commitments, how a constant function market maker's price function creates invariants, and what makes tokenomics sustainable versus extractive — this is what separates engineers who build from engineers who architect. This stage provides that depth.

Competence at the End of This Stage

You can explain the trust assumptions of Optimistic vs. ZK rollups from the cryptographic level. You can derive an AMM's price impact formula mathematically. You can design a token incentive structure and reason about its Nash equilibrium. You can explain why the scalability trilemma is a real constraint and evaluate any proposed solution against it.

Conceptual Map

Ethereum Architecture
├── Execution layer (EL)
├── Consensus layer (CL)
├── Engine API
└── State management (state trie, EIP-4895)
        │
        ▼
Scalability Trilemma
├── Decentralization
├── Security
├── Scalability
└── Why you can only optimize two
        │
        ▼
Layer 2 Scaling
├── State Channels
├── Sidechains
├── Rollups
│   ├── Optimistic (OP, Arbitrum)
│   └── ZK (zkSync, StarkNet, Scroll, Polygon zkEVM)
├── Validiums
└── Data availability (calldata, blobs, DACs)
        │
        ▼
DeFi Primitives
├── Automated Market Makers (AMMs)
├── Order books (on-chain vs. hybrid)
├── Lending and borrowing
├── Stablecoins (collateralized, algorithmic, hybrid)
├── Derivatives (perpetuals, options)
└── Yield aggregators
        │
        ▼
NFTs — Technical Architecture
├── Metadata (on-chain vs. off-chain)
├── Royalty standards (ERC-2981)
├── Dynamic NFTs and oracles
└── Soulbound tokens (ERC-5192)
        │
        ▼
DAOs — Governance Architecture
├── Token-weighted voting
├── Quadratic voting
├── Conviction voting
├── Delegation
└── Security: governance attacks
        │
        ▼
Crypto-Economics
├── Token supply models
├── Emission schedules and inflation
├── Value capture mechanisms
├── Mechanism design for protocol incentives
└── Sustainable vs. extractive tokenomics

Topic 1: Ethereum Architecture (Post-Merge)

Explanation

The Ethereum post-Merge architecture separates concerns across two distinct client types:

Execution Layer (EL)
The execution layer (Geth, Nethermind, Besu, Reth) handles:

Consensus Layer (CL)
The consensus layer (Prysm, Lighthouse, Teku, Nimbus, Lodestar) handles:

Engine API
The two layers communicate via the Engine API (a local HTTP API):

Ethereum's Current Roadmap

Ethereum's development roadmap (as of 2024–2026):

EIP-4844 (Proto-Danksharding)

Introduced blob-carrying transactions (blobs) — a new transaction type that carries large data payloads (~128 KB per blob) at low cost. Blobs are not accessible to the EVM but are used by rollups for DA (data availability). Blobs are pruned after ~18 days. This reduced L2 transaction costs by 10–100x upon Cancun upgrade (March 2024).

Why It Matters

Ethereum is the dominant smart contract platform. The architectural choices made in the Merge, EIP-4844, and the upcoming Verge and Purge directly affect how rollups work, what data costs, and what it takes to run a full node. Every dApp developer and protocol engineer must understand these changes because they shift assumptions about cost, finality, and state availability.

Real-World Context

Tools / Technologies

Tool Purpose
ethpandaops.io Ethereum network monitoring and testing infrastructure
beacon-api Standard API for CL interaction
engine-api EL-CL communication specification
EIP-4844 blob explorer etherscan.io/blob-txs

Deep Mastery Questions

  1. Why does Ethereum use two separate clients (EL + CL) post-Merge rather than one integrated client? What are the engineering and security benefits of this separation?
  2. Explain how EIP-4844 blobs differ from calldata in terms of cost, EVM accessibility, and persistence. Why can't blobs be read by contracts?
  3. What is stateless validation, and how do Verkle trees enable it? Why is this important for decentralization?
  4. What is Proposer-Builder Separation (PBS), and why is the Base Fee burn (EIP-1559) insufficient to prevent MEV centralization without it?
  5. If Ethereum implements full danksharding (64 blobs per block, with 2D erasure coding), what does this mean for the throughput of rollups that use Ethereum as a DA layer?

Topic 2: The Scalability Trilemma

Explanation

The scalability trilemma (attributed to Vitalik Buterin) states that a blockchain can satisfy at most two of three properties:

Decentralization: Any commodity hardware can participate in validation. No trusted set of validators can permanently censor transactions. The network has many independent participants.

Security: The cost of successfully attacking the network (rewriting history, double-spending) is economically prohibitive. The security assumption is quantified either in hash power (PoW) or staked value (PoS).

Scalability: The network can process a large number of transactions per second at low cost per transaction. Throughput scales with demand.

Why You Can't Have All Three (In One Layer)

Quantifying the Trade-off

A precise formulation: given a target block validation time T, maximum block size B, and minimum network bandwidth N:

Real-World Context

Deep Mastery Questions

  1. Is the scalability trilemma a law of physics or a constraint of current designs? What would need to be true to circumvent it?
  2. Solana claims to achieve high TPS without sacrificing security or decentralization. What is the counterargument? What specific metrics would you use to evaluate its decentralization?
  3. Why do Layer 2 rollups "inherit" Ethereum L1 security? What is the exact mechanism that makes a rollup exit trustless?
  4. How does increasing block size affect node count over time? What economic and access dynamics drive this?

Topic 3: Layer 2 Scaling — Rollups, Channels, and Sidechains

Explanation

State Channels

A state channel allows two or more parties to transact off-chain, with the blockchain as the final arbiter. Parties lock funds into a contract, exchange signed state updates off-chain, and submit the final state on-chain. Only the opening and closing transactions touch the chain.

Sidechains

A sidechain is an independent blockchain with its own consensus mechanism that uses a bridge to move assets to/from the mainchain.

Optimistic Rollups

Transactions are batched and submitted to L1 as calldata (or blobs post-EIP-4844). A sequencer posts "optimistic" state transitions — assumed valid unless challenged.

  1. Sequencer batches transactions, computes new state, posts (compressed_txs, new_state_root) to L1.
  2. During a challenge window (7 days on OP Mainnet, Arbitrum), any verifier can submit a fraud proof.
  3. If a fraud proof is valid, the fraudulent batch is reverted and the sequencer is slashed.
  4. After the challenge window, the state is final.

ZK Rollups

Transactions are batched and a validity proof (SNARK or STARK) is generated, cryptographically proving the new state root is correct given the old state root and the transactions.

  1. Relayer batches transactions, executes them off-chain, generates a ZK proof.
  2. The proof and new state root are posted to L1.
  3. An L1 verifier contract checks the proof. If valid, the state update is accepted immediately.
  4. No challenge period — validity is cryptographically guaranteed.

ZK Proof Systems

System Proof Size Verifier Cost Prover Cost Trustless Setup
Groth16 (SNARK) ~200 bytes Very low (~300k gas) High No (trusted setup ceremony)
PLONK (SNARK) ~1KB Low Moderate Universal setup
STARKs ~100KB Higher Low Yes (no trusted setup)
FRI-based STARKs ~50KB Moderate Low Yes

Ethereum rollups:

Validiums

Like ZK rollups, but data is available off-chain (not posted to L1). Cheaper, but requires trusting the Data Availability Committee (DAC) to not withhold data. Used by dYdX V3 StarkEx, Immutable X.

Data Availability — The Critical Component

For a rollup to be safe:

EigenDA, Celestia, Avail: Alternative DA layers — separate blockchains optimized for cheap, high-throughput data storage. Rollups using these sacrifice Ethereum's DA security for lower cost.

Why It Matters

L2 rollups will carry the vast majority of Ethereum activity within the next 2–3 years. Understanding their security models, trust assumptions, and technical architecture is essential for: choosing which L2 to build on, reasoning about withdrawal delays and finality, designing cross-L2 interactions, and evaluating the real security of a so-called "L2."

Real-World Context

Tools / Technologies

Tool Purpose
OP Stack Framework for building Optimistic Rollups
Arbitrum Nitro / Stylus Arbitrum's rollup stack (supports WASM contracts)
zkSync Era SDK ZK rollup development SDK
StarkNet SDK STARKs-based L2 development
L2Beat L2 security, TVL, and risk analysis

Deep Mastery Questions

  1. What is the exact cryptographic or economic mechanism that prevents a rollup sequencer from posting a fraudulent state root?
  2. Why does an optimistic rollup need a 7-day challenge window? What attack does this prevent, and what user experience problem does it create?
  3. In a ZK rollup, if the ZK proof is valid but the prover implementation has a bug that allows invalid state transitions to generate valid proofs, what happens?
  4. What is the difference between a rollup and a sidechain from a security trust model perspective?
  5. Why does posting data to Ethereum (even just as blobs) matter for rollup security? What specific attack does DA availability prevent?
  6. What is "based sequencing," and how does it eliminate the trusted sequencer assumption?
  7. Compare the verifier contract complexity for a STARK-based rollup vs. a Groth16-based rollup. Why does verifier complexity matter for security?

Hands-On Exercises

  1. OP Stack deployment: Deploy a local OP Stack rollup using op-geth and op-node. Submit transactions to L1 and L2. Verify the state root updates.
  2. Fraud proof tracing: Trace a synthetic invalid state transition through Arbitrum's dispute resolution contracts (use the public ABI and testnet). Identify where the bisection game narrows the dispute.
  3. Blob transaction: Construct and send a blob-carrying transaction (Type 3 EIP-4844) on a testnet. Verify the blob sidecar is retrievable during its availability window.
  4. L2Beat analysis: For OP Mainnet, Arbitrum, and zkSync Era, use L2Beat to identify: their DA mechanism, proof type, sequencer trust assumptions, and upgrade key holders. Write a comparative risk assessment.

Mini Build Task

Build a simple Payment Channel. Two parties (Alice and Bob) lock ETH into a two-party state channel contract on a testnet. They exchange signed state updates off-chain (tracking balances). After 10 off-chain transfers, Alice submits the final state on-chain. Implement the dispute mechanism: if Alice submits an old state, Bob has a timeout to submit a newer one. Final settlement distributes ETH according to the latest agreed state.

Topic 4: DeFi Primitives — Technical Architecture

Explanation

Automated Market Makers (AMMs)

An AMM replaces the traditional order book with a mathematical invariant. The most fundamental: the constant product formula (Uniswap V1/V2): 

x * y = k

where x = reserve of token X, y = reserve of token Y, and k is a constant (maintained by the contract). When a trader swaps Δx of token X for token Y: 

(x + Δx) * (y - Δy) = k
=> Δy = y - k / (x + Δx) = (y * Δx) / (x + Δx)

Price impact: The larger Δx relative to x, the larger the price movement. This is why "slippage" increases with trade size.

Concentrated Liquidity (Uniswap V3)

V3 allows LPs to provide liquidity within a specific price range [p_a, p_b], rather than across the entire [0, ∞) curve. Within the range, liquidity is L = sqrt(k) and the virtual reserves are: 

x_virtual = L / sqrt(p)
y_virtual = L * sqrt(p)

LPs earn more fees when the price is within their range, but earn zero fees outside it. This dramatically increases capital efficiency for narrow-range LPs.

Lending Protocols

Protocols like Compound and Aave implement over-collateralized lending:

  1. Suppliers deposit assets → receive interest-bearing tokens (cToken, aToken).
  2. Borrowers lock collateral → borrow up to their collateral factor (e.g., 75% of collateral value).
  3. Collateralization ratio = (collateral value * collateral factor) / debt value. Must be ≥ 1.
  4. If the ratio falls below 1 (price moves against collateral), liquidators repay the debt and claim collateral at a discount.
  5. Interest rates are set algorithmically based on utilization: rate = base_rate + slope * utilization.

Interest Rate Models:

Stablecoins

Type Mechanism Examples Risk
Fiat-collateralized 1:1 USD reserves held off-chain USDC, USDT Custodian risk, regulatory
Crypto-collateralized Over-collateralized by volatile assets DAI (MakerDAO), crvUSD Collateral volatility, oracle
Algorithmic Seigniorage / supply elasticity (LUNA/UST failed) Death spiral
Hybrid Partial collateral + reserve FRAX (v1-v3) Complex risk

The MakerDAO CDP (Collateralized Debt Position)

Users deposit ETH (or other accepted collateral) into a Vault. The system mints DAI (a stablecoin targeting $1 USD) up to a collateralization ratio (e.g., 150%). A stability fee (interest rate) is charged. Undercollateralized vaults are liquidated via Maker's collateral auction mechanism. The DAI peg is stabilized by the Peg Stability Module (PSM) — allowing 1:1 swaps between DAI and USDC.

Flash Loans

Uncollateralized loans that must be borrowed and repaid within a single transaction. Enabled by:

  1. Protocol sends tokens to the borrower's contract.
  2. Borrower's executeOperation callback runs arbitrary logic.
  3. Borrower must return principal + fee before the transaction ends.
  4. If repayment fails, the entire transaction reverts.

Flash loans expose the power (and danger) of atomic composability. They are the financial primitive that makes most DeFi exploits possible (by providing capital to manipulate prices).

Perpetual Futures and Options

Why It Matters

DeFi primitives are the financial infrastructure of the blockchain ecosystem. Understanding AMM math enables you to: reason about LP returns, impermanent loss, and MEV. Understanding lending protocol rates enables you to design yield strategies. Understanding stablecoin mechanics prevents you from building on fragile foundations. These primitives compose — most advanced DeFi strategies layer multiple primitives, and understanding the composability risks is essential.

Real-World Context

Tools / Technologies

Tool Purpose
v3-core (Uniswap) Reference AMM implementation
Compound / Aave codebase Reference lending implementations
DeFi Llama TVL and protocol analytics
Dune Analytics Custom on-chain analytics
forge fuzz testing AMM price impact verification

Deep Mastery Questions

  1. Derive the impermanent loss formula for a Uniswap V2 AMM as a function of price ratio. At what price ratio does IL reach 50%?
  2. In Uniswap V3, why does concentrated liquidity increase fee earnings but also increase IL (for narrow ranges)? What is the LP's break-even condition?
  3. How does Compound's interest rate model prevent utilization from reaching 100%? What happens economically if it does reach 100%?
  4. Why does the LUNA/UST mechanism create a "death spiral" under sufficient selling pressure? Identify the feedback loop mathematically.
  5. Flash loans are atomic — they must be repaid in the same transaction. What EVM property makes this enforceable?
  6. How does GMX's "zero-slippage" trading model work differently from an AMM? What is the risk transferred, and to whom?
  7. What is "just-in-time (JIT) liquidity" in Uniswap V3, and why is it a form of MEV extraction that disadvantages passive LPs?

Hands-On Exercises

  1. AMM implementation: Code a CFMM in Solidity (constant product, no fees). Simulate 100 swaps. Plot the price curve and verify x * y = k holds throughout.
  2. Impermanent loss calculator: Given a starting price and an ending price, calculate the IL for a V2 LP position. Verify algebraically against your formula.
  3. Flash loan arbitrage: On a forked testnet, write a contract that: (a) takes a flash loan from Aave, (b) swaps on Uniswap V2, (c) swaps back at a profitable price on another pool, (d) repays the flash loan and keeps profit.
  4. Lending rate model: Implement Compound's jump-rate interest model. Plot borrow and supply APR as a function of utilization.

Mini Build Task

Build a Minimal AMM. A Solidity contract implementing constant product market making with: token pair reserves, swap(tokenIn, amountIn) with correct price calculation and fee (0.3%), addLiquidity / removeLiquidity with LP token minting/burning proportional to contribution, and slippage protection (minAmountOut parameter). Write a full Foundry test suite with fuzz tests verifying: invariant x * y >= pre_swap_k (fees accumulate in reserves), no price manipulation via rounding, and correct LP share math.

Topic 5: NFTs — Technical Architecture

Explanation

What an NFT Actually Is

An NFT (Non-Fungible Token) at the protocol level is a uint256 tokenId uniquely owned by one Ethereum address, tracked in a smart contract. The "non-fungibility" comes from the token ID uniqueness — each ID maps to exactly one owner.

ERC-721 Internals

Core state: mapping(uint256 tokenId => address owner) and mapping(address owner => uint256 balance). Transfer: atomic update of both mappings. Events: Transfer(from, to, tokenId) enables off-chain indexers to track ownership.

Metadata: On-Chain vs. Off-Chain

tokenURI(uint256 tokenId) returns a URI pointing to metadata JSON. Three patterns:

  1. IPFS-based: URI points to IPFS CID (e.g., ipfs://Qm...). Content-addressed, immutable if the gateway persists the data. Risk: IPFS pinning may fail.
  2. Centralized server: URI points to https://api.nft.com/token/1. Mutable, controlled by the project. Risk: server disappears, metadata changes.
  3. Fully on-chain: Metadata (including image as base64-encoded SVG) encoded as a data:application/json;base64,... URI. Most durable. Gas-intensive.

ERC-2981 Royalties

The standard interface for on-chain royalty enforcement: royaltyInfo(tokenId, salePrice) returns (recipient, royaltyAmount). Marketplaces voluntarily implement this — there is no trustless enforcement at the protocol level. This created the "royalty wars" of 2022–2023 as marketplaces competed on trading fees by ignoring creator royalties.

Dynamic NFTs

NFTs whose metadata or appearance changes based on on-chain or off-chain state:

Soulbound Tokens (ERC-5192)

Non-transferable NFTs representing credentials, identity, or reputation. Implement by overriding transfer functions to revert. Enables on-chain attestation systems.

Real-World Context

Deep Mastery Questions

  1. Why is IPFS not a solution to the centralization problem of NFT metadata if the NFT project stops paying for pinning?
  2. How does safeTransferFrom differ from transferFrom? Why does it exist?
  3. What exactly does "holding an NFT" mean at the protocol level? What attack surfaces does this create for the holder?
  4. Why can royalties not be enforced trustlessly at the smart contract level (without marketplace cooperation)?
  5. What prevents an NFT from representing double ownership — could a contract claim to own the same tokenId as another contract?

Topic 6: DAOs — Governance Architecture

Explanation

What a DAO Actually Is

A DAO (Decentralized Autonomous Organization) is a set of on-chain smart contracts that collectively govern a protocol's parameters, treasury, and upgrades. "Governance" means: token holders vote on proposals, and approved proposals execute automatically.

Standard Governance Architecture (Governor Bravo / OpenZeppelin Governor)

  1. Proposal: An address with sufficient token balance creates a proposal — a list of (target, value, calldata) tuples to be executed if approved.
  2. Voting period: Token holders vote (for/against/abstain) during a fixed window (e.g., 48 hours).
  3. Quorum: A minimum number of votes must be cast for the proposal to be valid.
  4. Timelock: Approved proposals enter a timelock (e.g., 2 days) before execution.
  5. Execution: Anyone can call execute() after the timelock, which calls the target contracts with the specified calldata.

Voting Mechanisms

Mechanism Description Risk
Token-weighted 1 token = 1 vote Plutocracy — wealthy actors dominate
Quadratic voting Vote power = sqrt(tokens) More egalitarian but costs governance tokens
Conviction voting Votes accumulate over time with tokens locked Encourages long-term thinking
Delegation Token holders delegate voting power to representatives Concentrates power in delegates

Governance Attacks

Why It Matters

DAOs govern protocols holding billions of dollars. Poor governance design has led to: the Beanstalk hack (governance flash loan, $182M), Compound's near-governance-attack in 2023, and Meta-Governance attacks where protocols with large governance token positions influence other DAOs. Protocol engineers must understand governance architecture as deeply as contract architecture.

Real-World Context

Deep Mastery Questions

  1. Why does taking a balance snapshot at a past block prevent flash loan governance attacks?
  2. What is the quorum requirement in terms of game theory? What happens to governance quality if quorum is set too high? Too low?
  3. Explain how a protocol could be attacked via meta-governance — by accumulating governance tokens of a protocol that holds governance tokens in another protocol.
  4. Why does on-chain execution of passed proposals require a timelock? What specific attack does the timelock prevent?
  5. What are the limits of on-chain governance? What aspects of protocol management cannot be governed on-chain?

Topic 7: Crypto-Economics — Sustainable Tokenomics

Explanation

Supply Models

Value Capture Mechanisms

Mechanism Description Examples
Protocol fees Transaction or swap fees flow to token holders Uniswap (potential), Curve
Staking rewards Tokens are locked and earn newly-minted tokens Ethereum validators (ETH)
Buyback and burn Protocol revenue used to buy and burn tokens BNB, MKR
Revenue share Protocol revenue distributed to stakers GMX (30% of fees to GMX stakers)
Governance rights Tokens grant governance power over fee parameters Most DAO tokens

Emission Schedules and Liquidity Mining

Liquidity mining distributes tokens to users who provide liquidity. This bootstraps TVL but creates:

The Reflexivity Problem

Many DeFi protocols create circular value: token price supports TVL (collateral) → TVL generates revenue → revenue supports token price. When confidence fails, the loop reverses catastrophically. (LUNA/UST, OHM forks, many yield protocols.)

cadCAD Modeling

cadCAD (Complex Adaptive Dynamics Computer-Aided Design) is an open-source Python framework for simulating crypto-economic systems. Used to model: token flows, incentive responses, and system stability under stress.

Real-World Context

Deep Mastery Questions

  1. What is the game-theoretic Nash equilibrium of Olympus DAO's (3,3) bonding mechanism? Why did the equilibrium collapse?
  2. How does veCRV solve the mercenary capital problem of traditional liquidity mining? What new centralization risk does it create (the Convex problem)?
  3. In what conditions does buying and burning tokens create real value vs. illusory value? How would you distinguish between the two?
  4. A protocol earns 10Minfeesannually.Itstokenhasa10M in fees annually. Its token has a500M market cap. What would its P/E ratio be? Is this sustainable?
  5. Design a token emission schedule for a new DEX that: bootstraps $100M TVL in the first 6 months, reduces emissions to near-zero after 2 years, and incentivizes long-term liquidity provision. Show your reasoning.

Mini Projects

Project 1: AMM with Liquidity Mining

Extend your AMM from Topic 4 with a liquidity mining program: LPs earn protocol tokens proportional to their share of the pool over time. Implement emission scheduling with a decay function. Simulate the TVL lifecycle: liquidity enters during high emissions, analyze what happens to TVL when emissions drop by 80%.

Project 2: DAO Governance System

Deploy a full on-chain governance system consisting of: a governance token (ERC-20 with snapshot/delegation), a Governor contract with proposal creation and voting, and a Timelock controller. Write proposals that: update a protocol fee, change an interest rate parameter, and upgrade a contract address. Verify that flash loan governance attacks fail.

Project 3: L2 Analytics Dashboard

Build a dashboard that compares OP Mainnet, Arbitrum, and zkSync Era across: daily transactions, average fee, total value locked, withdrawal finality time, and security assumptions. Use public RPC endpoints and APIs. This forces you to understand each chain's architecture to correctly interpret the data.

Project 4: Tokenomics Simulator

Using cadCAD or a custom Python simulation, model a DeFi protocol's token economy: starting supply, emission schedule, fee revenue, staking returns, and sell pressure from farmers. Simulate 3 years of operation under optimistic (high usage) and pessimistic (mercenary capital exits) scenarios.

Capstone Project: Full DeFi Protocol (Lending Market)

Build a multi-asset lending protocol from scratch with rigorous tokenomics:

  1. Lending pool: Support 3 assets (ETH, a mock WBTC, and a mock USDC). Suppliers earn interest; borrowers pay interest.
  2. Interest rate model: Implement the kinked (jump) interest rate model.
  3. Price oracle: Use Chainlink on testnet for asset prices. Implement a circuit breaker that pauses borrowing if price feed deviation is too high.
  4. Collateralization: Over-collateralized borrowing with per-asset collateral factors.
  5. Liquidations: Liquidators repay debts and claim collateral at a bonus (5%). Incentivize liquidators via the protcol token.
  6. Protocol governance token: Emits to suppliers and borrowers proportional to their activity, over a 2-year schedule, then stops.
  7. Fee capture: 20% of interest goes to a treasury; remaining 80% to suppliers.
  8. Invariant testing: 10+ invariant tests including: total borrows ≤ total deposits per asset, no insolvent positions survive without liquidation, protocol token supply never exceeds cap.
  9. Tokenomics analysis: Write a report analyzing the long-term sustainability of the token model.

Common Mistakes & Misconceptions

Mistake Reality
"L2 = sidechain" Sidechains do not inherit L1 security. Rollups do (via fraud proofs or validity proofs).
"High APY = high value" High APY in new DeFi protocols almost always means high token inflation subsidizing returns. Sustainable yield comes from real protocol revenue.
"The trilemma is being solved" Current proposals trade one property for another under different assumptions. No known solution eliminates the trilemma.
"NFTs are immutable" Only the token ID and ownership are immutable. The metadata URI can point to mutable data.
"DAO governance = decentralization" Most DAO governance tokens are highly concentrated at launch. Plutocratic governance is often less decentralized than it appears.
"Flash loans are an attack tool" Flash loans are a neutral financial primitive. They amplify both legitimate arbitrage and exploitative attacks.

Security Considerations

Readings & Resources

Books

Papers

Documentation

Technical Blogs

Previous 03 · Smart Contracts & EVM Stage 4 of 6 · Ecosystem & Scaling Next 05 · Full-Stack dApp