TL;DR
Crosschain bridges have lost roughly $2.9 billion to exploits since 2022, and the pace hasn't slowed. Peckshield tracked $328.6M drained across 8 bridge incidents in May 2026 alone.
The four failure patterns that produce almost every bridge hack: wrapped-asset mint exploits, compromised validator sets, multi-sig key concentration, and locked-liquidity honeypots.
Across uses an intents architecture: users sign an outcome, relayers front capital from their own balance sheet, and UMA's Optimistic Oracle settles repayment. There are no locked user funds to drain.
If you're integrating crosschain into your app, start with the Across docs.
The bridge sitting underneath your app is a liability you inherited
Every crosschain app, every multichain DEX, every yield router, every wallet with a "Bridge to" button, sits on top of a bridge it didn't write. The bridge's failure modes become your failure modes. When the bridge gets exploited, your users lose their money; when the bridge is slow, your product feels broken; when the bridge holds a billion dollars in a single contract, your users' funds sit inside that honeypot whether they know it or not. Bridging security is not a feature you bolt on after launch. It is the foundation of any crosschain infrastructure, and it dictates what risks you are actually shipping to your users.
The crosschain space has spent four years learning this the hard way. Roughly $2.9 billion has been drained from bridges since 2022, and the bleeding hasn't stopped. Peckshield counted $328.6 million stolen across eight separate bridge incidents in May 2026 alone. The structural reasons these protocols keep getting hacked are well understood. So is the architecture that avoids them.
Four ways bridges break, and why each one is structural
Bridge exploits look chaotic from the outside, but they cluster into a small number of repeating patterns. Each pattern points at a design decision the bridge made years before the exploit happened.
Wrapped-asset minting. Lock-and-mint bridges hold user assets in a contract on the source chain and mint a representative token on the destination chain. If the mint function can be tricked into producing tokens without matching collateral, the entire wrapped supply becomes worthless. In February 2022, an attacker exploited a deprecated signature verification path in the Wormhole bridge to mint 120,000 wETH on Solana that had no backing on Ethereum, walking away with roughly $325 million in the largest DeFi hack of that year.
Validator capture. Bridges that depend on a small set of validator nodes to sign off on transfers create a target the size of those validator keys. The Ronin bridge used nine validators, with five required to approve a transaction. In March 2022, Lazarus Group socially engineered access to five validator keys and drained 173,600 ETH and 25.5M USDC, roughly $540 million at the time and as high as $625 million by other counts. The protocol's signature check worked exactly as designed. The keys were the whole bridge.
Multi-sig concentration. Some bridges concentrate admin control in a multi-sig holding a handful of keys. Harmony's Horizon Bridge required 2-of-5 signatures to move funds. In June 2022, attackers compromised two operator keys and drained roughly $100 million. The bridge contract itself wasn't exploited. The bridge contract didn't need to be.
The locked-funds honeypot. Every bridge that holds user assets in pooled liquidity creates a single contract that scales with adoption: the more users trust the bridge, the larger the prize sitting in the contract. Multichain's $125 million loss in July 2023 came after private keys controlling the bridge's locked liquidity were compromised. The contract did exactly what it was supposed to do: sign transactions from its administrator. The administrator was the attacker.
Each of these is a different vulnerability, but they share an inheritance: the user puts assets into the bridge, and the bridge holds the bag. Whatever fails inside the bridge, the mint logic or the validator set or the multi-sig or the admin key, fails into the user's wallet.
Intents shift the risk off the user and off the contract
Across uses an intents architecture, which inverts the model. A user doesn't send funds into a bridge contract and wait for messages to arrive on the other chain. The user signs an intent (an outcome they want, denominated in the input token, the output token, the chains, and the amount) and a competitive network of relayers bids to fulfill it. The winning relayer fronts capital on the destination chain from their own balance sheet and delivers the asset to the user. Then, and only then, the protocol verifies the fill and repays the relayer.
There is no pool of user funds locked in a destination-chain contract. There is no wrapped asset minted in the user's wallet. When you bridge ETH with Across, you receive ETH, not a representative token. There is no validator set holding the signing keys to a billion dollars in collateral. The relayer takes the finality risk. The user gets canonical assets in roughly two seconds.
That risk-shift is the load-bearing claim. Across's architecture is documented as a three-layer system: a request-for-quote mechanism that houses the user's intent, a competitive relayer network that fills it, and a settlement layer that verifies and repays. The settlement layer is where the optimistic oracle sits, and it's the part most bridges don't have.
Optimistic verification, one honest participant, no waiting
Across settles through UMA's Optimistic Oracle. The Dataworker ingests deposit and fill events over a roughly 60-minute window, aggregates valid fills into a repayment bundle, and posts the bundle for optimistic verification. If no one disputes it within the challenge period, the bundle executes and relayers get repaid. If anyone disputes, the dispute is adjudicated by UMA's oracle, which has been securing onchain financial contracts since 2020.
Two things matter about this design. First, it requires only a single honest participant in the network to flag a malicious bundle. There is no honest-majority assumption, no validator quorum to corrupt. Second, the optimistic step happens off the user's critical path. The user already has their assets in roughly two seconds, filled by a relayer who is now waiting for repayment. The verification window doesn't slow the user down; it slows down how fast the relayer gets paid. That's a relayer's problem to price into their fees, not a user's problem to wait through.
The system also scales gas costs at O(1) instead of O(N) in the number of fills, because repayments are aggregated into bundles rather than verified one transfer at a time. That's an order of magnitude cheaper than per-fill verification, and the savings show up in user pricing.
V4 makes settlement chain-agnostic with ZK proofs
Across V4, which is live today, removes the protocol's last dependency on destination-chain canonical bridges. Previous versions of Across relied on each destination chain to expose Ethereum-finalized state, which worked for rollups like Arbitrum and Optimism but not for L1s like BSC. V4 replaces those custom adapters with a zero-knowledge light client of Ethereum, generated with Succinct's SP1 prover and verified on the destination chain by a contract called SP1Helios.
The practical consequence is that adding a new chain to Across no longer requires a custom verification layer per chain. The security model stays the same on every chain Across reaches, because every chain is verifying Ethereum state the same way. Builders integrating Across don't inherit a different trust model when they expand to a new network. The bridge doesn't get weaker as it gets wider.
What "no exploits" actually means as a track record
Across has been in production since 2021. Across has processed $36+ billion in bridge volume across millions of transfers and serviced hundreds of thousands of monthly active wallets, without a single security incident at the protocol level. Not a wrapped-asset exploit. Not a validator compromise.
This is a record built on a structural choice, not on luck. The four failure modes catalogued above all describe risks that the architecture explicitly does not take on. No wrapped assets to over-mint. No validator set whose quorum can be captured. No multi-sig holding billions in locked liquidity. No honeypot contract for an attacker to drain. Removing those attack surfaces is what makes the track record possible.
What to ask before you integrate any bridge
If you're choosing a bridge for your crosschain infrastructure, or evaluating the one you've already integrated, there are four questions worth answering on paper before you ship a user to it.
What asset does the user actually receive on the destination chain? If the answer is a wrapped or representative token, the bridge has introduced a separate token-failure mode on top of the underlying chain. If the answer is the canonical asset, the bridge cannot fail in a way that makes the user's destination-chain holdings worthless.
Who bears the risk between source-chain deposit and destination-chain delivery? If the bridge architecture leaves the user holding the risk while messages get verified across chains, every minute of verification is a minute of exposure. If a relayer fronts capital and absorbs that risk in exchange for a fee, the user is done as soon as the destination-chain transfer settles.
How is settlement secured? A small multi-sig is not a security model; it's a list of phone numbers an attacker can target. An honest-majority validator quorum is a probabilistic bet against social engineering. An optimistic oracle with a one-honest-participant assumption is a different kind of guarantee, slower to settle and harder to subvert.
What does the contract hold? If the bridge contract holds pooled user liquidity, the contract is the prize. If the bridge contract holds no user liquidity, because relayers front their own capital, there is nothing for an exploit to drain.
These four questions cut through the marketing of every bridge in the market, including Across. The right answers are documented or they aren't.
Build with infrastructure that doesn't put your users in line for the next hack
Bridging security isn't a checkbox on an integration checklist. It is the architectural decision sitting underneath every crosschain product, and the wrong decision costs your users money on a timeline you don't control. The bridges that have lost the most have all lost it in roughly the same way: by holding the bag, by trusting the wrong key. The infrastructure that hasn't lost any has stopped holding the bag in the first place.
Build crosschain with Across.