Multisig bridges sound like they already have "multiple people confirming" — why do they still fail so often?
Multisig security depends on two things: whether the signer threshold is high enough, and whether those signers are genuinely independent — different organizations, different geographic locations, different Private Key custody methods. If the number of signers is small (say, just a handful) and they're highly interrelated (multiple accounts within the same company, for instance), the actual attack surface is far smaller than "multisig" sounds on the surface — an attacker only needs to obtain a few of those private keys, without genuinely breaking the system's cryptographic foundation at all.
In recent years, some bridges have publicly raised their verifier thresholds after being compromised, and this kind of after-the-fact adjustment reflects an ongoing industry correction to the problem of multisig thresholds being set too low — but it also indicates that this risk was, in fact, widely underestimated in the past.
If trust-minimized bridges are more secure, why do multisig bridges still make up the majority of the market?
The main reason is that cryptographic verification approaches (light clients, ZK proofs) are noticeably more complex to engineer and take longer to develop, and not every pair of chains has an off-the-shelf native verification solution available — if the source and destination chains have very different technical architectures, implementing a Light Client or proof system on the destination chain capable of verifying the source chain's state is itself a substantial engineering challenge. Multisig solutions, by contrast, are quick to set up and low-cost, which is why multisig bridges still account for the majority of TVL (Total Value Locked) flow in the market, even though the risks are now widely understood.
This also reflects that the industry is currently in the middle of a transition, not already through one — trust-minimized designs like native Rollup bridges and CCTP have indeed grown rapidly in recent years, but genuinely displacing the multisig model still requires the engineering barrier for cryptographic verification approaches to keep coming down.
The optimistic verification model (like Across) relies on someone monitoring during the challenge window — how reliable is that mechanism in practice?
The reliability of the optimistic verification model depends on how well the economic incentives for the watcher role are designed — ideally, the monitoring network should have enough independent participants continuously operating that as long as one honest watcher catches an invalid message and successfully disputes it, that message can be blocked from taking effect. This is a relatively loose security assumption of "just one honest party is enough," easier to satisfy than the multisig model's threshold of "a majority of signers must be honest."
But this mechanism also depends heavily on the challenge window's length being reasonably designed — too short, and watchers might not react in time; too long, and it sacrifices user experience, since funds take longer to actually confirm. Across having processed over $5 billion cumulatively with no major exploit as of mid-2026 reflects, to some extent, that this mechanism has worked well in practice — but that doesn't mean the mechanism itself has no theoretical weak point, just that the current monitoring network's scale and challenge window design haven't yet been genuinely tested to their limit by an attack.
If I don't understand the technical side at all and just want to safely move assets between chains, is there a simplified way to judge which bridge to use?
A few relatively mature paths with longer operating track records and no major incidents are worth prioritizing: official native Rollup bridges (using a Layer 2's own official bridging function directly, rather than a third-party bridge service), Circle's CCTP (well suited for cross-chain USDC transfers, since the mechanism burns and mints native assets, avoiding wrapped-asset risk), or well-known bridge services with a publicly transparent operating history and cumulative processed volume. For smaller amounts or when speed is urgent, third-party aggregator services — which let you compare fees and settlement times across multiple bridge routes at once — are also a practical option. But for larger transfers, it's worth sacrificing a bit of speed or paying slightly higher fees in exchange for the security that native verification or cryptographic proof mechanisms provide.
Another simple habit worth adopting: before transferring, spend a few minutes searching the bridge's name alongside "hack" or "exploit" to check whether it's had a major incident before, and whether its architecture was publicly adjusted afterward — this is far more practical than trying to work through a dense technical Whitepaper.
Cross-chain bridges are among the most concentrated targets for losses in crypto — since 2022, bridge-related hacks have totaled more than $2.8 billion, roughly 70% of total DeFi losses over the same period. But dig into the root cause of these major incidents, and you'll find almost none of them stem from the underlying blockchain's cryptography being broken. The real point of failure is almost always the same: the component in a bridge's architecture responsible for confirming that a transaction on the source chain genuinely happened.
The 2022 Ronin Bridge incident cost $625 million, Harmony lost roughly $100 million, and Orbit Bridge lost roughly $81 million — three of the largest bridge incidents in crypto history, sharing the same root cause: attackers didn't achieve any cryptographic breakthrough, they simply obtained enough signers' private keys to meet the multisig mechanism's threshold, directly forging the confirmation message that "this cross-chain transaction is legitimate." The same pattern showed up in the February 2022 Wormhole incident, which cost roughly $320 million, where attackers forged multisig verification and minted the equivalent amount of ETH out of thin air on Solana.
These incidents all point to the same structural problem: a multisig bridge's security depends entirely on whether that small group of signers is honest and whether their private keys are properly secured. Once the number of signers is too small, or insufficiently distributed geographically and organizationally, or a Private Key gets compromised, the bridge's entire reserve of assets is exposed to extreme risk — completely unrelated to the underlying cryptographic security of either connected chain.
In contrast to the multisig model, another bridge design adopts trust-minimized verification logic: rather than relying on a group of signers' testimony, the destination chain cryptographically verifies the source chain's state directly — implemented concretely through a Light Client, a validity ZK proof, or the destination chain maintaining its own validator set to directly verify the source chain's Block headers and transaction proofs. This design replaces "trusting what a small group of people say" with "independently verifying mathematical proof," theoretically removing the most fragile link in the multisig model.
Typical examples include each chain's own native Rollup bridges, Circle's Cross-Chain Transfer Protocol (CCTP) — which burns native USDC on the source chain and mints native USDC on the destination chain, requiring no wrapped assets and carrying no Liquidity Pool risk; CCTP V2, launched in March 2025, now covers more than 13 chains plus Solana — and bridges using optimistic verification logic, such as Across, which operates through the UMA optimistic Oracle: as long as no one disputes a message during the challenge window, it's treated as valid. Across has processed over $5 billion in cumulative volume with no major exploit as of mid-2026.
It's worth noting that even designs branded as trust-minimized are rarely fully trustless. Take the optimistic verification model: its security assumption is that at least one honest watcher must remain online during the challenge window, willing to dispute invalid messages — if every watcher goes offline simultaneously, a forged message would pass automatically with no one to challenge it. Take the light-client verification model: its security ultimately still depends on the security of the source chain's own Consensus Mechanism — if that consensus mechanism is attacked at scale, a light client has no way to independently identify that the resulting compromised chain is fraudulent. This means evaluating a bridge's security can't stop at labels like "trust-minimized" or "decentralized" — it requires specifically asking who you're actually trusting under this design, and what conditions have to hold for that trust to be justified.
If you regularly move assets across chains, it's worth taking the time to verify a few concrete things about any bridge before using it: what mechanism actually controls the assets (a small group's multisig, or cryptographic verification), how publicly disclosed the number and independence of signers or verifiers is, whether the bridge has experienced a major incident before, and whether its architecture was publicly adjusted afterward (some bridges, for instance, have publicly raised their verifier thresholds after being compromised). For larger transfers, prioritize bridge routes using native verification or cryptographic proof mechanisms over simply comparing which route has the lowest fee or fastest settlement — the difference in fees and speed is usually a matter of a few percentage points, but the security gap in bridge mechanism design can be the difference between keeping your assets and losing all of them.