Keep Bridge Relays Out of Consensus

1 rule keeps a bridge relay out of consensus: it may carry evidence between chains, but it must not decide what either chain accepted. That rule measures the boundary between message delivery and agreement on the chain’s state. Keep that boundary clear, and a relay outage or compromise does not automatically become a consensus failure.

A relay, often called a relayer, watches one chain for a bridge event and submits information about it to another chain. The destination contract then decides whether that information meets the bridge’s rules. For a Polygon Bridge transfer, the details of the checks matter; this guide to checks before moving tokens through Polygon Bridge covers them in more depth.

What does a bridge relay do?

A relay transports claims; it does not make them true. It can read a source-chain event, wait for the required confirmation or finality, and send a proof or signed message to the destination. The destination verifies that submission according to the bridge design.

That verification step is the security boundary. If the destination checks a cryptographic proof against a trusted source-chain commitment, a relay can be replaced or run by several independent operators without giving them authority to invent valid events. If the destination instead accepts signatures from a bridge committee, the committee’s threshold and key management become part of the trust model.

How is relay work different from consensus?

Consensus is how a chain’s participants agree on its canonical blocks and state. A relay reports what it observed on one chain to another system; it should not control which blocks the source chain finalizes or what the destination chain accepts as its own state.

The distinction can blur when a bridge uses its own validators or signers. Those participants may agree on cross-chain messages, but that is bridge-level authorization, not the source or destination chain’s consensus. A design should say plainly which evidence is checked on-chain and which operators must be trusted.

For a user or developer evaluating a bridge, look for these separate roles:

• Chain consensus: decides which blocks and state are canonical on each network.
• Relay software: observes events and submits proofs or messages.
• Bridge verification: checks proofs, signatures, thresholds, and any delay rules.
• Destination contract: releases, mints, or records assets only after verification succeeds.

How can a bridge keep the roles separate?

Make relay operators replaceable. Give their software read access to chain data and permission to submit bridge transactions, but do not give it validator keys or a way to bypass the destination contract’s verification. Independent relays can improve availability, but they do not improve security if every relay relies on the same unverified data source.

Then check what the destination verifies. A proof-based bridge shifts trust toward the proof system and the contract’s verification logic; a signature-based bridge depends on the signer set, its threshold, and how keys are secured. Neither approach removes trade-offs: stronger independent verification can add complexity, while simpler attestations require more trust in bridge operators.

For most users, the practical question is not how many relays a bridge advertises. It is whether the destination independently checks evidence of a finalized source event, or relies on a small set of parties to attest that it happened. A relay should move that evidence; consensus and verification should determine what it means.