A bridge is not a piece of plumbing that joins two blockchains. Nothing moves between chains, because nothing can: each ledger records its own state and has no view of any other. What a bridge does is transport a claim. It observes an event on one chain, decides that the event happened, and then instructs the other chain to act as though it had. Everything interesting about bridges follows from the middle step, and the middle step is always a question about who is believed.
That is why this category produces the largest losses in the industry, and why the losses are found in a small number of shapes. The designs are variations on four ideas, each of which makes a different assumption about who has to be honest. Once the four are stated separately, most of the field’s complexity resolves into a single question asked four ways: what exactly is being trusted, and how many parties would have to collude to break it?
The problem: two ledgers that cannot see each other
A blockchain is a machine that can validate its own history and nothing else. A node on one network does not read another network’s blocks, does not verify its signatures, and cannot be persuaded to accept a statement about another chain unless that statement is submitted and checked by rules the node already has. This isolation is a security property rather than an oversight: a chain whose validity depended on another chain’s state would inherit that chain’s failures as well.
So the transfer of value across chains is not a transfer at all. It is three separate operations: an asset is locked or burned on the source, a message describing the operation is delivered to the destination, and the destination acts on that message according to its own rules. The only hard part is the second step, because a message is just data and data can be forged, replayed, or misread. A bridge is, precisely, a mechanism for establishing that a particular message from another chain is real.
Design one: lock the original and issue a representation
The first design is the oldest and the easiest to explain. The user deposits the asset into a contract or a custodian on the source chain, which holds it, and a corresponding token is issued on the destination chain. Coming back reverses the process: the representative token is destroyed and the original is released.
The trust assumption is the entire business. Whoever holds the locked asset can release it at will, which means the security of every outstanding representative token is the security of that holding arrangement. When the arrangement is a single custodian, the bridge is a bank with a website. When it is a committee of validators or a multi-signature set, the bridge is as strong as the quorum rules and the key management of that set, which is where a series of large failures have come from.
The design’s advantage is that it works between chains with nothing in common. Its disadvantage is that the total value at risk grows with use, and the cost of attacking the bridge does not: a structure holding five billion dollars in locked assets is protected by the same dozen keys that protected it when it held fifty million.
Design two: pools on both sides
The second design avoids a single custodian by keeping a pool of liquidity on each side. A user who wants to move value pays into the pool on the source chain and takes an equivalent amount out of the pool on the destination, and the pools are rebalanced by traders who are paid to do so.
What is trusted here is less obvious and just as consequential. The pools have finite depth, so the price of a transfer depends on their state, and the price is usually computed from a feed rather than negotiated. That combination has produced a specific failure mode: if the feed can be moved within a single transaction, or if the depth is thinner than the size of the transfer, a user can drain one side against the other at a favourable rate, and the loss is socialised across the liquidity providers who funded the pools.
The design is capital-efficient for small transfers and structurally exposed to large ones, and it is also the design most dependent on the quality of the price it reads. The honest description is that it replaces custody risk with market-structure risk, which is a different risk rather than a smaller one.
Design three: verify the other chain’s consensus
The third design is the only one that tries to remove the middleman entirely. The destination chain runs verification logic for the source chain’s consensus, so that a state proof from the source can be checked against rules the destination already enforces. If the proof verifies, the message is real by construction, and no committee has to be trusted.
The assumption it removes is the largest one available: there is no custodian, no validator set with keys to steal, and no price feed to manipulate. What it substitutes is cost and complexity. Verifying another chain’s consensus means implementing its light protocol, tracking its validator set or its accumulated work, handling its finality rules, and updating all of that in code that must be correct forever.
Two consequences follow. Transfers are slower, because a proof cannot be verified until the source chain has finalised the event it describes. And the engineering surface is much larger, which means the failure mode shifts from a stolen key to a bug: a verification routine that accepts something it should not is as good as a signature that can be forged.
Design four: swap or nothing happens
The fourth design removes the message step altogether. Two parties on two chains agree to trade, and the exchange is arranged so that either both sides complete or neither does, with a time limit that lets each party recover its own asset if the other does not deliver.
Nothing is trusted beyond the two parties and the hashing rules, which makes this the most conservative mechanism available and also the least useful as a general service. It requires a counterparty who wants the opposite trade in matched size, at the same moment, and it produces no bridge in the usual sense: there is no liquidity sitting idle, no wrapped asset that can be used elsewhere, and no way to move value to a chain where nobody wants to trade back.
The design’s honest niche is large, occasional, bilateral movements where the parties can wait, and it is the reason the phrase “trustless bridge” should be read as a description of a mechanism with severe requirements rather than as a better version of the other three.
Where the trust actually sits
Laying the transfer out in steps makes the comparison mechanical. Locking is a transaction that either succeeds or does not. Emitting a message is a log entry with no discretion in it. Releasing value on the destination is another transaction. The only step with a judgement in it is verification, and every design above is a different answer to how the judgement is made: by a party holding the asset, by a set of parties signing, by a contract checking a proof, or by nobody because the two sides are the same transaction.
That is also why the marketing language around bridges is so unreliable. A service can describe itself as decentralised while running the first design with a committee of a dozen signers, and a service can describe itself as simple while implementing the third. The description that matters is not about decentralisation in general but about the specific party or parties whose honesty the verification step requires.
The five attack surfaces
Whatever the design, incidents concentrate in five places, and each is checkable in advance by somebody willing to read documentation.
The first is the size of the validating set: a bridge secured by one key is one compromised laptop away from total loss. The second is the signature threshold, which is the number of those validators that must collude, and which is often described as a fraction of a set that may itself be small. The third is the verification logic, where the failure is not a stolen key but a check that accepts an invalid input, including the classic case of a message being replayed twice. The fourth is the liquidity that stands behind the transfer, where thin depth combined with a readable price produces a profitable attack. And the fifth is administrative authority: contracts that can be upgraded or paused concentrate all four previous surfaces into whoever holds the upgrade key, which is the most common way a bridge that was technically fine became a bridge that was not.
Why bridges carry the largest losses
Four properties of the category explain the concentration of damage. The first is that a bridge holds assets belonging to many users at once, so a single compromise is not limited to the amounts involved in one transaction. The second is that the code is among the hardest to write and to audit in the field, because it has to reason about two different chains’ rules at once and about the state of both while it does so.
The third is that the economic asymmetry favours the attacker: a defensive team has to be right about every path, while the attacker has to find one. The fourth is that bridges are a chokepoint, which means the payoff of an attack is proportional to how much traffic the industry routes through them rather than to how carefully any particular one was built. A bridge that becomes popular becomes a target in proportion, and popularity is not a security control.
What has gone wrong, by category
The recorded failures of the last several years fall into three groups, and the grouping is more instructive than any individual case. The largest group involved compromised signing keys or validator sets: attacks on the parties whose signatures authorised releases, producing losses in the hundreds of millions of dollars in several instances, including one case where the compromised set signed off on transfers worth more than six hundred million.
The second group involved flaws in the verification logic itself, in which a message was accepted that should not have been, or accepted more than once. The third group used the liquidity design against itself, exploiting a price that could be moved within a transaction or a pool that was thinner than the transfer being attempted.
A pattern runs across all three. In every case the mechanism did what its code said, and the question afterwards was why the code said that. The failures were not cryptographic: no signature scheme was broken and no hash function was reversed. They were all failures of design assumptions about who would behave.
The trade-off nobody can remove
Safety, cost and latency form the same triangle here as in every settlement system, and each design occupies a different corner. Verification by a committee of signers is fast and cheap and requires trusting the committee. Verification by proof is slow and expensive and requires trusting only consensus rules. Pools are cheap for small transfers and fragile for large ones. Atomic swaps are safe and slow and only work when both sides want the trade.
No design escapes the triangle, and the reason is structural: the property being bought is the absence of a trusted party, and that property has to be paid for somewhere — in computation, in time, or in the functionality that has to be given up. A bridge that advertises all three simultaneously is either describing a different mechanism than the one it runs, or it has moved the cost somewhere the user does not see.
The canonical bridge and the third-party bridge
One distinction deserves its own section because it changes what a user is trusting. A canonical bridge is the one operated by the network that needs it — the standard path between a base layer and a layer built on top of it. Its trust assumption usually reduces to the governance of that destination chain, which a user is already relying on by holding assets there at all.
A third-party bridge is a separate business: it connects chains that do not otherwise know each other, and it adds its own trust assumptions on top of both. Users are frequently unaware of which one they are using, because the interfaces look identical and the fees are comparable. The difference appears at the moment something goes wrong, when the recourse available depends entirely on which of the two arrangements was involved.
What to check before using one
Three questions cover the material risks and are answerable before a transfer. Who verifies, and how many are they? A bridge that publishes its validator set and its threshold is inviting scrutiny, and one that describes the set only in general terms is telling you something by the omission. What can the operators do unilaterally — upgrade the contracts, pause withdrawals, change the validator set? Each of those powers is a trust assumption that exists whether or not it is disclosed.
And where do the assets actually sit while in transit? For the first design this determines everything: if the locked assets are held by a contract with an upgrade key, then the security of the arrangement is the security of that key, and every other property of the bridge is decoration on top of it.
The direction of travel
Three developments are visible, and each is an attempt to reduce the amount of trust the third step requires. The first is standardisation of the message layer, so that verification logic is shared rather than reimplemented by every operator, on the theory that one heavily reviewed implementation is better than ten bespoke ones. The second is the pattern known as intents, in which a user states an outcome and a competing set of solvers delivers it, with the trust moving from a bridge to a market of parties who are paid to compete.
The third is redundancy as a design choice: routing value across several bridges at once so that a single failure is partial rather than total. That is an admission about the state of the art, and it is also the most honest one available. Until verification can be done cheaply and correctly on the destination chain, the practical answer is not to find a trustless bridge but to stop depending on any single one.
What a wrapped asset actually is
The representative token that a bridge issues is not a title deed. It is a liability of the bridge, recorded in a contract, redeemable for the original only by going back through the same mechanism. That distinction matters most in the scenario nobody wants to think about: if the locked assets are taken, the representative tokens are not backed by anything, and a holder who never touched the bridge discovers that the asset they were using was a claim on a mechanism rather than a claim on a coin.
Two consequences follow for anyone holding one. The first is that the credit quality of the wrapper is the credit quality of the bridge, so a token that trades at par on a normal day is trading at par because the mechanism is believed, not because the mechanism is riskless. The second is that multiple representatives of the same asset can exist at once, issued by different bridges with different designs, and they are not interchangeable: the price difference between two versions of the same coin is the market’s estimate of the difference in trust.
That price difference is the most useful signal a reader can watch. When two wrappers of one asset trade at different prices, the market is pricing a specific mechanism’s risk, and it does so before anything fails. A wrapper that trades persistently below its peers is telling you what somebody knows about the arrangement behind it.
Why the industry keeps building them anyway
The risks are well documented and the category keeps growing, and the reason is that the alternative is worse for the participants. Value is spread across dozens of networks, users want to hold one balance rather than a portfolio of chain-specific positions, and an application on one network cannot serve a user whose assets sit on another. A bridge is what makes an asset usable where it is not, which is a service rather than a convenience.
The incentives are also asymmetric in a way that explains the volume of construction. Whatever a bridge connects, the traffic that passes through it pays fees, and the team that operates the canonical route between a base layer and a network built on top of it holds a position that is difficult to displace. That combination of demand and rent explains why bridges are built faster than they are audited, and why the audits that matter are the ones conducted after a failure rather than before.
Where bridge engineers disagree with each other
The four designs are not ranked the same way by the people who build them, and the disagreement is instructive. The camp that favours proof verification argues that any arrangement requiring a set of parties to be honest is a temporary compromise whose failure is a matter of time, and that the cost and complexity of verification are the price of a property worth having. The camp that favours signed messages argues that proof verification has produced its own failures, that a verification routine which is subtly wrong is indistinguishable from a bridge with a forged signature, and that a well-audited committee with a published set of members is easier to reason about than a proof system nobody can review.
Both positions are defensible and they disagree about what a user is actually buying. The proof camp is buying the absence of a trusted party. The committee camp is buying inspectability, because a quorum of named entities can be evaluated, insured and, when necessary, held responsible in a way that a verification contract cannot. A reader can hold both ideas at once and ask a simpler question instead: which of the two risks does this particular bridge concentrate, and am I willing to carry it?
There is also a third position, held by a minority, that most bridges should not exist. Its argument is that the value of connecting two ledgers is smaller than the cost of the security machinery required to do it safely, and that the industry would be better served by users holding assets where they are rather than by constructing verification systems whose failures are measured in hundreds of millions of dollars. That view has not prevailed, and its persistence is a reasonable indication that the trade-off is genuinely contested.
The middle step is the product
A bridge is a mechanism for making one chain believe a fact about another, and everything else is the arrangement around that mechanism. The four designs differ in who is asked to vouch, and the largest losses in this industry have all been failures of that vouching rather than failures of cryptography.
Two sentences are worth keeping. The asset never moves between chains; a claim about it does, and the claim is only as good as the verification that admitted it. And the security of the arrangement is the security of the weakest party whose honesty the verification step requires, which is a fact that no amount of documentation can change and that every user can check in about five minutes if the operator is willing to say.
