Cowrie Research

bridge-verification-failure

20 min read

Bridge Verification Failure

  • Name: Bridge verification failure
  • Category: exploit pattern / bridge security failure / invalid-proof acceptance / signer-set or verifier compromise
  • Summary: A bridge breaks most catastrophically when its destination-side verifier accepts a forged message as authentic. That failure can come from stolen signer keys, a broken signature check, a poisoned trusted root, a bad light-client assumption, an event-driven relayer that mistakes a log for proof of locked value, or an upgrade that silently changes proof semantics. Once the verifier is lying, every downstream asset-release path becomes a mint or withdrawal oracle for the attacker.
  • What it is:
    • A bridge has some trust anchor that decides whether an inbound cross-chain message is real.
    • That trust anchor might be a multisig / guardian quorum, an optimistic root plus challenge window, a light client, a proof verifier, an offchain relayer that interprets source-chain events as deposit proof, or a modular verifier stack inside the destination contract.
    • A verification failure happens when attacker-crafted data crosses that boundary and is accepted as valid.
    • At that point the bridge no longer needs to be economically manipulated. It simply releases or mints assets against fake provenance.
  • Typical preconditions:
    • The bridge keeps valuable custody on the destination side or can mint a canonical wrapped asset there.
    • The verifier depends on a small trust anchor, a complex parser, upgradeable code, or externally managed signer state.
    • There is no secondary balance-sheet guard that limits what a single forged message can release.
    • Operators or contracts can update verifier state, membership, roots, or implementation without airtight invariant checks.
  • Common vulnerable surfaces:
    • multisig / validator bridge contracts with low quorum or poor key hygiene
    • guardian-signature parsing and signature-verification libraries
    • token registries and denom-to-asset mappings that decide which destination-side custody asset a source-side identifier refers to
    • event-driven relayers that mint or release assets from logs without separately proving msg.value, token transfer success, or balance deltas on the source side
    • offchain verifier / DVN observation stacks, RPC failover paths, and quorum designs that look multi-step onchain but still collapse to one operator or one data-source cohort
    • degraded-mode validation paths that preserve bridge liveness by weakening source-authentication or observation guarantees under outage pressure
    • optimistic root confirmation mappings and proof-status bookkeeping
    • light-client or header-verification logic
    • bridge upgrade initializers and migration scripts
    • destination-side process, execute, receive, withdraw, or mint paths that trust the verifier’s answer without rate limits, challenge windows, or circuit breakers
  • Exploit sequence:
    1. The attacker compromises or bypasses the bridge’s verification mechanism.
    2. The destination-side bridge contract accepts a forged message, proof, root, or signature set.
    3. The bridge executes the message as if assets had genuinely been locked or burned on the source side.
    4. Custodied assets are released or wrapped assets are minted unbacked.
    5. The attacker exits into deeper-liquidity assets, other chains, or cash-out rails before operators can pause the system.
  • Variants:
    • Signer-set compromise — enough validator / multisig keys are stolen or coerced to satisfy the bridge quorum, or a captured admin path can rewrite the endpoint that defines valid bridge withdrawals, as in ALEX XLink. When this is the main failure mode rather than just one bridge-specific variant, see signer-quorum-compromise.
    • Signature-verification bypass — the contract or runtime incorrectly verifies guardian / validator signatures and accepts forged attestations.
    • Trusted-root contamination — a root-tracking or proof-status bug marks an invalid or default root as acceptable, as in Nomad. For the deeper recurring pattern note on bootstrap / default / legacy verifier state inheriting execution authority, see proof-state-sentinel-collapse.
    • Proof-to-message binding failure — the verifier checks a real trusted root or header but no longer proves that the specific message being executed actually participated in that authenticated commitment, as in BNB Chain and Hyperbridge. For the deeper recurring pattern note, see proof-to-message-binding-failure.
    • Event / deposit-proof ambiguity — the bridge treats an emitted event or deposit record as equivalent to locked value even though the underlying source-chain call path, token transfer, or msg.value check did not actually move assets, as in Qubit and Meter Passport. For the deeper source-side value-authentication version of this bug class, see deposit-signal-locked-value-mismatch.
    • Message-source authentication failure — watchers or guardians authenticate a bridge-looking message without proving it came from the canonical emitter contract or custody-changing path, as in Alephium, pNetwork, Qubit, and THORChain. For the deeper source-authentication note, see message-source-authentication-failure.
    • Registry / asset-identity poisoning — a permissionless or weakly validated token-registration path lets an attacker poison the mapping between source-side denomination identity and destination-side custody assets, so honest validator-approved withdrawals release the wrong token, as in Gravity Bridge. For the deeper recurring pattern note, see asset-identity-registry-poisoning.
    • Cross-layer interpretation mismatch — one authenticated source-side artifact resolves to different asset identity or release semantics in different bridge layers, so downstream custody logic acts on a meaning the whole stack never canonically shared, as in Syscoin. For the sharper recurring pattern note, see cross-layer-interpretation-mismatch.
    • Local mint-authority substitution — a bridge-local quota, allowance, or signer-maintained ceiling becomes sufficient destination-side mint authority even though it no longer proves one exact source-side lock or burn, as in ChainSwap. The bridge is still accepting forged truth; it has just hidden that truth inside local quota bookkeeping instead of inside a classic proof verifier. For the sharper recurring pattern note, see local-mint-authority-substitution.
    • Verifier-composition failure — a modular verifier stack is misconfigured so the wrong verification module or threshold is treated as authoritative.
    • Observation-layer poisoning — the verifier signs an otherwise valid attestation over falsified source-chain state because the RPC, indexing, or observation path feeding it is compromised or single-sourced, as in KelpDAO’s 1-of-1 DVN route. For the deeper recurring pattern note on fake verifier diversity and shared observation stacks, see verifier-input-independence-failure.
    • Degraded-mode authenticity failure — the bridge preserves delivery during outage or connectivity loss by silently broadening its trust boundary, so fallback validation or failover accepts data that the primary path would have rejected. For the sharper recurring pattern note, see degraded-mode-authenticity-failure.
    • Upgrade-induced verifier regression — a migration, initializer, or refactor changes message-validity semantics without preserving the old safety invariant.

Three bridge-truth promotions reviewers should not collapse

  1. Some bridge-shaped artifact exists

    • A root, signature set, event, packet, burn record, quota mutation, or bridge-local attestation is visible somewhere in the stack.
    • That is only the weakest fact: something parseable happened.

  2. That artifact deserves to count as route-local bridge truth

    • The harder question is whether it came from the right source domain, the right emitter or custody-changing path, the right verifier or signer set, the right route, and the right asset-identity meaning.
    • Most catastrophic bridge losses happen here: the system promoted a weaker artifact into money-good source truth even though source authorship, locked-value meaning, proof semantics, verifier independence, or parser meaning had already drifted.

  3. That accepted bridge truth deserves this much destination-side authority

    • Even authentic-enough bridge truth should not automatically inherit unlimited reserve reach, arbitrary dispatcher power, unchanged degraded-mode limits, or rights over destination assets it was never meant to touch.
    • This is where bounded release, typed handlers, route-local redeemability, and narrower degraded-mode policy start to matter.

Healthy review gets materially better once teams stop flattening those three promotions into one vague moment called message verified.

One bridge-local headroom distinction worth keeping explicit

  • Transfer-derived headroom means one exact authenticated source-side transfer already created a bounded destination-side mint or release right, and the remaining local capacity is only the unspent remainder of that exact right.
  • Policy-authored route budget means an issuer, governor, or sovereign token-control plane intentionally granted a route-local mint ceiling as a treasury policy choice; that is still risky authority, but it is not pretending to be proof that one exact source-side transfer already happened.
  • Synthetic pseudo-headroom is the dangerous bridge-failure middle state: quota, allowance, fee-gated mint capacity, or signer-maintained ceiling is narrated like earned transfer-derived headroom but behaves like ambient local authority to print supply.

This umbrella note cares about the third state. If the system is honestly spending an explicit policy-authored route budget, the sharper review question usually lives in bridge-headroom-provenance-and-exact-consumption-discipline and often the token-control-plane note such as erc-7281, not in bridge verification failure alone.

  • Detection heuristics:
    • Ask what exact object proves authenticity on the destination side: signatures, roots, headers, fraud-window expiry, or some composition of them.
    • Check whether default storage values can be misread as valid verifier state.
    • Inventory what concrete infrastructure each verifier, DVN, or relayer actually reads from. Distinct signatures are not independent if they all inherit the same RPC provider, cloud-admin path, or failover cohort.
    • Review upgrade and initialization code with the same suspicion as the steady-state verifier path.
    • Look for one-shot release authority with no per-message caps, per-asset throttles, or independent accounting sanity checks.
    • Treat bridge verifiers as custody code, not middleware. Any ambiguity in proof semantics is treasury risk.
  • Defenses:
    • Keep the authenticity invariant brutally simple: invalid / unproven / uninitialized must never alias to valid.
    • Minimize privileged upgrade paths and formally test migration state, especially verifier roots, signer sets, and proof-status mappings.
    • Add rate limits, circuit breakers, and per-asset caps so one verifier failure cannot immediately empty the whole bridge.
    • Keep bridge-local quotas, fees, signer-raised ceilings, and mint allowances subordinate to a separately proven source-side custody event. Local operational headroom may narrow an already-authentic transfer, but it should never become the thing that makes new bridge supply look authentic.
    • Require genuinely independent verifier paths for meaningful value: separate operators, separate observation stacks, and separate failover domains, not just multiple signatures downstream of one infrastructure team.
    • Separate signer-key compromise assumptions from contract-bug assumptions; watchers for one are not monitors for the other.
    • Prefer explicit proof states over overloaded sentinel values, and test zero / empty / legacy cases aggressively.

What sound design looks like

  • One canonical source-side fact should authorize one bridge action: the same security object needs to bind the canonical emitter, the custody-changing path, the measured locked or burned value, and the asset identity being redeemed on the destination side.
  • One canonical message commitment should survive end to end: the exact transfer, mint, or admin action being executed must be the thing the root, header, or signature payload authenticated, not just a nearby root, log shape, or loosely related bridge artifact.
  • One verifier story should mean one real independence story: extra signatures do not help if their observation stack, failover path, or operator control still collapses to one upstream truth source.
  • One degraded-mode rule should dominate: if the bridge can no longer prove the same authenticity object under outage pressure, it should fail closed rather than silently broaden who or what is allowed to author bridge truth.
  • One bridge should keep artifact visibility, accepted bridge truth, and destination-side spending authority as separate states. A parseable packet, a money-good message, and a fully spendable release right should not be the same bit in different clothes.
  • One authenticity break should still be survivable: per-asset caps, pauses, and bounded release paths should stop a forged bridge truth event from immediately emptying every custody pool.

Failure-prevention checklist

  • Treat artifact exists, artifact counts as bridge truth, and accepted bridge truth can spend this much here as separate promotions in code, ops, and monitoring; do not let one success flag silently stand in for all three.
  • Define one canonical bridge security object per flow and write down exactly what it authenticates: source chain, source contract, source channel, asset identity, amount, nonce, destination, and action type.
  • Keep uninitialized, default, legacy, and already spent verifier states disjoint from valid. Treat zero values and empty proofs as adversarial inputs, not convenience cases.
  • Bind source-side value movement to destination-side execution. A release or mint should require proof of the exact custody-changing path, not just a log shape or bridge-looking message.
  • Make verifier composition explicit. If a route depends on guardians, DVNs, RPC observers, fallback signers, or failover modes, document which combinations are sufficient and test that no weaker combination accidentally becomes authoritative.
  • Require real operational independence where the design claims it: separate key custody, separate observation stacks, separate admin domains, and separate failover providers for high-value routes.
  • Put hard blast-radius limits under the verifier: per-asset caps, per-epoch limits, delayed large withdrawals, rate limits, and fast pauses that can stop an ongoing counterfeit-release stream.
  • Constrain upgrade and membership changes with the same paranoia as withdrawals. New roots, new verifier modules, new signer sets, and migration scripts should carry explicit invariant checks and rollback plans.
  • Reconcile bridge liabilities against source-side assets or burns continuously enough to catch counterfeit minting before secondary markets socialize the loss.
  • Design degraded-mode handling to fail closed. If the bridge cannot establish the same authenticity object during outages, it should stop releasing value rather than silently accept a cheaper proof story.
  • Drill the incident path operationally: who can pause which route, how quickly limits can be lowered, and how custody assets are ring-fenced when one verifier or chain route is suspect.

Audit prompts

Use these prompts to keep the three bridge-truth promotions separate during review: artifact exists, artifact counts as route-local bridge truth, and accepted bridge truth deserves this much destination-side authority.

Verifier semantics and proof binding

  • Which bridge-truth promotion is happening at each step here: parseable artifact, accepted route-local bridge truth, or destination-side authority to mint / release / dispatch against real value?
  • What exact bytes or state root does the destination contract treat as proof this transfer is real, and where is each semantic field actually bound?
  • Can any real authenticated object be replayed with a different leaf, asset mapping, destination, amount, or execution payload because the verifier proves only a nearby fact?
  • What default storage values, sentinel constants, legacy roots, or migration leftovers can be misread as already-approved proof state?
  • Can any bridge-local quota, signer-maintained ceiling, flat-fee path, or pre-authorization counter expand mint or release authority without simultaneously proving the exact source-side lock, burn, or message it is supposed to correspond to?

Source provenance and locked-value truth

  • Which source-side contract, channel, or custody-changing path is being authenticated? Could a bridge-looking event from another contract, helper path, or router branch produce the same attestation outcome?
  • Does the bridge ever equate event observed with value locked without separately proving token transfer success, native-value transfer, burn semantics, or balance delta?
  • Where does asset identity get fixed: source denomination, destination asset mapping, and route-local redeemability? Could a real proof still resolve to the wrong destination-side asset?

Observer, signer, and operator independence

  • Are there fallback or outage paths that reduce quorum, trust one RPC source, skip source-contract checks, or otherwise broaden who gets to define bridge truth?
  • How independent are the allegedly separate verification parties in practice? Trace infra providers, admins, key ceremonies, alerting, and emergency-access paths instead of trusting the architecture diagram.
  • Which admin, registry, membership, or config actions can redefine what counts as an authentic message, and how are those paths separated from day-to-day operations?

Destination-side reserve reach and incident response

  • If one forged message lands, what onchain or operator-side control actually limits cumulative loss before assets can be swapped out?
  • Can upgrades, signer-set rotations, registry changes, or emergency actions alter verifier semantics without a pause window, shadow validation, or invariant assertion?
  • Is there continuous liability reconciliation between wrapped supply / released custody and source-side locked or burned value, and who is paged when that invariant drifts?
  • Could a route-local quota, mint headroom bucket, or signer-maintained allowance quietly give a compromised route rights over a wider destination reserve than its own authenticated source-side transfer history should ever reach?
  • If one route is suspect, can responders narrow only that route’s mint / release authority, or does every destination reserve still sit behind the same authenticity failure domain?
  • Do pause drills, rate-limit drills, and cap-lowering drills prove that bounded-release controls still bind in practice, or are they only present as configuration claims in documentation?

Lessons that should already be standard

Verifier and message-semantics control surface

  • Bridges are custody systems wearing messaging clothes. Verification code, signer ops, observer infra, and upgrade paths all deserve treasury-grade review rather than middleware-grade review.
  • Something bridge-shaped happened, that thing counts as bridge truth, and that truth can now spend destination-side value are three different claims.
  • Authenticity must be single-story. If operators need a long explanation for what exactly proves a withdrawal is real, the trust boundary is probably already too ambiguous.
  • Bridge-local quotas are not substitute proofs. If a fee payment, signer-maintained allowance, or local quota mutation can authorize fresh supply without one exact source-side custody fact, the bridge has already outsourced truth to bookkeeping.

Observer, signer, and admin-independence control surface

  • Claimed decentralization is not a defense unless independence is real at the observation, admin, and key-custody layers. Multiple signatures downstream of one cloud, one team, or one fallback path are one failure domain.
  • The best time to discover that a signer set, DVN stack, or failover route collapses to one operator is before the first forged message, not in the postmortem.
  • Migration code, registry management, and signer-set maintenance are part of the live bridge security model, not peripheral maintenance. Many catastrophic bridge losses start when an apparently operational change quietly redefines truth.

Destination reserve and bounded-release control surface

  • Destination-side releases should assume the verifier can eventually fail and bound loss accordingly. Bridges that rely on perfect authenticity forever without caps or throttles are betting the treasury on one bug-free path.
  • A bridge should be able to answer, at any moment, which source-side assets back each destination-side liability. If that answer is slow, manual, or approximate, counterfeit-release detection is already too weak.
  • Route-local reserve segregation matters. If one verifier or route is compromised, honest routes should not automatically inherit the same uncapped reserve reach.

Degraded-mode and operational-response control surface

  • Fail open for liveness is usually just delayed loss recognition. High-value bridge routes should halt when authenticity becomes uncertain.
  • Incident response is part of bridge design, not an afterthought. If operators cannot quickly narrow blast radius, lower route caps, or de-recognize a suspect route, the verifier already has too much ambient authority.

Where this pattern stops

  • Use proof-to-message-binding-failure when the trusted root or header stayed real, but the verifier no longer proved that the specific attacker-chosen leaf or message actually lived under it, as in BNB Chain and Hyperbridge.
  • Use account-confusion-root-of-trust-substitution when the bridge-specific failure only paid because the verifier first trusted the wrong root object — for example a caller-supplied sysvar, config account, or integration endpoint — as the thing allowed to define verification reality, as in Wormhole.
  • Use message-source-authentication-failure when the bridge authenticated a bridge-looking log or payload from the wrong source contract, router side path, or forged emitter, as in Alephium, pNetwork, Qubit, and THORChain.
  • Use deposit-signal-locked-value-mismatch when the decisive lie is not wrong message source but source-side deposit record never proved matching value was locked or burned, as in Qubit, Meter, and THORChain.
  • Use degraded-mode-authenticity-failure when the route only becomes unsafe because outage handling, failover, or fallback validation silently broadens who or what counts as bridge truth, as in Alephium and KelpDAO.
  • Use verifier-input-independence-failure when the signatures are real but the supposedly separate verifier path still collapses onto one observation stack, RPC cohort, or operator-admin boundary, as in KelpDAO and some opacity-heavy operator incidents.
  • Use asset-identity-registry-poisoning when later validator-signed withdrawals are structurally honest but the registry already lies about which destination-side asset a source-side denomination is allowed to redeem, as in Gravity Bridge.
  • Use cross-layer-interpretation-mismatch when one authenticated payload or burn artifact was itself ambiguous enough that different bridge layers derived different asset identity or release semantics from the same bytes, as in Syscoin.
  • Use local-mint-authority-substitution when the bridge did not lose a classic proof verifier at all; instead, a destination-side quota, allowance, or signer-maintained amount bucket quietly became enough to print supply without one exact source-side custody fact, as in ChainSwap.
  • Use bridge-headroom-provenance-and-exact-consumption-discipline (and often erc-7281) when the bridge or token system is explicitly exposing a policy-authored route budget or bridge-local mint ceiling and the sharper question is not did local quota masquerade as proof? but is this budget honestly typed, route-local, revocable, and impossible to confuse with transfer-earned headroom?
  • Use signer-quorum-compromise when the bridge really did just lose enough signing authority to make counterfeit withdrawals authentic, or the same captured authority could rewrite the live endpoint that defined authentic withdrawals, as in Ronin, Harmony, and the ALEX XLink bridge-hybrid case.
  • Use operator-boundary-opacity when the important lesson is that the visible signer or MPC story never described the real effective control boundary in the first place, as in Multichain and likely Orbit.
  • Best concrete case studies:
    • Nomad — trusted-root contamination turning bytes32(0) into accepted bridge truth.
    • Wormhole — root-authentication collapse on guardian-signature verification.
    • BNB Chain Token Hub — forged proof accepted by the destination-side verifier, with the deeper recurring mechanics living in proof-to-message-binding-failure.
    • Hyperbridge — a strong modern trusted root, forged message cousin where one verifier edge case authenticated a fabricated admin payload and then escalated into mint authority.
    • Ronin — signer-quorum collapse as bridge-truth failure.
    • ALEX XLink — captured admin rewrote the live bridge endpoint that defined valid withdrawals.
    • Multichain — hidden-centralization custody story behind threshold branding.
    • Qubit — deposit-looking event accepted as proof of locked value.
    • ChainSwap — destination-side factory quota logic drifted into standing mint authority, so invalid non-whitelisted addresses could expand mintable amount, pay a tiny per-call fee, and print unbacked mapping tokens across many assets.
    • Alephium — forged emitter plus degraded validation path.
    • KelpDAO rsETH — fake verifier diversity collapsing to one poisoned observation path.

Internal linkages

Control surface

Graph View

Backlinks