# 12 — Security and Incentive Design Here's a pattern you'll see over and over in this field's post-mortems: the cryptography was sound, the consensus held, the contract executed exactly as written — and the funds are gone anyway. So where was the hole? Almost never in the math. Blockchain security is a stack, and the cryptographic layer is its *strongest* floor. Attackers, sensibly, go where the assumptions are. ## The whole surface Take an inventory of what "security" actually includes here: - Consensus safety - Economic incentives - Smart contract correctness - Key management - Frontend integrity - RPC trust - Oracle trust - Bridge trust - Governance trust - Operational security - User signing UX Every earlier module contributed a layer to this list, and every layer is somebody's full-time job to break. The discipline this module asks of you is simple to state and hard to practice: don't let "secure" quietly come to mean "the layer I happen to work on." ## The attack catalog | **Attack** | **Meaning** | |---|---| | Reentrancy | Contract sends funds before updating its balance; recipient re-enters and drains again | | Oracle manipulation | Price feed pushed temporarily wrong | | Flash loan exploit | Borrow enormous capital inside one atomic transaction, use it, repay before the tx ends | | Signature replay | A signature reused in an unintended context | | Approval drain | Token approval granted to a malicious spender | | Bridge compromise | Cross-chain verification or admin failure | | Governance attack | Voting power used maliciously | | Private key compromise | Admin or user key stolen | | Frontend compromise | Website tricks users into malicious signing | Four worth walking through, because they recur constantly: **Reentrancy.** A contract sends ETH before updating its balance. The recipient's fallback function calls back into the contract, which still thinks the balance is unchanged — and pays out again. **Flash loan.** Borrow millions inside a single transaction, manipulate a price or governance vote, profit, repay — all atomically. No collateral because the loan cannot outlive the transaction boundary. **Oracle manipulation.** Push a price feed wrong for one block. The lending protocol "correctly" liquidates healthy positions or issues bad loans. **Approval drain.** User once signed `approve` for a malicious contract. The contract pulls tokens days later, when the user has forgotten. Now read the right-hand column again and ask how many of these are actually new. Reentrancy is a reordering bug. Oracle manipulation is trusting an unvalidated input. Replay is missing context-binding. Approval drain is over-broad delegation. Frontend compromise is phishing. You've met every one of them in ordinary systems. So what changed? Three things: exploits are **atomic** (all steps succeed or all revert — nothing partial commits), capital is borrowable via flash loans, and settlement is final. Two entries close threads we opened earlier: approval drains are ERC-20's `approve` bearing its predictable fruit ([[05 Execution and Smart Contracts]]), and malicious signing is the wallet-UX gap ([[07 Wallets and Account Abstraction]]). Bridges — [[10 Bridges and Interoperability]] — remain the record holders for sheer scale. ## Incentives: the other half There's a second half to security here, and it's the half traditional threat modeling misses. Blockchains are *economic* distributed systems — their steady state is set by incentives, not intentions. Consider the cast: users, validators, block builders, searchers, RPC providers, sequencers, liquidity providers, token holders, app developers, governance delegates. Each optimizes for itself, indefinitely, with real money at stake. The design goal that keeps such a system standing: > A protocol is robust when honest behavior is the most profitable strategy, or dishonest behavior is too expensive to attempt. Look back and you'll find this pattern everywhere you've been: slashing ([[04 Consensus]]), challenge windows ([[09 Scaling - Rollups and Data Availability]]), liquidation bounties ([[11 DeFi, Stablecoins, and Governance]]), [[MEV]] auctions. In each case, an incentive stands where a trusted operator would traditionally stand. Mechanism design as a load-bearing component. The threat-model questions, worth internalizing until they run automatically: 1. Who can make money by breaking this? 2. Who detects fraud? 3. Who pays for verification? 4. Who can censor? 5. Who can reorder? 6. Who can halt? 7. Who can upgrade? 8. Who has admin keys? 9. What happens in partial failure? 10. What happens if the token price collapses? Give the tenth one an extra look — it's the one outsiders skip. Security budgets here are denominated in the asset being secured, so a validator set paid in a collapsing token is a shrinking army. Incentive security is reflexive in a way electricity never was. ## Privacy One more structural tension before closing. Public chains are transparent: balances, transfers, contract interactions, behavioral patterns — all visible, all linkable, forever. Verification was the point; surveillance came bundled with it. | **Approach** | **Idea** | |---|---| | Mixers | Break the transaction graph | | ZK privacy | Prove validity without revealing details | | Stealth addresses | Unlink recipients | | Confidential transactions | Hide amounts | | Private mempools | Hide pending transactions | | Trusted execution | Compute inside enclaves | The genuinely hard part: the same opacity that protects users obstructs the compliance that exchanges, issuers, and regulators require. If there's an elegant exit, it runs through [[02 Cryptographic Primitives|zero-knowledge proofs]] — prove the rule was followed without revealing the data — and building that properly is still an open frontier. ## Learning outcomes Questions worth trying on: - Given any protocol, could you run the ten questions and come out with its real threat model — the one its whitepaper doesn't advertise? - Could you explain why flash loans changed attack economics, without concluding they should be banned? - Could you trace one historical exploit end to end and name the *assumption* — not the bug — that failed? - Could you argue both sides honestly: privacy as a prerequisite for real usage, and transparency as a prerequisite for trust? - And finally, the question this vault opened with, now yours to close: for anything you build on these systems — what, exactly, does the user have to trust? When you can answer that precisely and unprompted, the map is yours. ## Checkpoint 1. Reentrancy: what ordering rule prevents it, and why did the intuitive way of writing the code invite it? *(If unsure — do the Ethernaut level rather than reading about it. It sticks better.)* 2. Walk a flash-loan-plus-oracle-manipulation attack through a lending protocol, step by step, inside one atomic transaction. *(Hint: borrow huge → manipulate oracle price → trigger wrongful liquidations or borrows → repay loan, keep profit. If unsure, revisit "The attack catalog" and [[11 DeFi, Stablecoins, and Governance]].)* 3. Why is "what if the token price collapses?" a security question and not just a financial one? *(If unsure, revisit "Incentives".)* **Exercise.** The capstone: pick a real protocol you haven't studied. Spend two hours with its docs and contracts, then write a one-page threat model answering the ten questions. Afterward, find its audit reports and compare. The gap between your page and theirs is your remaining curriculum — and you may be pleasantly surprised by how small it's become. ## Resources - **Ethernaut** — the first hands-on lab: **reentrancy**, **delegatecall** (run another contract's code in your storage context), **tx.origin** (dangerous auth check), access control, storage layout. Do them in order. - **Damn Vulnerable DeFi** — protocol-level adversarial reasoning: flash loans, oracles, governance, liquidations. This is where thinking like an attacker starts to feel natural. - **Paradigm CTF** — the deep end. Not a starting point — but a few writeups, studied carefully, sharpen instincts more than many audits read passively. - **Rekt.news and major post-mortems** — the field's case law. Every entry is an assumption someone found the hard way. --- You've walked the map. Two good places to go from here: build something real — [[Projects to Build]] — or study the boundary where protocols meet products: [[Wallet Infrastructure Roles (Privy)]]. The vault's spine remains [[Blockchain Home]].