Why Cross-Chain Bridges Became the Top Target for Crypto Hackers

A cross-chain bridge is a system that moves tokens or messages between two blockchains that cannot read each other's state directly. Ethereum, Solana, rollups and other networks each keep their own ledgers, so a token on one chain has no native way to appear on another.

Bridges fill that gap. Most work by locking or burning tokens on the source chain and then creating or releasing a matching asset on the destination chain. Users see this as a simple transfer, but behind it is a chain of contracts, validators, relayers and sometimes off-chain servers that all have to agree that the deposit really happened.

There are several common types. Lock-and-mint bridges hold the original tokens in a vault and issue wrapped versions elsewhere. Liquidity-network bridges keep pools of tokens on both sides and settle later. Messaging protocols pass arbitrary data between chains, which apps then use to move assets or trigger actions. Canonical bridges, such as the official Arbitrum Bridge between Ethereum and its rollup, are maintained by the layer-2 team itself and are generally treated as the reference route for that network.

The key point for readers is that a bridge is not a single product. It is a set of moving parts, and each part can fail in a different way.

A bridge is useful because it pools assets. Locked tokens sit in one contract or set of contracts so that users on the destination chain can get wrapped versions or liquidity. That pooling is exactly what makes bridges valuable to attackers.

A single successful exploit can drain the entire pool rather than one user's balance. Compare that with a wallet, where an attacker must phish or infect each victim one at a time. A bridge concentrates value in a few addresses and a few lines of code, so the reward for one successful intrusion can be very large.

The pool also creates a second problem. Wrapped tokens circulating on the destination chain are only worth something if the locked collateral on the source chain is real. If an attacker can make the bridge believe a deposit happened when it did not, they can mint tokens with no backing. From there they can sell those tokens for real assets on decentralised exchanges, lending markets or centralised venues.

Total value locked figures for bridges change constantly, so readers should check current balances on public dashboards rather than relying on any single number. The structural point stays the same: the more value a bridge holds, the more an attacker stands to gain.

Bridge attacks tend to fall into a few recurring categories. Most real incidents combine more than one of them.

• Compromised keys: attackers obtain the private keys or signing authority that approve withdrawals, through phishing, malware or social engineering of operators.
• Weak validator or multisig setups: if only a small number of signers are needed to approve a message, a few compromised parties can authorise fake transfers.
• Verification bugs: a smart contract may fail to check a signature, a Merkle proof or a message source correctly, so forged data is accepted as valid.
• Initialisation and upgrade mistakes: a configuration value set wrongly during deployment or an upgrade can open a path that should have been closed.
• Relayer and off-chain component failures: servers that pass messages between chains can be hijacked or misconfigured.
• Economic attacks: attackers manipulate prices, liquidity or oracle inputs that a bridge or its linked apps rely on.

For each category, the defence is different. Key security depends on hardware signing, operational separation and monitoring. Verification bugs depend on code review, formal checks and bug bounties. Validator risk depends on how many independent parties must agree and how they are chosen. Readers evaluating a bridge should ask which of these risks the design addresses and which it leaves open.

In March 2022, the Ronin Bridge, which served the Ronin sidechain used by the Axie Infinity game, lost a very large amount of ETH and USDC. The bridge relied on a set of validator keys to approve withdrawals. Attackers gained control of enough of those keys to sign fraudulent withdrawals, and the loss was reported at several hundred million dollars at the time.

The lesson most security researchers drew is about threshold design and operational security rather than code alone. The bridge used a multi-signature scheme, but a meaningful share of the required signatures were controlled through infrastructure that was not sufficiently isolated. Social engineering aimed at operators and access that remained in place after some changes were part of the story as reported afterwards.

For users, the case shows that a bridge can be widely used and still rely on a small trusted group. A high number of users does not measure how many independent parties must agree before funds leave the bridge.

The exact figures, timeline and how funds were later handled are documented in the bridge operators' post-mortem material and in public incident trackers. Check those sources for the authoritative details, as summaries online often differ on amounts and dates.

Two other major incidents in 2022 show how a single bug in verification logic can be enough to drain a bridge.

Wormhole, which connects Solana with Ethereum and other chains, suffered an exploit in February 2022 in which the attacker bypassed a signature verification check on the Solana side. The attacker was able to mint wrapped ETH without depositing the matching collateral. The protocol's backers covered the shortfall, and the losses were reported at roughly three hundred million dollars.

Nomad, a messaging-based bridge, had an upgrade that set a trusted root to an invalid default value during initialisation. Because of that, many transactions that should have failed were treated as valid. Once the flaw was public, numerous people copied the same transaction pattern, and the bridge lost a large sum in a short period. Several participants returned part of the funds.

These cases share a pattern. The code looked reasonable at a high level, but one check was missing or one default was wrong. Bridges often have many contracts and many parameters, so a single configuration error can affect every message that follows. Careful audits, staged upgrades and public bug bounties reduce that risk, but they cannot remove it completely.

Different bridge architectures change who you need to trust. Readers do not need to be cryptographers to compare them, but they should understand the basic trade-offs.

Design	Main trust assumption	Typical risk to watch
Canonical rollup bridge	The layer-2 rollup and its proof or challenge system	Upgrade keys and rollup-level bugs
Multisig-validated bridge	A fixed set of signers reaches the threshold honestly	Key compromise and small signer sets
Messaging protocol with configurable verifiers	The verifiers and settings chosen by the app	Weak configuration by individual apps
Intent-based bridge	Solvers fill the request and settlement logic works	Solver failures and settlement contract bugs

LayerZero V2 is a messaging protocol that lets applications choose how their messages are verified, which means security depends partly on each app's configuration. Across is an intent-based bridge and swap protocol, where a solver fronts funds and the user's request is settled later. The official Arbitrum Bridge is a canonical route tied to the rollup itself.

None of these is automatically safe. Each has its own failure modes. The useful question is not which label is best, but who can change the rules, who can approve withdrawals and how much value sits in the path at any time.

Bridge hacks are often hard to reverse for several reasons. Transactions on public blockchains are final once confirmed, and attackers usually move stolen funds through mixers, bridges, decentralised exchanges or other chains within minutes.

Recovery depends on cooperation. Some stablecoin issuers can freeze tokens, and some exchanges can block deposits from known addresses, but that only works if the stolen assets pass through those points. Attackers who convert to assets without those controls, or who move funds through non-cooperating venues, are harder to stop.

Legal action varies by jurisdiction and by the specific facts of each case. Some bridges have offered bounties, negotiated returns, or compensated users from treasuries, but these outcomes are not guaranteed and are not a standard protection that users can rely on.

For readers, the practical lesson is that prevention and limiting exposure matter more than recovery. Keeping bridge balances small, moving funds in stages and watching transaction status closely reduce the damage a single failure can cause.

Users cannot audit a bridge's code line by line, but they can run a short set of defensive checks before moving funds.

1. Use the official bridge link from the destination app's documentation or the network's own website, and bookmark it.
2. Check the token contract address on the destination chain against a trusted source before you approve or send.
3. Send a small test amount first and confirm it arrives correctly.
4. Avoid unlimited token approvals. Approve only the amount you need, and revoke old approvals you no longer use through a reputable approval-management tool.
5. Read the bridge's documentation on who can pause, upgrade or sign messages, and how many parties must agree.
6. Look for a public audit history, a bug bounty programme and a post-mortem policy. Their presence does not guarantee safety, but their absence is worth noting.
7. Do not move your full balance at once. Split large transfers and keep idle funds on the chain where you need them.
8. Watch for unexpected prompts to sign messages, add networks or import seed phrases. Legitimate bridges rarely ask for those.

None of these steps removes risk. They reduce the chance of an easy mistake and limit the damage if a bridge fails.

Figures about bridge security change quickly. New incidents happen, protocols upgrade, and recovery efforts evolve, so any amount or status written here would go out of date.

To check current information, use these sources:

• The bridge or network's own security page, audit reports and post-mortems.
• Public hack trackers that list incidents with dates, amounts and root causes.
• Public dashboards that show value locked and flows across bridges, which help you see whether a bridge's holdings are changing sharply.
• Official announcements from the bridge team about pauses, upgrades or changes to signers.

When you compare sources, prefer primary documents over summaries, and check the date on each one. If two sources disagree on a figure, go with the operator's own report and note the discrepancy.

For readers researching a specific bridge, the most useful questions are: who can change the rules, how many parties must approve a withdrawal, whether the code has been audited and whether the team has a clear incident process. The answers to those questions tend to stay useful even as individual numbers change.

Cross-chain bridges became a favourite target because they combine three things attackers want: large pools of locked value, complex code that spans several chains and operational systems that people must keep secure. A single failure can expose an entire pool, and the same design features that make bridges useful also make them hard to audit fully.

The history of major incidents shows several recurring weak points. Keys and signers can be compromised. Verification code can miss a check. Default values and upgrades can open unintended paths. Each bridge design shifts which risks matter most, and no design removes them entirely.

For users, the practical approach is to treat bridging as a higher-risk action than a simple swap within one chain. Verify the route, test with small amounts, limit approvals and keep balances spread out. For anyone building on or evaluating bridges, the same logic applies at a larger scale: minimise how much value a single key or contract can control, and make every privileged action visible.

The field is still developing, and the details of any one bridge will change. The underlying questions about trust, verification and concentration of value remain the right ones to ask.