# Trust Assumptions The question this note answers: what, exactly, am I trusting? "Trustless" makes for good marketing, but every system trusts something. The useful engineering habit isn't to reject the word — it's to always name what's being trusted, and then decide whether removing that trust is worth what it costs. ## The spectrum Roughly, from least trust required to most: | **You verify...** | **You trust...** | **Example** | |---|---|---| | Everything yourself | Math and your own node | Running a **full node** | | Proofs against headers | Consensus honesty | **Light client** | | A validity proof | The proof system's soundness (+ often a DA path) | **ZK rollup** / **ZK bridge** | | That fraud would be challenged | At least one honest watcher | Optimistic rollup | | That a sequencer ordered fairly (or can be escaped) | The sequencer's behavior until forced inclusion / exit | L2 **sequencer** | | A published feed's integrity | Oracle operators + aggregation design | **Oracle** | | That an index matches the chain | Indexer correctness and reorg handling | **Indexer** / subgraph | | A committee's signatures | m-of-n named parties | **Multisig bridge**, validium | | A server's response | One company | **RPC** user, **CEX** | Each step down the table is cheaper and faster than the one above it. Each step down is also a new way to be lied to. Most real products sit several rows down from "full node" while marketing language stays at the top. The interesting design work is choosing the row deliberately rather than by accident — and saying so to the user. ## The reflex When you meet any new system, run the eight questions: ```text Who orders transactions? Who verifies execution? Who stores data? Who can censor? Who can reorder? Who can upgrade? Who has admin keys? What happens during partial failure? ``` The answers *are* the trust assumptions. Throughput, fees, UX — all real, all negotiable, all layered on top of those answers. Two observations that clear up a surprising amount of confusion: - Calling an RPC provider is not verifying the chain. If your app trusts a third-party RPC, that provider can lie, censor, lag, or fail. More in [[08 Nodes, RPCs, and Indexers]]. - A bridge is, at bottom, a statement about which chain's [[Finality]] another chain is willing to believe. More in [[10 Bridges and Interoperability]]. ## Where this matters Everywhere, honestly — but concentrated in: - [[08 Nodes, RPCs, and Indexers]] — the RPC trust boundary - [[09 Scaling - Rollups and Data Availability]] — every scaling design is a trust trade - [[10 Bridges and Interoperability]] — trust assumptions compound across chains - [[12 Security and Incentive Design]] — attacks live in the gap between assumed and actual