Cross chain bridge security: a bounded incident ledger and trust-model review

Trust-model taxonomy: identify who can authorize the destination state

The central question in cross chain bridge security is what evidence allows a destination contract to accept a message about another chain. A bridge transfers a claim across a boundary with different state and verification rules. Its security argument must explain how the destination distinguishes an authorized message from a convincing substitute.

Describe the verification mechanism before assigning a marketing category.

A committee may sign messages, a light client may verify source-chain evidence or an optimistic design may rely on a challenge process. Liquidity-based transfers add another set of settlement and inventory assumptions. A bridge can combine mechanisms, so a single label may omit a privileged path.

The source and destination chains remain dependencies.

A proof can be correctly verified against a source state that has not reached the finality the application assumes. A destination can receive a valid message but process it twice or release the wrong asset. Verification of origin is therefore one part of the accounting and execution model.

Administrative authority is another layer.

A system with cryptographic message proofs can still expose an upgrade key able to replace its verifier. Record that capability beside the proof design. Otherwise, the taxonomy describes the normal route while omitting the route that can change the rules.

The Ethereum bridge documentation distinguishes externally verified designs from designs that rely more directly on connected-chain verification. Use those categories as an introduction, then inspect the concrete mechanism. The label trustless should not be read as a guarantee that implementation, upgrades and asset accounting require no review.

Keep a separate asset model.

Locked collateral, issued representations and liquidity claims are not interchangeable. A failure can create unbacked destination assets without immediately moving source collateral, or it can release source collateral against a forged destination message. The accounting invariant should identify the specific asset and chain.

For a deployment review, trace the message identifier, origin and destination context through verification and consumption.

Then identify the operation that marks the message processed. This creates a concrete test target for replay and domain-binding checks without assuming that a valid signature alone authorizes the full action.

Ethereum bridge architecture documentation supplies the taxonomy reference. The signature replay guide covers the message-binding questions that can arise within those models.

Incident ledger: loss, mechanism and audit status

The ledger below is a bounded historical cross-check, not a list of every major bridge loss.

It contains cases for which this review opened an incident analysis and audit-related evidence. Missing scope or causal evidence remains explicit rather than being filled from a current project badge.

Nomad's case connects initialization state to later verification logic.

Coinbase's technical analysis describes an initial committed-root value that caused a default mapping value to be accepted, followed by a change in the message-verification path. It dates the relevant infrastructure upgrade to June 21, 2022 and the attack to August 1, 2022.

The opened Quantstamp report is dated June 6, 2022 and lists source revisions.

That establishes a historical review record. It does not establish that the later deployed verification change matched the reviewed scope. The relationship requires a revision and deployment comparison; chronology alone cannot decide whether the exploit was in scope.

Ronin's June 28, 2022 reopening account names CertiK and Verichains as external reviewers after the March exploit. Those are postincident audits. Placing either firm in a column labeled auditor before the hack would reverse what the source establishes.

The reopening account states the drained asset quantities but contains a March day that conflicts with other historical accounts. This ledger therefore uses March 2022 without asserting the disputed day. It also does not derive a dollar loss from those token quantities. A valuation would need a stated price source and time.

Coinbase's Nomad technical analysis, the historical Quantstamp report and Ronin's reopening account support those rows.

The differing loss definitions prevent a defensible direct total. The Nomad figure is a dollar estimate from an analysis, while the Ronin row preserves asset units from the protocol's account. Adding them would require a conversion method that this ledger does not perform. Gross loss, outstanding liability and recovered assets would need separate fields as well.

An audit relationship should be represented as evidence, not a binary badge. A review may cover an earlier implementation, a fix round or a component other than the compromised route. Preserve the report date, revision and affected component before assigning any in-scope conclusion.

For Nomad, the actionable review question is how default values interact with a changed acceptance rule. A value that was benign under one verifier can become authoritative under another. Rehearse the upgrade against existing state and test uninitialized, absent and already processed messages. The importance of that test follows from the verified mechanism, not from assuming that the historical auditor caused the incident.

For Ronin, the opened evidence supports a different conclusion: later security work and a new control model should be recorded as later work. It cannot be projected backward into the original deployment. Keeping that limitation visible makes the ledger useful to an investigator who needs to know which primary artifact is still missing.

Our catalog census: bridge flags and failure labels are different fields

The public DeFiLlama response returned 1,253 records. Of these, 88 carried a true bridgeHack flag, but only 37 of those 88 used the classification Bridge & Cross-Chain. The remaining flagged rows were distributed across other failure labels. A bridge label identifies a context; it does not supply the trust model or a single root cause.

Method

Source

DeFiLlama hacks endpoint

Retrieved

September 5, 2026

Population

All 1,253 returned rows, retained without deduplication.

Selection

The 88 rows whose bridgeHack field is exactly true.

Counting unit

A catalog row and its publisher-supplied classification, not an independently verified unique incident.

Exclusions

No selected rows were dropped. No missing value was converted into a clean outcome.

Results

All 88 selected rows had an empty source field in the retrieved response. This limits what can be independently reconstructed from that endpoint alone. It does not establish that the catalog publisher or affected projects lack supporting evidence elsewhere.

Limits

• The classifications are publisher labels, not our adjudication of root causes.
• The bridge flag does not identify committee, light-client, optimistic or liquidity-based trust models.
• Possible duplicate or related records remain in the data, so the count is not presented as 88 unique bridges or attacks.
• No dollar total, risk ranking or architecture failure rate is calculated from this response.

Reproduction uses seo/research/incident-evidence-fields-survey.py; its dated output is seo/research/incident-evidence-fields-survey-2026-09-05.json. These files remain in the repository and are not published as downloads. The output preserves source responses, retrieval outcomes and the selection rules for later verification.

Patterns by trust model: use failure classes as review prompts

The catalog cannot rank trust models because it does not provide the required model field or an exposure denominator. It can still help organize questions for an architecture review. Treat each failure class as a prompt, then test whether the corresponding path exists in the chosen bridge.

For a signer-based design, examine who can produce the required authorization and how that set changes. The relevant dependency can include key custody, signer software and the authority that replaces the set. Counting signer addresses does not establish independent control. A single shared operating dependency can affect several apparent participants.

For a proof-verifying design, inspect the evidence accepted by the verifier, the source state it refers to and the code that updates that state. Then follow the message into application execution. A correct origin proof cannot prevent an application from interpreting the amount incorrectly or consuming the same message twice.

An optimistic route adds challenge and delay assumptions. Establish who can observe and dispute a claim, what evidence a challenge needs and what the destination does during that interval. The normal settlement duration is only part of the model; a challenge path that becomes unavailable changes the acceptance argument.

Liquidity-based transfers need an explicit settlement and asset-identity model. A user may receive a claim whose backing or redemption route differs from the asset's name in a wallet. Trace the issued representation to the collateral or settlement obligation it depends on. A familiar ticker is not proof of equivalence.

Emergency controls change both loss containment and availability. Ronin's historical reopening account describes withdrawal limits and administrative actions around them. For a current design, identify who can stop a route, who can restart it and whether an administrator can override an advertised limit. The interface should not imply a stronger restriction than the authority graph enforces.

The cost of a false acceptance and the cost of a false rejection differ. Accepting a forged message can create an irreversible claim. Rejecting valid traffic can trap liquidity or disrupt dependent applications. The audit should specify the intended behavior under uncertainty and the recovery process, rather than assuming that rejecting everything is an adequate operating model.

Source evidence

Define finality assumptions.

Destination check

Authenticate the message.

Asset accounting

Consume the claim once.

The upgrade audit guide addresses verifier changes and existing state. The incident response workflow adds the operating decisions needed when a bridge must restrict traffic.

Maintenance cadence: update the evidence before the conclusion

A maintained ledger needs a correction procedure as well as a retrieval date. Preserve the original entry when a later report changes the loss estimate, attributes a cause or clarifies scope. Add the new evidence with its publication date and explain which field changed. Replacing the old row without an explanation makes the history difficult to audit.

Use event-driven review for consequential changes. A new implementation, signer-set update, verifier dependency or postmortem can change the interpretation of a case. A scheduled editorial review can also check stale links and unresolved fields, but this article does not imply that an automated monitor has been installed.

Keep incident evidence and current-deployment evidence separate. A historical root cause can guide a test without establishing that a current bridge remains vulnerable. Conversely, a current audit cannot repair the historical record of which implementation was reviewed before a loss. Both records are useful when they retain their dates and scope.

1. Record the new source, retrieval outcome and exact field it can support.
2. Compare dates, asset definitions and component identifiers before changing a ledger value.
3. Retain an unknown verdict when the source does not connect the exploit path to the reviewed revision.
4. Review the current architecture separately if the bridge changed its verification or operating model.
5. Publish the correction with a clear explanation of the evidence that changed.

For a buyer commissioning a bridge audit, the ledger is a way to ask better questions. Request evidence for the verification model, message consumption, asset accounting and authority to replace those rules. The member directory and Halborn analysis provide provider context; the scope must still identify your own bridge and deployment state.

Do not choose an architecture from raw incident counts alone. The data would need comparable deployment exposure, asset values, observation periods and incident definitions before such a comparison could support a risk rate. The present census lacks those denominators and makes no such ranking.

The useful maintenance outcome is a ledger whose unknowns remain actionable. A missing report revision should lead to a revision request. An unresolved deployment match should lead to a code and state comparison. That approach preserves the distinction between a documented historical failure, a publisher's catalog label and an engineering conclusion about the bridge being reviewed.

The message record also needs chain-specific identifiers. A token address on one chain does not identify the same asset on another, and a protocol name can cover several bridge routes. Record the source asset, destination representation and route being evaluated. Otherwise, a later correction may attach an incident to a similarly named but technically different deployment.

Distinguish a paused user interface from a paused contract path. An operator may disable a website while direct contract interaction remains possible. The ledger should describe the control that actually changed and the evidence for its effect. A status announcement can support the communication timeline without proving that every value-moving route was blocked.

When an incident spans several transactions, preserve the difference between the first observed exploit and later copying or related extraction. Counting each transaction as an independent bridge failure would change the unit of analysis. This census deliberately retains publisher rows and does not claim to resolve that incident-level grouping.