Topic starter
23/10/2026 12:45 am
TL;DR: Repeated bridge losses keep happening when destination-side checks accept fabricated, replayed, or reinterpreted source events, Blockaid's H1 2026 Onchain Security Report found. Bridge governance has to bind payouts to observable source-chain state, or forged messages can still drain liquidity.
Editorial analysis by NHI Mgmt Group, based on content published by Blockaid: “Cross-Chain Verification Failures: How Bridges Lost Another $24.6M and How Onchain Teams Stay Protected”.
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.
Key questions
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.
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.
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.
Practitioner guidance
- Bind payouts to source-chain state Require every destination release to match a real, funded source event before any value leaves the bridge path.
- 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.
Bottom line: Cross-chain bridge losses keep recurring because destination systems accept proofs that do not sufficiently bind to real source-chain state.
Glossary terms: Cross-Chain Verification, Relayer, Standard Encoding, Destination-side Authorisation
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 6 days ago by NHI Mgmt Group
23/10/2026 9:49 am
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.
A question worth separating out:
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.
👉 Read our full editorial: Cross-chain verification failures keep draining bridge liquidity
This post was modified 6 days ago by NHI Mgmt Group