Crypto Bridges Explained: What Actually Moves Between Chains and Where Trust Breaks

Crypto bridges, explained: a crypto bridge is a system that allows one blockchain to act on verified evidence of an event that happened on another. What actually moves between chains is information about that event, not the coin you started with. If you have ever moved funds to a different chain and felt unsure about what you were actually holding, or read about a nine-figure bridge hack and wondered whether bridges are simply unsafe, that uncertainty is the real problem this guide is built to clear up.

What a crypto bridge actually is

A crypto bridge is infrastructure that allows one blockchain to act on verified information about something that happened on another blockchain. That is a more precise idea than "moving coins between chains," and the difference matters more than it sounds. At Blockready, we structure education around understanding a mechanism before deciding whether to use it, and bridges are a clear case where the popular shorthand hides the part you most need to understand.

The reason bridges exist at all is that separate blockchains do not naturally read each other's state. An Ethereum smart contract has no built-in way to know that a transaction finalized on Solana, on a Cosmos chain, or on an Ethereum rollup. Each network reaches consensus only about its own history. So for value or instructions to be useful across chains, the destination chain needs to receive evidence it can check under some rule, and then it needs logic that decides what to do once that evidence is accepted. Ethereum's own bridge documentation describes bridges as transport routes between otherwise isolated environments, carrying tokens, messages, arbitrary data, and even smart contract calls from one chain to another.

This is also why bridges sit underneath so much of decentralized finance. Liquidity, applications, and users are spread across many networks, and bridges are the plumbing that lets them interact. If you want the fuller picture of why bridges matter for DeFi liquidity and applications, that wider context helps. For now, hold onto one idea: a bridge is not a pipe. It is a messenger and an accountant working across two systems that cannot talk on their own.

It also helps to separate two things that often get blurred together. An asset bridge is an application whose visible result is a token balance on another chain. A generalized messaging protocol is the layer underneath that carries authenticated data, which an application can use to move tokens or to trigger almost any other action on the destination side. Many token bridges are built on top of a messaging layer, and when they are, the risks of the messaging layer and the application layer add together rather than cancel out. Knowing which of the two you are using tells you how much a single accepted message is allowed to do.

What actually happens when you bridge an asset

When you "bridge" a token, the original token usually stays exactly where it was. What changes is the accounting and your right to use value somewhere else. Depending on the design, your source asset might be locked in a contract while a representation is minted on the destination chain, or it might be burned while an authorized issuer mints a fresh native token elsewhere, or a liquidity provider might simply pay you on the destination side and get reimbursed later. The smart contracts that enforce these rules are the same kind of self-executing code described in our explainer on how smart contracts enforce bridge rules.

Those choices fall into a few recognizable patterns, and the pattern decides what you actually receive. In lock-and-mint, your asset is locked in a source contract and a representation is minted on the destination chain. In burn-and-mint, the source token is burned and an authorized issuer mints an equivalent native token elsewhere. In lock-and-release, an asset is locked on one side while an existing reserve is released on the other. In a liquidity-network route, a provider pays you on the destination chain from inventory and is reimbursed later. Same word, four different things happening underneath.

Some bridges skip the wrapped representation entirely. An issuer-controlled design can burn a native token on the source chain and mint the same native token on the destination chain, so you end up holding the real asset rather than a wrapper. Other routes feel instant because a liquidity provider fronts the funds on the destination side and settles up later. That speed is real, but it usually means risk has moved to a liquidity provider rather than disappeared, which is part of why liquidity pools support some bridge routes. The lesson here is simple to state and easy to forget: "your tokens move" is a UX story, not a description of what the contracts actually do.

Why the token you receive is a claim, not your original coin

If a bridge mints a representation, the token that lands in your wallet is a claim. Its contract proves you hold a balance. It does not, by itself, prove that the escrow behind it is still full, that the minting authority has not been compromised, that the issuer will honor redemption, or that the market will keep treating it as equal to the original. Two tokens can share a ticker and a logo and still be entirely different contracts with different backing and different risks.

This trips up careful people, not just careless ones. It is completely reasonable to assume that "wrapped ETH" on another chain is just ETH wearing a coat. The accounting underneath says otherwise, and the gap between those two beliefs is exactly where avoidable losses tend to hide.

Where trust actually breaks: the bridge trust stack

The most useful way to think about bridge safety is not "is this bridge decentralized?" It is "which facts, contracts, and powers have to stay honest for this particular transfer to settle correctly?" That reframing turns a vague fear into a checklist of layers, and almost every real bridge failure maps to one of them.

Each layer carries a different kind of risk. A bridge can wait too few confirmations and act on a source event that later gets reorganized away, leaving the destination side with assets that no longer have backing. A verifier can be tricked into accepting a forged message. A destination contract can have a minting bug. And a privileged key can quietly change any of these rules. The independent risk framework maintained by L2BEAT organizes much of this around how source events are verified and who holds upgrade power, which is a good habit to borrow. One more distinction matters here: the bridge designated as canonical or official by a chain is not automatically the safest, and a third-party bridge is not automatically the riskiest. Both inherit their own mix of these layers, which is also where Layer 2 bridges fit into Ethereum scaling and where withdrawal windows and sequencer assumptions enter the picture.

Two of these layers cause more confusion than the rest. Finality is one. A bridge has to choose how confident it wants to be that a source event will not be reversed before it acts, and acting too early means a source-chain reorganization can leave the destination side holding assets with nothing behind them. The role of relayers is the other. In some designs a relayer only transports a valid proof, so it can delay a transfer but cannot forge one, which makes it a liveness concern rather than a safety one. In other designs, the actor called a relayer also helps verify or execute, which gives it real authority. The label alone does not tell you what someone can do, so the honest move is to ask what each participant is actually allowed to authorize.

This is the moment the abstract becomes concrete for you as a user. The next time an interface offers to bridge an asset, the real decision is not "is this app trustworthy" in a general sense. It is "which of these five layers am I relying on, and which ones can I actually check?" That question is harder than clicking a button, and it is also the difference between using a bridge and understanding one.

What the failures teach us

Bridge exploits make headlines because the losses are large, but the more useful lesson is that the biggest failures each broke a different layer. According to the Chainalysis 2026 Crypto Crime Report, about $3.4 billion in crypto was stolen across all attack types in 2025, with most of those losses now coming from exchange and private-key compromises rather than from bridge contracts themselves. That is a meaningful shift from 2022, when Chainalysis estimated bridge hacks alone accounted for roughly $2 billion, about 69 percent of all crypto stolen that year. The point is not that bridges have become safe. Orbit Chain in January 2024 and the Kelp DAO bridge incident in April 2026 are recent reminders that the same failure modes keep returning, and bridges have also become a primary route for laundering funds stolen elsewhere. The earlier cases below remain the clearest teachers of what those failure modes are.

The Ronin bridge was compromised in March 2022 when attackers gained control of five of nine validator keys, which met the threshold needed to authorize withdrawals. Elliptic valued the stolen 173,600 ETH and 25.5 million USDC at about $540 million at the time of the theft, with higher figures reported later reflecting price movement rather than additional losses. The lesson is about effective thresholds: "nine validators" did not mean nine independent keys were required, and the number of participants told you little about how concentrated control really was.

Wormhole, in February 2022, broke a different layer. An attacker exploited a signature-verification flaw and minted 120,000 wrapped ETH on the destination side without any matching ETH locked behind it. The deficit did not come from draining escrow. It came from a verification bug that let an unbacked claim exist. Jump Crypto later supplied 120,000 ETH to restore the backing, which repaired the hole for users but is best described as sponsor recapitalization, not recovery of the attacker's funds. Nomad, in August 2022, showed how a single faulty configuration can convert a bridge into a public withdrawal mechanism, as a flawed upgrade caused unproven messages to be treated as valid and copycats drained roughly $190 million. The BNB Smart Chain Token Hub incident in October 2022 added one more discipline: attackers forged a proof to mint about 2 million BNB, but the amount minted was not the amount lost, and chain validators halted the network to limit how much actually moved.

Multichain, in 2023, is the case that resists a clean story. More than $125 million left the protocol, and the project itself pointed to heavy dependence on one person for operational and key infrastructure. Whether it was an external hack, an insider event, or something else was never conclusively settled, which is exactly why careful writing separates what is known from what is alleged. Across all of these, notice the discipline that responsible reporting uses: stolen, minted, frozen, recovered, and reimbursed are different numbers, and blending them produces a "hack size" that means nothing.

That distinction is where reporting goes wrong most often. A gross amount minted or withdrawn is not the same as the amount an attacker actually realized, which is not the same as funds later frozen or returned, which is not the same as a sponsor recapitalizing the hole, which is not the same as users being reimbursed. Each of those is a separate figure with its own date and its own price assumption. A headline that collapses them into a single dollar amount, or that quietly uses the highest available number, is usually telling you less than it appears to.

Why safety signals are not proof of safety

Once you understand the trust stack, the usual reassurances start to look thinner. An audit tells you that a named reviewer examined a defined scope and version of the code and reported findings. It does not tell you that every contract, off-chain signer, upgrade key, and integration was in scope, or that the code running today matches what was reviewed. Our guide to what audits can and cannot prove about bridge safety goes deeper, but the short version is that an audited badge is evidence, not a guarantee.

The same caution applies to the other signals people lean on. High total value locked measures how much is entrusted to a system under a particular methodology, which also makes it a larger target, not a proof of solvency. High transaction volume can be incentivized or routed through aggregators. A long incident-free history can be reset by a single upgrade. And "decentralized validator count" tells you nothing if those validators share an operator, a cloud provider, or a key-management process. Each of these is a useful question to ask, and none of them is an answer on its own.

Two more reassurances deserve a flag. "No previous hack" means no publicly known incident under the records you can see, not that nothing happened, and a recent change to the code or configuration can quietly reset whatever comfort that history gave you. "Insured" is only as strong as the policy wording, the coverage limits, the exclusions, and whether the affected users are actually the parties who get paid. Smart-contract, key-compromise, and governance events are often exactly the kinds of losses that coverage carves out. Read those details before you treat either signal as protection.

How to inspect a bridge before you trust it

You will not become a security auditor by reading one article, and you do not need to. What helps is a short, repeatable set of questions that surface hidden dependencies before you rely on a route. Blockready's curriculum sequences this kind of risk literacy after the foundations of blockchains, wallets, and smart contracts, because the questions below only make sense once you understand what is underneath them. We call the habit the BRIDGE Trust Review, and it is deliberately a set of questions, not a score.

The honest limit of any framework like this is worth stating plainly. Completing it can reveal dependencies and unanswered questions you would otherwise miss. It cannot calculate a probability of loss, certify code, or predict how governance will behave under pressure. A single critical unknown, such as an opaque upgrade key, can outweigh a long list of reassuring signals. The framework makes you more capable of asking the right questions, which is the realistic goal.

Risks that remain even when the bridge works

Here is the part most bridge explainers skip. A transfer can complete exactly as designed and still leave you worse off. You might select the wrong destination network or address. The destination token might lack liquidity or be a representation you did not expect. A route aggregator might swap through a thin or malicious token along the way. The destination chain itself can halt, reorganize, or censor. And the act of using a bridge often involves signing token approvals, which is why understanding why bridge interactions can create token-approval risk matters as much as understanding the bridge contract. A representation can also lose its peg if the market starts to doubt its backing or redemption, even when no contract was exploited and the bridge behaved perfectly. And if the only way to claim or withdraw runs through a single company's interface, you are exposed to that operator staying online and honest. This is the difference between protocol correctness and your actual outcome.

Frequently Asked Questions