Bridge Architectures and Their Trust Assumptions

A bridge exists to answer a question that is genuinely hard: chain B has no way to observe chain A, so something has to tell it that a deposit occurred. Every design is a different answer to “who attests, and what happens if they lie”.

External validator sets

The most common design. A set of nodes watches chain A, and when enough of them sign an attestation, chain B mints or releases the corresponding assets.

The trust assumption is explicit: a threshold of that validator set is honest and their keys are secure. If an attacker obtains enough keys, they can mint arbitrary assets on chain B without any deposit on chain A, and this is precisely the shape of the largest bridge losses to date.

The relevant questions are how many validators, what threshold, who operates them, and — critically — whether they are genuinely independent. A “decentralised” set of fifteen nodes run from three organisations on one cloud provider is a three-party trust assumption wearing a larger number.

Key management is the recurring failure. Not the signature scheme, not the contract logic: how the keys are stored, who can access them, and whether signing is automated in a way that means compromising one machine compromises the threshold.

Light-client bridges

The strongest design. Chain B runs a light client of chain A — actually verifying chain A’s consensus on chain B — so the trust assumption reduces to the security of chain A itself. No external attesters.

The cost is that verifying another chain’s consensus on chain is computationally expensive, and it must be implemented separately for every pair of chains with different consensus rules. That is why these bridges are less common and typically support fewer routes. Zero-knowledge proofs of consensus are the active area of work here, reducing the on-chain cost substantially.

Worth noting: a light-client bridge still has an upgrade key, and that key can be worth more than the design it protects.

Liquidity networks

Structurally different. Nothing is minted; a liquidity provider on chain B hands you assets they already hold, and settles with their counterpart on chain A separately.

This removes the catastrophic minting risk — there is no contract that can be tricked into creating unbacked assets. The trust assumption moves to the provider and to whatever mechanism guarantees settlement, and the practical constraint is available liquidity on the destination side.

The failure mode is much less severe: a stuck or failed transfer rather than an unbacked mint that destroys the value of every wrapped asset at once.

Optimistic bridges

Borrowing from optimistic rollups: attestations are assumed valid unless challenged within a window. The trust assumption is that at least one honest watcher exists and can submit a challenge in time.

The trade-off is latency — the challenge window is a real delay — and the practical questions are who is actually watching, whether they are incentivised to keep watching during a quiet year, and whether the challenge path has ever been exercised.

What to actually ask

Who attests, and what happens if they collude? How many independent parties, and independent in what sense? Where are the keys and is signing automated? Is there an upgrade key, and does a timelock sit in front of it? Has the failure path — challenge, forced exit, recovery — ever been used in production?

That last question is the one that separates designs which work from designs which are described as working. A mechanism nobody has ever exercised is an assumption.

The uncomfortable summary

Bridge losses have overwhelmingly been operational rather than cryptographic. Compromised keys, misconfigured thresholds, upgrade functions with inadequate protection, validator infrastructure sharing a failure domain. The cryptography has mostly held. The people and processes around it have not — which is where scrutiny is best spent.