Trust Assumption
A trust assumption defines what entities or conditions must remain honest for a protocol's security guarantees to hold.
Key Takeaways
- A trust assumption is the set of conditions a protocol requires to remain secure: if those conditions are violated, the system's guarantees break down. Common examples include honest-majority assumptions in proof-of-work and proof-of-stake, and 1-of-N honesty in trusted setup ceremonies.
- No blockchain system is truly assumption-free: trustless means minimizing trust, not eliminating it. Every protocol relies on at least cryptographic hardness, network connectivity, or rational economic behavior from participants.
- Trust assumptions compound across layers and bridges: when a system depends on multiple protocols (an L2 plus a cross-chain bridge, for example), the combined security is only as strong as the weakest assumption in the stack.
What Is a Trust Assumption?
A trust assumption defines what entities, behaviors, or environmental conditions must hold true for a protocol's security guarantees to remain valid. In blockchain systems, these guarantees typically cover safety (the system never produces an invalid result) and liveness (the system continues to make progress). If the stated trust assumptions are violated, the protocol may fail, produce incorrect outputs, or allow funds to be stolen.
Every distributed system carries trust assumptions, even those described as trustless. Bitcoin's proof-of-work consensus assumes that no single entity controls more than 50% of the network's hash power. Ethereum's proof-of-stake assumes that two-thirds of validators follow the protocol honestly. A sidechain might assume that a majority of federation members are honest. These assumptions exist on a spectrum: systems with fewer and weaker assumptions are said to be more trust-minimized.
Understanding trust assumptions is essential for evaluating any protocol's actual security rather than its marketing claims. A system advertised as "decentralized" may still rely on a single sequencer for liveness, and one described as "trustless" may depend on the honesty of a small committee.
How It Works
Trust assumptions operate at every layer of a blockchain stack: consensus, execution, data availability, and bridging. Each layer introduces its own set of conditions that must hold for the overall system to function correctly.
Common Trust Assumption Categories
The following categories cover the most widely encountered trust assumptions in blockchain protocols:
| Category | Assumption | Example Systems |
|---|---|---|
| Honest majority | More than half (or two-thirds) of participants follow the protocol rules | Bitcoin PoW, Ethereum PoS, most consensus mechanisms |
| Economic rationality | Participants act in their financial self-interest and will not attack if the cost exceeds the reward | MEV game theory, slashing penalties, fee markets |
| Trusted setup (1-of-N) | At least one participant in a setup ceremony behaved honestly and destroyed their secret | Groth16 ZK-SNARKs, powers-of-tau ceremonies |
| Federation honesty | A threshold (e.g. 11-of-15) of known signers will not collude to steal funds | Liquid Network, Fedimint |
| Sequencer liveness | The sequencer continues to order and publish transactions | Optimistic rollups, ZK rollups, most L2s with centralized sequencers |
| Data availability | Transaction data is published and accessible so that anyone can verify state transitions | DA layers, rollups, validiums |
| Cryptographic hardness | The underlying math problems (discrete log, hash preimage) remain computationally infeasible to break | All blockchain systems, elliptic curve cryptography |
Honest-Majority Assumptions
The honest-majority assumption is the most fundamental in blockchain consensus. In Bitcoin's PoW, safety holds as long as no entity controls more than 50% of hash power: a 51% attack could allow double-spending or chain reorganization. In PoS systems like Ethereum, the threshold is typically two-thirds of staked value for Byzantine fault tolerance.
Some systems weaken this to an honest-minority or 1-of-N assumption. Optimistic rollups, for instance, require only one honest full node to monitor the rollup and submit fraud proofs within the challenge period. This is significantly weaker than requiring a majority: the system remains safe as long as a single watcher is functioning.
Trusted Setups
Certain zero-knowledge proof systems, particularly those using Groth16, require a one-time ceremony to generate public parameters. During this ceremony, secret randomness (sometimes called "toxic waste") is created and must be destroyed. If any single participant in the ceremony honestly destroys their share, the setup is secure.
The Ethereum Foundation's Perpetual Powers of Tau ceremony, running since 2019, applies this 1-of-N model: security holds as long as at least one contributor out of all participants was honest. If no one destroyed their secret, an attacker could forge proofs and compromise every system built on that ceremony's output.
Not all ZK systems require trusted setups. ZK-STARKs use transparent setup procedures with no toxic waste, trading larger proof sizes for the elimination of this trust assumption entirely.
Federation and Operator Trust
Federated systems delegate custody or signing authority to a fixed set of known entities. The Liquid Network uses an 11-of-15 federation of functionaries: users trust that fewer than 5 functionaries will collude to steal funds. There is no unilateral exit mechanism, so if the federation fails, user funds are at risk.
Statechain-based systems like Spark use a different model. The statechain entity consists of multiple operators that collectively hold one share of a 2-of-2 key using FROST threshold signatures. As long as at least one operator is honest and properly deletes old key shares during transfers, user funds remain safe. Users also retain the ability to exit unilaterally to the Bitcoin base layer using pre-signed transactions, providing a fallback independent of operator cooperation.
Trust Assumption Compounding
When multiple protocols are composed together, their trust assumptions stack. A user interacting with a DeFi protocol on a rollup that uses a cross-chain bridge inherits the assumptions of the smart contract, the rollup's sequencer and data availability layer, and the bridge's verification mechanism. The combined security is bounded by the weakest link in the chain.
Consider a concrete example: a stablecoin bridged from Ethereum to an optimistic rollup and then deposited into a lending protocol. The user now depends on:
- Ethereum's PoS consensus (two-thirds honest validators)
- The rollup's sequencer (liveness) and at least one honest fraud proof submitter (safety)
- The bridge's verification mechanism (multisig committee, light client, or relayer set)
- The lending protocol's smart contract correctness and oracle accuracy
A failure at any single layer compromises the entire stack. Historically, bridge assumptions have been the most commonly exploited: multisig key compromise has been the single largest attack vector for cross-chain bridge losses. This is why bridge security models are critical to evaluate before moving assets across chains.
Bitcoin L2 Trust Spectrum
Bitcoin's Layer 2 solutions span a wide range of trust models. Understanding where each system falls on the spectrum helps users and developers choose the right tradeoffs for their use case. For a deeper comparison, see the research article on Bitcoin L2 trust model comparison.
| L2 Type | Trust Assumptions | Unilateral Exit |
|---|---|---|
| Lightning | Counterparty (2-of-2 channel), watchtower or self-monitoring for fraud | Yes (force close) |
| Spark (statechains) | 1-of-N operator honesty for key deletion, threshold signing via FROST | Yes (pre-signed exit transactions) |
| Sidechains (e.g. Liquid) | Federation threshold (e.g. 11-of-15 honest functionaries) | No (federation-controlled peg-out) |
| Rollups | Sequencer liveness, data availability, 1-of-N honest verifier (optimistic) or validity proof correctness (ZK) | Yes (via L1 escape hatch, subject to challenge/proof delay) |
Lightning Network
Lightning is often described as the most trust-minimized Bitcoin L2. Each payment channel is a 2-of-2 multisig between counterparties, and either party can close the channel on-chain at any time. The primary trust assumption is that the user (or a delegated watchtower) monitors the blockchain for fraudulent channel closures and can broadcast a justice transaction before the timelock expires.
Spark (Statechain Model)
Spark uses a statechain entity composed of multiple operators sharing key shares via FROST. The trust assumption is 1-of-N: as long as at least one operator honestly deletes old key material during a transfer, the previous owner cannot reclaim funds. If all operators go offline, users can still exit to the Bitcoin base layer through pre-signed transactions. For a comprehensive overview, see What Is Spark? and the rollups vs state channels vs statechains comparison.
Sidechains
Federated sidechains like the Liquid Network rely on a fixed set of functionaries to process peg-ins and peg-outs. Liquid's 11-of-15 threshold means that if 5 or more functionaries collude or are compromised, they could steal pegged funds. There is no on-chain escape hatch: users depend entirely on the federation for withdrawals.
Bitcoin Rollups
Bitcoin rollups are at an early stage compared to Ethereum rollups. Optimistic rollups require at least one honest verifier to submit fraud proofs within a defined window. ZK rollups rely on the correctness of validity proofs and, in some cases, a trusted setup. Both types currently depend on centralized sequencers for liveness, though sequencer decentralization efforts are underway.
Use Cases
Understanding trust assumptions is not just theoretical: it directly affects protocol selection, security auditing, and risk management.
- Protocol evaluation: before committing funds to a Layer 2, bridge, or DeFi protocol, users should identify every trust assumption in the stack and assess the likelihood of each being violated
- Security auditing: auditors examine whether a protocol's stated trust model matches its actual implementation, checking for hidden assumptions like reliance on a single admin key or a centralized upgrade mechanism
- Architecture design: developers choose between trust models based on their use case: a high-value custody system might require trust-minimized architecture, while a low-value micropayment system might accept federation trust for better UX
- Risk disclosure: protocols should clearly communicate their trust assumptions to users rather than hiding behind labels like "decentralized" or "trustless"
Risks and Considerations
Hidden Assumptions
Many protocols carry trust assumptions that are not immediately obvious. A rollup may be "trust-minimized" in theory, but if its sequencer has an admin key that can censor transactions or if its upgrade mechanism bypasses the challenge period, the effective trust model is weaker than advertised. Projects like L2Beat systematically catalog these gaps for Ethereum rollups, classifying them by maturity stages.
Assumption Violation Is Not Hypothetical
Multiple high-profile exploits have resulted from violated trust assumptions. The collapse of the Terra/UST ecosystem in 2022 demonstrated that economic rationality assumptions in algorithmic stablecoins can fail under extreme market stress. Bridge exploits such as the Ronin hack (compromised validator keys) and the Multichain incident (single-device MPC key storage) showed that federation and multisig assumptions fail when key management is centralized.
Liveness vs Safety Tradeoffs
Safety and liveness often require different trust thresholds. A system might guarantee safety with a 1-of-N honest assumption (one watcher submitting fraud proofs) while requiring an honest majority for liveness (the sequencer set continuing to produce blocks). When evaluating protocols, it is important to distinguish which properties hold under which conditions.
Upgradeability and Governance Risk
A protocol's trust assumptions can change over time through upgrades. A system that launches with strong trust minimization can weaken its model through a governance vote or admin key action. Evaluating trust assumptions is not a one-time exercise: ongoing monitoring of protocol governance and upgrade patterns is essential.
This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.