TL;DR: Cross-chain bridges keep losing funds when destination-side checks accept fabricated, replayed, or reinterpreted source events, according to Blockaid's H1 2026 Onchain Security Report, which also highlighted at least seven notable bridge incidents in the first half of the year. The controlling assumption is that a verified message proves a real deposit, and that assumption breaks whenever the bridge trusts representation instead of observable source-chain state.
At a glance
What this is: This is an analysis of why cross-chain bridges keep paying out real funds for deposits that never happened, with recent incidents showing the same verification failure across multiple networks.
Why it matters: It matters because bridge governance is really trust-boundary governance, and IAM teams managing privileged signing, offchain relayers, or policy enforcement need controls that validate state before any release occurs.
By the numbers:
- Blockaid's H1 2026 Onchain Security Report flagged at least seven noteworthy bridge incidents led by the $292 million KelpDAO exploit.
- July and August produced 10 more bridge-verification incidents totaling roughly $24.6 million, with about $2.7 million recovered.
- Across Protocol lost roughly $4.5 million to forged deposits, Wanchain lost about $9.3 million to a reused signature, and Verus lost $7.54 million to an unbound payout.
Context
Cross-chain verification is the problem of deciding whether a destination chain should trust a message that claims a source-chain event happened. The article shows that the destination side often relies on a representation of the source event rather than the event itself, and that is where the control gap begins.
For IAM and NHI practitioners, the useful analogy is not user authentication but delegated trust: a relayer, signer, or bridge contract is accepting proof of state change from a different system. When that proof is wrong, the resulting release decision becomes a governance failure, not just a technical bug.
Key questions
Q: What breaks when a bridge verifies a message instead of the source-chain event itself?
A: The bridge can release real value for a deposit that never happened. A signed proof may confirm that bytes were produced, but it does not prove the source transaction succeeded, the amount was funded, or the destination payout is justified. Governance fails when verification stops at the message layer instead of the state transition layer.
Q: Why do offchain relayers and indexers create bridge risk?
A: They sit inside the trust boundary and can turn failed or fabricated activity into an apparently valid withdrawal request. If those components do not verify source-chain success and contract legitimacy, downstream signers may approve a payout that should never have existed.
Q: What are the signs that cross-chain verification is failing?
A: Look for payouts triggered by reconstructed events, reused signatures, inconsistent parsing between components, and destination releases that cannot be tied cleanly to funded source-chain activity. Those symptoms show the bridge is trusting representation more than state.
Q: When should teams stop treating bridge signing as a routine approval flow?
A: When a destination payout can move material value without an independent check that the source event really happened. At that point, signing is no longer administrative friction. It is the last control preventing a forged message from becoming an irreversible loss.
Technical breakdown
Why destination-side verification fails
A cross-chain bridge cannot directly observe the source chain, so it relies on a proof, signature, relayer message, or re-observation path to represent what happened elsewhere. That design works only if the representation is bound to the actual funded event. The article's examples show the failure modes clearly: forged deposits, reused signatures, and unbound payouts all exploit the gap between a valid message and a real source-chain state change. In practice, the bridge is trusting a claim about reality rather than the reality itself.
Practical implication: validate source-chain state, not just the cryptographic wrapper around it.
Why encoding and parsing ambiguity is so dangerous
A valid signature does not always mean a valid intent. If two components parse the same payload differently, an attacker can shift byte boundaries, reinterpret field values, or reuse a signed message in a context the signer never meant to authorize. Wanchain illustrates this pattern: the MPC signed one withdrawal, but non-injective encoding let the attacker make that same signature authorize a much larger unlock. This is a classic trust-boundary problem where agreement on bytes is not the same as agreement on meaning.
Practical implication: canonicalize message formats and reject any payload that can be parsed more than one way.
Why offchain relayers belong in the trust boundary
Relayers, indexers, and re-observation services are often treated as plumbing, but the article shows they can decide whether a failed or fabricated event becomes an accepted withdrawal request. Across Protocol's July incident came from reconstructed deposit-like data that had not been adequately checked against successful source-chain execution. Once an offchain component admits bad state, honest signers downstream can still turn it into a loss. The bridge is only as trustworthy as the weakest component that feeds its signing path.
Practical implication: bring relayers and indexers into formal controls, monitoring, and approval logic.
Threat narrative
Attacker objective: The attacker wants the bridge to release real assets against a source event that never happened, then move the funds beyond recovery.
- Entry occurred when the attacker supplied fabricated, replayed, or re-encoded source-event data into bridge verification paths that were meant to confirm legitimate deposits.
- Credential access was not the issue here. The attacker instead abused trust in proofs, signatures, relayers, and message formats to make the bridge accept a false authorization signal.
- Escalation happened when the destination side treated that false signal as sufficient to release reserves, mint value, or unlock funds from escrow.
- Impact followed as real assets left protocol control, with recovery depending on how quickly defenders could freeze, burn, or contain the outflow.
NHI Mgmt Group analysis
Cross-chain verification is a trust-boundary problem, not a contract problem: the bridge fails when destination-side systems accept representation as proof of reality. That means the real control plane spans source-chain state, offchain relays, signing policy, and payout logic. Practitioners should stop treating the bridge as a single application and govern it as a distributed authorization process.
Canonical message binding is the critical control gap: the Wanchain case shows that a valid signature can still authorize the wrong action when fields are ambiguously encoded. This is not just a software quality issue. It is a governance failure over what exactly was approved, and the implication is that every signed payload must be unambiguous at the semantic level, not only at the cryptographic level.
Offchain verification paths are first-class security components: Across demonstrates that relayers and indexers can convert a failed or fabricated event into a payout request that downstream systems trust. That puts them inside the security boundary alongside signers and contracts. The practitioner conclusion is simple: if an offchain component can influence value release, it needs production-grade control ownership.
Response speed determines the final loss curve: the article's Elastos and Verus examples show that the same class of failure can produce radically different outcomes depending on containment speed. This is a reminder that verification failures are also incident-response problems. The field should measure not only whether a bridge can be fooled, but whether it can stop the outflow before the funds clear into a mixer.
Identity and privilege assumptions are too narrow for bridge governance: these systems rely on a chain of delegated trust that resembles privileged non-human identity behaviour more than traditional user access. The control issue is not who logged in, but which component is allowed to speak for state, and under what checks. That makes governance over signer policy, relayer authority, and destination-side policy enforcement the real security requirement.
What this signals
Identity governance for bridges should be designed around delegated trust, not just keys and signatures: the real question is which component is allowed to speak for source-chain reality. When relayers, MPC signers, and policy engines each participate in the decision, governance has to cover the full authorization chain or the weakest parser becomes the point of failure.
Cross-chain payout controls need to move upstream: once a forged event reaches the signing layer, the damage window is already narrow. The practical shift is to validate source state and message semantics before any destination-side signing step, because post-signature recovery is usually a race defenders lose.
Bridge teams should treat response speed as a security control: the article shows that containment can dramatically change loss outcomes even when the underlying verification flaw is the same. That means freeze authority, burn paths, and consensus escalation belong in the operating model, not in a postmortem only.
For practitioners
- Bind payouts to source-chain state Require every destination release to match a real, funded source event before any value leaves the bridge path. Treat the proof as evidence only, not as final authorization.
- Canonicalize signed payloads Define one parseable message format for every signed bridge request and reject any encoding that could produce two different meanings from the same signature.
- Bring relayers into control scope Assign ownership, monitoring, and approval rules to relayers and indexers because they can transform failed source events into accepted destination-side requests.
- Screen every outflow before signing Simulate the destination-side transaction against live state and block signatures when the resulting transfer does not correspond to a valid source event.
- Plan for rapid containment Pre-authorize freeze, burn, or consensus-response paths so a verified forgery can be stopped before it exits into a mixer or other irreversible sink.
Key takeaways
- Cross-chain bridge losses keep recurring because destination systems accept proofs that do not sufficiently bind to real source-chain state.
- The recent incidents in the article show three recurring failure modes: forged deposits, reused signatures, and unbound payouts.
- The strongest defence is to validate source state and destination intent before signing, then retain fast containment paths for anything that still slips through.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Bridge verification failures often begin with untrusted message paths and forged event inputs. |
| NHI-05 — Overprivileged NHI | Relayers and signing components can release value if their authority is too broad. | |
| Recommendation — Treat any path that supplies signed bridge inputs as sensitive and block forged or replayed event data. Restrict bridge relayers and signers to the minimum authority needed to approve destination payouts. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The incidents hinge on abusing trusted signing paths to move value across systems. |
| Recommendation — Map forged-event bridge abuse to credential access and lateral movement tactics in your threat models. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Destination-side releases depend on strict authorization over which component may approve value movement. |
| Recommendation — Apply PR.AA-05 to every bridge signer, relayer, and approval path that can release funds. | ||
| CIS Controls v8 | CIS-5 — Account Management | Bridge operations depend on controlling who and what can authorize cross-chain payouts. |
| Recommendation — Use account management controls to review and remove bridge signing authority that is no longer required. | ||
Key terms
- Cross-Chain Verification: The process a bridge uses to decide whether activity on one chain should be treated as valid on another. It is not proof of history on its own. The security issue is whether the bridge can bind a destination payout to a real source-chain state change.
- Relayer: A relayer is a component that carries messages or state between blockchains. It acts as part of the trust boundary for cross-chain communication, so defects in relayer logic can affect message integrity, asset movement, and the reliability of interactions between separate networks.
- Standard Encoding: Standard Encoding is a method of representing data with a common character or byte scheme so it can be transferred or stored consistently. Attackers abuse encoding to hide commands, payloads, or indicators from simple inspection, so defenders should inspect decoded content, flag unusual encoding chains, and validate where encoded data is accepted.
- Destination-side Authorisation: Destination-side authorisation is the practice of checking permissions on the target object, not only the source object being modified. It matters in move, copy, reorder, and delegation workflows because access to the original item does not imply access to the destination context.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org