Module 9: DeFi Deep Dive
A Risk Framework for Using DeFi Safely
Chapter 13 of 14 · about 5 minutes
13.1 One page, again
"I understand the pieces now," said Mint. "AMMs, LPs, impermanent loss, lending, liquidations, stablecoins, staking, restaking, farming, loops, contagion. But when I'm about to deposit into something, what do I actually check?"
"A framework," said Hash. "Just like the due diligence checklist in Module 5. Each type of risk, the questions to ask, and what to do about it."
13.2 The DeFi risk categories
These are the categories to work through before depositing. They regroup the broader risk map from Chapter 1 into practical checks: liquidation and impermanent loss get their own treatment in Chapters 6 and 4, while composability and contagion appear here as dependency risk.
| Risk | Core question |
|---|---|
| 1. Smart contract | Could the code be exploited? |
| 2. Oracle | Could prices be wrong or manipulated? |
| 3. Economic design | Could the incentives or mechanisms fail under stress? |
| 4. Liquidity | Can I exit when I need to, at a fair price? |
| 5. Governance and admin | Could someone change the rules against me? |
| 6. Dependency | What does this depend on, and could those fail? |
| 7. User and operational | Could I make a mistake, or be tricked? |
13.3 Smart contract risk
| Questions | Good signs | Warning signs |
|---|---|---|
| Has it been audited? By whom? Were findings fixed? | Multiple reputable audits; public reports | No audits, or unresolved critical findings |
| How long has it held significant funds? | Years with large TVL and no core exploits (Module 5, Chapter 10) | Brand new, or recently upgraded |
| Is there a bug bounty? | Large, active bounty | None |
| Is the code verified and open? | Verified source on explorers (Module 3, Chapter 6) | Unverified contracts |
| Is it a fork? | Well-known original, with careful changes | Hasty copy with unexplained modifications |
Audits reduce risk but don't eliminate it. Many exploited protocols had been audited.
13.4 Oracle risk
| Questions | Good signs | Warning signs |
|---|---|---|
| Which oracle prices each asset? | Decentralised oracle networks with many sources | Single DEX spot price (Module 3, Chapter 12) |
| How are thin or small assets handled? | Strict caps and conservative parameters | Small tokens accepted as collateral with high limits |
| What happens if the oracle fails? | Documented fallback and pause procedures | No plan |
13.5 Economic design risk
| Questions | Good signs | Warning signs |
|---|---|---|
| Where does the yield come from? | Clear, sustainable sources (Chapter 1) | Unclear, or mostly token emissions |
| How does the mechanism behave in a crash? | Tested through past downturns | Depends on continuous growth or inflows |
| Is there a buffer for losses? | Reserves, insurance funds, safety modules | No mechanism for bad debt |
| Are parameters conservative? | Reasonable LTVs and caps | Aggressive settings to attract users |
13.6 Liquidity risk
| Questions | Good signs | Warning signs |
|---|---|---|
| Can I withdraw at any time? | Instant or short, predictable withdrawals | Long lockups, queues, or utilisation near 100% |
| If I need to sell a token, is there enough liquidity? | Deep pools on several venues | Thin pools, large discounts during past stress |
13.7 Governance and admin risk
| Questions | Good signs | Warning signs |
|---|---|---|
| Can contracts be upgraded? By whom? | Time-locked upgrades through governance | Instant upgrades by a small team multisig |
| Who holds voting power? | Broad distribution, active participation | Concentrated insider control (Module 5, Chapter 11) |
| Can the protocol pause or freeze funds? | Limited, transparent emergency powers | Broad, undocumented powers |
Emergency powers are a trade-off: they can stop an exploit in progress, but they also mean trusting whoever holds them.
13.8 Dependency risk
Use the dependency map from Chapter 12. Identify the stablecoins, oracles, bridges, chains, and other protocols your position relies on, and how each could fail.
13.9 User and operational risk
Many DeFi losses aren't protocol failures at all. They're mistakes or scams (Module 2):
- Use bookmarked links, not search results or messages.
- Read every signature and approval (Module 2, Chapters 7 and 8).
- Limit approvals and revoke unused ones.
- Use separate wallets for experiments.
- Keep gas tokens on each network (Module 2, Chapter 9).
- Test with small amounts first.
- Track positions, health factors, and ranges.
13.10 DeFi cover
Some protocols offer cover or insurance-like products that pay out if a specific protocol is exploited. These can reduce smart contract risk, but they have their own conditions, limits, and counterparty risks. Read exactly what's covered: many policies exclude losses from economic design failures, oracle issues, or depegs. Cover is one tool, not a guarantee.
13.11 Sizing DeFi positions
Even after due diligence, some risk remains. Size positions so that a total loss in any single protocol would be painful but survivable.
| Protocol risk profile | Possible allocation approach |
|---|---|
| Long-established, simple, heavily tested | Larger share of DeFi capital |
| Newer but audited, moderate complexity | Smaller share |
| New, complex, many layers, high advertised yield | Small, experimental amounts only |
"So the more layers and the higher the yield, the less I put in," said Mint.
"As a rule of thumb, yes," said Hash. "High yield is usually telling you something about risk."
13.12 Try it yourself
Pick one DeFi protocol you're considering. Go through every risk category in this chapter and rate each as low, medium, or high, with a sentence of evidence for each. Based on your ratings, decide what maximum share of your DeFi capital you'd allocate to it.
Key takeaways from this chapter
- For due diligence, DeFi risks group into these categories: smart contract, oracle, economic design, liquidity, governance, dependency, and user error, alongside the liquidation and impermanent loss risks covered in earlier chapters.
- Audits, time with significant funds, bug bounties, and verified code reduce smart contract risk, but don't eliminate it.
- Strong oracles, sustainable yields, conservative parameters, and loss buffers reduce oracle and design risks.
- Check withdrawal terms and exit liquidity before depositing.
- Time-locked upgrades and broad governance reduce admin risk; emergency powers cut both ways.
- Many losses come from user error; Module 2's habits are essential.
- DeFi cover can help but has limits. Size positions so that any single failure is survivable.