Assets do not move between chains. Understanding what actually happens explains why this category has produced some of the largest losses in the field.
What actually happens
Assets are locked or burned on one chain and a representation is issued on the other.
Which means the representation is a claim, and its value depends entirely on the locked assets remaining secured.
Reversing the process burns the representation and releases the original.
The custody problem
Something must hold the locked assets and decide when to release them.
Which is the whole security question, and it is a custody question rather than a cryptographic one in most designs.
Bridge contracts have accumulated very large balances, making them concentrated targets.
Validator set designs
A set of signers attests that a deposit occurred on the source chain.
Which means compromising a threshold of those signers allows fraudulent withdrawals.
Several of the largest incidents followed exactly this pattern, with attackers obtaining enough keys to authorise transfers.
Light client designs
Verify the source chain's consensus directly on the destination chain.
Which removes the external trusted set and is substantially harder to implement.
It also costs more in computation, which is why simpler designs remain common.
Common failure causes
Key compromise, signature verification bugs, incorrect message parsing, and mismatched assumptions between the two chains.
Which are implementation failures more often than design failures.
Verification logic accepting a malformed proof has appeared in more than one incident.
Wrapped assets
A representation is only as good as the bridge holding the backing.
Which means holding a wrapped asset is holding exposure to the bridge as well as to the underlying.
Multiple wrapped versions of the same asset from different bridges are not interchangeable, and this catches people out.
Messaging protocols
General cross-chain messaging generalises the problem beyond assets.
Which is more useful and carries the same trust question about who attests to what.
What to check
Who authorises releases, how many independent parties are required, whether the contracts have been audited and whether administrative keys exist.
Public trackers document these arrangements, and the answers vary enormously between bridges that market themselves similarly.
This is technical description rather than a recommendation about using any specific bridge.
Liquidity network designs
Rather than locking and minting, some systems maintain pools on both sides and swap.
Which avoids issuing a representation and requires liquidity on the destination chain.
The failure mode is liquidity shortage rather than custody compromise, which is a different risk profile.
Native issuance
Some assets are issued natively on multiple chains by the same issuer.
Which removes bridge risk for those assets entirely and replaces it with issuer risk.
The distinction between a natively issued asset and a bridged representation is worth checking before assuming they are the same thing.
Incident response
Several bridges have paused operations on detecting anomalies, limiting losses.
Which requires monitoring and a pause capability, itself a centralised control.
The trade-off between the ability to intervene and the trust it requires is a real design tension.
Recovery after incidents
Some losses have been partially recovered through negotiation, chain analysis or protocol reimbursement.
Which is not the general case, and most losses have not been recovered.
Practical caution
Moving only what is needed, and not leaving large balances in wrapped form, limits exposure.
Which is basic and is not what most users actually do.
Audits and bounties
Most large bridges have been audited, and several were exploited afterwards.
Which indicates that audits reduce risk without eliminating it, particularly for complex cross-chain logic.
Bug bounty programmes with meaningful payouts have prevented documented incidents and are a reasonable signal of seriousness.
Concentration of value
Bridge contracts holding very large balances are among the most attractive targets in the field.
Which is a structural feature rather than a fixable bug.
Native cross-chain standards
Some ecosystems provide protocol-level transfer between connected chains rather than relying on external bridges.
Which moves the security to the consensus layer.
Availability depends on the chains involved being part of the same interoperability framework.
The summary position
Bridges are among the highest-risk components in common use.
Which argues for minimising exposure rather than for avoiding them entirely, since they are frequently necessary.
Watching for warning signs
Unusual withdrawal patterns, paused contracts and delayed confirmations are frequently the first public indication of a problem.
Which several communities monitor and publish.
Following the protocol's own status channels is the fastest source during an incident.
Insurance
Cover for smart contract failure exists and is limited in capacity and in what it pays for.
Reading the exclusions matters more than the headline cover.
Checking before use
Public risk trackers document validator sets, upgrade keys and audit history for major bridges.
Which takes minutes to read and differentiates products that market themselves identically.
The information is available precisely because these systems are public.