PaperlayerView exact revision on arXiv

Source-linked AI summary

Bridging the Opacity: Evidence-Backed Cross-Chain Transaction Correspondence Reconstruction Across Heterogeneous Blockchains

Dan Lin, Huan Xiao, Ziwei Li, Xiapu Luo, Jiachi Chen, Jiajing Wu, Zibin Zheng

arXiv:2609.18158v1cs.CR

TL;DR

Third-party investigators often lack bridge-backend mappings, and public tracking is limited across surveyed bridges. XSPLICER compiles public protocol artifacts into analyzers and verifiers that reconstruct correspondence using hard evidence first. Across seven bridges, it reports 87.92%–98.61% oracle-assisted conditional accuracy, while noting boundaries where public protocol invariants are unavailable.

  • Problem

    Only 16.79% of surveyed bridge protocols provide verifiable public transaction mappings, leaving third-party investigators without consistent source-to-destination correspondence.

    Source: §8 · p. 13

  • Method

    XSPLICER synthesizes public protocol artifacts into semantic specifications and executable analyzers and verifiers that produce evidence-linked correspondence decisions.

    Source: §1 · p. 2, §3.3 · p. 4, §4.3 · p. 7

  • Results

    87.92%–98.61% oracle-assisted conditional accuracy across seven evaluated bridge protocols spanning EVM, Solana, and Bitcoin.

    Source: §8 · p. 13

  • Takeaways & Limitations

    Public protocol evidence can support post-mortem traceability when official services are unavailable.

    Source: §5.6.1 · p. 12, §8 · p. 13

    XSPLICER cannot reconstruct correspondence for custodial bridges with private-backend mappings or anonymity protocols that remove cross-chain identifiers via zero-knowledge proofs.

    Source: §6 · p. 13

Abstract

from arXiv · show

Cross-chain bridges enable interoperability, but they also break the transaction trails needed to trace illicit funds. Third-party investigators typically cannot access the source-to-destination mappings maintained by bridge backends, and our survey of 131 bridges finds that only 16.79% provide complete public tracking. Existing approaches depend on official APIs, EVM-specific assumptions, or fragile temporal heuristics, limiting their ability to trace transfers across heterogeneous ledgers. We present XSplicer, an evidence-driven system for reconstructing cross-chain transaction correspondence (xTCR) without privileged access to bridge backends. XSplicer derives unified semantic specifications from public protocol documentation and transaction examples, translates them into lightweight parsers and verifiers, and links source and destination transactions by prioritizing hard evidence and using soft clues only when necessary. We evaluate XSplicer on seven bridge protocols spanning EVM, Bitcoin, and Solana. XSplicer achieves 92.5% global recovery rate and up to 98.61% on individual protocols. Under adversarial noise, its hard-evidence verifier retains the correct match in 100% of tested cases, while soft-clue matching degrades as ambiguity increases. In two real-world case studies, XSplicer recovers more than 1,900 historical transaction pairs after Multichain ceased operations and identifies 754 illicit cross-chain transfers worth 105.6 million USD in the Bybit laundering incident. These results show that public protocol invariants can support practical cross-chain forensics without privileged bridge mappings.

1 Introduction

Cross-chain bridges disrupt transaction-tracking continuity, while third-party investigators often lack public mappings from source to destination transactions. XSPLICER reconstructs correspondence from public protocol evidence, reporting accuracy of 87.92%–98.61% across seven bridges.

1 Introduction

  • Bridge-mediated transfers disrupt single-chain tracking, leaving third-party analysts reliant on public data to trace funds across heterogeneous networks.The paper cites more than $21.8 billion in high-risk on-chain assets transferred via cross-chain mechanisms, according to the Elliptic 2025 report.Source: §1 · p. 1
  • Only 16.79% of 131 surveyed bridges provide precise destination-transaction retrieval from source transaction hashes.When official interfaces are unavailable or operations cease, investigators must work from scattered state-transition logs and transaction payloads.Source: §1 · pp. 1–2
  • XSPLICER compiles public protocol documents and transaction examples into semantic specifications, then uses analyzers and verifiers to reconstruct correspondence.Candidate construction is separated from verification: protocol-level hard evidence is prioritized, with soft clues used only when hard evidence is unavailable.Source: §1 · p. 2
  • 87.92%–98.61% accuracy across seven bridges spanning Ethereum, Bitcoin, and Solana demonstrates XSPLICER’s cross-chain reconstruction performance.The results also indicate that public protocol evidence supports reconstruction across heterogeneous execution models under constrained third-party observability.Source: §1 · p. 2
  • XSPLICER’s hard evidence retains discriminative power under candidate ambiguity and adversarial noise, while time- and amount-based clues degrade under interference.The paper reports historical-path reconstruction after the Multichain shutdown and tracing of THORChain-mediated flows associated with the Bybit Hack.Source: §1 · p. 2
  • The paper frames xTCR as candidate search guided by destination-side constraints, followed by verification using shared protocol evidence.Its evaluation covers 54,578 transaction pairs across seven bridges spanning EVM, Bitcoin, and Solana, with adversarial-noise experiments and real-world case studies.Source: §1 · p. 2

2 Background and Empirical Study

Bridge transfers progress from source initiation through relaying to destination settlement, but heterogeneous ledgers encode evidence differently. A survey finds that only 16.79% of 131 protocols provide verifiable public mappings, while public interfaces are not reliable forensic oracles.

2.1 Cross-Chain Bridge Workflow

  • Bridge workflows proceed through source initiation, relaying of signed proof, and destination settlement that validates the proof and delivers assets.The source and destination transactions are observable anchors for reconstructing fund flows; intermediate verification, hops, or refunds are related transactions.Source: §2.1 · p. 2

2.2 Blockchain Heterogeneity

  • Cross-chain evidence occupies different formats and locations across EVM, Bitcoin, and Solana, making simple heuristic matching insufficient.EVM evidence may appear in calldata, logs, or traces; Bitcoin in scripts, outputs, or OP_RETURN; and Solana in instructions, metadata, or logs.Source: §2.2 · p. 3

2.3 Empirical Study: The Observability Crisis

  • Only 16.79% of 131 surveyed protocols provide verifiable source-to-destination transaction mappings through public official interfaces.The study defines traceability as consistent availability of a mapping from source transaction hash to corresponding destination transaction hash.Source: §2.3 · p. 3
  • Public bridge APIs are designed largely for developer integration and real-time status rather than forensic-grade historical reconstruction.Some require production API keys, discourage caching, or became inaccessible after a service ceased operations or was deprecated.Source: §2.3 · p. 3
  • Because official APIs cannot be treated as reliable correspondence oracles, third-party reconstruction must rely on public on-chain artifacts and protocol documentation.Temporal and monetary proximity are soft cues, not evidence strong enough for forensic attribution.Source: §2.3 · p. 3

3 Problem Overview

The paper frames cross-chain transaction correspondence reconstruction as a non-privileged task: infer a latent destination transaction and support the link with protocol evidence. Heterogeneous encodings and ambiguous soft clues motivate restoring comparability before verification.

3.1 Third-Party Analyst Model

  • A third-party analyst uses public artifacts and protocol specifications without privileged backend mappings or continuously available official correspondence services.The model targets non-cooperative and post-mortem investigations; when official mappings exist, XSPLICER can provide an independent cross-check.Source: §3.1 · pp. 3–4

3.2 Adversary Model

  • The adversary may use chain-hopping and vary transfer amounts, while the bridge is assumed honest but opaque rather than compromised or unmapped.The problem is observability loss: the bridge may maintain a deterministic internal mapping that is inaccessible to third parties.Source: §3.2 · p. 4

3.3 Problem Formulation

  • The output is a reconstructed destination transaction paired with the source transaction and an evidence set supporting their correspondence, or no correspondence when none can be established.The destination transaction is the transaction that completes delivery of the user’s asset.Source: §3.3 · p. 4

3.4 Motivation: Why Prior Work Breaks Down

  • Heterogeneous encodings can hide destination constraints and shared identifiers, so source and destination fields may require protocol-specific decoding and normalization before comparison.In the deBridge Ethereum-to-Solana example, destination fields and orderId use different representations across chains.Source: §3.4 · p. 4, Figure 3 · p. 5
  • Time and amount similarities can leave multiple plausible destination candidates, and long BTC-to-ETH settlement delays expand the search window and interference.The paper describes attack samples where monetary proximity lacks uniqueness.Source: §3.4 · p. 4

3.5 Challenges and Design Rationale

  • XSPLICER extracts destination intent and shared evidence from public artifacts, compiles protocol semantics into decoding and normalization operators, and verifies with hard evidence first.Soft temporal and monetary clues are fallback support when structural evidence is unavailable, producing evidence-backed forensic states rather than similarity rankings.Source: §3.5 · p. 5

4 System Design

XSPLICER reconstructs cross-chain transaction correspondence through a three-stage workflow that turns public protocol documents and transaction examples into executable rules. It narrows destination candidates, then prioritizes deterministic cross-chain evidence while reserving soft clues for cases where hard evidence is absent.

4.1 Stage I: Protocol Knowledge Reconstruction

  • Stage I combines protocol documentation and public transaction examples into a semantic specification of destination constraints and cross-chain evidence.A conservative merge finalizes fields only when multiple independent sources corroborate them; conflicting or weak items remain pending.Source: §4 · p. 5, §4.1 · p. 6

4.2 Stage II: Executable Rule Generation

  • Stage II compiles the specification into an Analyzer for destination constraints and a Verifier for normalized cross-chain evidence checks.Generated modules are validated against examples and the specification, repaired if checks fail, and revalidated before use.Source: §4 · p. 5, §4.2 · p. 7

4.3 Stage III: Online Correspondence Recovery

  • Stage III decodes a source transaction, uses extracted constraints to bound destination candidates, and applies hard-evidence checks before soft clues.A unique hard-evidence match is Confirmed; a soft-clue match without competitive ambiguity is Supported, while broken evidence or irreconcilable ambiguity is Unresolved.Source: §4 · p. 5, §4.3 · pp. 7–8

4 System Design

  • The THORChain example links an Ethereum source hash to a Bitcoin destination through a matching OP_RETURN payload.The memo provides the Bitcoin destination marker and recipient constraints, while the destination payload explicitly refers to the source transaction hash.Source: §4.1 · p. 6, §4.3 · p. 8, Figure 7 · p. 8

5 Evaluation and Analysis

XSPLICER is evaluated across heterogeneous chains and bridge protocols using labeled transaction pairs, then assessed for accuracy, robustness, and practical forensic utility. Results show that protocol-level evidence can distinguish correspondences where soft clues or official interfaces leave ambiguity or gaps.

5.2 Overall Performance

  • Once the correct transaction is in the candidate set, Allbridge and THORChain exceed 93% Acccov, while Wormhole reaches 98.61% Acccov despite 56.56% soft-clue ambiguity.Candidate coverage exceeds 93% for most protocols, but falls to 87.92% for Symbiosis; without unique hard evidence, XSPLICER returns Supported or Unresolved rather than forcing confirmation.Source: §5.2 · p. 9, Table 2 · p. 9
  • ETH→SOL reaches 97.98% Acccov versus 84.56% for SOL→ETH, where hard-evidence availability is 54.99% and soft-clue ambiguity is 30.45%.The text attributes this asymmetry to reduced public identifier exposure when moving from Solana’s instruction model to the EVM account model.Source: §5.2 · pp. 9–10, Table 3 · p. 10

5.3 Baseline Comparison

  • XSPLICER reports higher conditional accuracy than EVM-focused baselines in their EVM setting and reconstructs verifiable protocol invariants rather than relying primarily on trace/log-pattern heuristics.Because the baselines are not directly applicable to Bitcoin or Solana, the comparison is limited to Celer cBridge ETH→Polygon and ETH→BSC routes.Source: §5.3 · p. 10, Table 4 · p. 10

5.4.1 Influence of the LLM Backbone

  • GPT-5.4 leads the tested LLMs across all three metrics, but its F1dst of 0.835 exceeds its F1cross of 0.667, reflecting weaker recovery of complex pairing logic.Destination-side specification quality systematically outpaces cross-chain shared-spec quality; XSPLICER uses GPT-5.4 and treats LLM outputs as heuristic anchors followed by deterministic checks.Source: §5.4.1 · p. 11, Table 5 · p. 11

5.4.2 Functional Utility of Input Artifacts

  • Removing documentation drops WanBridge BTC→ETH candidate coverage from 72.60% to 0% and Wormhole ETH→SOL hard-evidence availability from 99.86% to zero, while Allbridge is unaffected.For Allbridge, hard evidence is exposed in raw logs; Wormhole’s composite identifiers require a textual schema.Source: §5.4.2 · p. 11
  • On 4,999 Allbridge samples, minimum-coverage traces yield 1.66% Acccov and require eight traces to reach 96.54%, whereas one maximum-coverage trace yields 86.58% Acccov.The findings distinguish structural coverage from raw trace volume: documentation supplies declarative schemas, while traces ground them in ledger layouts.Source: §5.4.2 · p. 11

5.5 Robustness to Adversarial Ambiguity

  • Hard-evidence samples retain 100% of correct matches across routes and distractor counts; soft-evidence retention falls from 96% to 10% on ETH→SOL at k = 16 and to zero on BTC→ETH at k = 2.Figure 8 depicts the degradation of soft-evidence retention as amount-identical distractors increase.Source: §5.5 · pp. 11–12, Figure 8 · p. 11

5.6 Practical Forensic Analysis

  • XSPLICER reconstructs 1,808 EVM-to-EVM and 116 BTC→ETH correspondence pairs, manually verified by two researchers, and recovers 754 ETH→BTC pairs totaling approximately 105.6 million USD, with 100% destination hash accuracy.Across 1,381 Wormhole transfers, it discovers 51 intermediate destination-side related transactions absent from the official API.Source: §5.6.2 · p. 12, §5.6.3 · p. 12, §5.6.1 · p. 12

6 Discussion

XSPLICER’s applicability and evidentiary strength depend on public protocol invariants and identifiable shared evidence. Its scope ends at transaction correspondence, not multi-hop entity recognition or attribution.

Applicability boundaries

  • XSPLICER applies to decentralized bridges and contract-driven DeFi flows with public protocol invariants and identifiable destination intent and shared evidence.Custodial bridges with private-backend mappings and anonymity protocols that remove cross-chain identifiers via zero-knowledge proofs remain unresolved.Source: §6 · p. 13

Evidence boundaries

  • Without protocol-level hard evidence, XSPLICER returns a soft-clue lead only for one candidate matching both time and amount with extremely high confidence.Multiple matches or excessive noise yield unresolved.Source: §6 · p. 13

Functional boundaries

  • XSPLICER reconstructs transaction-level correspondence, not end-to-end multi-hop entity recognition, entity attribution, or legal conclusions.Address clustering and illicit-flow analysis require off-chain intelligence and manual investigation for attribution and legal conclusions.Source: §6 · p. 13

Extensibility

  • New bridge onboarding requires public protocol documentation and a transaction example; future work targets bytecode-based invariant extraction and mixing bridges.The system generates an Analyzer and Verifier without manually implementing bridge-specific rules.Source: §6 · p. 13

7 Related Work

Prior work studies bridge security and cross-chain tracing, while XSPLICER focuses on evidence-backed correspondence reconstruction across heterogeneous environments without privileged interfaces.

Cross-chain Interoperability and Bridge Security

  • Bridge-security studies examine vulnerabilities and defenses, including attack-pattern detection, static contract analysis, and runtime monitoring.These works focus on bridge vulnerabilities and defenses.Source: §7 · p. 13

Multi-chain Transaction Forensics and Tracing

  • Cross-chain forensics has used address consistency, ledger tracing, LLM-based search pruning, and logical relations for anomaly detection.Earlier work also covers single-chain fund flows, heuristics, and graph mining.Source: §7 · p. 13
  • XSPLICER differs by reconstructing evidence-backed correspondence across heterogeneous environments, including EVM, Bitcoin, and Solana.The cited prior approaches include homogeneous settings or specific protocols.Source: §7 · p. 13

8 Conclusion

XSPLICER compiles public protocol artifacts into evidence-linked decisions for heterogeneous cross-chain reconstruction, with reported results across seven bridges. The paper also describes its release, ethical safeguards, and stakeholder implications.

8 Conclusion

  • Across seven bridges spanning EVM, Solana, and Bitcoin, XSPLICER achieves 87.92%–98.61% oracle-assisted conditional accuracy.The conclusion reports resilience of hard-evidence verification to adversarial noise and practical value in the Multichain and Bybit case studies.Source: §8 · p. 13

A Open Science

  • The implementation, benchmark subsets, and illicit-flow traces are planned for public release, while large benign-address dumps and evasion-facilitating scripts are withheld.The authors also emailed bridge developers about systematic oracle failures and observability blind spots.Source: A Open Science · p. 16

B Ethical Considerations

  • The study uses public artifacts, avoids natural-person de-anonymization and legal attribution, and relies on passive observation rather than live probing.Official APIs serve only as evaluation oracles; the system distinguishes hard-evidence confirmation, soft-clue support, and unresolved cases.Source: B Ethical Considerations · p. 16

C Implications and Recommendations

  • The authors recommend public evidence anchors for audits, protocol-level evidence alongside time-and-amount heuristics, and assessing privacy from protocol design and on-chain evidence.These implications are directed respectively to bridge developers, forensic analysts and compliance systems, and users.Source: C Implications and Recommendations · p. 16

D Cross-Chain Bridge Survey

The survey defines public traceability by a verifiable source-to-destination transaction-hash mapping and documents tracking-interface coverage across 131 protocols. The Bybit analysis illustrates recovered Ethereum-to-Bitcoin transaction pairs.

D Cross-Chain Bridge Survey

  • The survey covers 131 aggregator-sourced protocols and marks tracking as adequate only when a stable, public, verifiable source-hash-to-exact-destination-hash mapping exists.It records documentation, explorer accessibility, heterogeneous execution support, and API mapping; the authors report prevalent missing or inadequate tracking interfaces.Source: D Cross-Chain Bridge Survey · p. 17

E Cross-chain Transactions in Bybit Hack Laundering

  • The Bybit analysis presents ten recovered Ethereum-to-Bitcoin transaction pairs, with deterministic source-to-settlement matching and exact transfer amounts verified without official bridge interfaces.The table is described as illustrating reconstruction of precise illicit fund flows.Source: E Cross-chain Transactions in Bybit… · p. 17

F THORChain cross-chain attack

The THORChain attack analysis shows a source transfer split into two destination-side Ethereum transactions. XSplicer reconstructs their correspondence from protocol-level evidence rather than relying on potentially incomplete explorer displays.

F THORChain cross-chain attack

  • 14.165 ETH sent into THORChain was split into destination-side transfers of 5.979506 ETH and 8.185494 ETH.The amounts sum to the source-side internal transfer amount, excluding transaction fees.Source: F THORChain cross-chain attack · p. 17
  • Both outgoing transfers occurred in the same destination block and interacted with the same destination-side contract.Together, these properties characterize the one-to-two correspondence in this example.Source: F THORChain cross-chain attack · p. 17
  • XSplicer reconstructs the correspondence using the THORChain memo and Inbound/Outbound Tx ID linkage, not explorer display logic.A public bridge interface may show only one outbound transaction or collapse the flow into a simplified status view.Source: F THORChain cross-chain attack · p. 17

G Impact of Public Examples

The section examines how the number and selection of public examples affect protocol-knowledge reconstruction, then describes the protocol-specific rules compiled for the seven-bridge benchmark.

G Impact of Public Examples

  • 4,999 Allbridge ETH→SOL test samples are used to compare protocol-knowledge reconstruction with different numbers of input examples.The experiment uses least-covering and most-covering example-selection strategies.Source: G Impact of Public Examples · p. 17, Figure 10 · p. 18
  • The least-covering strategy selects examples covering the fewest remaining similar-pattern samples, while the most-covering strategy selects those covering the most.The former simulates unfavorable selection; the latter estimates the upper bound from representative examples.Source: G Impact of Public Examples · p. 17

H Protocol-Specific Evidence Rules Generated by XSPLICER

  • For seven evaluated bridges, Table 7 summarizes reconstructed destination-side constraints and cross-chain evidence used to assess candidate correspondences.These rules are reconstructed in Stage I and compiled into the Analyzer and Verifier in Stage II.Source: H Protocol-Specific Evidence Rules… · p. 18

I Stage I Evaluation Metrics

Stage I evaluates protocol-knowledge reconstruction through destination-spec correctness, cross-chain shared-spec correctness, and groundedness. Semantic matching aligns protocol-specific synonyms before predicted and ground-truth specifications are compared.

I Stage I Evaluation Metrics

  • The semantic-equivalence operator σ aligns predicted and ground-truth specifications using a predefined dictionary of protocol synonyms.This supports reproducible comparison when protocols use different terms for semantically equivalent entities, such as recipient and to_address.Source: I Stage I Evaluation Metrics · p. 18
  • Destination-spec correctness uses F1 to assess identification of destination-chain boundaries and address conventions.The predicted destination field set is compared with the baseline set using semantic intersection under σ.Source: I Stage I Evaluation Metrics · p. 18
  • Cross-chain shared-spec correctness measures recovery of protocol invariants and relational mappings, including cross-chain transaction identifiers and value-conversion formulas.The overlap between Scross and Gcross reflects accuracy of invariants and mappings used by downstream verifiers.Source: I Stage I Evaluation Metrics · p. 18
  • Groundedness measures the proportion of correct predictions supported by verifiable evidence, distinguishing direct evidence, partial evidence, and unsupported predictions.Direct evidence includes explicit text or transaction JSON; partial evidence relies on contextual clues requiring moderate inference.Source: I Stage I Evaluation Metrics · p. 18

Related papers

Loading 2609.18158v1…