Bridge trust assumptions

A chain can verify its own history and nothing else. It has no way to observe that a deposit occurred somewhere it cannot see.

So a bridge is a mechanism for convincing one chain that something happened on another. Value is locked or burned on the source side, a claim about that event travels, and the destination side releases or mints against the claim. Every design is a different answer to one question: what would convince the destination that the claim is true.

In plain terms: the funds are not protected by the contract holding them. They are protected by whatever decides which messages that contract will believe.

That is why the aggregate losses here exceed every other category, and why so few of them were contract bugs. The contracts mostly did what they were told. The problem was who got to tell them.

External validators. A set of parties watches the source chain and signs attestations; the destination accepts a message carrying enough signatures. Simple, fast, and the assumption is explicit: the signer set does not collude and is not compromised. Most large losses have occurred under this model, and usually by acquiring signing power rather than by breaking anything.

Light clients. The destination verifies a proof of the source chain consensus directly, so correctness depends on cryptography and on the source chain security rather than on a committee. Strong, expensive to build, expensive to run, and fragile at the edges: a chain that changes its consensus or finality rules can break a client that was correct yesterday.

Optimistic verification. Messages are accepted by default and may be challenged during a window. The assumption is that at least one honest party is watching and able to submit a challenge in time. That party has to exist, have an incentive, and be able to get a transaction included during congestion.

Liquidity networks. Nothing is minted; a party on the destination side fronts the asset and settles later. This changes the failure mode from a minting exploit to a solvency and settlement question, which is a genuinely different risk rather than a smaller one.

In plain terms: there is no trustless bridge. There are bridges whose assumptions are cryptographic and bridges whose assumptions are about people, and both are assumptions.

Message verification is the first and worst. If the destination accepts a message without correctly checking the proof behind it, an attacker writes their own message. Real incidents have come from a verification routine that skipped a check, accepted an empty proof set as valid, or validated the wrong field of a structure.

Replay is the second. A valid message accepted twice mints twice. Preventing it requires a nonce or a commitment that is recorded and checked on the destination, and recorded in a way that survives an upgrade.

Signer-set compromise is the third, and the one behind the largest individual losses. The threshold was reached by an attacker who obtained keys rather than by anyone defeating the protocol. Which makes the real question not whether the scheme is sound but how many independent parties would have to be compromised, and whether they are independent in practice.

Rotation is where that quietly degrades. A signer set that changes needs a rule for how changes are authorised and what happens to messages in flight across the change. Rotation logic is reviewed less often than the verification it protects.

And emergency powers are the fourth. Someone can usually pause a side. That capability is necessary and it is also a privileged role with all the properties of one: it can be used against you, and pausing one side of a bridge while the other keeps operating strands value in transit.

A bridge is reviewed properly only when both ends are in scope, and frequently only one is.

The source side burns or locks. The destination side mints or releases. Each is correct on its own terms, and the agreement between them is where the risk lives. A review of the destination contract can confirm it checks signatures correctly without ever establishing that the thing being signed means what the source side believes it means.

The same gap appears across teams. The chain is one team, the bridge is another, the application on top is a third, and each assumes a neighbour validates something. In plain terms: when a scope covers one side of a bridge, the report is describing half an agreement, and the half it omits is the half that has to agree with it.

In the common design, an asset is locked on the source chain and a representation is minted on the destination. That representation is a claim on the locked pool, and its value depends entirely on the pool remaining intact and the redemption path remaining open.

Two consequences follow. The locked pool is a single concentrated target holding the full backing for everything minted, which is why bridge contracts are among the largest standing balances in the industry. And if the bridge halts, the wrapped asset does not become worthless so much as become unredeemable, which markets price somewhere between the two.

Any protocol accepting a wrapped asset as collateral has inherited the bridge trust model whether or not anyone wrote that down. In plain terms: the collateral is only as sound as the mechanism that issued it, and that mechanism is usually operated by people the protocol has no relationship with.

Bridges halt. Operators pause them, validators go offline, a source chain reorganises deeper than expected, or a destination chain upgrades. Designing for the stopped state is as much the work as designing for the moving one.

The questions are concrete. What happens to a message that was in flight? Is there a path to recover funds locked on the source side if the destination never completes, and who can trigger it? If one side is paused and the other is not, what accumulates? And if the operator disappears permanently, is anything recoverable at all, or is the design dependent on their continued participation?

In plain terms: a bridge that works is easy to evaluate. A bridge that has stopped is where the design is revealed.

Six questions, whether you operate a bridge or merely depend on one.

What convinces the destination chain that the source event occurred, precisely?

If that is a signer set, how many independent parties would have to be compromised, and are they independent in practice rather than on paper?

What prevents the same message being processed twice, and does that record survive an upgrade?

Who can pause which side, and what is stranded while one side is paused?

How does the signer set rotate, who authorises a rotation, and what happens to messages in flight during one?

If we accept a wrapped asset anywhere, whose bridge is it, and have we evaluated their trust model as carefully as our own code?