Introduction to Part B
Technical Crypto OS—read chains, write contracts, build systems, and deliver a product running on mainnet.
For people who already write code. The goal is to independently understand and build a complete on-chain system.
Prerequisites
Part A chapters 1–12. This is a real requirement:
- Without understanding that assets live in on-chain state and wallets manage keys, you cannot implement signatures and approvals correctly.
- Without understanding blockspace as a market, you cannot understand what gas optimization optimizes.
- Without understanding probabilistic finality, your frontend will mistake “broadcast” for “successful.”
Engineers usually need only one week for these twelve chapters.
Six stages
Develop a builder's perspective: what is actually stored on-chain, and what happens between code and confirmation of a transaction?
Stage deliverable: A command-line tool that reads blocks and accounts, parses a transaction, and prints state changes.
Write, test, and deploy usable contracts and programs under both the EVM and Solana models.
Stage deliverable: A fully tested token contract, deployed to testnet with source code verified in a block explorer.
Turn a contract into a product: wallet, frontend transaction state, backend, database, indexing, and real-time updates.
Stage deliverable: A full-stack dApp: connect a wallet, send transactions, index events, and refresh in real time.
Implement AMMs, routing, oracles, lending, and perpetuals from math through code, and understand MEV.
Stage deliverable: A runnable AMM and router, with tests for slippage, fees, and liquidation.
Turn on-chain data into a queryable system and protect funds with threat models and invariants.
Stage deliverable: A threat model and invariant checklist, with fuzzing tests and monitoring alerts.
Let the model participate in decisions without controlling funds: separate proposal, validation, simulation, execution, and audit.
Stage deliverable: An on-chain agent with a wallet, budget, strategy engine, and audit log.
T1–T36
| Chapter | Title | Core question |
|---|---|---|
| T1 | What exactly is blockchain data? | What is actually stored on a chain? |
| T2 | Cryptography fundamentals | How can a signature prove “it is me”? |
| T3 | A transaction from code to chain | From construction to confirmation, what must the code do? |
| T4 | What is RPC? | Who is your dApp really talking to? |
| T5 | EVM Account Model | What is the difference between an EOA and a contract account? |
| T6 | Solana Account Model | Why don't Solana programs store their own data? |
| T7 | Solidity fundamentals | What form does a contract take once deployed on-chain? |
| T8 | Inside the EVM | Why can the same assignment statement cost 100 times more gas? |
| T9 | ERC Standards | What problem do standards actually solve? |
| T10 | Solana Program | Without contract storage, how does a program remember state? |
| T11 | Token Program | Why isn't a Solana token a standalone contract? |
| T12 | Testing & Deployment | How can you catch problems before real money is spent? |
| T13 | Wallet Connection | What actually happens when you log in to a dApp? |
| T14 | Web3 Frontend | What should the interface show during the seconds while a transaction awaits confirmation? |
| T15 | Backend for Crypto | If the data is already on-chain, why do we need a backend? |
| T16 | Databases and on-chain data | How should on-chain data be stored in a database? |
| T17 | Indexer | What happens to your data after a chain reorganization? |
| T18 | Realtime System | How can you push on-chain changes to users in real time? |
| T19 | AMMs: from math to code | What does x·y=k look like in code? |
| T20 | DEX Architecture | How many layers does one swap pass through? |
| T21 | Oracle | How does a chain know the outside price? |
| T22 | Lending Protocol | When must the liquidation engine outrun the market? |
| T23 | Perp DEX | How do margin, funding rates, and a risk engine form a system? |
| T24 | MEV | Who saw your transaction before it entered a block? |
| T25 | Blockchain Data Infrastructure | How can you turn all on-chain data into a queryable warehouse? |
| T26 | Cross-chain | Is an asset still the same asset after crossing chains? |
| T27 | Account Abstraction | Can users stay safe without holding private keys directly? |
| T28 | Smart Contract Security | The code was correct, so why was it still stolen? |
| T29 | Protocol Security | What can attackers do with money alone, without exploiting a bug? |
| T30 | Audit | What does an audit actually examine? |
| T31 | AI-assisted Crypto Development | Can an AI-written contract go to mainnet? |
| T32 | Reliable AI Architecture | How can the model participate in decisions without controlling funds? |
| T33 | Tool-using Crypto Agent | How can agents really use on-chain tools? |
| T34 | Agent Wallet & Payment | Which safety switches should an agent's wallet have? |
| T35 | DeFi Agent | What checks must an agent pass before rebalancing? |
| T36 | Autonomous Onchain Economy | Where are the boundaries of a system that can earn and spend money on its own? |
Two parallel threads
Each stage presents both EVM and Solana models. Comparison is the fastest way to understand a model. Seeing Solana require transactions to declare which accounts they touch in advance makes the meaning of the EVM's global state machine much clearer.
Choose one as your main platform and learn to read the other.
After the course
Complete the Build an Onchain Economy capstone, then enter the T-series Career Tracks.