Math, Not Multisigs: How Trust-Minimized Bridges Work in 2026

Every few weeks in 2026, the same headline comes back around: a cross-chain bridge has been drained, and the users on the wrong side of it are waiting to learn whether they will be made whole. In September alone, a bug in Blockstream’s Liquid Network let attackers peg out roughly 4,000 BTC, about $320 million, from the sidechain’s federation wallet, according to Chainalysis, and a flaw in the Symbiosis bridge minted around $46 billion of synthetic Bitcoin on paper before monitoring tools caught it and the attacker walked away with only about $336,000. Bridges move well over $10 billion in value in a typical month, which is exactly why they remain the richest single target in the industry.

The stakes are only rising. Bitcoin traded around $84,000 in late September, easing from an eight-month high as markets weighed the Federal Reserve’s shift to a higher policy rate, a backdrop we covered in our look at the post-hike rally. More value on-chain, and more of it rotating between chains, means more value sitting in the vaults these bridges guard.

For most of crypto’s history, a bridge asked you to trust a group of people or servers to tell it the truth about another chain. The 2026 story is different. A growing set of bridges try to remove that trust, verifying the other chain the way the chain verifies itself, and a new class of tokens caps how much any single bridge can ever lose. This is a guide to how trust-minimized bridging actually works: light clients, zero-knowledge proofs, and token-level rate limits, and to the places where even the math still leans on people.

What a bridge actually has to prove

Strip a bridge down to its core and it is trying to answer one question: did a specific event really happen on another chain? A smart contract living on Ethereum cannot natively read Solana, Bitcoin, or a Cosmos chain. It has no way to look across and confirm that you locked 10 ETH somewhere else. So before it releases anything, something has to attest to that deposit. Every bridge design in existence is just a different answer to the same two questions: who or what do you trust to make that attestation, and what happens when the attestation turns out to be false?

The plumbing usually takes one of two shapes. In the lock-and-mint model, you lock a real asset in a contract on the source chain and the bridge mints a wrapped claim on the destination, an IOU redeemable one-for-one. In the burn-and-mint model, the token is destroyed on the source chain and reissued natively on the destination, with no locked pool behind it. Either way, the moment that decides everything is the attestation. Get that wrong, and the bridge either releases collateral it should not or prints tokens that nothing backs. Almost every catastrophic bridge loss on record traces back to a false attestation that the system treated as true.

It also helps to separate two jobs that often travel together. A token bridge moves value; a messaging protocol moves arbitrary data, a function call on one chain that triggers an action on another. Most modern systems are really messaging layers with a token bridge built on top, which is why a flaw in the message layer, a forged instruction that the destination faithfully executes, can be more dangerous than a bug in any single token contract. The attestation problem is identical either way: something has to vouch that the message is real.

The trust spectrum, from take-my-word to verify-it-yourself

Bridge trust models sit on a spectrum. At one end, you simply trust a named set of signers. At the other, the destination chain re-checks the source chain’s own consensus and trusts almost nobody. The further right you move, the harder the system is to fool, and usually the harder and more expensive it is to build. The table below maps the main families through that lens.

The pattern is worth internalizing. The left of the table asks you to trust that a group is honest and uncompromised. The right asks you to trust mathematics and the security of the chain you were already using. That shift, from trusting a report about a chain to verifying the chain, is the whole thesis of trust-minimized bridging.

The middle of that spectrum deserves a closer look, because not every design reaches for a light client. Optimistic bridges make a different bet: assume every message is valid, publish it, and give independent watchers a window to challenge anything fraudulent with a fraud proof. The economics are appealing, since nobody verifies the happy path, but the safety rests on two conditions Nomad failed to meet: at least one honest, funded watcher has to be paying attention, and the challenge mechanism itself has to actually work. When the fraud check is broken or the window is too short, the optimistic assumption becomes a blank check. Light clients and validity proofs remove that dependency by verifying up front instead of trusting a challenge later.

Why believing a report keeps failing

Ben Fisch, chief executive of Espresso Systems, put the recurring flaw plainly after one of 2026’s largest bridge losses: “Most bridges don’t fully verify what happened on another chain. Instead, they rely on a smaller system to report it,” he told CoinDesk. His summary of that exploit is the sentence every bridge builder should tape to the wall: “The bridge worked as designed. It just believed the wrong information.”

The case files bear him out. Wormhole lost about $325 million in 2022 when an attacker forged a validator approval and bypassed its guardian network without ever breaking the guardians’ keys, according to Halborn’s teardown. The $292 million KelpDAO exploit in April 2026 hinged on a configuration that let a single verifier suffice, so spoofing one data feed was enough, as Chainalysis documented; we traced the fallout and the rescue in our account of the DeFi United coalition. On Liquid, an eleven-of-fifteen federation dutifully signed a peg-out; the signers were honest, but the data they were signing was a forged proof their software had been tricked into caching. And when Symbiosis was drained in September, the lesson repeated in miniature: a signature check confirms who sent a message, not whether the message describes something real.

Nomad is the purest illustration. A botched upgrade in 2022 set its trusted root to a blank value that happened to match the default for unproven messages, so the system auto-approved essentially everything, and hundreds of copycats replayed the first attacker’s transaction with their own addresses, per Mandiant’s analysis. The through line is that a quorum verifies agreement, not truth. This is why the numbers skew the way they do: TRM Labs found that infrastructure, key, and operational compromises made up roughly 15 percent of incidents in the first half of 2026 but around 76 percent of the value stolen. Bridges lose money because their verifiers approve lies, not because their Solidity is sloppy.

What a light client is, and why it is the honest answer

A light client is the closest thing crypto has to verifying another chain without trusting a middleman. Rather than ask a committee whether a block is real, a light client checks that a block header was signed by a sufficient fraction of the source chain’s own validator set, reproducing the source chain’s consensus check on the destination chain. As one survey of the field puts it, a light client verifies that a block header was accepted by enough of a chain’s validators by checking their signatures. If it accepts a header, it is because the same validators you already rely on when you use that chain signed it. There is no separate group to bribe.

This is as good as cross-chain verification gets, and it has a hard ceiling that Ethereum co-founder Vitalik Buterin flagged years ago. He argued that “there are fundamental limits to the security of bridges that hop across multiple zones of sovereignty.” A light-client bridge cannot make the destination safer than the source; if the source chain reorganizes or its validators collude, a faithful light client will faithfully report the damage. What it can do is refuse to add a new, weaker trust assumption on top. Cosmos has run this model in production for years through IBC, where each chain keeps a light client of the others and verifies transfers directly. The reason light clients did not immediately take over the rest of the industry is not security. It is cost.

The gas problem, and how zero-knowledge proofs solve it

Verifying a chain’s consensus on-chain means checking a large set of validator signatures inside a smart contract, and that is brutally expensive. By Polyhedra’s accounting, the naive approach of verifying every validator signature on the Ethereum Virtual Machine runs to roughly 80 million gas, far more than a block can hold, before you even get to the mismatch between signature schemes: Cosmos chains sign with Ed25519, and the EVM has no native support for that curve. A pure on-chain light client for many chain pairs is simply unaffordable.

Zero-knowledge proofs collapse that cost. Instead of re-running the entire light-client check on-chain, a prover runs it off-chain and produces a small cryptographic proof that the check was performed correctly. The destination contract then verifies the proof, which is cheap and constant-sized, rather than the thousands of signatures behind it. The savings are dramatic. Polyhedra’s zkBridge reports cutting EVM verification from about 80 million gas to under 230,000 gas, roughly a 350-fold reduction. Succinct’s SP1 can prove a Cosmos-to-Ethereum transfer for around 200,000 gas, about 25 times cheaper than the naive path, with a full cross-chain transfer costing under a dollar in gas and relay fees. That is the breakthrough that turned light-client bridging from a research demo into something a treasury can actually route through.

Not all proofs are alike, and the choice carries its own tradeoffs. SNARK-based systems produce tiny proofs that are cheap to verify, though some require that one-time trusted setup; STARK-based systems drop the setup and lean on hashing, at the cost of larger proofs. Either way, proving is heavy work: generating a validity proof for a chain’s consensus can demand specialized hardware and real time, which adds latency to a transfer and concentrates the effort in whoever can afford the machines. Verification is cheap and public; proving is expensive and, for now, fairly centralized. That asymmetry is the seam where practical trust quietly re-enters an otherwise trustless design.

The 2026 ZK-bridge wave

The result is a cluster of production systems that replace committees with proofs. They differ in the chains they connect, the proving stack they use, and how decentralized their provers are, but they share the same ambition: verify, do not trust.

Gnosis OmniBridge is the clearest before-and-after. It once leaned on a five-of-seven multisig of validators; it now takes additional security from Succinct’s Ethereum ZK light client, with more than $40 million in value locked and over $1.5 billion in stablecoin flow now relying on consensus proofs rather than a signing committee. Cardano founder Charles Hoskinson made the case for going further after a 2026 bridge hack on infrastructure his ecosystem touches, arguing that zero-knowledge proofs should replace trust in bridge operators and multisigs outright. “All software is under this enormous assault,” he warned, describing a world where automated tools probe every contract until something gives.

Even math has trust assumptions

A ZK bridge is trust-minimized, not trustless, and the difference matters. The same field survey lists the assumptions that survive. Some proof systems require a trusted setup, a one-time ceremony whose secret must be destroyed; if it leaks, forged proofs become possible. The proving circuit itself is code, and an unaudited circuit is a fresh attack surface: a bug there does not crash loudly, it silently accepts a false statement as true. Most production ZK bridges still rely on small, semi-trusted prover clusters, which introduces both a censorship risk and a liveness risk, since a bridge that cannot generate proofs is a bridge that halts. And when a source chain changes its consensus mechanism, the circuits must be updated to match, which raises the obvious question of who holds the key to update them.

That last point is the one that quietly undoes a lot of cryptography. A flawless proof verified by a contract that an admin can upgrade at will is only as safe as that admin’s key. This is the keys-not-code reality that dominates modern exploits: the strongest verification in the world does not help if a single privileged signer can swap the rules underneath it. The same delegation-of-authority questions that make wallet security hard, which we unpacked in our explainer on EIP-7702, apply to bridge governance. A ZK bridge moves trust from a committee of attesters to a smaller circle of provers, circuit authors, and key holders. That is progress, because the circle is smaller and its work is publicly checkable, but it is not the same as trusting no one.

The second line of defense: make the token fight back

Better verification lowers the odds of a false attestation. The second half of the 2026 playbook assumes verification will sometimes fail anyway and tries to make failure survivable. The clearest example is a token standard called xERC-20, proposed as EIP-7281 by Connext’s Arjun Bhuptani and often described as sovereign bridged tokens. It hands control of cross-chain minting back to the token issuer.

Under xERC-20, the issuer deploys and fully controls the token, decides which bridges are allowed to mint or burn it, and sets a rate limit for each one, a cap on how much that bridge can mint in a given window that refills over time, as the Connext documentation describes. A companion contract called a Lockbox wraps the existing canonical token so it can move under the new rules. The security consequence is the important part. If a bridge is compromised, it can only mint up to its rate limit before the cap trips, so the catastrophic whole-supply mint that defined so many exploits, the 120,000 wrapped ETH conjured in the Wormhole hack, the $46 billion of synthetic Bitcoin printed on Symbiosis, becomes impossible by construction. A breach turns into a bounded, capped loss the issuer can absorb or halt.

The arithmetic makes the point. Suppose an issuer lets a given bridge mint at most a few million dollars of its token per day. An attacker who completely compromises that bridge still cannot conjure the entire supply; they hit the ceiling, the next mint reverts, and monitoring has hours rather than seconds to respond. The cost of the breach is capped at roughly one day’s allowance instead of the whole market capitalization, which turns a protocol-ending event into a line item and buys defenders the one thing they never have during a live exploit: time.

Chainlink’s Cross-Chain Token standard applies the same idea on its own transport layer, letting issuers keep control of token pools with configurable rate limits rather than handing minting rights to a bridge wholesale. In practice these caps are a circuit breaker for the cross-chain economy, the same off-switch logic we examined in our piece on crypto’s pause buttons. They do not stop an attack from starting; they stop it from becoming existential.

Delete the honeypot: native issuance

Rate limits shrink the blast radius. Native issuance tries to remove the bomb. The reason lock-and-mint bridges are such tempting targets is that the locked collateral piles up in one contract, a growing honeypot that an attacker only has to breach once. Every dollar bridged makes the prize bigger.

Burn-and-mint native issuance breaks that dynamic. Circle’s Cross-Chain Transfer Protocol destroys native USDC on the source chain and mints native USDC on the destination, with no wrapped IOU, no locked liquidity pool, and no custodian holding the bag in between. There is no reserve to drain and no wrapped claim to forge, because the asset that arrives is the real thing, not a derivative of it. The wrapped-versus-native distinction is now one of the fastest ways to gauge a bridge’s risk profile: a wrapped token is a claim on collateral somewhere else, and that somewhere else is what gets attacked, while a natively issued asset carries no such hostage. Combine native issuance with per-bridge rate limits and you have a token layer that is both a smaller target and a capped one.

Bitcoin is where this problem bites hardest. Bitcoin’s scripting language cannot run a light client of Ethereum or verify another chain’s consensus, so almost every way to use BTC elsewhere leans on someone holding the real coins: a federation, as with Liquid, or a custodian minting a wrapped representation, as with the dominant wrapped Bitcoin products. That is precisely why the largest bridge loss of 2026 struck a Bitcoin sidechain, and why so much wrapped BTC has been moving toward arrangements with stronger verification and clearer custody. Trust-minimizing Bitcoin bridging, whether through threshold-signature custody spread across many independent parties or newer research designs, remains one of the field’s hardest open problems, because the chain being bridged cannot help do the checking.

Defense in depth, and the market’s verdict

No single technique is a silver bullet, so the strongest designs stack them. LayerZero’s V2 architecture lets applications require a configurable set of independent verifiers, an X-of-Y-of-N model where a message is only accepted if enough distinct verifier networks independently agree, so no single one can wave a forgery through. Chainlink’s CCIP layers an independent Risk Management Network on top of its main committee as a defense-in-depth check that can block anomalous transfers even if the primary path is fooled. The philosophy across both is the same: assume any one layer can fail, and make sure a second, independent layer has to fail at the same time.

The market has been repricing bridge trust in real time. After the KelpDAO exploit exposed the danger of a single-verifier setup, capital voted with its feet. Roughly $15 billion in bridged assets migrated from LayerZero toward Chainlink’s CCIP over the following months, a tally that climbed sharply when custodian BitGo moved billions in wrapped Bitcoin. Johann Eid of Chainlink Labs described the trend to CoinDesk as a “continued flight to safety.” LayerZero, for its part, raised its verifier minimums so that the one-of-one configuration behind the KelpDAO loss is no longer allowed for production deployments. Security is no longer a checkbox; it is a feature users and institutions now shop for.

Stacking verifiers also spreads the operational load, and that load is easy to underrate. Every trust-minimized bridge still needs someone to relay messages, generate proofs, and keep the light-client state on the destination up to date. Those roles are not trust in the attestation sense, since a relayer cannot forge a valid proof, but they are single points of failure for liveness: if the provers stop or get censored, the bridge freezes, and funds frozen during a market panic are their own kind of loss. A healthy design uses multiple independent relayers and provers and leaves a permissionless path for anyone to submit a valid proof, so the system keeps moving even if its main operator walks away.

Which defense would have stopped which hack

It helps to run the 2026 toolkit against the landmark failures and ask, honestly, what each layer would have changed. The answer is rarely a clean win, and that honesty is the point.

Liquid is the cautionary line in that table. Verification only proves that a rule was followed, so if the rule itself is flawed, a valid proof will faithfully certify a bad outcome. No amount of cryptography rescues a broken consensus rule; only a rate limit, an alert, and a fast patch contain it. That is why the mature answer is layers, not a single miracle mechanism.

What the SEC can and cannot do

Users who assume a regulator will backstop a bridge failure are usually disappointed, and the reason is structural. Once an autonomous bridge is deployed, there is frequently no operator to license, subpoena, or fine. The Securities and Exchange Commission and the Commodity Futures Trading Commission reach the service providers around a bridge, the exchanges and custodians that touch it, far more easily than the contract itself. In a March 2026 joint interpretation, the two agencies signaled that most crypto assets are not securities, which narrows the SEC’s direct hook over the tokens moving across bridges in the first place.

The sanctions story shows the same limit. The Treasury sanctioned the Tornado Cash mixer in 2022, naming funds from bridge hacks including Ronin, Harmony, and Nomad, per its own announcement. A federal appeals court later found that Treasury had overstepped, on the logic that immutable smart contracts nobody controls are not property that can be sanctioned, and Tornado Cash was delisted in March 2025. The same no-controllable-operator property that makes a bridge hard to secure after deployment makes it hard to sanction after the fact. Enforcement against individuals, developers and launderers, has held up better than action against protocols. For everyone else, the legislative fix keeps slipping, a saga we tracked in our rundown of the post-CLARITY deadlines. The practical takeaway for a user drained by a bridge is blunt: there is usually no deposit insurance and no issuer with a duty to refund you.

How to read a bridge’s trust model

You do not need to audit circuits to make a safer choice. A handful of questions separates the trust-minimized designs from the take-my-word ones, and most of the answers are public.

• What actually verifies your transfer: a committee’s signatures, or a proof of the source chain’s consensus?
• How many independent verifiers are there, and can a single one suffice? A one-of-one configuration is a red flag.
• Is the asset native, minted through a burn-and-mint model, or a wrapped IOU sitting in a drainable pool?
• Does the token carry per-bridge rate limits, so a breach is capped rather than total?
• Who can upgrade the bridge or verifier contracts, and is there a timelock that gives users warning?
• Has the circuit or verifier been independently audited, and is the report public?
• Is there a pause or rate-limit circuit breaker, and who is allowed to pull it?

Keep the base rate in mind while you answer them. Because most losses come from keys and infrastructure rather than clever Solidity, the governance answers, who holds the keys and how fast they can move, often matter more than the cryptography on the label. A move-a-small-test-amount-first habit costs almost nothing and has saved more funds than any audit badge.

The bottom line

Trust-minimized bridging is the clear direction of travel in 2026. Verify with math instead of a committee, cap the damage with per-bridge rate limits, and delete the honeypot with native issuance; stacked together, those three moves shrink both the odds of a failure and the cost of one. The old question, do you trust these signers, is being replaced by a better one: can this design fail without taking everything with it?

The catch is that the last mile is still human. Whoever holds the upgrade key, runs the prover, or signs the config remains the softest surface, and the exploit record keeps proving it. The safest bridges of 2026 are not the ones that promise they will never break. They are the ones engineered so that when a piece breaks, and something always eventually breaks, the blast is bounded, the alarm is loud, and the money is still there in the morning.

Frequently Asked Questions

What is a trust-minimized bridge?

A trust-minimized bridge is one that verifies what happened on another chain using cryptography rather than the word of a committee. Instead of asking you to trust a fixed group of signers, it re-checks the source chain’s own consensus with a light client, often compressed into a small zero-knowledge proof that the destination chain can verify cheaply. You still rely on the source chain’s security and on the correctness of the proving code, so the trust is reduced, not eliminated.

Are zero-knowledge bridges actually trustless?

No. A ZK bridge removes the need to trust a signing committee, but it introduces new assumptions: the proving circuit must be bug-free and audited, the prover network must stay online and uncensored, and the contracts that verify proofs must not be quietly upgraded by an admin key. A proof also only shows that a rule was followed, so if the source chain’s own consensus is flawed, a valid proof can still attest to a bad result. The honest label is trust-minimized, not trustless.

How do xERC-20 rate limits stop bridge hacks?

The xERC-20 standard, proposed as EIP-7281, lets a token issuer decide exactly which bridges may mint or burn its token and how fast. Each approved bridge gets a mint cap that refills over time, so a compromised bridge can only create a limited amount before the limit trips. That turns a catastrophic whole-supply mint, the kind seen in several 2026 exploits, into a bounded loss the issuer can absorb or pause.

Why are wrapped tokens riskier than native issuance?

A wrapped token is an IOU: real collateral is locked in one bridge contract and a claim on it is minted elsewhere. That locked pile is the honeypot every attacker aims at, and if the bridge is fooled into minting extra IOUs, the peg breaks. Native issuance, such as Circle’s burn-and-mint model for USDC, destroys the token on the source chain and mints the real asset on the destination, so there is no locked pool to drain and no wrapped claim to forge.

What is the safest way to bridge crypto in 2026?

Prefer native issuance or an intent-based route over locking assets into a wrapped-token pool, and check how the bridge verifies transfers: a single verifier is a red flag, while a light-client or multi-verifier design is stronger. Favor tokens with per-bridge rate limits, confirm who can upgrade the contracts and whether a timelock applies, and move a small test amount first. Remember that if a bridge is drained, there is usually no insurer or regulator that can refund you.

Yuki Tanaka is a DeFi and cross-chain infrastructure correspondent at HOGE Wire, covering interoperability, protocol security, and the economics of on-chain trust.