Trust Assumptions in Bridges: Validators, Oracles, and Relayers Explained

Every time you move crypto from one chain to another, you are making a blind bet. You are betting that the mechanism connecting those two independent worlds won't steal your money, lose it, or simply freeze it forever. In the world of blockchain interoperability, this mechanism is called a bridge, and its safety depends entirely on who-or what-you have to trust.

We often hear the word "trustless" thrown around in crypto marketing. But as of 2026, experts agree on one hard truth: no practical bridge is entirely free of trust assumptions. Independent blockchains don't share a common authority. To connect them, we need intermediaries. These intermediaries come in three main flavors: validators, oracles, and relayers. Understanding how each of these roles works-and where the trust actually lies-is the only way to keep your assets safe.

The Core Problem: Why We Need Trust Assumptions

Imagine two countries with different currencies and no shared banking system. If you want to send money from Country A to Country B, you need a courier or a bank that both sides accept. In blockchain terms, Chain A and Chain B have separate ledgers. They don't talk to each other natively. A bridge acts as that translator.

Academic surveys classify bridge verification into four main methods: external, optimistic, local, and native. Each method shifts the burden of trust differently. The core issue is atomicity-the guarantee that if something happens on Chain A, it will definitely happen on Chain B, and vice versa. Without a trusted coordinator or a cryptographic proof that both chains can verify independently, this guarantee doesn't exist.

When you use a bridge, you are effectively choosing which actors you rely on for safety. Are you trusting a small group of people (validators)? A decentralized network feeding data (oracles)? Or just a messenger carrying a package (relayer)? Let's break down each role.

Validators: The Gatekeepers of Truth

External Validator Sets are groups of entities responsible for confirming that an event occurred on the source chain before authorizing the corresponding action on the destination chain. Think of them as a committee of auditors.

In many older or simpler bridge designs, this takes the form of a multisignature wallet (multisig). For example, a 5-of-9 multisig means five out of nine designated validators must sign off on a transaction for it to go through. On the surface, this looks secure. But history has shown us that "decentralized" labels can be misleading.

The Ronin Bridge hack in March 2022 is a textbook case of validator trust failure. The bridge used a 5-of-9 multisig setup. However, four of the validators were operated by Sky Mavis, one by the Axie DAO, and four by external partners. Due to a temporary delegation arrangement that was never revoked, Sky Mavis effectively controlled five of the nine keys. Attackers compromised those specific keys and drained roughly $625 million. The lesson? If a single entity controls the quorum required to validate transactions, the bridge is functionally centralized, regardless of how many signatures are technically required.

Newer models try to solve this by using Proof-of-Stake (PoS) networks. Axelar is a Cosmos-SDK based PoS chain that uses a large set of validators (75 as of mid-2026) to secure cross-chain messages. Instead of a small multisig, Axelar requires a 90% threshold of validators to cooperate to forge a state proof. This makes collusion economically expensive and difficult. Validators use Distributed Key Generation (DKG) so no single validator holds a full signing key. While more robust than a simple multisig, it still relies on the honesty and operational security of that validator set.

Oracles: Feeding Data Across Chains

If validators are the auditors, oracles are the messengers bringing verified data from outside the chain. In bridge architecture, oracles attest to events on the source chain and deliver signed messages or state digests to the destination chain.

Oracle-style bridges shift trust off-chain. Instead of verifying the entire state of the source chain, the destination chain trusts the oracle's report that "Event X happened." This reduces gas costs and complexity but introduces new risks. If the oracle is corrupted, manipulated, or goes offline, the bridge breaks or becomes vulnerable.

A prominent example is LayerZero, introduced in 2021 as an omnichain interoperability protocol. LayerZero’s security model explicitly splits duties between an Oracle and a Relayer. The Oracle reads the block header from the source chain, while the Relayer fetches the transaction proof. Both are required for the message to be accepted-a "2-of-2" style assumption. The theory is that neither party alone can forge a message. However, critics point out that if the same entity operates both the Oracle and the Relayer, or if they collude, the trust assumption collapses back to a single point of failure. Users must treat the independence of these two components as a critical security factor.

Another approach is the Optimistic Oracle, used by bridges like Across. Here, claims about cross-chain state are assumed correct unless disputed within a challenge window (usually 30 minutes to 7 days). This relies on at least one honest watcher being online to catch fraud. It’s similar to how Optimistic Rollups work on Ethereum. As of mid-2026, Across has processed over $5 billion in volume with no major exploits, showing that optimistic models can be viable if economic incentives for watchers are strong enough.

Relayers: Transporters vs. Trusted Actors

Relayers are the processes that physically submit cross-chain messages or proofs from one chain to another. Their role varies dramatically depending on the bridge design.

In the best-case scenario, relayers are untrusted transporters. This is the model used by Cosmos IBC (Inter-Blockchain Communication), a light-client protocol specified since 2019. In IBC, relayers carry no special trust. Each chain independently verifies everything a relayer submits using its on-chain light client of the counterparty. A malicious relayer can delay or censor messages, but they cannot forge them. The trust assumption here reduces to the honest-majority assumption of each base chain’s validator set, not the relayer itself. This is considered one of the safest architectures because it minimizes the attack surface.

In contrast, many externally verified bridges blur the line between relayer and validator. In these systems, the relayer network might also sign attestations about events. If these relayers fail or collude, safety is compromised. For instance, in Wormhole’s design, guardians (validators) sign Verified Action Approvals (VAAs), and relayers help route these. The 2022 Wormhole exploit wasn't a validator key theft; it was a contract bug that allowed an attacker to bypass the signature check. This highlights that even if validators are honest, the code processing their proofs must be flawless.

Comparing the Trust Models

So, which model should you trust? There is no perfect answer, only trade-offs between security, cost, and speed.

• External Validator/Multisig Bridges: Fast and cheap, but high risk. You trust a small committee. If their keys are stolen or they collude, you lose everything. Best for low-value transfers or testing.
• Oracle-Based Bridges (e.g., LayerZero): Flexible and widely compatible, but complex trust assumptions. You trust the independence and integrity of the oracle and relayer networks. Risk increases if these roles are centralized.
• Optimistic Bridges (e.g., Across): Good balance of security and usability. You trust that at least one honest watcher exists during the challenge window. Suitable for frequent, medium-to-high value transfers.
• Native Light-Client Bridges (e.g., IBC): Most secure. You trust the underlying blockchain consensus. However, they can be slower and more expensive due to higher gas costs for verifying proofs. Ideal for high-value institutional flows.

As of 2026, the industry is shifting away from simple multisigs toward PoS-secured networks and native light-client verification. Enterprise users increasingly prefer IBC-style connections because they avoid adding a new third-party trust domain. Meanwhile, developers building on Ethereum L2s are exploring ZK-proof-based bridges, which promise to reduce trust to the mathematical soundness of cryptographic proofs rather than human honesty.

Practical Tips for Users and Developers

If you are moving significant funds, do not just click "Bridge" without checking the backend. Ask these questions:

1. Who validates the message? Is it a small multisig, a large PoS network, or the base chain itself?
2. How is verification performed? Are there cryptographic proofs (light clients/ZK) or just signed attestations?
3. What is the cost of corruption? Would it take stealing a few private keys, bribing a small group, or attacking the entire base chain consensus?

For developers, design relayers as untrusted transporters whenever possible. Use Merkle proofs and replay-protected operations so that relayers cannot alter state. If you use oracles, treat them as first-class security infrastructure-require decentralization and transparent incident response procedures. And always remember: deprecated code paths in verification logic are potential backdoors. Remove them, don't just ignore them.