Chapter 33 Key Takeaways

Core Concepts

  1. A dApp is a full-stack system, not just a smart contract. The complete stack includes smart contracts (state and execution), an RPC provider (node access), a wallet (user identity and transaction signing), a frontend (user interface), decentralized storage (IPFS for large data), and an indexing layer (The Graph for efficient queries). Each layer has distinct responsibilities and distinct centralization tradeoffs.

  2. ethers.js v6 separates Providers from Signers for a reason. A Provider is a read-only connection to the blockchain — it can query balances, read contract state, and listen for events. A Signer extends a Provider with the ability to sign transactions. This separation makes the code's intent clear: pass a Provider when reading, pass a Signer when writing.

  3. IPFS solves the on-chain storage cost problem through content addressing. Storing data on Ethereum costs $5-20 per kilobyte. IPFS stores data off-chain for minimal cost, and only the CID (a 32-byte content-addressed hash) is stored on-chain. The CID guarantees data integrity — if the content changes, the CID changes. But IPFS does not guarantee availability; pinning services are required to keep data accessible.

  4. The Graph makes dApp frontends practical. Without indexing, answering simple queries like "show all active proposals sorted by vote count" requires scanning every block since contract deployment. The Graph indexes blockchain events into a queryable database and exposes a GraphQL API. This reduces hundreds of RPC calls to a single query.

  5. Smart contract testing is non-optional and must be comprehensive. The four categories of tests — unit, integration, edge case, and security — each catch different classes of bugs. Coverage tools verify that every code path is exercised. Gas reporters track the economic cost of each operation. A governance system without comprehensive tests is a liability, not an asset.

Architecture Principles

  1. Decentralization is a spectrum at every layer. The contracts are decentralized. The RPC provider is centralized. The frontend hosting is centralized. The IPFS gateway is centralized. True decentralization requires effort at every layer, and tradeoffs are inevitable.

  2. The frontend is the most vulnerable layer. It is subject to hosting provider policies, DNS seizures, regulatory pressure, and content moderation — as the Uniswap delisting demonstrated. Mitigations include IPFS hosting, ENS names, open-source code, and multiple alternative frontends.

  3. The timelock is the most important governance safeguard. It creates a mandatory delay between proposal passage and execution, giving stakeholders time to react to malicious or controversial proposals. Without it, governance is vulnerable to surprise attacks.

Development Practices

  1. Revoking the deployer's admin role is the most critical deployment step. If the deployer retains the TimelockController admin role, they can bypass governance entirely. This is the single most common governance deployment mistake and the one with the most catastrophic consequences.

  2. Testnet deployment reveals a class of bugs invisible to local testing. Network latency, gas estimation, nonce management, RPC provider behavior, block confirmation timing, and frontend-to-chain synchronization all behave differently on live networks. Budget significant time for testnet iteration.

  3. Smart contract verification on Etherscan is a requirement, not a nice-to-have. Unverified contracts cannot be read or audited by the community. A governance system with unverified contracts should not be trusted. Plan for verification from the start.

  4. The smart contract is typically 20% of the total development effort. Frontend integration, deployment scripting, error handling, testing, and user experience account for the remaining 80%. Blockchain developer education that focuses exclusively on Solidity misses the majority of the work.

Progressive Project Completion

  1. The governance dApp you built across this textbook uses the same architecture as production DAOs. Compound, Uniswap, ENS, and hundreds of other DAOs use OpenZeppelin's Governor framework, ERC20Votes tokens, and TimelockControllers. The patterns transfer directly.

  2. Every component was built incrementally. The token (Chapter 11), the testing framework (Chapter 14), the security patterns (Chapter 15), the token economics (Chapter 26), and the governance structure (Chapter 28) were all developed in earlier chapters and assembled here. This is how real software is built — not in one monolithic effort, but through the composition of well-understood parts.