DeFi loses money to many things: oracle manipulation, smart-contract bugs, liquidity crunches, and the slow drain of MEV. One category dwarfs the rest. Bridges, the infrastructure that moves assets between blockchains, are the most-hacked part of DeFi by a wide margin, responsible for billions in cumulative losses and the majority of what was stolen in early 2026.

For a vault that earns yield across multiple chains, this is not someone else's problem. A cross-chain vault depends on bridges to move its capital, which means it inherits the risk of every bridge it touches. Cross-chain bridge risk is therefore one of the most important and least understood exposures an allocator takes on when a strategy spans more than one chain.

This guide explains why bridges are so vulnerable, how the major hacks actually happened, why the threat has shifted from code to keys, the defenses that reduce the risk, and what an allocator should ask about a cross-chain vault. For the structures involved, our complete guide to DeFi vaults is the starting point, and the cross-chain yield companion covers the opportunity side of the same coin.

Why Are Bridges the Most-Hacked Part of DeFi?

The root of the problem is that blockchains are sovereign and do not naturally talk to each other. A bridge has to solve a genuinely hard problem: convincing one chain that something true happened on another chain, without a shared source of truth between them. The destination chain must verify a message from the source chain and release funds on the strength of that verification, and everything in a bridge hangs on whether that verification can be trusted.

The track record is stark. Hacks of bridges account for more than half of all value lost in DeFi, with cumulative theft in the billions of dollars. The pattern has continued: bridge vulnerabilities accounted for more than two-thirds of all DeFi losses in the first quarter of 2026, and analysts have warned that the growing complexity of these interoperability rails creates systemic risk, where a single bridge exploit could destabilize the broader stablecoin market.

What makes this worse is that the failures repeat. The same kinds of bridge hacks happen again and again, not because no one learns, but because the core problem is architectural rather than a single fixable bug. Each new bridge re-solves the same verification challenge, and each new solution introduces a new version of the same risk.

How Do Bridges Work, and Where Do They Break?

Most bridges fall into a few designs, and each has a distinct failure point.

The most common is lock-and-mint. The bridge locks an asset in a contract on the source chain and mints a wrapped version of it on the destination chain. The wrapped token is a claim on the locked original, so if the lock contract is drained, the wrapped token becomes unbacked and worthless. A close cousin, burn-and-mint, destroys the token on one chain and recreates it on the other. The third model is a liquidity network, which keeps pre-funded pools on both chains and pays out from them, so a swap depends on those pools holding enough to honor it.

Underneath the mechanics, the real differentiator is the trust model. A trusted bridge relies on a set of validators or a multisig to attest that a transfer is valid, and the fewer signers in that set, the weaker the link, because compromising a threshold of them compromises the bridge. A trustless bridge tries to remove that human element using light clients or zero-knowledge proofs that verify the source chain's state cryptographically. Trustless designs are harder to build but far harder to corrupt, and the distinction matters enormously for any strategy that moves value across chains, including cross-chain yield strategies.

The verification mechanism itself is where much of the danger concentrates. The most secure architectures separate validation, execution, and message relay into independent layers rather than collapsing them into one trusted component. Many bridges lean on oracles to confirm that a transaction occurred on the source chain, which is convenient but creates an obvious target: if the oracle can be fed a false proof, the bridge will mint or release funds against a transfer that never happened. Oracle manipulation has been one of the single largest attack vectors in bridge history, a reminder that cross-chain bridge risk overlaps directly with the oracle risk that affects vaults more broadly.

How Do Bridges Actually Get Hacked?

The headline incidents map onto a few recurring attack classes, and seeing them together makes the pattern obvious.

The first is validator-set compromise. The Ronin bridge lost around $625 million when an attacker gained control of a threshold of its validator keys; the operator controlled most of the set itself, and an unrevoked permission left the door open long enough for the theft to go unnoticed for days. When a small set of keys authorizes withdrawals, those keys are the bridge's single point of failure.

The second is faulty verification logic. The Wormhole exploit, around $320 million, came from a signature-verification flaw, and the Nomad loss of roughly $190 million followed a configuration error that effectively let attackers forge valid-looking messages. In 2026, the Kelp DAO loss of nearly $290 million traced to a bridge configuration that relied on a single verifier and lacked strict validation of the cross-chain instruction, so the attacker made the bridge believe a forged message was legitimate. As the analysis put it, a bridge can have real liquidity, real users, and real contracts and still fail if its message-to-execution logic is not strict enough.

The third, and now the most common, is the compromise of keys and people. Private-key compromises accounted for 88% of stolen funds in the first quarter of 2025, and the trend carried into 2026. The Resolv breach saw an attacker compromise a private key through an off-chain key-management service and mint tens of millions in unbacked tokens; the Drift loss of around $285 million was not a code exploit at all but a months-long social-engineering operation against the people who controlled admin keys. The lesson the industry has been forced to absorb is that audits protect against code bugs, not against a developer who gets phished by a patient, well-resourced attacker. With code becoming harder to exploit, the main attack surface is now people.

Beyond these three, a longer tail of vectors rounds out the picture. Governance attacks let an adversary who accumulates enough voting power steer a bridge's own contracts against it. Frontend and DNS hijacks leave the contracts untouched but trick users into sending funds to malicious addresses by compromising the website in front of the bridge. Signature-replay attacks reuse a valid signature in a context it was never meant for, fooling the bridge into releasing funds more than once. None of these requires breaking the cryptography directly; each finds a softer edge of the same system, which is why defending a bridge means defending far more than its core contract.

How Do You Defend Against Bridge Risk?

The defenses follow directly from the failure modes, and the strongest bridges layer several of them.

The first principle is to never trust a single validator or signature. Modern architectures are moving toward multi-proof aggregation, requiring several independent verification paths, such as a combination of zero-knowledge proofs and a decentralized validator network, so that compromising one path is not enough to release funds. The Kelp lesson was precisely the opposite setup, a single verifier with nothing behind it.

The second is structural separation and delay. Separating validation, execution, and message relay into independent layers shrinks the attack surface, and a release pattern that routes a verified message through a timelock and governance check before a vault pays out means that even a compromised receiver still has to bypass the next layer. The third is disciplined key management, since keys are now the main target: hardware or multi-party signing, key rotation, and putting any minting authority behind timelocks and multisigs rather than a single hot key.

Beyond those, monitoring and containment matter. Invariant monitoring watches whether the system still balances, tracking conservation of value, collateral ratios, and sane rate bounds, while circuit breakers automatically pause the bridge on the signatures of an attack: volume spikes well above normal, transfers that are a large share of total value, rapid sequential drains, or oracle deviations. Two further approaches reduce trust at the design level: shared security, where a bridge uses an established validator set such as Ethereum's rather than bootstrapping its own, and intent-based bridging, where a user states the outcome they want and specialized solvers handle routing and security, abstracting away the choice of bridge. None of this removes bridge risk, but together it is the difference between a properly secured vault and one resting on a single key. Where these protections sit is part of what a serious security review examines.

What Should an Allocator Ask About a Cross-Chain Vault?

For an allocator, bridge risk turns into a specific line of questioning, because a vault rarely advertises its bridge dependencies.

Does the vault rely on a bridge to move or hold capital, and if so, which one? What is that bridge's trust model: how many validators, a single verifier or multiple independent proofs, a canonical bridge run by the chain itself or a third-party one? Is any of the vault's collateral a bridged or wrapped asset, which is a hidden dependency whose failure would cascade into the vault even if the vault's own contracts are flawless? Are there circuit breakers that would halt activity during an attack, and is there insurance covering a bridge failure?

The Kelp case is the cautionary tale to keep in mind, because it was a yield vault drained not through its own strategy but through the bridge configuration it depended on. The principle that follows is simple: a cross-chain vault is only as safe as the weakest bridge it touches, and that weakest link belongs in diligence from the start, which is exactly what a structured evaluation framework is built to surface.

Conclusion

Bridges are the weakest link in DeFi because connecting sovereign blockchains is genuinely hard, and the trust required to do it tends to concentrate in a small number of validators or keys. The losses repeat year after year because the problem is structural, not a sequence of unrelated bugs, and the threat has shifted decisively from exploiting code to compromising the people and keys that control the bridge.

For a cross-chain vault, the bridge is not a background detail; it is a core dependency that deserves the same scrutiny as the strategy itself. Ask which bridges a vault relies on, how they verify transfers, and what happens when something goes wrong. Platforms like Lucidly Finance treat bridge exposure as part of curating which vaults institutional capital should hold, because in a multi-chain world the safest yield is the one whose every dependency has been checked.