A Bridge Does Not Inherit the Chain's Guarantees — Why Cross-Chain Bridges Keep Getting Drained

2.6 billion dollars vanished between chains

Between 2021 and 2023, more than 2.6 billion dollars in crypto-assets were stolen in attacks targeting "bridges". A study analyzing the transactions these bridges handled during that period provides the tally at the outset (arXiv:2410.01107). Tallies with different timeframes point in the same direction. Counting from May 2021 onward, it is 3.2 billion dollars (arXiv:2410.02029), and some estimates put it close to 4.3 billion dollars since 2021 (arXiv:2410.14493). A SoK—in other words, a systematization of knowledge paper that gathers and structures research in a field—calls bridges "the single largest source of financial losses in Web3" (arXiv:2507.06156, preprint).

A bridge is a connecting device that moves assets or data between different blockchains. When you want to use tokens residing on Ethereum on another chain, it connects the two sides. As seen in "The Right to Write a Line in the Ledger", a token is a broad term for a share written in a ledger.

Let us follow a person. Ga has tokens on Ethereum and wants to use them on another chain B. However, a line in the Ethereum ledger cannot simply be copied over to the ledger of B. The two ledgers are held separately by different witnesses and cannot read each other.

Therefore, the bridge matches rather than moves. Lock-and-mint is a method where an asset is locked on the original chain, and a corresponding token is newly minted on the destination chain, representing the typical form of a bridge. When Ga sends tokens to the bridge contract on the Ethereum side, the contract locks them up. As defined in "What Is a Smart Contract?", a smart contract is a program with conditions and tasks written into a ledger, executed automatically without human judgment. Then, the bridge contract on side B mints an equivalent share of tokens for Ga. When returning, those tokens are burned on B, and the locked share is released on Ethereum.

There is a blank space in this scene. The contract on side B cannot read the Ethereum ledger directly. Someone or something must report "it has been locked over there" for it to minting to occur. What is used as that someone or something differs from bridge to bridge, and this article follows that blank space.

What blockchains boast is that they can be verified without trusting others. The fact that this transaction is included in this block on this chain can be verified independently without borrowing anyone's word. Hence, people often expect that because countless nodes holding copies of the ledger verify the same ledger and reversing that consensus costs an immense amount, assets crossing a bridge will be equally secure. The authors of an SoK see it the other way around. They write that bridges often offer inferior security guarantees compared to the underlying blockchains (arXiv:2403.00405, preprint). The question of this article is why the chains remain intact while the bridges collapse, and collapse repeatedly in the same spots.

This article does not evaluate specific bridges, explains the structure of vulnerabilities, but does not provide procedures to copy them. Many of the cited papers are preprints released before peer review, and all figures are values at the time those papers were measured.

A large share of stolen funds came from signing keys

There is a figure that shows most directly where stolen funds came from. A significant portion of stolen funds (65.8%) came from projects that were protected by a permissioned intermediary network and whose cryptographic key operations were not secure (DOI: 10.36227/techrxiv.24595764, preprint). This is the result of an SoK that classified 50 interoperability solutions using 178 documents filtered from 531 sources, and organized 45 cross-chain vulnerabilities and 25 theoretical attacks, mapped against a list of 14 major bridge hacks with total losses exceeding $2.9 billion.

A permissioned intermediary network is a structure that fills in the blanks from the previous scene with pre-selected participants. The validator set is a group of participants predetermined by the bridge, who verify what happened on the other chain and attach a signature to that verification. They may be people or servers. The validators in "Consensus Without Trust" were participants who produced and verified the next block in the ledger, and in chains that finalize through a quorum, security hinged on the quorum of those validators—that is, the number deemed sufficient to finalize a decision. Even if the name is the same, the validators of a bridge have a different job. Their job on the bridge is not to produce blocks, but to verify and sign what happened on the other ledger. While some designs run their own separate chain and also produce blocks, the bridge's share of the work is this verification and signature. The requirement that more than a designated number must sign before anything moves has the same architecture as the multisig in "Where Are My Coins?", where a set number of keys out of many must sign together for the line to move.

What is used for that signature is the signing key. The signing key is the private key from "Keys and Locks"—the key that only the owner holds and never sends anywhere. If a key leak occurs where that key falls into the hands of someone other than the owner, the box opens even if the math of the lock is completely fine. The place this figure points to is the same. In a large share of the stolen funds, what collapsed was not the chain's consensus, but who held the signing keys and how they protected them.

When there is only a single validator, this structure becomes the thinnest. In April 2026, attackers exploited a single-validator configuration on a bridge for a service called KelpDAO to forge cross-chain messages and drain funds. The scale was about $292 million at the time of valuation, or 18% of the token supply (DOI: 10.2139/ssrn.6699478, a preprint covering this incident). When the size of the validator set is 1, the assumption that "the majority must be honest" shrinks to "that single one must be honest." The chain's consensus tells us nothing about that shrinkage.

The results of formalizing the structures of 13 major bridge designs and evaluating 23 attack vectors and 43 attack scenarios also point to overlapping places. Design flaws repeated across both static code and transaction networks, particularly in validator trust assumptions, access control, and verification logic. As countermeasures, defensive mechanisms like layered verification and circuit breakers were proposed together (arXiv:2507.06156).

Crypto-asset systems are often built so that the party holding the key holds the power to move funds. This ties control over cryptographic keys to financial control. Losing the key makes the spending authority disappear, and compromising recovery makes theft possible (arXiv:2608.07104). This SoK, which systematized key recovery, points to "recovery shifts trust" as one of its findings (arXiv:2608.07104, preprint). "Where Are My Coins?" concluded that whether you hold the key directly or entrust it to someone else, the risk does not disappear—only which risk changes hands and to whom. It is the same on a bridge. Because the power to unlock the locked share lies in the signature of the validator set, a bridge protected by a validator set shifts trust from the chain's consensus to the validator set and their keys.

Accidents repeat in the same patterns

Bridge accidents are not a new attack every single time. The work of gathering accidents and grouping them into patterns has emerged repeatedly. Potential attack vectors that attackers can target were organized into 12, and actual attacks from the 2 years prior were divided into 10 types (arXiv:2312.12573, 2023 SoK). Across 60 bridges and 34 exploits over 3 years, 13 architectural components led to 8 types of design flaws (arXiv:2403.00405, 2024 SoK). An exploit is an attack that actually digs into a vulnerability to siphon off funds. This means accidents of the same shape have repeated often enough for lists to be made.

A 2026 preprint puts this repetitiveness to the test. The authors systematically reviewed the literature to create a classification system cross-referencing bridge structures, verification models, trust assumptions, and attack categories. They then designed a rule-based score that estimates risk using only seven publicly observable design parameters. The authors deliberately emphasize that these are rules anyone can follow and calculate, rather than machine learning. When they retroactively applied this score to 8 publicly documented bridge accidents and 2 unexploited comparison targets, the hacked designs were consistently assigned a higher risk tier (DOI: 10.21203/rs.3.rs-10534111/v1, preprint).

The authors also noted the limitations of the retroactive validation and threats to its validity. If you design a score after an accident has already happened, it is easy for a high score to end up on the accident side. Therefore, the scope of what these results tell us is as follows. Across these ten bridges, scores assigned using only public design information successfully separated the hacked side from the unhacked side. This validation did not measure whether those scores could have predicted accidents before they happened.

The Bridge Didn't Count What Was Locked and What Was Issued

There is also a formalization that bundles recurring flaws into one. The authors of a preprint presenting an empirical analysis of 10 million transactions processed by major bridges from 2021 to 2023 conclude: although the exploits differ across attacks, beneath all of them lies a single design flaw: the absence of end-to-end value accounting in cross-chain transactions (arXiv:2410.01107, preprint). End-to-end value accounting means tallying the amount locked at one end and the amount issued at the other end from start to finish to ensure they match.

What the authors wrote is a simple invariant: that cross-chain inflows and outflows must match. An invariant is a condition that must always remain true no matter what state the system is in. This condition did not conflict with normal usage while precisely pointing out every known attack within this data. The authors report that this method can be used for post-mortem audits as well as built directly into existing bridge designs as a universal protection to prevent a wide range of bridge vulnerabilities (arXiv:2410.01107).

To shift back to the earlier scene: the bridge itself was not counting whether the share locked on the Ethereum side and the tokens minted on side B matched.

What Bridges Assume

We look again at where the correspondence in the opening scene is located. The locked assets and the issued tokens are written in different ledgers on different chains. The two ledgers cannot read each other. The correspondence between what is locked and what is issued is what a bridge promises, and neither chain guarantees it.

The method of that promise also differs from bridge to bridge. Five cross-chain token standards all share the goal of "existing on multiple chains while maintaining a single total supply," but their implementation methods, trust models, and target ecosystems differ significantly (arXiv:2603.06388). This means they are making different promises toward the same goal.

Instances where promises were not kept have also been observed. When data from the two attacked bridges, Ronin and Nomad, was examined using logical rules, transactions that caused massive losses were identified. In the process, other anomalies were also revealed. There were 37 cross-chain transactions that the bridge should not have accepted, as well as failed exploit attempts. Over $7.8 million worth of tokens were locked on one chain but never ended up being released on Ethereum, and $200,000 was lost because users mishandled the bridge (arXiv:2410.02029). The last two items were classified as anomalies rather than attacks. Tokens that remained locked and unreleased represent a misalignment between the locked side and the issued side without any attack occurring. Correspondence breaks down even without an attack.

The same story emerges from the code side of bridge contracts. A vulnerability is, as defined in "What Is a Smart Contract?", a gap that causes unintended results for the creator whenever anyone simply invokes it according to the written rules. The reason why finding such gaps in bridge contracts using tools—namely, automated code auditing—is difficult is twofold: access control conditions required for cross-chain asset exchanges vary by application, and it is hard to detect when the cross-chain semantics on both sides of the bridge conflict with each other (arXiv:2406.15999). Static analysis tools targeting these two difficulties recorded a precision of 84.95% and a recall of 89.77% on a labeled dataset of 88 vulnerabilities. Across 129 operational bridge applications, they found 232 previously unknown vulnerabilities (arXiv:2406.15999).

Both difficulties point to the same reality. There is no standardized correct answer on a bridge, and each bridge follows its own rules by itself.

There is nowhere written which two ledgers make a pair

People say blockchains are transparent. Within a single chain, that is true. Cross-chain transactions are recorded in two separate pieces, one on each chain, and there is no record anywhere that ties those two pieces together.

The fact that there is no record pairing up a cross-chain transaction makes tracking funds, detecting advanced vulnerabilities, and conducting transaction-graph-based analysis all difficult (arXiv:2511.01393). One way to find the pairs is to use a large language model to narrow down candidate clues for pairing and then verify them again by the transaction amount, achieving an average F1 score of 0.9746 across roughly 500,000 transactions from 5 major bridges. This score bundles together the accuracy of what was found and how much was not missed, where closer to a perfect score is better. In this process, the semantic search space for picking clues was reduced from 10 to the 10th power to under 100 (arXiv:2511.01393). This means there were that many candidate spots just in figuring out which entry of the transaction record held the clue to form a pair.

Looking at the same problem from a different angle, the authors of a study point out that existing methods relied entirely on internal ledgers or APIs that cannot be seen from the outside. That is evaluated as running counter to the openness and decentralization of blockchains. Using that study's method, deposit transactions were identified 100% and withdrawal transactions were paired 95.81% using only the execution history of the bridge contract (arXiv:2409.04937).

More noteworthy than the accuracy is the fact that pairing was itself a research problem. If the correspondence had been explicitly recorded, there would be no reason to guess. Even the data to study did not exist. There was no public dataset of cross-chain transactions to study interoperability protocols, and a framework built to fill that void identified some 11.28 million cross-chain transactions across 11 chains and 5 protocols (arXiv:2503.13637). On the bridge, even "seeing," the first step of monitoring, was a research problem.

New Cracks in the Bridge Handed Out First

One trend aimed at improving user experience is intent-based design. An intent-based bridge is a structure where, once the user simply states the desired outcome—"I want to receive this asset on that chain"—off-chain participants called solvers advance their own funds to fill the request immediately and get settled later. Instead of waiting to cross the bridge yourself, someone over there hands it across to you first.

The experience improves, but a new system risk arises. The issues are the concentration of the money the solvers must advance—that is, liquidity—in a few places, and delayed settlement. A 2026 preprint analyzing this structure defines a new class of attack called liquidity exhaustion attacks (arXiv:2602.17805). The authors analyzed 3.5 million cross-chain intents that moved $9.24 billion across 3 major protocols and 9 blockchains from June to November 2025 by replaying them.

The result is that the safety of the protocols depended on the parameters at that time. Assuming profit-seeking attackers, the side with high solver profitability was vulnerable under the parameters of the time. The side with low solver margins and very deep liquidity was robust across all tested configurations, and another side was mostly safe but became vulnerable under stress conditions. Assuming attackers willing to take losses just to cause disruption, service could be brought to a halt in all three protocols (arXiv:2602.17805). These values were measured in that period and under those parameters, so they do not tell us which protocol is safe right now. Translated into structure, in a design that has someone else advance money for the sake of speed, drying up that money becomes the attack. Convenience and a new attack surface emerge together from the same design.

Whether multiplying bridges ties chains together as one to that extent is also something to be measured separately. A measurement study covering 2022–2025 data from 20 chains and 16 bridge protocols reports that the connectivity created by deployed bridges (structural interoperability) and the movement driven by actual use (active interoperability) diverge significantly. The authors conclude that connectivity alone does not mean economically meaningful integration (arXiv:2604.03083).

Directly measuring whether the shock of one bridge being hacked spread to other tokens using the same infrastructure is the subject of the earlier preprint covering the April 2026 KelpDAO incident. The author pre-registered the analysis method and compared the prices of nine tokens before and after the event. They looked at whether tokens using the same bridge infrastructure shook more than those that did not. While the hacked token itself deviated significantly, other tokens using the same infrastructure showed no statistically meaningful difference. The author presents this discrepancy itself as a finding. Operators stopped their bridges as a preventative measure, but the price data aligned with the market viewing the incident as an individual failure rather than a problem with the infrastructure as a whole (DOI: 10.2139/ssrn.6699478, preprint). Because this is a single preprint covering a single event, it cannot be generalized.

Designing a Bridge That Doesn't Require Trust

If the problem with bridges is that you have to trust a set of validators, there is a way to make them trust-minimized. A trust-minimized bridge is a bridge that lets this chain check the records of that chain directly instead of relying on bridge operators, reducing the group of people you have to trust separately.

There are two paths. One is the light client. A light client is a miniature validator that does not receive all the data from that chain, but instead uses only the header of a block to verify for itself that "this event really happened on that chain." The other is a succinct proof. It compresses claims about the state of that chain into a short cryptographic proof, letting this chain check only that proof. Succinctness, as we saw in "Zero-Knowledge Proofs: Proving the Truth Without Revealing the Data", is a property where the size of the proof and the verification time are much smaller than the original data. Both paths fill the blank space from the previous scene with that chain's own records instead of a validator set's signatures. Instead of reducing the separate group of people to trust, this bridge leans on the assumption that the consensus of that chain is being upheld over there. Saying that there are no "external" trust assumptions, as later research puts it, means there is no separate group of people to trust other than that chain's consensus.

Representative research on the succinct proof side diagnoses that existing solutions suffer from performance problems or rely heavily on trust assumptions in committees, significantly lowering security. The authors report that the bridge they built significantly reduces on-chain verification costs without external trust assumptions (arXiv:2210.00264). On the light client side, the problem is that costs balloon. If there are N chains, they must each run light clients for one another, so the required number is proportional to N². The development team of one relay chain design reports that they reduced this to be proportional to N, cutting on-chain costs by about 35%, and actually deployed it to support over 6 public chains (arXiv:2411.00422).

While these designs exist and some actually run, the tradeoffs with cost, delay, and generality remain. Even if individual cryptographic protocols are secure, combining several of them can make them insecure. Using a trusted custodian can strip away most of the benefits that decentralization provides (arXiv:2212.09227).

There is also a path of not building a bridge at all. An atomic swap is an exchange where assets on different chains are traded directly, but with the guarantee that either everything succeeds or everything fails—only one of the two happens. Since there is no intermediary, there is no need for a validator set or signing keys. Three guarantees that such an exchange must maintain are defined formally, and the protocol can be built using hash time-locked contracts (arXiv:1801.09515). A hash time-locked contract is a contract locked with the hash of a secret value and given a deadline, and it can only be unlocked by revealing that secret value within the deadline. A hash, as defined in "What Is a Blockchain", is taking any long text and shrinking it down into a single short value of a fixed length. Conditions under which such a protocol is impossible were also proved in the same paper. In a diagram where arrows represent who transfers assets to whom, if you cannot travel from anyone to anyone else following the arrows (if it is not strongly connected), such a protocol does not exist (arXiv:1801.09515).

Even if atomicity is guaranteed, fairness is another matter. Hash time-locked-based swaps are like an American call option received without a premium—in other words, the right to choose whether or not to complete a transaction for free at any time before the deadline. The party that initiated the exchange can simply let the deadline pass if conditions turn unfavorable while waiting, and the counterpart's assets remain locked in the contract during that time. The loss belongs entirely to the counterpart. Analyzing this structure with game theory, the authors conclude that this model lacks fairness, and propose a method where both sides stake a premium along with the principal (arXiv:2211.15804). Griefing is harming others while accepting one's own losses, and the griefing factor is the ratio of the victim's loss divided by the loss accepted by the attacker (DOI: 10.3389/fbloc.2023.1137155). What can be targeted in an atomic swap is the counterpart's time and locked capital rather than funds.

An atomic swap only works if there is a counterpart to trade with. A bridge lets you cross alone without having to find a counterpart.

What Detection Catches, and What It Misses

If we cannot prevent every collapse, the remaining path is to notice the moment of collapse. The detection tools scored well in their respective evaluations.

The first tool to systematically address bridge security documented three new classes of security bugs, detected all known attacks across four major bridges using those patterns, and found suspected attacks that had not been reported until then (arXiv:2208.07119). A study collecting 49 incidents from June 2021 to September 2024 showed that attacks targeting cross-chain business logic—in other words, the operating rules of the bridge spanning two chains—caused significantly more damage than other attacks. The tool from this study achieved a recall 36.32% higher than the previous best tool (arXiv:2410.14493). A tool modeling the source chain, off-chain coordination, and destination chain within a single graph achieved an average F1 score of 92.58% across 51 actual attacks. This study points out that most existing methods only deal with the behavior of a single chain and fail to capture cross-chain semantics (arXiv:2508.20517).

Formal methods have also advanced. Formal verification is a method of writing down the properties that code must obey in the language of mathematics as defined in "What Is a Smart Contract?" and checking them. A tool that sets the business logic specification of a smart contract as a formal model and monitors whether execution violates it detected attacks across 54 exploit evaluations with zero false positives (arXiv:2305.08254). An iterative process combining a large language model and a model checker found bugs within a maximum of two iterations across three cross-chain targets, and independently discovered vulnerability classes absent from human-written baseline specifications (arXiv:2604.12172, 2026 preprint).

These report cards share a common premise. Monitoring without false positives is only possible when precise specifications exist (arXiv:2305.08254). The iterative process of the language model and model checker allowed the language model to write specifications directly and find gaps outside human-written specifications, but whether those specifications properly translated the bridge's promises still needs to be checked separately (arXiv:2604.12172). Learning-based detectors were evaluated on attack incidents that already occurred. The authors of one study report that they can catch unknown attack transactions as well, but it is impossible to know from the abstract alone just how unfamiliar those "unknowns" look (arXiv:2410.14493; arXiv:2508.20517). Accounting invariants are tools for catching violations of value conservation, and do not replace determining what the bridge promised (arXiv:2410.01107). Nor can humans oversee everything instead. It is nearly impossible for humans to individually inspect and test every potential trap and possible cross-chain interaction in an interoperability protocol (DOI: 10.3389/fbloc.2023.1248962).

Let us re-examine what logic rule checks found. 37 transactions that the bridge should not have accepted, and over 7,800,000 dollars worth of tokens that remained locked and were never released (arXiv:2410.02029). Among these, the tokens that were not released are not classified as attacks. Detectors that only look for attacks leave broken counterparts behind without an attack.

The authors of one design study trace the fundamental vulnerability of existing bridge security models to binary thinking. Their diagnosis is that bridges are either completely normal or catastrophically compromised, with no intermediate state to hold partial failures. To create that middle ground, the authors propose a design that treats cross-chain message delays as measurable execution risks, adjusting collateral discount rates and withdrawal limits on the fly (arXiv:2601.12434). According to this diagnosis, a bridge has no "slightly broken state." Even the compromise of a single signing key has nowhere to be contained as a partial failure.

The Boundary of Guarantees Lies at the Edge of the Chain

The list of what a blockchain guarantees is clear and short. That this transaction is in this block on this chain. That this signature was made with this key. That this state transition followed the rules. These can be verified without borrowing anyone's word. The list ends there, and the bridge is outside that list.

If you list the things you must trust on a bridge, the list grows long. Is the majority of the validator set honest, and how many are in that set to begin with (DOI: 10.2139/ssrn.6699478, preprint)? Are their signing keys managed securely (DOI: 10.36227/techrxiv.24595764, preprint; arXiv:2608.07104)? Do what is locked on this side and what is issued on the other side truly correspond (arXiv:2410.01107)? Is access control fully applied to meet the needs of this application without gaps (arXiv:2406.15999)? Are the two chains reading the same event with the same meaning (arXiv:2511.01393)? Will the solver provide liquidity tomorrow as well (arXiv:2602.17805)? Will the assets that crossed this bridge truly be released on the other side (arXiv:2410.02029)? Consensus on the chain does not guarantee any item on this list in place of something else.

Therefore, the sentence "Because the blockchain is secure, the assets on top of it are also secure" is more accurately rewritten like this: The blockchain guarantees what happened inside itself, and does not guarantee what happens the moment it steps outside itself. The earlier SoK also noted that bridges often provide inferior security guarantees compared to the underlying blockchain (arXiv:2403.00405).

What this article has drawn is the boundary of guarantees. Knowing where the boundary lies brings two things. One is the direction of research. End-to-end accounting can be made robust by the bridge itself (arXiv:2410.01107), the crowd of things we must trust can be reduced through proofs (arXiv:2210.00264), and correspondence can be made to be explicitly recorded (arXiv:2409.04937). The other is how to read a bridge. What you must ask in front of a bridge is "What does this assumption rely on?" Those assumptions are mostly inside publicly available design documents. One preprint even argues that risk zones can be separated using just seven publicly observable design parameters, and the basis for this is retrospective verification aligned after incidents (DOI: 10.21203/rs.3.rs-10534111/v1, preprint).

Drawing a line between what can be verified and what must be trusted was also a question left by "The Code Did Exactly What It Promised". In that article, the line was outside the code—namely, in human demands. On a bridge, the line lies at the edge of the chain, and every time you cross the bridge, you cross that line once. What becomes dangerous is forgetting the fact that you are crossing it.

Source Papers

• "Count of Monte Crypto: Accounting-based Defenses for Cross-Chain Bridges" (2024) — arXiv:2410.01107 (preprint) — 10 million instances demonstrated. The defect running through all attacks is the absence of end-to-end value accounting, and a simple invariant identifies all known attacks.
• "XChainWatcher: Monitoring and Identifying Attacks in Cross-Chain Bridges" (2024) — arXiv:2410.02029 (preprint) — Logic rule checking. 37 transactions that should not have been accepted, and over $7.8 million in funds locked and unreleased.
• "Safeguarding Blockchain Ecosystem" (2024) — arXiv:2410.14493 (preprint) — 49 incidents from 2021 to 2024. Cross-chain business logic attacks cause greater damage, and the recall is 36.32% higher than existing top tools.
• "Hedge Funds on a Swamp" (2025) — arXiv:2507.06156 (preprint) — 13 bridges, 23 attack vectors, and 43 scenarios. Recurring defects are access control, validator trust assumptions, and validation logic.
• "SoK: Cross-Chain Bridging Architectural Design Flaws and Mitigations" (2024) — arXiv:2403.00405 (preprint) — 60 bridges and 34 exploits. "Bridges often provide inferior security guarantees."
• "SoK: Security and Privacy of Blockchain Interoperability" (2023) — DOI: 10.36227/techrxiv.24595764 (preprint) — 178 papers and 56 solutions. 65.8% of stolen funds came from projects where key management in the permissioned intermediary network was insecure.
• "Bridge-Confidence Contagion in Liquid Restaking" (2026) — DOI: 10.2139/ssrn.6699478 (preprint) — Cross-chain message forgery in a single-validator configuration, roughly $292 million and 18% of supply. Homogeneous token contagion is null in the pre-registered design.
• "SoK: Cryptographic Key Recovery for Cryptoasset Custody" (2026) — arXiv:2608.07104 (preprint) — Cryptographic key control is financial control. Recovery shifts trust.
• "SoK: Security of Cross-chain Bridges" (2023) — arXiv:2312.12573 (preprint) — Identified 12 potential attack vectors and classified 10 types of real-world attacks.
• "A Systematic Taxonomy and Risk-Scoring Framework for Cross-Chain Bridge Security" (2026) — DOI: 10.21203/rs.3.rs-10534111/v1 (preprint) — Rule-based scoring using only 7 public parameters. In retrospective application to 8 incidents and 2 comparison groups, exploitative designs consistently fall into the high-risk band (with the authors also noting threats to the validity of retrospective verification).
• "Comparative Analysis of Cross-Chain Token Standards" (2026) — arXiv:2603.06388 (preprint) — Five standards share the same goal but differ greatly in implementation, trust model, and target ecosystem.
• "SmartAxe" (2024) — arXiv:2406.15999 (preprint) — Access control constraints vary across apps, and semantic mismatches between both sides are hard to know. 232 undisclosed vulnerabilities in 129 apps during operation.
• "ConneX" (2025) — arXiv:2511.01393 (preprint) — Absence of cross-chain pairing records. Reduces the semantic search space from 10 to the 10th power to under 100, with an average F1 of 0.9746.
• "CONNECTOR" (2024) — arXiv:2409.04937 (preprint) — The problem that existing methods rely on unobservable internal ledgers and APIs. 100% deposit and 95.81% withdrawal matching using only execution logs.
• "XChainDataGen" (2025) — arXiv:2503.13637 (preprint) — To fill the gap of public datasets, approximately 11.28 million cross-chain transactions were identified across 11 chains and 5 protocols.
• "Exploiting Liquidity Exhaustion Attacks in Intent-Based Cross-Chain Bridges" (2026) — arXiv:2602.17805 (preprint) — Playback analysis of 3.5 million intents. Defines liquidity exhaustion attacks as a new category, where safety depends on the parameters at that moment.
• "zkBridge: Trustless Cross-chain Bridges Made Practical" (2022) — arXiv:2210.00264 (preprint) — The problem where existing solutions lower security through committee trust assumptions. Significantly reduces on-chain verification costs without external trust assumptions.
• "MAP the Blockchain World" (2024) — arXiv:2411.00422 (preprint) — Reduced the $N^2$ explosion of light clients to be proportional to $N$, saving about 35% in on-chain costs. Real-world deployment case.
• "Blockchain Interoperability Landscape" (2022) — arXiv:2212.09227 (preprint) — Individually secure cryptographic protocols can become insecure when combined, and trusted custodians diminish the benefits of blockchains.
• "Atomic Cross-Chain Swaps" (2018) — arXiv:1801.09515 (preprint) — Defines three guarantees and constructs them with hash time locks, but proves they are impossible in non-strongly-connected graphs.
• "Towards faster settlement in HTLC-based Cross-Chain Atomic Swaps" (2022) — arXiv:2211.15804 (preprint) — This structure is equivalent to a premium-free American call option, lacking fairness. Proposes a premium deposit method.
• "An analysis of griefs and griefing factors" (2023) — DOI: 10.3389/fbloc.2023.1137155 — Formalization of acts that harm others while accepting self-loss, defining griefing factors.
• "Xscope: Hunting for Cross-Chain Bridge Attacks" (2022) — arXiv:2208.07119 (preprint) — Documented three new security bug categories, detected all known attacks across four bridges, and discovered unreported suspected attacks.
• "BridgeShield" (2025) — arXiv:2508.20517 (preprint) — Average F1 of 92.58% across 51 real-world attacks. Existing methods only covered single-chain behavior and failed to capture cross-chain semantics.
• "HighGuard: Cross-Chain Business Logic Monitoring of Smart Contracts" (2023) — arXiv:2305.08254 (preprint) — Formal model-based monitoring, detecting 54 exploits in evaluation without false positives.
• "COBALT-TLA" (2026) — arXiv:2604.12172 (preprint) — A loop combining language models and model checkers. Autonomously discovered vulnerability classes absent from standard specifications.
• "Formal verification of the pub-sub blockchain interoperability protocol" (2023) — DOI: 10.3389/fbloc.2023.1248962 — Manually inspecting and testing all potential pitfalls and inter-chain interactions is nearly impossible.
• "Structural and Active Interoperability Measurement" (2026) — arXiv:2604.03083 (preprint) — Measurements from 2022 to 2025 across 20 chains and 16 bridges. Re-evaluates by separating structural and active interoperability, showing that connectivity alone does not mean economically meaningful integration.
• "ASAS-BridgeAMM" (2026) — arXiv:2601.12434 (preprint) — Diagnosis of the binary nature of bridge security models (either completely normal or catastrophic breach) and dynamic adjustment design.