{"id":"6ed62477-44b5-4ada-8408-7d87b65da8ad","arxiv_id":"2507.06156","paper_version":3,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A data-driven study of blockchain bridge attacks concludes that most losses come from trusted signer compromise and code validation bugs, while trustless designs have so far escaped major exploits.","lead":"Blockchain bridges, the software that moves assets between networks, keep getting hacked for enormous sums. This paper catalogs those attacks, inspects bridge contracts, and argues that simpler bridges with fewer trusted signers are much safer.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The claim that light-client bridges have never been breached is contradicted by the paper's own BSC Token Hub case, which Appendix F calls 'a seemingly trustless bridge (a light-client-based one)' but Table 8 labels 'Custodial'.","rationale":"The reader's weakest_assumption—dataset completeness and label accuracy—is closely related, but the strongest stress-test finding is an internal contradiction in the paper itself. The central thesis is that trustless light-client and rollup bridges have withstood real-world attacks. The paper's own BSC Token Hub analysis, however, describes that bridge as light-client-based and attributes the exploit to a light-client proof verification bug. Table 8 classifies the same incident as 'Custodial' and 'Proof Verifier Bug', and Table 9 does not list a light client in its off-chain mechanism. The paper thus uses two incompatible descriptions of the same bridge. If the light-client description is correct, the central claim must be weakened or qualified; if the custodial description is correct, the appendix's own language contradicts it, and the classification criteria are unclear. This is not an external disagreement about consensus; it is an internal inconsistency in the evidence supporting the paper's headline conclusion. The reader's CONDITIONAL verdict remains appropriate: the paper's other contributions (formal model, static analysis, transaction forensics) are valuable, but the strongest empirical assertion needs correction and a clear classification rubric. I therefore recommend no change to the reader's verdict, while flagging that the concern is more specific than a generic completeness worry and should be addressed explicitly.","tokens_in":1126,"tokens_out":1077,"duration_ms":46081,"concrete_test":"Re-apply Section 3.3.2's definition to BSC Token Hub: does Toff = {L, M} (light client) hold? If yes, recompute the set of exploited bridges in Table 8 whose off-chain mechanism is a light client; if BSC Token Hub is in that set, the RQ1 statement 'no major exploits ... on light-client bridges' is false. As a supplementary check, locate BSC Token Hub in Table 9: its off-chain mechanism is listed as 'Notaries/Relays – Binance-controlled relay system', with no light-client entry, yet Appendix F explicitly calls it a light-client bridge. A one-paragraph reconciliation in the paper would settle which description governs, and whether the trustless-safety claim survives.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 5 (RQ1) asserts: 'no major exploits have occurred on fully trustless light-client bridges or rollup bridges', citing IBC and rollups. Appendix F's BSC Token Hub description states: 'This incident revealed that even a seemingly trustless bridge (a light-client-based one) can have implementation flaws in its verification logic.' Table 8 lists 'Binance Bridge' as 'Custodial' with technique 'Proof Verifier Bug' (V9) targeting the off-chain relayer, and the appendix describes the root cause as 'a bug in the light-client based proof verification' that allowed a forged proof to mint 2M BNB (~$570M). If BSC Token Hub uses a light client for verification, then either it is a light-client bridge and the central claim is false, or it is excluded because custody/validators are centralized, in which case the 'trustless' category is defined by custody rather than verification, making the claim circular. The paper never reconciles these positions. The classification labels in Table 8 are asserted without a rubric that maps Section 3.3's Toff definitions to each incident, so the strongest empirical conclusion rests on an internally inconsistent labeling.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"This paper presents a systematization of blockchain bridge security, combining a formal model of bridge architectures and trust sets, a taxonomy of 23 attack vectors, a static analysis of 16 deployed smart contracts, transaction-level tracing of 18 attacker wallets, and a catalog of 43 real-world incidents. The authors argue that most bridge exploits stem from off-chain trust failures and on-chain validation bugs, and that fully trustless designs (light-client and rollup-native bridges) have so far resisted major attacks while trusted and trust-minimized bridges remain disproportionately vulnerable. They also discuss detection, mitigation, and outlook in four research questions.","tokens_in":40467,"tokens_out":7633,"duration_ms":78261,"significance":"If the central empirical claim held, the paper would provide actionable guidance for bridge architects by shifting attention from cryptographic weaknesses to trust-set design and verification-logic correctness. The paper usefully assembles a broad incident table, a layered threat model, and a concrete static-analysis metric set; it also ships traceable case narratives for Ronin, Wormhole, Nomad, and others. However, the load-bearing conclusion is undermined by an internal contradiction involving the BSC Token Hub incident and by the absence of a verifiable incident-selection and classification methodology. The taxonomy and formal framework have merit, but the empirical claims need substantial rework before the conclusions are reliable.","major_comments":[{"comment":"The central claim that \"no major exploits have occurred on fully trustless light-client bridges or rollup bridges\" is contradicted by the manuscript's own Binance Bridge/BSC Token Hub case. Appendix F states that the root cause was \"a bug in the light-client based proof verification\" and that \"even a seemingly trustless bridge (a light-client-based one) can have implementation flaws in its verification logic,\" while Table 8 classifies the same incident as \"Custodial\" with technique \"Proof Verifier Bug\" (V9). If BSC Token Hub is excluded from the trustless category because of custodial control, the category is effectively defined by custody rather than by verification mechanism, and the claim that trustless verification has not been breached becomes circular; if it is included, the \"no major exploits\" claim is false. Please reconcile the taxonomy with this case, and provide a rubric that maps each incident to the Section 3.3 trust-set definitions.","section":"Section 5 (RQ1), Appendix F, Table 8"},{"comment":"The empirical foundation of RQ1 is not verifiable as presented. The paper does not state how the 43 attacks were selected, does not provide a completeness analysis, and does not supply the dataset (the \"repository URL\" mentioned in Section 2 is not given). The negative claim about trustless bridges depends on the set of considered incidents being representative and complete, so a missed or mislabeled exploit would invalidate the conclusion. In addition, the \"Architecture Type\" labels in Table 8 are asserted without a visible mapping from Section 3.3's T_src/T_off/T_dest definitions to each incident; for example, \"Binance Bridge\" is labeled Custodial despite the appendix describing light-client verification. Please add the incident-selection methodology, a completeness discussion, and a per-incident classification rubric.","section":"Section 5, Table 8"},{"comment":"The attack-vector numbering used in Table 8 is unreliable because the vector definitions in Appendix E do not match Table 2. Table 2 defines V3 as access control, V9 as malicious transaction modification, and V10 as light-client verification flaws, whereas Appendix E assigns V3 to reentry, V9 to oracle manipulation, and V10 to consensus failure, and it lists only vectors V1–V18 against Table 2's V1–V23. Since Table 8 uses these vector codes (e.g., V9 for the Binance proof-verifier bug and V10 for Nomad's trusted-root exploit), the frequency counts and causal attributions built on them cannot be checked. The two lists must be aligned, or the vector codes should be removed from the incident table.","section":"Section 3.6, Appendix E, Tables 2 and 8"},{"comment":"Definition 3.5 first defines der(V)=I(V)/E(V) as a damage-to-effort ratio, then immediately redefines the same symbol as an indicator: \"der(V)=1 if der(V)>1, 0 otherwise.\" Equation (8) sums these indicator values while the surrounding text and Section 5 interpret der as a ratio (\"high damage-to-effort ratios\"). This conflation makes the formal attack-surface model internally inconsistent and should be fixed by introducing a separate viability indicator, e.g., viable(V)=1[der(V)>1], and using it in the area sum.","section":"Section 3.5.2, Eq. (8)"}],"minor_comments":[{"comment":"The theorem is numbered Theorem 1 in Section 3.4 but appears as Theorem 2 in Appendix B; please renumber consistently.","section":"Appendix B vs. main text"},{"comment":"The transaction definition tx_b2=(theta_2, v_2=0, ...) conflicts with the subsequent balance update a_2 maps to v_x-f_2; clarify that v_2 is the amount in the transaction tuple, not the resulting balance.","section":"Section 3.2.3"},{"comment":"The text reports \"6 out of 18 wallets continued transacting,\" but Table 10 lists 19 exploit addresses; please align the count and provide full addresses in a supplementary dataset.","section":"Section 4.2 and Table 10"},{"comment":"The phrase \"available at our repository URL\" is a placeholder; include an actual URL or remove the pointer so reviewers can access the claimed dataset and code.","section":"Section 2"},{"comment":"The caption contains a typo, \"Blockhain,\" and the address entries are truncated; consider providing complete addresses in the data release.","section":"Table 10 caption"}],"recommendation":"major_revision","confidential_remarks":"The paper addresses a timely and practically important topic, and the qualitative observation that off-chain trust failures and validation bugs dominate bridge exploits is plausible and consistent with well-known incidents. However, the strongest conclusion about trustless bridges is currently supported by an internally inconsistent classification of the BSC Token Hub case and by an incident dataset whose completeness and labeling are opaque. These issues are fixable within the manuscript's scope by reworking the taxonomy and providing the missing methodology. I also note that several SoK papers already cover overlapping ground, so the authors should sharpen the novelty claim after the empirical rework."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Useful, not as new as claimed. The original material is the 16-contract static metric tables, the 43-incident classification, and the transaction-flow graphs; those are worth having. The high-level message—most bridge losses come from compromised signers and validation bugs, not broken cryptography—is plausible and matches public incident records. But the \"first large-scale\" framing doesn't survive contact with SmartAxe, which does static analysis of bridge contracts and is only cited in the appendix. And the strongest claim, that fully trustless bridges have never been breached, rests on a dataset that isn't shipped and an incident classification that is internally inconsistent in places.\n\nThe concrete problems: (1) No dataset, no collection methodology for the 43 incidents, no completeness analysis. Table 8 is interesting but not checkable. (2) The attack-vector numbering disagrees between Table 2 and Appendix E; Table 8 uses labels that match neither. For example Wormhole's signature-verification bug is labeled V12, which in the two taxonomies means \"custodian manipulation\" or \"key theft.\" That is a real problem for a paper whose contribution is a taxonomy. (3) The BSC Token Hub case is sloppy. Appendix F calls it \"a seemingly trustless bridge (a light-client-based one)\" and Table 8 calls it Custodial. The conclusion can be saved by saying it isn't fully trustless because Binance controls validators, but the paper never says that. It needs a per-incident rubric mapping trust category to each attack. (4) der(V) is defined but never computed; \"high damage-to-effort\" is asserted without numbers. (5) Static analysis covers 16 contracts, manually tabulated, with no tool or scripts; that is descriptive evidence, not \"large-scale\" in the SmartAxe sense.\n\nThe formal model is simple and mostly definitional—Theorem 1 follows from the definitions—but that is acceptable for a systematic review. The paper would be a good baseline for bridge designers and forensic researchers if the repository were published and the claims toned down. As is, I would accept it for peer review with major revision: the empirical section needs to be reproducible, the taxonomy needs consistent labels, and the trustless-safety claim needs an explicit classification of BSC Token Hub.","headline":"Useful SoK-style synthesis with original measurements, but overclaims novelty and its 'trustless is safer' conclusion needs a reproducible dataset and a consistent classification before it should be taken at face value.","tokens_in":41012,"tokens_out":5859,"would_cite":true,"duration_ms":60097,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper claims that most blockchain bridge hacks come from two classes of failure—off-chain trust failures and on-chain validation bugs—and that fully trustless designs have so far escaped major exploits.","keywords":["blockchain bridges","cross-chain security","trustless verification","bridge attack surfaces","smart contract static analysis","transaction network analysis","validator compromise","bridge exploit taxonomy"],"falsifier":"A documented, confirmed exploit of a fully trustless light-client bridge or rollup-native bridge, such as a forged proof or state root accepted by a light-client contract or a fraud-proof bypass, would directly contradict the paper's central design claim; one concrete check is whether any Cosmos IBC channel or Ethereum rollup bridge has suffered a fund-draining incident through verification logic since 2021.","tokens_in":40057,"feed_emoji":"🌉","tokens_out":6492,"duration_ms":68679,"temperature":0.7,"pith_summary":"Blockchain bridges move tens of billions of dollars between chains every month and are the single largest source of financial loss in Web3. This paper tries to establish that the losses are not random or cryptographic: most successful exploits fall into two classes, off-chain trust failures (stolen keys, compromised signers, insider control) and on-chain validation bugs (forged proofs, broken access control, unchecked calls). It formalizes three bridge security priors (peg, causality, consistency), a layered threat model across source chain, off-chain, and destination chain components, and evaluates 43 attacks alongside static code from 13 bridges. Its central conclusion is that trustless designs—light-client and rollup-native bridges with no external signers—have so far withstood real-world attacks, while trusted and trust-minimized bridges remain disproportionately exposed. If the paper is right, bridge security is largely a matter of subtracting trusted signers and rigorously validating proof-checking code, not of inventing stronger cryptography.","feed_headline":"Most bridge hacks trace to trusted signers and code bugs, not cryptography","feed_subtitle":"A 43-attack study finds light-client and rollup bridges intact while multisig and validator bridges keep failing","key_machinery":"The load-bearing mechanism is a layered attack-surface model combined with a trust-set decomposition. A bridge's trust set is written $T=T_{\\mathrm{src}}\\cup T_{\\mathrm{off}}\\cup T_{\\mathrm{dest}}$, and its attack surface is $\\Sigma=\\langle T, I\\rangle$, where $I$ is the implementation. Three security priors are formalized: bridge peg (equation 4), bridge causality (equation 5), and bridge consistency (equations 6 and 7), with an attack defined as a malicious violation of any of them. The damage-to-effort ratio $\\mathrm{der}(V)=I(V)/E(V)$ converts incident stories into a scalar whose sum over vectors gives a bridge's attack surface area. These objects carry the argument by letting the paper map every historical exploit to a specific layer and trust assumption, and then read off which designs remove entire classes of vectors (notably V3) by having no external signers at all.","core_discovery":"On the paper's own terms, the discovery is that bridge vulnerability is a design property, not an accident. The majority of the 43 representative attacks violate the causality or consistency priors, while the peg prior is violated only as a downstream effect of unauthorized minting or release. Across the incident table, two vectors dominate—access control flaws (V3) and key leakage or theft (V13), each appearing ten times—and these map cleanly onto the two failure classes: off-chain trust failures (Ronin, Harmony, Multichain, Orbit) and on-chain validation bugs (Poly Network, Wormhole, Nomad, BSC Token Hub, Qubit). The paper argues that no major exploit has occurred on fully trustless light-client bridges or rollup-native bridges, whereas trusted and loosely trust-minimized bridges, whose validator sets are weaker than either chain's consensus, keep falling. The damage-to-effort ratio, $\\mathrm{der}(V)=I(V)/E(V)$, is introduced to explain why these vectors persist: the impact is often hundreds of millions of dollars while the effort, key theft or a poorly audited contract, remains relatively low.","pith_inferences":["The 'trustless has never been hacked' conclusion is only as strong as the incident dataset behind Table 8; a single missed exploit on a light-client or rollup bridge would invert the design ranking, so a completeness audit of attack collections is a natural next step.","The damage-to-effort framework suggests a testable prediction: bridges whose trust set is a bonded, slashable validator set with hundreds of nodes should show attack rates between those of naive multisigs and light-client designs, and that gradient could be quantified from incident history.","The transaction tracing is Ethereum-centric, so extending the same methodology to Solana and Cosmos exploit flows could reveal laundering and attacker-behavior patterns that are invisible from an Ethereum full node.","If the design hierarchy holds, insurance underwriters and regulators could price bridge risk by trust-set size and verification method, an application the paper itself does not develop."],"forward_implications":["Bridge security investment should shift from stronger cryptography to shrinking the trust set: eliminating multisig signers and adopting light-client verification removes the two highest-frequency vectors.","Rollup-native bridges and IBC-style light-client channels should be the default for compatible chains, because their security reduces to the underlying chains' own consensus.","Layered validation, such as requiring both an off-chain multisig and an on-chain light client to agree, should drastically cut exploit probability, at the cost of added complexity and latency.","Verification-logic bugs (Wormhole, BSC Token Hub) argue for formal verification and independent double-checks of proof code, not just conventional audits.","Detection latency and containment need to become first-class benchmarks, since the Ronin case shows a $624 million theft going unnoticed for six days."],"supporting_citations":[{"why":"Kiepuszewski's argument that rollups are the most secure bridges supplies the rollup-native trustless claim the paper tests and extends.","marker":"[2]"},{"why":"Belenkov et al.'s SoK of cross-chain bridge hacks in 2023 provides the failure-mode taxonomy and post-mortem material the paper reclassifies under its own priors.","marker":"[9]"},{"why":"Li et al.'s survey of bridge architectures and common vulnerabilities grounds the attack-vector table and the comparison against prior taxonomies.","marker":"[10]"},{"why":"Lindrea's report on the Cosmos IBC bug is the evidence that a lossless reentrancy bug was found early, supporting the claim that IBC channels have operated without fund-draining incidents.","marker":"[35]"},{"why":"LI.FI's quantified trust-spectrum analysis supplies the claim that many trust-minimized bridges still rely on a small validator set and remain vulnerable to key compromise or 51% attacks.","marker":"[36]"},{"why":"Wu et al.'s BridgeGuard dataset of 49 bridge exploits is the closest prior incident corpus and the baseline the paper extends with static analysis, formal priors, and a unified threat model.","marker":"[8]"},{"why":"Augusto et al.'s XChainWatcher reconstruction of the Ronin and Nomad attacks demonstrates the transaction-level tracing methods the paper generalizes across 43 incidents.","marker":"[7]"},{"why":"Augusto et al.'s SoK on security and privacy of blockchain interoperability catalogs bridge exploits without full transaction tracing or static code analysis, marking the gap the paper fills.","marker":"[20]"},{"why":"zkBridge supplies the prototype for trustless zk-SNARK-based bridging that the paper cites as evidence some traditional attack vectors can be closed without any trusted signer.","marker":"[62]"}],"fun_headline_variants":["Bridge hacks root in design flaws, not crypto breaks","Trusted signers and code bugs drive most bridge hacks","Bridge failures: weak validators and buggy code","Bridges fail from design, not broken cryptography","Why bridges keep falling: trust and code, not math"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The central claim depends on the completeness and representativeness of the dataset of 43 attacks: if a real exploit on a fully trustless light-client or rollup bridge was missed, or a bridge-type label is wrong, the conclusion that trustless designs are safer loses its empirical ground.","fun_headline_variants_meta":{"raw":{"variants":["Bridge hacks root in design flaws, not crypto breaks","Trusted signers and code bugs drive most bridge hacks","Bridge failures: weak validators and buggy code","Bridges fail from design, not broken cryptography","Why bridges keep falling: trust and code, not math"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000229,"raw_usage":{"total_tokens":1510,"prompt_tokens":1010,"completion_tokens":500,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":626,"completion_tokens_details":{"reasoning_tokens":421}},"tokens_in":626,"tokens_out":500,"duration_ms":5717,"temperature":1.0,"reasoning_tokens":421,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T19:09:41.119346+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"A documented, confirmed exploit of a fully trustless light-client bridge or rollup-native bridge, such as a forged proof or state root accepted by a light-client contract or a fraud-proof bypass, would directly contradict the paper's central design claim; one concrete check is whether any Cosmos IBC channel or Ethereum rollup bridge has suffered a fund-draining incident through verification logic since 2021.","supporting_citations":[{"cited_title":"Cosmos patches ‘critical’ ibc protocol bug, saving $126m,","cited_arxiv_id":null,"evidence_quote":"Lindrea's report on the Cosmos IBC bug is the evidence that a lossless reentrancy bug was found early, supporting the claim that IBC channels have operated without fund-draining incidents."},{"cited_title":"Li.fi: With bridges, trust is a spectrum,","cited_arxiv_id":null,"evidence_quote":"LI.FI's quantified trust-spectrum analysis supplies the claim that many trust-minimized bridges still rely on a small validator set and remain vulnerable to key compromise or 51% attacks."},{"cited_title":"Sok: Security and privacy of blockchain interoperability,","cited_arxiv_id":null,"evidence_quote":"Augusto et al.'s SoK on security and privacy of blockchain interoperability catalogs bridge exploits without full transaction tracing or static code analysis, marking the gap the paper fills."},{"cited_title":"zkBridge: Trustless Cross-Chain Bridges Made Practical,","cited_arxiv_id":null,"evidence_quote":"zkBridge supplies the prototype for trustless zk-SNARK-based bridging that the paper cites as evidence some traditional attack vectors can be closed without any trusted signer."}],"review_version":1}