Trust Assumption

Users trust the exchange operator with the custody of their assets and the integrity of its internal ledger. This includes assumptions that:

• The exchange is not insolvent and holds 1:1 reserves.
• Its internal security (e.g., hot wallets) is not compromised.
• It will honor withdrawal requests and not engage in fractional reserve banking.

Example: Depositing Bitcoin on Binance or Coinbase.

In a Proof-of-Stake (PoS) network, users trust that a supermajority (e.g., 2/3) of the staked capital is controlled by honest validators. This is the economic security assumption. If malicious validators control enough stake, they could finalize invalid blocks in a slashing-resistant attack. The security model shifts from trusting computational work (PoW) to trusting capital holders.

Users trust the key management protocol and the entities controlling the signing shares. For a 2-of-3 multisig, you assume:

• At least two of the three key holders are honest and available.
• The signing ceremony or Multi-Party Computation (MPC) protocol has no cryptographic flaws or backdoors.
• The key storage (HSMs, enclaves) for each party is secure.

Example: Gnosis Safe or institutional custody solutions.

Users trust the bridge's verification mechanism. For a trusted (custodial) bridge, you rely on a multisig committee to hold assets and mint representations. For a lightly validated bridge, you trust a small set of oracles or guardians. The core assumption is that this validator set will not collude to steal the locked funds, a failure mode responsible for major exploits like the Wormhole and Ronin bridge hacks.

Applications trust that the oracle network (e.g., Chainlink) provides accurate, tamper-proof external data. This involves trusting:

• The decentralization and anti-collusion of the node operators.
• The cryptographic proofs of data provenance.
• The security of the data source itself (the "API assumption"). A failure here can lead to incorrect smart contract execution, such as faulty liquidations or price manipulations.

Node operators and users implicitly trust the client software developers (e.g., Geth, Lighthouse teams) and the governance process for upgrades. This includes assumptions that:

• The code is bug-free and contains no malicious logic.
• Protocol upgrades (EIPs) are properly reviewed and tested.
• The core development team acts in the network's best interest. This is a form of social consensus and credible neutrality trust.

A trust assumption is any dependency on an external party or condition that must behave as expected for a system's security to hold. This creates a spectrum of trust:

• Trustless: No reliance on external parties (e.g., Bitcoin's consensus).
• Trust-Minimized: Reliance on a large, decentralized, or economically incentivized set of entities (e.g., Ethereum's validator set).
• Trusted: Reliance on a specific, identifiable party (e.g., a multisig council or oracle).

Trust can be required in several key areas of a protocol:

• Consensus: Trust in validators/miners to follow protocol rules.
• Data Feeds (Oracles): Trust that off-chain data (e.g., price feeds) is accurate and timely.
• Upgradeability: Trust that a multisig council or DAO will not enact malicious upgrades.
• Bridge Validators: Trust that the signers of a cross-chain bridge will not collude to steal funds.
• Client Software: Trust that the node client software is bug-free and maintained.

Introducing trust assumptions is often a deliberate trade-off for scalability or functionality. For example:

• A sidechain may use a smaller validator set (more trust) for higher throughput.
• A bridged asset relies on the security of its origin chain and the bridge's validators.
• An optimistic rollup assumes a honest majority will challenge invalid state transitions during the challenge window. The security model is defined by the weakest trust assumption in the stack.

Security audits must explicitly map and evaluate all trust assumptions. Key questions include:

• Who are the trusted entities? (e.g., a 5-of-9 multisig)
• What is their failure mode? (e.g., collusion, negligence)
• What is the economic cost of failure? (e.g., total value at risk)
• Can the assumption be removed or decentralized over time? Protocols should document these clearly, as a system is only as secure as its most critical trust assumption.

The goal is to architect systems that are trust-minimized. Common techniques include:

• Economic Bonding/Slashing: Requiring trusted parties to post collateral that can be destroyed for misbehavior.
• Decentralization: Distributing trust across a large, permissionless set of participants (e.g., Proof-of-Stake).
• Fraud Proofs & Validity Proofs: Allowing anyone to cryptographically prove malfeasance (Optimistic & ZK Rollups).
• Time Locks & Escape Hatches: Providing users a way to exit a system if trust is broken, often after a delay.

Understanding trust assumptions connects to several key security models:

• Trustless: A system with zero trust assumptions for its core operation.
• Trust Model: The formal specification of all assumptions a system makes.
• Attack Surface: The set of trust assumptions that an adversary can potentially exploit.
• Byzantine Fault Tolerance: The system's resilience to a subset of participants acting maliciously, which directly defines its trust threshold.

The core design goal of reducing reliance on any single trusted third party. This is achieved through cryptographic proofs, economic incentives, and decentralized consensus. Examples include:

• Proof-of-Work: Trust in the majority of honest hash power.
• Proof-of-Stake: Trust in the majority of honest, economically bonded validators.
• Light Clients: Trust in the consensus of the full node network, verified via Merkle proofs.

A one-time ceremony where a set of secret parameters is generated to initialize a cryptographic system, such as a zk-SNARK circuit. The system's ongoing security assumes these initial parameters were created correctly and destroyed, preventing forgery. If compromised, the entire system's security fails. Notable examples are the original Zcash Sprout ceremony and many zk-rollup launch sequences.

A property of a distributed system that allows it to reach consensus correctly even if some participants (Byzantine nodes) act arbitrarily or maliciously. The trust assumption is that no more than a certain fraction (e.g., <1/3 or <1/2) of the validating power is Byzantine. Practical Byzantine Fault Tolerance (pBFT) and its variants underpin many consensus algorithms in permissioned blockchains and modern Proof-of-Stake networks.

A form of finality where a transaction is considered settled because the cost to reverse it (e.g., via a 51% attack) is prohibitively expensive, making it economically irrational. The trust assumption shifts from pure honesty to rational economic actors. This is central to Nakamoto Consensus in Proof-of-Work, where deeper block confirmations increase the economic cost of reorganization.

The ultimate, off-chain layer of agreement among users, developers, and miners/validators on the canonical state of the blockchain. When protocol rules change (a fork), the network assumes trust in this social layer to coordinate. A hard fork (e.g., Ethereum → Ethereum Classic) represents a failure of this consensus, splitting the network based on differing trust assumptions and values.