--- url: /academy-handbook/foundation/week-2/part-6-trust-and-risk-map.md --- # Week 2 · Part 6 — The trust and risk map This is the shortest page in Week 2 and the one the rest of the Foundation leans on hardest. Week 1 Part 5 sorted assets by what could go wrong with each. Week 1 Part 8 traced how the list of things you trust changes at every step. Parts 3 to 5 this week showed the machinery underneath. **Today turns all of that into one question you can ask about anything, forever.** ## Learning objectives * List the trust assumptions behind any common Web3 action * Explain why self-custody redistributes trust rather than removing it * Identify which assumption in a stack is the weakest * Apply the map to something the handbook has never mentioned ## Core ### The claim this page corrects The popular version of Web3 is *"trustless — you don't have to trust anyone."* That is not right, and believing it is actively dangerous, because it stops you asking the useful question. ::: important The accurate version \==**Web3 does not eliminate trust. It changes and redistributes trust assumptions.**== You are always trusting *something*. What changes is **what**, **how many things**, and crucially **whether you can inspect them**. ::: Traditional finance generally asks users to rely on institutions, regulators and external audits rather than independently verifying the full system state themselves. Web3 can make some assumptions directly inspectable while adding or shifting others — some inspectable, some very much not. A real improvement in some respects and a real downgrade in others. ==**The skill is telling which is which.**== ### The map Each row highlights the main assumptions worth checking first. It is not an exhaustive dependency graph; real systems can add more dependencies. WHAT YOU DO WHAT YOU ARE TRUSTING ### Reading the map | Row | What to notice | |---|---| | ==**Hold BTC**== | The shortest row. No issuer, token contract or custodian is added. The network still has to work, while most of the user-specific responsibility sits with your own keys | | **Hold USDC** | Adds two. The contract could have a flaw. The issuer could fail to hold reserves, or freeze your address | | **Use a CEX** | Exchange custody becomes the dominant immediate trust assumption, while the underlying network, token or issuer may still matter depending on the asset being held | | ==**Use a DEX**== | Replaces a central custodian or account gatekeeper with code. You keep custody, but several contracts — including token contracts — now have to behave correctly | | **Lending protocol** | Adds an **oracle**, and this is the row worth dwelling on | | **Use a bridge** | Adds a historically important source of exploit risk: the bridge mechanism between two chains | | **Use an L2** | Keeps the underlying L1 assumption and adds L2-specific machinery: contracts and verification, a sequencer or operator, and upgrade controls | ::: warning Why the oracle row matters most The protocol needs a price to decide whether to liquidate. [Part 3](./part-3-why-ethereum-and-evm.md) explained that contracts cannot see outside the chain, so a price must be *put* on-chain by someone. Corrupt that feed and the contract behaves perfectly while producing a catastrophic outcome. ==**The code can be flawless and the input still wrong.**== ::: ### The useful question For anything you encounter, from now on: ::: important The question to keep asking \==What has to be true, and who has to behave, for me to still have this tomorrow?== Then find the **weakest** item in the answer. Not the scariest-sounding one — the weakest. They are frequently different, and the gap is where people get hurt. ::: ```mermaid flowchart TD A["What am I doing?"] A --> B["List every assumption
network · contracts · issuers
operators · oracles · me"] B --> C["Which is weakest?"] C --> D["What happens if it fails?
total loss · partial · delay · nothing"] D --> E["Is that acceptable
for what I'm getting?"] ``` ::: tip The final box is the whole point \==This is not a method for **avoiding** risk. It is a method for **taking risk deliberately** instead of accidentally.== ::: ::: warning What this is not A **conceptual tool**, not a risk-management course. It does not tell you how much to allocate, how to hedge, or what is safe. And it is not an argument against using anything. Every row describes things people use every day for good reasons. The point is to be able to **name what you accepted**. ::: ## Landscape * **Counterparty risk** — the chance the other party fails to perform. In the CEX row, an exchange can delay withdrawals or fail while holding the assets * **Smart contract risk** — bugs or exploitable logic. Audits reduce risk but do not guarantee safety; a bug can change balances or block withdrawals * **Oracle risk** — bad or manipulated external data. A contract that trusts the wrong price can lend, liquidate or pay out incorrectly * **Custodial risk** — someone else holding your assets. You gain support and convenience, but depend on that custodian's controls and solvency * **Systemic risk** — one failure cascading because protocols build on one another. A broken collateral asset can make other applications fail too * **Composability** — protocols plugging into each other freely. This makes new applications possible, but one failure can spread through connected contracts * **Governance risk** — the rules being changed by whoever controls governance. A vote or admin key may change permissions, fees or upgrade code * **Key management risk** — you losing your keys. **The most common loss of all**, because there may be no separate support desk that can restore access ## Worked example Someone deposits USDC into a lending protocol on an L2, having bridged from Ethereum. An entirely ordinary thing to do. Here is the full stack. | Layer | Trusting | If it fails | |---|---|---| | Ethereum | The L1 | Total loss of the dependent position if the L1 fails | | The bridge | Its attestation mechanism | **Total loss** | | The L2 | Its proof system, its sequencer today | Delay, or censorship | | USDC contract | The code | Total loss of that token | | Circle | Reserves, redemption, and token-level controls | Depegging, or a frozen address | | Lending contracts | The code | Total loss of the deposit | | The oracle | Honest, timely prices | **Wrongful liquidation** | | Liquidation model | Sound economic design | Bad debt, partial loss | | Their own keys | Themselves | Total loss of everything | \==**Nine assumptions. For one deposit.**== Now the two questions that matter: | Question | Answer | |---|---| | Which is **weakest**? | Almost certainly the bridge, on the historical record — with the oracle close behind, because oracle failures can produce losses even when the contract behaves as written | | Which is most likely to **actually get them**? | **Their own keys.** By a wide margin | ::: important The most sophisticated row is not the one that gets most people Lost keys, phishing and careless approvals are common sources of loss alongside protocol exploits. Which brings the week back to [Week 0 Part 4](../../getting-started/safety.md). **The basics are the basics because they are what actually happens.** ::: ::: details Further exploration — optional, not assessed * [L2BEAT](https://l2beat.com/) — this exact analysis, done professionally, for every L2. Read one and compare it to your own attempt * [ethereum.org — Oracles](https://ethereum.org/developers/docs/oracles/) — the oracle problem, which Week 3 returns to * Pick any protocol you have heard of and build its map before Week 3. Fifteen minutes, and the single most transferable skill in this handbook ::: ::: details Sources and attribution * [ethereum.org — Security](https://ethereum.org/security/) — Reuse (CC BY 4.0), adapted * [ethereum.org — Bridges](https://ethereum.org/developers/docs/bridges/) — Reuse (CC BY 4.0), adapted * [ethereum.org — Oracles](https://ethereum.org/developers/docs/oracles/) — Reuse (CC BY 4.0), adapted * [L2BEAT](https://l2beat.com/) — Link, referenced only :::