Capstone Projects
Crypto Research OS, Build an Onchain Economy, and the advanced Create a Machine Economy project.
The course centers on Proof of Skill: produce work at every stage, then connect it through a capstone project.
Stage Deliverables
Submit one at each stage's end. The twelve deliverables form a portfolio.
| Part A | Deliverable |
|---|---|
| One | Explain your wallet's first onchain transaction, from signing to finality |
| Two | Compare three chains on security, execution, state, latency, decentralization, and hardware requirements |
| Three | Explain one DeFi pool's yield sources, with onchain data and a risk list |
| Four | Analyze tokenomics: supply, unlocks, value capture, and dilution |
| Five | A thirty-minute project review: thirteen Project Canvas cells and a judgment |
| Six | Agent permission design: budget, allowlist, approval threshold, and audit log |
| Part B | Deliverable |
|---|---|
| One | A CLI that reads blocks and accounts, parses transactions, and prints state changes |
| Two | A fully tested token contract, deployed to testnet with verified source |
| Three | A full-stack DApp with wallet connection, transactions, indexed events, and live updates |
| Four | A working AMM and router with slippage, fee, and liquidation tests |
| Five | A threat model and invariant list with fuzzing and monitoring alerts |
| Six | An onchain agent with wallet, budget, strategy engine, and audit log |
Non-Technical Capstone: Crypto Research OS
Choose a real Crypto project and produce a complete research report.
Cover fourteen parts:
- Industry
- Users
- Product
- Protocol
- Chain
- Token
- Tokenomics
- Revenue
- Competition
- Onchain data
- Community
- Capital
- Risk
- AI analysis
Acceptance criteria:
Every conclusion is traceable to a source. Prioritize primary sources. Mark untraceable claims “unverified”; do not fill gaps with speculation.
Collect the onchain data yourself. Include queries or data-platform links so others can reproduce the numbers.
Answer all twelve questions. Especially 11 and 12: can it operate if its token goes to zero, and do users remain when subsidies stop?
Assess all ten risk categories individually. Mark unassessed risks explicitly rather than omitting them.
Document AI use. State where you used it, for what, what you verified, and where it failed. This section often demonstrates your competence most clearly.
Technical Capstone: Build an Onchain Economy
Build a genuinely usable system in a direction you choose: DEX, prediction market, RWA, perpetuals, payments, or agent treasury, for example.
Required:
| Layer | Requirement |
|---|---|
| Smart Contract | Tests, invariants, and fuzzing for critical paths |
| Frontend | A complete transaction state machine with clear failure messages |
| Backend | Idempotency, retries, and rate limits |
| Database + Indexer | Replayable, reorg-safe, and resumable |
| Analytics | At least one chart that explains system health |
| AI | At least one AI-assisted function following the AI Safety Stack |
| Security | A threat model and invariant list |
| Deployment | Others can access it and complete an entire workflow |
Acceptance always begins: Give me a link; I will try it myself.
Advanced Project: Create a Machine Economy
Your sandbox contains 1,000 users, 100 agents, one stablecoin, one chain, and one market.
Design all its economic rules:
- Agent Identity
- Wallet
- Payment
- Reputation
- Market
- Protocol
- Token
- Governance
- Security
The system then triggers random events. For each, identify affected layers, reason through outcomes under current rules, and decide whether to change rules, recording why.
| Event | What it tests |
|---|---|
| Liquidity crisis | Market depth and market-maker incentives |
| Oracle failure | Single dependencies and fallback strategies |
| Agent attack | Permission boundaries and rate limits |
| Stablecoin depeg | Reserve structure and redemption paths |
| Token collapse | Whether value capture depends on token price |
| AI hallucination | Whether verification genuinely blocks errors |
| Model failure | Fallback and shutdown plans |
| Wallet theft | Key management and loss isolation |
| Regulatory change | Compliance assumptions and adaptability |
Scoring evaluates your reasons for every rule change, rather than the number of events survived. This distinguishes a Crypto Architect from a Crypto Builder.
Submission and Presentation
- Publish your work. Private work has almost no value for hiring and collaboration.
- Include a README: what it is, how to run it, your tradeoffs, and known problems.
- Prepare a twenty-minute presentation: fifteen minutes explaining design, five answering objections. Answering objections matters more than presentation polish.