Bridge Risk: Validator Sets, Multisigs and Replay Attacks

2026-08-12

A bridge does not move anything. It makes a claim on one chain and gets a second chain to act on it, and every bridge failure is that second chain believing a claim it should have refused. So the useful way to sort bridge risk is by trust assumption rather than product name: what does the destination chain believe, and what would it take to make it believe something false. This article works through five structural answers, from external validator sets to upgrade keys.

The question that sorts every bridge

Ethereum's own developer documentation compresses bridge security into a single question: who verifies the system? Fees, speed and the number of connected chains all sit downstream of it.

The mechanics rarely vary. Something happens on the source chain. Some party attests that it happened. A contract on the destination chain checks that attestation against a rule and, if it passes, releases or mints. Everything an attacker wants is on the other side of that rule.

The documentation splits designs into two families. Trusted bridges are externally verified, by a federation with a multisig, a multi-party computation system or an oracle network. Trustless bridges lean on the chains they connect and those chains' own validators, adding no new trust assumption. The first family buys connectivity and speed and pays for it in security: bridges secured by external validators are typically weaker than bridges secured natively by the chains themselves.

The value at stake makes that trade unforgiving. By August 2022 Chainalysis had counted 13 separate cross-chain bridge hacks worth about 2 billion dollars, roughly 69% of everything stolen in crypto that year up to that point. Bridges attract attacks because they concentrate collateral at exactly the spot where one rule gets checked.

That is why the sections below are organised by assumption rather than by incident. Two bridges with different names and the same verification model fail the same way, and knowing the names tells you nothing about the one you are about to use.

External validator sets are a system you did not audit

The most common trusted design puts a set of N parties between the two chains. They watch the source chain, sign an attestation that an event occurred, and the destination contract accepts it if at least M of those signatures verify. The contract holds no other opinion about reality.

The consequence is blunt: whoever controls M keys can mint. Take a set of 9 with a threshold of 5. An attacker holding 5 keys needs no contract bug, no weakness in either chain and no further check. The bridge does exactly what it was built to do while the attacker drains it.

Notice what security you are actually buying. The validator set is its own system, with its own operators, machines and incentives, and it inherits nothing from the chains it connects. A bridge verified by an external set is as strong as that set and no stronger, however large the two networks on either side of it happen to be.

So the questions worth asking are membership questions. Who are the N, and are they disclosed at all? Are they distinct organisations, or one organisation running nine machines? What is M? Do members have anything at stake that can be taken from them if they sign a false message? And who can change the membership, because a set that one key can rewrite is a one-key bridge wearing a committee.

A threshold only counts if the keys fail independently

M-of-N is a claim about independence, not about arithmetic. Five of nine is meaningfully harder than one of one only if those nine keys can fail in nine unrelated ways.

Often they cannot. Keys held inside a single company share a hiring process, a laptop image, a VPN, a cloud key service and one signing interface. If a single phishing message reaches all nine holders, or one cloud account holds five of them, then N is a number on a dashboard and the real N is closer to 1.

Raising the threshold does not repair this, and it costs something. With M set high, losing a few keys leaves the bridge unable to sign at all: nothing is stolen, but nothing moves either, and whoever has assets on the wrong side waits. Every threshold is a choice between too easy to steal and too easy to freeze.

The signing surface deserves as much attention as custody. Signers approve payloads they mostly cannot read, so if the interface shows a friendly summary while the bytes underneath say something else, honest signers produce a valid malicious signature. Blind signing turns an M-of-N committee into an M-of-N rubber stamp, and no threshold protects against that.

Light clients and optimistic verification bet on different things

The trust-minimised designs remove the external set, but they do not remove trust; they relocate it. Two families do most of the work.

Light client verification puts a client of the source chain inside the destination chain. The destination stores the source chain's consensus state and checks that a claimed event is proven against it. In IBC, each side of a connection uses the other chain's light client to verify incoming messages, so the assumption reduces to the source chain's consensus plus the correctness of the client code. IBC's newer version is explicit that a client is simply a verification model, and can equally be a light client, a multisig or a proof verifier. The label is not the assumption; the client type is.

Optimistic verification takes the opposite route: accept the message provisionally, and give anyone a window in which to prove it false. The assumption is that at least one watcher is running, funded, and able to land a challenge transaction before the window closes. A watcher that is offline, out of gas or censored for the length of the window is the same as no watcher at all.

Neither family is free, and the costs are structural rather than accidental. Light clients cost gas and engineering for every chain pair, and a bug in the client is a bug in the rule itself. Optimistic designs connect cheaply but make every honest user sit out a delay chosen by the designer. Ethereum's documentation names both trade-offs directly: connectivity limits for light client bridges, speed for optimistic ones.

Replay is a valid message counted twice

A bridge message is an authorisation. Replay is the attack in which an authorisation that was genuinely issued gets presented again: a second time in the same place, or a first time somewhere it was never meant to apply. Nothing is forged. The same valid bytes are simply reused.

Ethereum's history holds the canonical fix. EIP-155 folds the chain ID into the data that is hashed and signed, so a signature made for one chain does not verify on another. Note how it arrived: the older six-element format stayed valid, which means this protection is something a signer opts into rather than something the format guarantees.

For the structured messages that bridges pass around, EIP-712 defines a domain separator. It can carry a name, a version, the chain ID and the address of the verifying contract, plus a salt as a separator of last resort, and it says a wallet should refuse to sign when the chain ID does not match the chain the user is actually on. Different chain, different contract, different version, different message. That is what domain separation means in practice: putting the destination inside what was signed.

Domain separation still does not stop the same message being delivered twice to the same destination. EIP-712 says so itself: the standard covers signing and does not include replay protection, so applications have to reject the repeat or make the authorised action idempotent. That work belongs to a nonce, a sequence number, or a record of messages already consumed.

IBC shows the finished pattern. Exactly-once delivery is a stated property of the protocol: each packet carries a sequence number, the receiving chain writes a receipt under that sequence, and a packet whose receipt already exists is refused. The specification notes that this is the same sequence-number problem as with signed messages, with the light client in the role of the signer. Verification without deduplication is half a bridge.

Bridge risk sorted by trust assumption: external validator sets, multisig thresholds, light client and optimistic verification, message replay and upgrade keys

Upgrade keys sit above every other assumption

Everything above describes the rule a bridge enforces today. The upgrade key decides who can replace that rule tomorrow.

Most bridge contracts are proxies, and ERC-1967 standardises where a proxy keeps its wiring: one storage slot for the implementation address it delegates to, another for the admin address allowed to change that implementation. One transaction from the admin points the proxy at new code, and new code can define validity however it likes.

This makes the upgrade key a superset of every other risk on this page. A nine-key validator set, a light client, a challenge window: all of them can be replaced by whoever controls the admin slot. The honest ceiling on a bridge's security is the weaker of its verification model and its upgrade path.

The consolation is that this one is checkable. The standard tells you where to look, and asks that changes to those slots emit events: Upgraded when the implementation changes, AdminChanged when the admin does. Read the admin slot. See whether it holds a single externally owned account, a multisig or a timelock, and if a timelock, how long the delay runs and who is allowed to cancel.

Pauses and parameter changes deserve the same reading. The power to halt a bridge or to raise a transfer limit is smaller than the power to rewrite the rules, but it is still a key in someone's hands, and a bridge that can be paused can be paused while your transfer is halfway across.

The bottom line

Bridge risk sorts cleanly once you ask who verifies. An external validator set is a separate system whose threshold is its security budget, and that threshold only holds if the keys behind it can fail independently. Light clients move the assumption onto the source chain's consensus and the correctness of the client code; optimistic designs move it onto one watcher staying alive and unhindered for the whole window. Replay protection is a separate requirement: the destination has to be part of what was signed, and every message needs a sequence or a receipt. Above all of it sits the upgrade key, which replaces the rest in one transaction. Those five answers, and not the brand on the interface, are what you trust when you bridge.

Disclaimer: This article is educational content from Bitbase Academy, provided for information only. It does not constitute investment, trading, tax, or financial advice. Crypto assets are volatile; assess your own risk. Written as of August 2026; refer to the latest official information.