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

Imagine handing over your life savings to a courier who promises to deliver it across town. You don’t know if the courier is honest, if they’ll get lost, or if someone will rob them on the way. In blockchain interoperability, this is exactly what happens when you use a cross-chain bridge. These mechanisms move assets between independent ledgers, but every design embeds specific trust assumptions about who verifies the state and under what conditions things can go wrong.

No bridge is entirely trust-free because independent blockchains lack a common enforcement authority. Instead, users must rely on validators, oracles, and relayers. Understanding these roles isn't just academic; it’s the difference between keeping your funds safe and losing them to a hack. Let’s break down how these components work and where the real risks lie.

The Core Problem: Why Trust Matters in Bridges

When you move assets from Ethereum to Solana, for example, the bridge doesn’t physically teleport coins. It locks your asset on the source chain and mints a wrapped version on the destination chain. This process requires verification that the lock actually happened. Academic surveys since 2023 classify bridge verification into four main methods: external, optimistic, local, and native. Each method shifts the burden of trust to different actors.

In 2026, the industry distinguishes between centralized trust (a single custodian), distributed trust (multiple validators), and trust-minimized systems (cryptographic proofs). The key insight? Fully trustless cross-chain communication is impossible without extra assumptions. Independent ledgers cannot enforce atomicity without some trusted coordinator or economic assumption. So, the question isn’t whether you have to trust something, but what exactly you are trusting.

Validators: The Gatekeepers of Cross-Chain State

Validators are often the first line of defense in bridge designs. They observe events on one chain and sign messages to confirm those events occurred. However, not all validator sets are created equal.

External Validator Sets and Multisigs

Many early bridges relied on external validator sets-multisig groups or committees separate from the chains themselves. Users had to trust that a threshold of these validators remained honest and that their keys weren’t compromised. Take Wormhole, which secures messages with a guardian network of 19 validators. On Solana, 13 out of 19 guardians must sign for a message to be accepted. In February 2022, an attacker exploited a deprecated instruction to bypass this check, minting $320 million worth of wETH without compromising any guardian keys directly. The lesson? Any function processing "pre-verified" proofs is part of the trusted boundary.

Then there’s the Ronin Bridge incident in March 2022. Ronin used a 5-of-9 multisignature quorum. Sounds decentralized, right? But Sky Mavis operated four validators, Axie DAO one, and external partners four. A temporary arrangement gave Sky Mavis control over five keys. Attackers compromised those five keys and drained $625 million. This showed that a 5-of-9 multisig is effectively a 1-of-1 multisig if one organization controls the quorum.

PoS-Secured Validator Networks

Newer systems like Axelar try to fix this by using dedicated Proof-of-Stake (PoS) chains. Axelar runs a PoS validator set (75 validators as of May 2026) that observes connected chains and signs cross-chain messages. It uses a safety threshold of 90%, meaning almost all validators must cooperate to forge a proof. Validators use distributed key generation so no single entity holds a full signing key. While this moves trust from a small multisig to a larger bonded set, security still depends on the honesty of the supermajority and the robustness of slashing mechanisms.

Oracles: Shifting Trust Off-Chain

Oracle-style bridges replace chain-specific validators with off-chain networks that attest to events. This shifts trust away from the blockchain itself to external infrastructure.

LayerZero’s Oracle-Relayer Model

LayerZero, introduced in 2021, centers its security on two off-chain components: an Oracle and a Relayer. The Oracle reads block headers from the source chain, while the Relayer submits transaction proofs to the destination. The destination endpoint verifies both. Officially, this is a "2-of-2" security model-if either component is compromised, the message fails. Applications can choose their Oracle (like Chainlink) and Relayer independently.

However, critics argue that if the same entity operates both the Oracle and the Relayer, the trust assumption collapses to a single point of failure. Despite being marketed as "trustless," LayerZero’s architecture effectively acts as a 2-of-2 multisig between two off-chain services. If they collude, the bridge is vulnerable.

Optimistic Oracles

Bridges like Across use optimistic oracles such as UMA. Claims about cross-chain state are assumed correct unless disputed within a challenge window (usually 30 minutes to 7 days). Across has processed over $5 billion in lifetime volume with no major exploits as of mid-2026. But this model relies on at least one honest watcher remaining online during the challenge window. If everyone goes offline, fraudulent claims pass unchallenged.

Relayers: Transporters or Trusted Actors?

Relayers physically submit messages from one chain to another. Their role varies dramatically depending on the bridge design.

In Cosmos IBC (Inter-Blockchain Communication), relayers carry no special trust. They are permissionless and merely transport packets. Each chain independently verifies everything using its on-chain light client. A malicious relayer can only delay or censor messages, not forge them. The trust assumption here reduces to the honest-majority assumption of each chain’s validator set, not the relayer’s behavior.

Contrast this with externally verified bridges where relayers also act as validators. Here, the line blurs. If the relayer network signs attestations, their failure or collusion directly compromises safety. Best practice suggests designing relayers as untrusted transporters whenever possible, ensuring any message they submit is fully verified on-chain.

How to Evaluate Bridge Safety in 2026

With billions lost to bridge hacks, knowing how to assess risk is crucial. Here are practical steps based on current expert frameworks:

• Prefer Native Light-Client Bridges: For high-value transfers, use bridges like IBC that inherit security from the underlying chains. Their trust assumptions are limited to the honest-majority of the base chains and cryptographic proof validity.
• Scrutinize Validator Diversity: If using external validator bridges, check who owns the keys. Avoid bridges where one organization controls a quorum, as seen in Ronin. Look for on-chain slashing and diverse ownership.
• Treat Oracles as Critical Infrastructure: In oracle-based designs, ensure the oracle network is decentralized and economically secured. Check if the Oracle and Relayer are operated by independent entities.
• Understand Challenge Windows: For optimistic bridges, know how long the dispute period is and who monitors it. Safety depends on active watchfulness.
• Check Contract Code: Bugs in signature verification or proof routing can bypass even strong trust assumptions. Wormhole’s hack wasn’t about bad validators; it was a contract bug allowing spoofed inputs.

The trend in 2024-2026 is moving away from simple multisigs toward PoS-secured networks, optimistic oracles, and native light-client verification. Enterprise solutions increasingly favor IBC-style models because they avoid adding new third-party trust domains. Meanwhile, hybrid systems combining light clients with Zero-Knowledge (ZK) proofs aim to reduce gas costs while maintaining trust minimization.

Frequently Asked Questions