Cross-chain bridges have lost more value to attacks than any other category of crypto infrastructure, and it is not because the people building them are careless. It is because of what a bridge fundamentally is, and once that is clear the pattern of failures stops looking like bad luck.
The mental model most people carry is of an asset travelling from one chain to another, the way a file moves between two computers. Nothing of the sort happens, and it cannot: a blockchain is a closed system that knows only its own state, and it has no mechanism for observing what is true on a different chain. There is no wire between them and no shared reality to appeal to.
What actually happens is that the asset is immobilised on the first chain and a new one is created on the second, representing a claim on the immobilised original. The two halves are joined by nothing except a system that decides when to create the claim, and that decision is the entire security question. Everything a bridge does reduces to answering it: who is allowed to say that assets were locked on the other side, and what stops them from saying it falsely.
A bridge does not move value. It locks value in one place and issues a promise in another, and every large failure has been an attack on the promise rather than the lock.
The token you receive is not the asset you deposited. It is a separate instrument, issued by the bridge, whose value depends entirely on the deposited asset remaining locked and retrievable. If the lock is compromised or the issuing mechanism is exploited, the token continues to exist and trade while the backing behind it does not, which is exactly the sequence observed in the largest incidents.
This has a consequence that catches people even after they understand the mechanism. Holding a bridged asset is holding a claim on a specific bridge, not on the underlying. Two versions of the same asset on the same chain, arriving through different bridges, are different instruments with different risks and often different prices, and they are frequently displayed with the same name and the same logo.
The practical form of that is to know which bridge issued what you hold before you hold it, and to check whether the asset you are receiving is the one the ecosystem you are entering actually uses. Being paid in a bridged version nobody accepts is a liquidity problem on top of a custody one.
The differences that matter are not about speed or fees. They are about who is capable of authorising the issuance of a claim, and how many of them would have to be wrong or dishonest at once.
A defined set of parties observes the deposit and signs the issuance, usually with a threshold requirement. This is the most common design and the easiest to build, and its security is exactly the security of that set: if the threshold number of signing keys is compromised, the attacker can mint claims backed by nothing. Several of the largest losses in the sector followed precisely that path, and the number of keys required was in every case small enough to be gathered.
A light client design puts enough of one chain's consensus logic into a contract on the other that it can verify proofs directly, with no committee involved. This is the strongest model available, because the trust assumption reduces to the security of the two chains themselves. It is also difficult and expensive to build, which is why far fewer exist than the marketing landscape suggests.
Rather than locking and issuing, some systems keep pools of the same asset on both chains and simply pay out from the destination pool when a deposit arrives at the origin. Nothing new is created, which removes the minting attack entirely, and the risk moves to whether the pools stay balanced and who provides them. It is a genuinely different shape of risk rather than a smaller one.
A bridge holds the entirety of the assets locked from every user who has crossed it, in one place, in a contract that must remain able to release them. That makes it the largest single pool of value in most ecosystems, guarded by code that is newer and less scrutinised than the chains on either side of it, and doing the most complex job in the stack.
Add that the job is inherently adversarial in a way that trading contracts are not. A bridge must decide whether an event occurred on a system it cannot see, based on evidence supplied by parties who may benefit from lying about it. That is a harder problem than transferring a token, it has more places to be wrong, and being wrong once is unbounded rather than incremental.
The result is not surprising once stated: the highest value, the newest code, the hardest problem, and an attacker population that only needs to find one defect. The pattern of losses in this category is what that combination produces, and nothing about it is specific to any particular team.
Grouping the incidents rather than listing them shows a small number of repeated mechanisms.
The threshold set of keys authorising issuance was compromised, often through ordinary means rather than cryptographic ones: a developer machine, a compromised credential, a social engineering attack on an individual. The bridge then minted claims that no deposit backed, and they were sold into the market before anybody noticed.
A defect in the verification logic allowed a forged or replayed message to pass as valid. These are the purest software failures in the category, they are subtle, and several of them survived audits, because verifying a proof correctly is a hard thing to get right and a hard thing to review.
A contract whose setup function could be called again, or whose privileged role was never renounced, allowed an attacker to take control of the mechanism outright. This is a deployment error rather than a design one, and it has caused very large losses.
Bridges are frequently upgradeable, which is sensible given how new the code is, and an upgradeable contract has an authority that can replace its logic. Compromising that authority is equivalent to compromising everything the contract holds, without needing to find any defect in the current code at all.
Three of the four failure modes are about who has authority rather than about the code. The attacks that worked did not usually need to break the mechanism, only to become the person allowed to operate it.
Most chains designate one bridge as canonical, meaning it is built and operated by the same team that builds the chain, and the assets it issues are the ones the ecosystem treats as native. That designation is worth attention because it concentrates liquidity: the canonical version of an asset is the one that trades everywhere on that chain, and every other version is a separate instrument with thinner markets.
It is not automatically safer, and treating it as a safety rating is a mistake. A canonical bridge inherits the same three design choices as any other and can be a committee holding keys just as easily. What it does provide is the answer to a different question, which is whether the asset you receive will be accepted where you intend to use it, and that question is worth answering separately from the security one.
A substantial share of bridging is done for reasons that do not require a bridge, and noticing that is the cheapest risk reduction available. If both chains are supported by a platform you already use, depositing on one and withdrawing on the other achieves the same outcome using an entity you have already accepted as a counterparty, which is a risk you were carrying anyway rather than a new one.
Where the asset exists natively on both chains because its issuer deploys it on both, no bridge is needed either: the issuer can burn on one side and mint on the other, and several major assets work this way. Checking whether that route exists before using a bridge takes a minute and removes the entire category of risk described above.
The remaining case, where a bridge is genuinely the only path, is narrower than the volume flowing through them suggests. Much of that volume is habit rather than necessity, and the habit is expensive in a way that only shows up on the days it does.
Four questions, none of which require reading code. Which design is this, meaning whether issuance is authorised by a committee, by a proof the chain verifies, or by nobody because liquidity sits on both sides. If a committee, how many signatures are required and are those parties identifiable and independent. Is the contract upgradeable, and if so who controls the upgrade and is that control itself distributed. And is there a non-bridge route to the same destination.
Then the operational habit that costs nothing: cross in the amount you need rather than the amount you hold, and do not leave value sitting in a bridged form longer than the reason for bridging requires. Time exposed is the variable most under your control, and most of the value lost in this category was sitting in transit or idle rather than being actively used at the moment it disappeared.
No. It is locked on the origin chain and a new token representing a claim on it is created on the destination chain. Nothing crosses, because a blockchain cannot observe the state of another one. Everything about a bridge's security is about who is allowed to authorise that second step.
They hold the largest single pool of value in most ecosystems, their code is newer and less scrutinised than the chains around them, and they perform the hardest task in the stack: deciding whether something happened on a system they cannot see. An attacker only needs to find one defect, and the payoff is unbounded.
Frequently not. If they arrived through different bridges they are different instruments with different backing, different risks and often different prices, despite usually sharing a name and a logo. Knowing which bridge issued what you hold is part of knowing what you hold.
It is the bridge designated by the chain's own team, and the assets it issues are the ones the ecosystem treats as native. That answers a liquidity question rather than a safety one: it tells you the asset will be accepted where you want to use it. Its security still depends on the same design choices as any other bridge.
The one where the destination chain verifies proofs from the origin chain directly, because the trust assumption reduces to the security of the two chains themselves rather than to a committee. It is also the hardest and most expensive to build, which is why far fewer exist than the vocabulary suggests.
Often. If a platform you already use supports both chains, depositing on one and withdrawing on the other reaches the same destination through a counterparty you had already accepted. And where an issuer deploys the same asset natively on both chains, no bridge is involved at all. Checking for either route takes a minute.
It reduces the probability of certain classes of defect and it has not prevented several of the largest incidents. Verification logic is subtle enough that errors have survived review, and three of the four common failure modes are about who holds authority rather than about the code an audit examines.
As briefly as the reason for bridging requires. Time exposed is the variable most under your control, and a large share of the value lost in this category was sitting idle or in transit rather than being actively used at the moment the mechanism failed.