Bridging the Opacity: Evidence-Backed Cross-Chain Transaction Correspondence Reconstruction Across Heterogeneous Blockchains Dan Lin1 Huan Xiao1 Ziwei Li1 Xiapu Luo2 Jiachi Chen3 Jiajing Wu1 Zibin Zheng1
arXiv:2609.18158v1 [cs.CR] 16 Sep 2026
1 Sun Yat-sen University
2 The Hong Kong Polytechnic University
Abstract
Src Chain 𝓒𝒔
Cross-chain Bridges
(e.g., Ethereum)
Cross-chain bridges enable interoperability, but they also break the transaction trails needed to trace illicit funds. Thirdparty investigators typically cannot access the source-todestination 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 XS PLICER, an evidence-driven system for reconstructing cross-chain transaction correspondence (xTCR) without privileged access to bridge backends. XS PLICER 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 XS PLICER on seven bridge protocols spanning EVM, Bitcoin, and Solana. XS PLICER 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, XS PLICER recovers more than 1,900 historical transaction pairs after Multichain ceased operations and identifies 754 illicit cross-chain transfers worth $105.6 million in the Bybit laundering incident. These results show that public protocol invariants can support practical cross-chain forensics without privileged bridge mappings.
1
3 Zhejiang University
Private indexed APIs
𝑡𝑥1 , … 𝑡𝑥𝑛
Bridge-internal mapping
𝑡𝑥𝑠
Privileged Information
Observability Space
… … …
Relayer / Validator state
Block N
Attacker
Dst Chain 𝓒𝒅
(heterogeneous chain)
User frontend context
Transactions
Logs / Traces
Protocol docs
Public example
𝑡𝑥𝑑 ?
Third Party Analyst
Figure 1: Limited observability in cross-chain transaction correspondence reconstruction. An attacker initiates a sourcechain transaction txs that is bridged to a destination chain, resulting in an unknown destination transaction txd .
hundreds-of-millions-of-dollars daily scale in decentralized finance [18, 22]. However, while this interoperability provides significant convenience, it disrupts the tracking continuity inherent in single-chain environments, severely compromising the observability of transactions. Attackers leverage “chainhopping” [15, 45] techniques to easily sever tracking leads on isolated ledgers, dispersing illicit funds across heterogeneous networks. According to the Elliptic 2025 report [15], over $21.8 billion in high-risk on-chain assets have been transferred via cross-chain mechanisms. For third-party analysts (e.g., security firms and regulators) constrained by publicly available data, cross-chain bridges are increasingly evolving into observability blind spots that obstruct tracking links. To quantify the extent of this observability deficit, we conduct an empirical analysis of 131 mainstream cross-chain protocols within the DeFi ecosystem. The results indicate that only 16.79% of the investigated bridge protocols provide precise destination-transaction txd retrieval capabilities based on source transaction hashes txs (detailed in Section 2.3). This implies that for the vast majority of cross-chain activities, third-party analysts are deprived of explicit on-chain mapping evidence, as shown in Fig. 1. Consequently, when official bridge interfaces are unavailable, oracle services are
Introduction
As blockchain networks evolve from isolated value islands into interconnected heterogeneous networks [4, 26, 46], crosschain bridges have become key infrastructure for asset interoperability [2, 19]. As of our access date, DeFiLlama [14] reports roughly $380M in 24-hour bridge volume and $15B over one month, placing bridge-mediated transfers at a 1
disrupted, or a protocol completely ceases operations (e.g., the Multichain shutdown [10] in 2023), investigators are forced to operate without any official auxiliary indexing. In such scenarios, they must rely solely on discrete state transition logs and transaction payloads scattered across heterogeneous chains. However, these isolated records inherently lack direct semantic continuity at the architectural level, imposing prohibitive analytical barriers to cross-chain forensics. Prior work [29, 30, 45] uses heuristics to bound the search space when bridge-internal mappings are invisible, but two core challenges remain. First, the heterogeneity of cross-chain protocols and execution environments exacerbates semantic discontinuity at the architectural level. Existing cross-chain association methods predominantly focus on relatively homogeneous scenarios (e.g., Ethereum → Polygon), relying on parsing logic built upon the assumption of similar address formats and transaction structures. However, within contemporary heterogeneous cross-chain architectures, destination clues are frequently fragmented and re-encoded within underlying payloads. For instance, in a deBridge (Ethereum → Solana) transaction, a 32-byte hexadecimal destination address on the Ethereum side must undergo protocol-specific Base58 parsing to map to a native Solana public key (detailed in Section 3.4). This heterogeneous re-encoding requires protocol-specific decoding and normalization before the relevant fields can be compared across ledgers. Second, existing approaches over-rely on probabilistic features such as time and amount similarities, lacking the evidentiary rigor required for forensics. In high-throughput or adversarial scenarios, these methods are highly susceptible to generating massive candidate pools and inducing false associations. To address the challenge of cross-chain transaction correspondence reconstruction under non-privileged conditions, we introduce XS PLICER, as illustrated in Fig. 2. XS PLICER implements protocol-evidence compilation as a three-stage workflow. Stage I uses Large Language Models (LLMs) [6, 25,38,44] to synthesize public protocol documents and execution traces into a unified semantic specification of destinationside constraints and cross-chain shared evidence. Stage II compiles this specification into an executable Analyzer and Verifier. Stage III uses these operators to bound destination candidates and assign an evidence-linked forensic decision. This separation of candidate construction and verification prioritizes protocol-level hard evidence and uses soft clues only as fallback support when hard evidence is unavailable. We evaluate XS PLICER on seven mainstream bridges across Ethereum, Bitcoin, and Solana, achieving accuracy ranging from 87.92% to 98.61%. The results show that public protocol evidence supports correspondence reconstruction across heterogeneous execution models, even under constrained third-party observability. Comparisons with existing tools and official interfaces expose systemic deficiencies in the interfaces’ historical coverage and handling of non-standard protocol states (e.g., cross-chain attacks). Component anal-
yses and robustness experiments further show that protocollevel invariants retain discriminative power under candidate ambiguity and adversarial noise, whereas time- and amountbased soft clues degrade under interference. Case studies further demonstrate practical forensic utility. XS PLICER reconstructs historical paths after the Multichain shutdown and traces THORChain-mediated flows associated with the Bybit Hack. Our primary contributions are summarized as follows. • Problem formulation. We formulate xTCR for third-party investigators as candidate search guided by destination-side constraints, followed by verification using shared protocol evidence. • System design. We design and implement XS PLICER, which compiles public protocol artifacts into semantic specifications and executable analyzers and verifiers for heterogeneous ledgers. • Evaluation. We evaluate XS PLICER on 54,578 transaction pairs across seven mainstream bridges spanning EVM, Bitcoin, and Solana, including adversarial noise experiments and real-world case studies. • Forensic findings. We show that official bridge interfaces can miss valid correspondences and that protocol-level hard evidence resolves ambiguities left by time- and amountbased matching.
2
Background and Empirical Study
2.1
Cross-Chain Bridge Workflow
1 Bridge workflows generally follow three stages [2, 11, 19]. ⃝ During initiation, the source protocol locks, burns, or escrows assets and emits a cross-chain event or message containing 2 During relaying, validators or relayers user information. ⃝ 3 propagate the signed proof to the destination environment. ⃝ During settlement, the destination protocol validates the proof and mints or releases assets. We use the following transaction definitions:
• Source transaction (txs ): The transaction on the source chain that initiates the bridge request and asset transfer. • Destination transaction (txd ): The transaction that concludes the process via asset delivery on the destination chain. Any auxiliary transactions, including verification proofs, intermediate hops, or refund/return executions, are categorized as related transactions (txrel ). In a third-party setting, these transactions represent the only observable anchors for reconstructing fund flows across disjoint ledgers. 2
Stage I: Protocol Knowledge Reconstruction Public Artifacts
Offline Preprocessing
Unified Semantic Spec
Documents LLM-based Semantic Extractor
Transactions
Online Query-time Recovery
𝒕𝒙𝒔 Source Transaction
Stage II: Executable Rule Generation
Decoder
Intent Recovery
𝑐𝑎𝑙𝑙𝑑𝑎𝑡𝑎
Target ChainID
𝑂𝑃_𝑅𝑒𝑡𝑢𝑟𝑛
Validation & Repair
Destination-side Constraints Cross-chain Shared Evidence
Analyzer
Candidate Collector 𝒯𝑑 Tagert Universe
𝑙𝑜𝑔𝑠 𝑖𝑛𝑠𝑡𝑟𝑢𝑐𝑡𝑖𝑜𝑛𝑠
Interface Synthesizer
Task Decomposer
Rule Operators
Forensic Recovery Hard Evidence Check No / Insufficient
Target Chain
Soft Clue Analysis
Target Address
𝓒𝒅
Verifier
Yes
Yes
Confirmed
Supported
No / Insufficient 𝒕𝒙𝒅
None
Unresolved
Stage III: Online Correspondence Recovery
Figure 2: Overview of the XS PLICER architecture. Offline, Stage I derives a unified semantic specification of destination-side constraints and cross-chain shared evidence from public documents and transaction examples. Stage II compiles the specification into two lightweight executable rule operators: the Analyzer and the Verifier. Online, Stage III uses the Analyzer to construct a bounded candidate set and applies hard-evidence-first verification to produce a forensic decision state.
2.2
Blockchain Heterogeneity
browsing functionalities instead of comprehensive and independently verifiable forensic indices intended for external investigators [39]. Following the cessation of operations by Multichain in 2023, all its APIs and the official explorer became inaccessible for queries. Similarly, the deprecation of the legacy API for Stargate underscores the volatility of such interfaces [33]. Therefore, official APIs cannot be treated as reliable correspondence oracles. In a third-party analysis setting, crosschain correspondence must be performed without bridgeinternal state and must rely on public on-chain artifacts and protocol documentation. Since temporal and monetary proximity provide only soft cues and lack the evidentiary strength required for forensic attribution, XS PLICER moves beyond similarity-based heuristics and reconstructs correspondence from verifiable hard evidence.
Heterogeneous execution models encode and store crosschain evidence differently. EVM chains distribute it across calldata, event logs, and internal traces; Bitcoin embeds it in locking scripts, change outputs, or OP_RETURN payloads; and Solana stores it in multi-instruction transactions, account metadata, and program logs. The same evidence therefore appears in different formats and locations across chains, making simple heuristic matching insufficient.
2.3 Empirical Study: The Observability Crisis To quantify the forensic visibility of existing cross-chain bridges, we conduct an empirical investigation of 131 mainstream cross-chain protocols and bridge-integrated DeFi services sourced from the cross-chain aggregator Chainspot [9]. We define traceability as the consistent availability of a mapping from a source transaction hash (txs ) to its corresponding destination transaction hash (txd ) via public official interfaces. Our findings reveal a pervasive observability crisis: only 16.79% of the surveyed protocols provide such verifiable mapping capabilities. Due to space constraints, the complete list of 131 bridges is presented in TABLE 8 of Appendix D. Furthermore, most public APIs are inherently designed for developer-oriented integration, pricing, and real-time status tracking, rather than for forensic-grade historical record reconstruction. For instance, the LayerZero Value Transfer API requires an application for a production environment API key to gain access [24]. The documentation for the Across protocol explicitly positions its API as a tool for generating executable calldata and quotes expressly advising developers against caching response data [1]. Explorer interfaces such as Wormholescan primarily offer superficial metadata
3
Problem Overview
Motivated by the privileged invisibility and representational heterogeneity observed in Section 2.3, this part defines the problem model for third-party analysis. We specify the capabilities of the analyst and the adversary, and extend prior cross-chain association analysis to cross-chain transaction correspondence reconstruction (xTCR), where the goal is to recover evidence-backed source–destination correspondence under privilege barriers.
3.1
Third-Party Analyst Model
We define the analyst as a non-privileged external entity, representing security auditors or regulatory bodies conducting postmortem forensics [29, 30, 45]. The analyst can access public 3
evidence, including on-chain artifacts, public protocol specifications, and publicly available cross-chain examples. We assume no access to bridge-internal privileged information, such as private backend mappings or proprietary relayer states, and no continuously available official correspondence service. This model targets non-cooperative and post-mortem investigations; when official mappings are available, XS PLICER provides an independent cross-check rather than replacing cooperative access.
3.2
First, in heterogeneous cross-chain scenarios, the task is no longer to simply select the most similar transaction from a candidate pool. Instead, the destination-side clues themselves elude existing parsing assumptions. As illustrated in Fig. 3, we examine a deBridge [12, 13, 17, 32] transaction from Ethereum 0x93b1...11d5 to Solana 4V7f...1QMb, in order to demonstrate this representation gap. While the CreatedOrder event on the source chain should logically correspond to the fulfillOrder instruction on the destination chain, this relationship lacks direct observability. On the Ethereum side, destination information is embedded within internal fields rather than explicitly exposed. The takeChainId parameter designates Solana as the target, but critical fields like receiverDst and allowedTakerDst are encoded as bytes32 values that cannot be directly interpreted as Solana addresses. Similarly, the cross-chain identifier orderId manifests as a hex bytes32 string on Ethereum, whereas it is represented as a u8 array of size 32 within the Solana instruction. Although these elements exhibit semantic consistency, their on-chain representations are entirely heterogeneous, precluding direct alignment through string or structural matching. Consequently, recovering the correspondence fundamentally requires decoding the destination-side fields from the source event into valid Solana public keys and normalizing the orderId into a unified byte representation to ensure robust verification. Second, even when cross-chain transfers occur in seemingly homogeneous environments, the temporal and monetary similarities utilized by existing work can at best help shrink the candidate space. However, attack samples from THORChain demonstrate that a single source chain behavior can simultaneously correspond to multiple seemingly valid destination-side candidates, depriving monetary proximity of its uniqueness capability. Furthermore, in directions like BTC→ETH, long delays may occur between the source chain transaction and the destination chain settlement, significantly expanding the search window and introducing more similaramount interference items (detailed analysis in Section 5.6.1). These two types of failures collectively indicate that, in a third-party analyst setting, the key to cross-chain reconstruction is no longer finding the most similar destination chain transaction for each source chain transaction. Instead, the key is to first restore the comparability of destination-side constraints and then verify protocol-level shared evidence within a local candidate space.
Adversary Model
We consider attackers who use “chain-hopping” [15, 45] to disrupt single-chain tracing by moving assets to a heterogeneous chain, aiming to obscure the public link between the source transaction (txs ) and its destination transaction (txd ). Attackers may also vary transfer amounts to hinder recovery. We assume an honest-but-opaque bridge that may maintain a deterministic internal mapping inaccessible to third-party analysts. Thus, xTCR addresses observability loss rather than a missing mapping or bridge compromise.
3.3
Problem Formulation
We model cross-chain transaction linkage as the reconstruction of latent transaction correspondence under a privilege barrier. The input is ⟨Cs ,txs , A , Ts ⟩, where txs ∈ Ts is a publicly observable cross-chain initiation transaction on the source chain Cs ; A denotes the public artifact space of the public protocol, including unstructured documentation and a limited set of pairs of public cross-chain examples; and Td denotes the complete set of public transactions on the destination chain Cd . Because Ts and Td differ in their underlying execution models, such as Account-based and UTXO-based models [5, 17], the destination-side execution transaction txd of txs is latent. Before reconstructing the protocol logic, an analyst cannot directly identify the deterministic attributes of txd , such as its hash or address, from the full set Td . We therefore construct an evidence reasoning model based on bridge protocol invariants to address this heterogeneity-induced observability gap. The output is y = ⟨Cd , (txs ,txd ), E⟩, where txd ∈ Td is the reconstructed destination transaction, i.e., the transaction that completes the delivery of the user’s asset, and E is the evidence set supporting the correspondence. If no / Each evidence correspondence can be established, then y = 0. item ei ∈ E is a multidimensional tuple that explicitly states the logical link between txs and txd . Section 4.1 defines this structure as a specification in detail.
3.5
Challenges and Design Rationale
The failures outlined above introduce three structural constraints that fundamentally shape our methodology. Challenge I: The opacity of bridge-internal mappings. Without privileged access, the txs → txd mapping is invisible to external analysts. In the absence of internal APIs that bound the search space, analysts face a severe observability gap.
3.4 Motivation: Why Prior Work Breaks Down The limitations of existing cross-chain association methods in real-world analysis primarily stem from the fact that their underlying assumptions do not hold in our setting. 4
Solana 𝑡𝑥𝑑 (4V7f…1QMb)
Ethereum 𝑡𝑥𝑠 (0x93b1…11d5) event CreatedOrder(..) { // core fields shown below takeChainId =7565164 //Solana ID receiverDst = 0xc2df...a6966 allowedTakerDst = 0xlbdd...e7931 orderId = 0x8c83...c7dd … }
xxx
hex bytes32 fulfillOrder instruction = { ≡ receiver = B51u…tr7x [u8; 32] allowedTakerDst = 2snH…kKuS orderId
## Transaction Memos and OP_RETURN in THORChain ### Memos Encode User Intent
= [194, 234, 156, 209, ..., 210, 234]
... THORChain processes inbound transactions by inspecting both the transaction object and its MEMO field. The memo expresses the user’s intent, such as swap type, target asset, destination address, price limit, and optional streaming parameters.All memos follow a structured format: FUNCTION:PARAM1: PARAM2:PARAM3:PARAM4 For example, a swap memo may specify the asset to receive, the final destination address, and execution constraints. This allows a native L1 transaction to instruct THORChain how funds should be routed across chains. ...
… }
Figure 3: The representation gap in deBridge cross-chain transactions from Ethereum to Solana. Although semantically identical, a shared identifier is encoded as hex bytes32 on Ethereum and as a [u8;32] byte array on Solana, making the semantic correspondence obfuscated.
### OP_RETURN on UTXO Chains For UTXO-based chains such as Bitcoin, Bitcoin Cash, Litecoin, and Dogecoin, transactions must follow a specific output structure. The first output sends funds to the inbound vault, the second output returns change, and the memo is placed in an OP_RETURN output, typically VOUT2, to specify the user’s intent. Because Bitcoin OP_RETURN space is limited, THORChain constrains UTXO-chain memos to 80 bytes. If the memo is longer than 80 characters, the first 79 characters plus “^” are placed in OP_RETURN, while the remaining data is encoded in additional outputs. ...
Design I: Artifact-driven semantic reconstruction. XS PLICER does not start by blindly scanning ledgers. It first extracts specifications, including destination intent and shared evidence, from public artifacts and examples. This provides a declarative basis for reconstruction without privileged information. Challenge II: Representation heterogeneity. Different execution environments fragment and re-encode cross-chain clues in low-level payloads, breaking their direct comparability and making static, template-based parsing insufficient. Design II: Executable specification synthesis. To bridge this structural gap, XS PLICER dynamically compiles reverseengineered protocol semantics into executable decoding operators and normalization rules, enabling uniform comparison across heterogeneous ledgers. Challenge III: The inconclusiveness of soft clues. Public traces are inherently ambiguous. Temporal and monetary heuristics can conflate statistical correlation with factual, verifiable correspondence. Design III: Evidence-stratified verification. The verification engine follows a hard-evidence-first principle. Soft clues are used only as probabilistic fallback when structural evidence is unavailable. This allows XS PLICER to output evidencebacked forensic states rather than fragile similarity rankings.
4
dev.thorchain.org
Figure 4: A public documentation snippet from THORChain Dev Docs [34] serving as input for Stage I. The highlighted text describes how transaction memos and OP_RETURN fields encode user intent, destination addresses, routing constraints, and execution parameters for cross-chain swaps.
chain shared evidence (e.g., message identifiers and sourcetransaction references) provides the basis for later verification. This intermediate specification provides a structured interface between heterogeneous public evidence and executable recovery logic. Stage II: Executable rule generation. Given the unified semantic specification, XS PLICER synthesizes two lightweight executable rule operators. The Analyzer extracts destination-side constraints from a decoded source transaction for online recovery, while the Verifier extracts, normalizes, and checks cross-chain shared evidence between a source transaction and a destination-side candidate. Rather than generating a general-purpose bridge analyzer, Stage II translates the recovered protocol semantics into bounded, auditable interfaces between high-level protocol descriptions and low-level chain-specific encodings.
System Design
XS PLICER provides a unified workflow for evidence-backed correspondence reconstruction across heterogeneous ledgers. As illustrated in Fig. 2, XS PLICER adopts a three-stage system architecture. Stage I: Protocol knowledge reconstruction. XS PLICER first reconstructs protocol-level semantics from public artifacts, including protocol documents and publicly available cross-chain transaction examples. The goal of this stage is not to directly identify the destination transaction, but to derive a unified semantic specification that captures two types of recoverable hard evidence: destination-side constraints and cross-chain shared evidence. Destination-side constraints (e.g., the destination chain and recipient) define where the corresponding destination-side execution may appear. Cross-
Stage III: Online correspondence recovery. Given a source chain transaction txs , XS PLICER first decodes data, then the Analyzer recovers destination-side constraints and uses them to construct a bounded candidate set Kd from the destination-side transaction universe Td . After that, the Verifier applies a hard-evidence-first decision strategy over Kd . If normalized cross-chain shared evidence uniquely supports a candidate, XS PLICER outputs a confirmed correspondence. If hard evidence is unavailable but soft clues provide auxiliary support, the system outputs a supported result rather than a proof. 5
4.1 Stage I: Protocol Knowledge Reconstruction
Destination-side Spec { "semantic_field": "target_chain" , "candidates": [{ "field_key": "memo", "description": "memo includes destination chain marker; observed example uses 'b' for Bitcoin", "value_examples": …}] }, { "semantic_field" : "target_address”, "candidates": [{ "field_key": "memo", "description": "memo includes destination Bitcoin address", "value_examples": …}] }
The objective of Stage I is to synthesize machine-actionable protocol rules from heterogeneous public artifacts, without privileged correspondence oracles. Our design relies on the observation that cross-chain correspondence appears in two complementary forms: • Textual protocol artifacts (e.g., official documentation and developer guides), which describe the declarative encoding of destination intent.
Cross-chain-shared Spec
• On-chain execution artifacts (e.g., public source– destination examples), which show how these semantics appear in native ledger structures, such as EVM logs and Solana instructions.
{ "key": "source_tx_hash_ref", "importance": "hard", "compare_mode": "contains", "source": [{ "field_key": "hash", "value_examples": […] }], "destination": [{ "field_key": "op_returns.ascii", "value_examples": […] }]
Stage I synthesizes these two modalities into a unified semantic specification (Semantic Spec). LLM-based semantic extractor. To reduce noise and handle structural disparities, Stage I first applies targeted preprocessing to the input artifacts:
}
Recover destination-side constraints from "memo"
Recover crosschain shared evidence constraints from "OP_RETURN"
Figure 5: The unified semantic spec generated by Stage I for THORChain. The upper section instructs the extraction paths for destination-side constraints from the memo field, and the lower section specifies the cross-chain shared evidence from the OP_RETURN payload.
• Documentation-side block filtering: XS PLICER segments protocol documentation into discrete text blocks. We use an LLM as a semantic filter to retain blocks relevant to cross-chain payloads and shared evidence, while discarding irrelevant boilerplate, such as SDK installation guides.
evidence sources. Conflicting or weakly supported items are marked as pending. This cross-validated merging strategy reduces LLM-induced errors in protocol interpretation. Stage I example input and output. To illustrate how XSPLICER operationalizes its evidence-driven reconstruction via the three-stage architecture, we walk through an end-to-end THORChain transfer (ETH→BTC) as follows. The system takes a public reference pair (ETH txs 0x2b05...65fc → BTC destination txd 5BDC...5714), and THORChain’s developer documentation [35,36] (as shown in Fig. 4) as input. The unified semantic specification is generated as shown in Fig. 5. 1 Destination-side constraints: The ETH transaction invokes ⃝ depositWithExpiry(). The spec defines rules to extract the destination chain marker (e.g., b for Bitcoin) and the recipient 2 Cross-chain shared evidence: The address from the memo. ⃝ system identifies a rigid correlation invariant, the OP_RETURN payload in the BTC destination transaction explicitly backfills the source transaction’s hash (source_tx_hash_ref). Because this reference is explicitly embedded by the destination protocol and uniquely points to the source execution, XS PLICER categorizes it as protocol-level hard evidence.
• Example-side trace summarization: For verified examples, XS PLICER uses offline parsing operators to convert raw low-level transaction traces into structured representations, which helps the LLM better interpret empirical evidence. Public-example grouping and selection. To cover different protocol execution patterns, we group and select public examples according to transaction structures on the source ledger. EVM examples are grouped by methodId and interacting contract addresses, whereas Solana examples are grouped by programId and instruction byte length. For Bitcoin examples, we use random selection by default or coarse grouping by OP_RETURN length. Section 5.4.2 evaluates how public examples affect performance. Second, XS PLICER extracts hard-evidence patterns from the preprocessed data to populate the protocol Semantic Spec: • Destination-side constraints: These include destination chain IDs, address-encoding variants, and recipient boundaries, which delimit the downstream search space. • Cross-chain shared evidence: These are deterministic invariants preserved across ledgers, such as unique message IDs, nonces, or protocol-specific hash references.
4.2
Stage I then merges evidence extracted from documents and traces into a unified Semantic Spec. The merge procedure follows a conservative consensus rule: fields and logic are finalized only when corroborated by multiple independent
Stage II: Executable Rule Generation
The semantic specifications produced in Stage I define what evidence should be recovered, but they do not directly parse the physical layout of raw on-chain payloads. Using LLMs for 6
online transaction processing is unsuitable: the workload is large, latency-sensitive, and requires deterministic byte-level operations, such as address decoding, hash normalization, and offset-based field extraction. Stage II therefore converts the declarative Semantic Spec into executable rule operators that can be invoked by the online recovery engine. As shown in Fig. 2, Stage II consists of two components: a task decomposer and an interface synthesizer. Task decomposer. The task decomposer first breaks the Unified Semantic Spec into two classes of executable tasks. The first class targets destination-side constraint recovery, including destination chain identifiers, destination addresses, recipient boundaries, and protocol-specific filters. The second class targets cross-chain shared evidence verification, including message IDs, nonces, hash references, and other protocol invariants that must be compared across ledgers. Interface synthesizer. The interface synthesizer then materializes these tasks into two lightweight modules:
def Analyzer ( source_tx ): memo = source_tx [" input " ][ " param " ][ " memo "] m_chain = re . match (r" =:(\ w):" , memo ) m_addr = re . search (r"( bc1 [0 -9 ac -hj -np -z ]{11 ,90}) " , memo , re .I) target_chain = " btc " if m_chain and m_chain . group (1) . lower () == "b" else None target_addr = m_addr . group (1) . lower () if m_addr else None return ... def Verifier ( source_tx , target_tx ): src = source_tx [" hash " ]. removeprefix ("0x"). upper () out = target_tx [" op_returns " ][0][ " ascii "] m = re . search (r" OUT :([0 -9A -Fa -f ]{64}) " , out ) tgt = m. group (1) . upper () if m else None matched = ( src == tgt ) return ...
Figure 6: Python core snippet of the lightweight executable rule operators synthesized by Stage II for THORChain. The Analyzer() function extracts destination side constraints, while the Verifier() function normalizes transaction hashes and extracts payloads from the target OP_RETURN output to authenticate cross-chain shared evidence.
• Analyzer: The analyzer recovers destination-side constraints from decoded source-chain traces. It follows the semantic paths emitted by the Task Decomposer and applies the corresponding decoding and normalization rules, such as address-format conversion or field extraction from calldata, logs, memos, or instructions.
4.3 Stage III: Online Correspondence Recovery Stage III operates as the online execution engine of XSPLICER . It applies the synthesized rules to live or historical transaction streams, driving the evidence-backed correspondence reconstruction. Decoder. XS PLICER first decodes raw input transactions, unrolling low-level traces across heterogeneous ledgers (e.g., EVM, Solana, Bitcoin) into a uniform evidence view. Crosschain traces manifest differently depending on the execution model: EVM transactions typically embed fields in calldata, event logs, or internal execution traces; Solana exposes evidence via instructions, inner instructions, program logs, account metadata, or memo fields; whereas UTXO-based chains rely on outputs, scripts, or OP_RETURN payloads. Analyzer & Collector. XS PLICER invokes the generated Analyzer to extract destination-side constraints from the source transaction. Based on these constraints, it constructs a localized destination-side candidate set (Kd ). This collection process utilizes chain-specific adapters designed to rigorously prune the search space from an open-world ledger down to a strictly bounded candidate pool. Verifier. During candidate evaluation, XS PLICER utilizes the Verifier to execute an evidence-stratified model, relying on heuristic soft clues strictly as a fallback when deterministic hard evidence is structurally absent. Rather than forcing a single transaction match, Stage III outputs a rigorous forensic decision state. We define three primary states:
• Verifier: The verifier checks cross-chain shared evidence for a candidate transaction pair. It extracts and normalizes protocol-specific evidence from both sides and evaluates whether the pair satisfies the required invariants, such as hash concatenation, prefix padding, byte-order conversion, or sequence-number matching. Validation and repair. After the Interface Synthesizer generates the Analyzer and Verifier, XS PLICER automatically validates their executability, behavior on public cross-chain examples, and consistency with the Semantic Spec. If a check fails, XS PLICER uses the validation report to guide the LLM in repairing the affected code and then revalidates the modules before they enter Stage III. Both modules expose standardized interfaces to Stage III. This separation keeps LLM-assisted reasoning offline and confines online recovery to deterministic operators. As a result, the runtime only applies fixed protocol-specific checks to each candidate pair, enabling scalable verification over large transaction sets. Stage II example output. XS PLICER statically compiles this Spec into executable code, as shown in Fig. 6. 1 The Analyzer is programmed to parse the source-side ⃝ 2 The Verifier memo to isolate the destination constraints. ⃝ is synthesized to decode the OP_RETURN payload from the BTC scriptpubkey and perform a hex-aligned comparison against the source hash. This critical step bridges the semantic gap, translating declarative LLM outputs into deterministic byte-level operations (e.g., handling the ASCII decoding of OUT: prefixes).
• Confirmed: If exactly one candidate in Kd satisfies the protocol-level hard-evidence checks, XS PLICER reports the correspondence as Confirmed. 7
this hard evidence, XS PLICER immediately bypasses probabilistic soft clues and reports the correspondence as Confirmed.
Source-side Ethereum Transaction { "hash": "0xF636891AF6325A5FD2FD535D9C1D7A3688493F3990CFAAE3AC25BBC7FC7510B3", "chain": "eth", "decode_mode": "abi", "input": { "func_name": "depositWithExpiry", "param": { "memo": "=:b:bc1q0ckzxjd2m2c6x3f2782vn30fexpa64emrtwxz0:11933892/1/0:sto:0",}, }, }
Hard Evidence Check
5
Evaluation and Analysis
5.1
Experimental Setup
Confirmed
We evaluate XS PLICER through these research questions:
Destination-side Bitcoin Transaction {
• RQ1: Overall performance. Can XS PLICER effectively reconstruct cross-chain correspondence across heterogeneous blockchains without relying on bridge-internal privileged information? (Evaluated in Section 5.2)
"hash": "198979d1ed437c11391cd7b028d1a352d3f2cfa2926ca47b2f83d41ee805541e", "chain": "btc", "decode_mode": "utxo", "to": "bc1q0ckzxjd2m2c6x3f2782vn30fexpa64emrtwxz0", "op_returns": [ { "ascii":"OUT:F636891AF6325A5FD2FD535D9C1D7A3688493F3990CFAAE3AC25BBC7FC7510B3", }],
}
• RQ2: Baseline comparison. How does XS PLICER perform compared with existing state-of-the-art cross-chain tracing tools? (Evaluated in Section 5.3)
Figure 7: Stage III online correspondence recovery process for THORChain. The system outputs a Confirmed forensic state by successfully matching the source Ethereum transaction hash with the payload embedded in the destination Bitcoin OP_RETURN field.
• RQ3: Component and robustness analysis. What are the individual contributions of XS PLICER’s core components, and how resilient is the system against artifact ablation and adversarial ambiguity? (Evaluated in Sections 5.4 and 5.5) • RQ4: Practical forensic analysis. What limitations do official bridge interfaces exhibit, and how effective is XSPLICER in post-mortem and adversarial fund-tracing scenarios? (Evaluated in Section 5.6)
• Supported: If hard evidence is structurally unobservable, yet a candidate exhibits high proximity in soft clues (amount, time, and address) without competitive ambiguity in the candidate set, the system outputs the match as a weighted investigative lead.
5.1.1
• Unresolved: If the evidence chain is broken or irreconcilable ambiguity exists (e.g., multiple equal-amount candidates lacking hard evidence), the system explicitly flags the state as unresolved, structurally preventing false positives.
Blockchains and Bridge Protocols
We evaluate XS PLICER across the EVM, Bitcoin, and Solana ecosystems, which span heterogeneous execution models. The EVM setting includes Ethereum (ETH) and Binance Smart Chain (BSC), account-based smart contract platforms with compatible execution structures but distinct ecosystems. Bitcoin (BTC) represents the UTXO model, where native contract event logs are absent and scripting is limited. On Solana (SOL), a high-throughput, instruction-driven nonEVM ledger, we evaluate destination-side constraint recovery under multi-instruction transactions and account-metadatabased candidate collection.
Stage III example output. As shown in Fig. 7, when a new ETH source transaction (0xf636...10b3) is observed, XS PLICER applies the Analyzer to extract the memo: =:b:bc1q0ckzxjd2m2c6x3f2782vn30fexpa64emrtw xz0:11933892/1/0:sto:0
The Analyzer isolates the chain marker (b → Bitcoin) and the destination address (bc1q...wxz0). Using these constraints, XS PLICER dynamically prunes the global BTC ledger to construct a localized destination-side candidate set. The system then iterates through this set using the Verifier. Even if the candidate pool is polluted with equal-amount adversarial transactions, the Verifier pinpoints the exact source hash reference deeply embedded within the OP_RETURN of the true destination transaction (1989...541e):
5.1.2
Dataset Construction
For quantitative correspondence evaluations, labeled transaction pairs come from accessible explorer/API records (RQ1 and transaction-level analyses in RQ3) or a published dataset (RQ2) [29]. TABLE 1 summarizes the scale of the APIverifiable dataset. Public examples used for system construction are disjoint from the evaluation pairs. For practical cases without complete official correspondence records (RQ4), we manually cross-check both XSPLICER ’s recovered correspondences and its generated hardevidence rules against raw on-chain events and protocolspecific invariants (Appendix H).
OUT:F636891AF6325A5FD2FD535D9C1D7A3688493F3 990CFAAE3AC25BBC7FC7510B3
This payload perfectly matches the normalized ETH source hash (stripped of the 0x prefix and capitalized). Supported by 8
Table 1: Dataset scale and ground-truth sources. Protocol
Dominant Paradigm
Explorer/API for Ground Truth
Documentation Availability
Supported Directions
Allbridge deBridge Wormhole THORChain WanBridge Orbiter Symbiosis
Liquidity-/swap-based Message-based Message-based Swap-based Gateway-/bridge-based Routing-/liquidity-based Swap-/routing-based
https://core.allbridge.io/explorer https://app.debridge.com/orders https://wormholescan.io/ https://thorchain.net/dashboard https://www.wanscan.org/ https://www.orbiter.finance/explore https://symbiosis.finance/
https://docs-core.allbridge.io/ https://github.com/debridge-finance https://docs.wormhole.com/wormhole/ https://docs.thorswap.finance/ https://docs.wanchain.org/products/wanbridge https://github.com/Orbiter-Finance https://docs.symbiosis.finance/
BSC / ETH / SOL BSC / ETH / SOL BSC / BTC / ETH / SOL BSC / BTC / ETH BSC / ETH / SOL BSC / ETH / SOL ETH / SOL
5.1.3
Evaluation Metrics
Protocol
• Candidate coverage (Cov.): Quantifies the recall rate of the destination-side intent recovery stage. It is formally defined as the probability that the ground-truth destination transaction, txd∗ , is successfully bounded within the generated local candidate set Kd (txs ) across all queries Q :
Allbridge deBridge WanBridge THORChain Orbiter Wormhole Symbiosis
|{txs | txd∗ ∈ Kd (txs )}| |Q |
339.70 12.53 396.80 559.14 2445.13 600.80 173.03
Cov. (%)
Acccov (%)
ρh (%)
ρs (%)
|Kd |
Lat. (s)
99.58 98.60 97.76 93.17 98.40 98.61 87.92
96.80 88.12 90.47 93.17 91.97 98.61 87.92
91.85 74.67 89.45 92.65 66.30 77.09 87.79
33.20 17.03 18.38 7.14 33.85 56.56 24.28
9.16 6.00 8.06 2.79 7.66 6.99 8.33
123.48 120.42 120.54 46.41 112.11 146.34 98.68
provide discriminative evidence within the covered search space. For Wormhole, despite its high soft-clue ambiguity ratio (ρs = 56.56%), the hard-evidence-first strategy filters candidates that are similar only in time or amount and achieves 98.61% Acccov . Failure analysis. XS PLICER may fail to produce a Confirmed correspondence for two main reasons. First, candidate collection may fail to include the correct destination transaction, leaving the Verifier with no correct candidate to evaluate. Candidate coverage exceeds 93% for most protocols, showing that XS PLICER usually narrows the search space effectively. Symbiosis is the main exception: its destination settlement is often obscured by intermediate contract executions and routing steps, reducing coverage to 87.92%. Second, even when the correct transaction is included in the candidate set, XS PLICER may lack the protocol-level hard evidence needed to confirm it uniquely. In such cases, the system returns Supported or Unresolved rather than forcing a Confirmed result.
• Conditional accuracy (Acccov ): To separate the discriminative capability of the Verifier from data-collection failures in on-chain trace retrieval, we introduce this oracleassisted metric. The metric assumes an evaluation oracle that guarantees txd∗ ∈ Kd , thereby providing an empirical upper bound on verification accuracy. This allows us to evaluate the precision of the Verifier independently of candidate-collection recall. • Hard-evidence availability ratio (ρh ): The proportion of cross-chain queries for which protocol-level deterministic hard evidence, represented by the unified semantic spec, can be reconstructed using only public artifacts. • Soft-clue ambiguity ratio (ρs ): Quantifies the risk of false positives when relying only on heuristic soft clues. It is defined as the percentage of candidate sets Kd that contain at least one non-target noise transaction whose transferred amount falls within a ±5% error margin of the source transaction’s amount.
Insight 1: Cross-chain linkability can remain observable even when bridge-internal mappings are opaque, because parts of the correspondence are preserved in public protocol artifacts. The core of xTCR is to recover destinationside constraints that prune the search space and then use hard evidence, when available (ρh ), to resolve ambiguity introduced by soft clues (ρs ). XS PLICER therefore shifts cross-chain tracing from similarity-based heuristics toward evidence-backed forensic reconstruction.
• Latency (Lat.): The average time required by the online Stage III pipeline to process one source transaction, from ingestion to the final correspondence decision.
5.2
Avg. Time (s)
14,999 13,828 3,243 6,000 9,752 5,986 770
Table 2: Overall performance of XS PLICER grouped by bridge protocol
We evaluate XS PLICER using these metrics.
Cov. =
Collected Pairs
Overall Performance
TABLE 2 and TABLE 3 report XS PLICER’s performance across seven mainstream bridge protocols and six heterogeneous chain directions, grouped by bridge and chain pair, respectively. Forensic discriminative power. TABLE 2 shows that, once the ground-truth transaction is included in the candidate set, Allbridge and THORChain exceed 93% Acccov . The protocol invariants reconstructed in Stages I and II therefore
Directional asymmetry in heterogeneous paths. The chain-pair breakdown (TABLE 3) exposes a pronounced directional asymmetry in cross-chain forensics. For instance, Acccov for ETH→SOL transfers reaches 97.98%, significantly exceeding the reverse SOL→ETH route at 84.56%. This 9
Table 3: Overall performance of XS PLICER by chain pair Chain Pair
Cov. (%)
Acccov (%)
ρh (%)
ρs (%)
|Kd |
Lat. (s)
ETH→SOL
98.36
97.98
97.26
28.12
7.67
130.04
ETH→BTC
93.41
93.40
92.88
9.51
2.61
42.88
BSC→SOL
98.75
94.91
94.85
BSC→BTC
95.82
98.37
95.12
23.63
8.07
135.10
15.09
3.32
39.67
BTC→ETH
91.93
91.68
87.76
6.85
2.39
63.83
SOL→ETH
98.79
84.56
54.99
30.45
7.83
106.48
Table 4: Comparative performance of XS PLICER against EVM-focused baselines. Method Connector ABCtracer XS PLICER
ETH → BSC
ρh (%)
Acccov (%)
ρh (%)
95.65 94.38 100.00
– – 100.00
95.35 94.08 99.89
– – 99.89
Entity Recognition (NER), and information retrieval to relax Connector’s heuristics, but remains limited to EVM→EVM.
discrepancy is not an artifact of ledger speed, but rather stems from asymmetric evidence exposure protocols. During SOL→ETH transfers, bridge protocols systematically strip away publicly verifiable identifiers when transitioning from Solana’s non-EVM instruction model to the EVM account model. Consequently, the hard-evidence availability (ρh ) plummets to 54.99%, while soft-clue ambiguity (ρs ) surges to 30.45%, forcing XS PLICER to downgrade its verification strategy to fragile heuristic fallbacks. Computational overhead and real-time viability. The correlation between candidate pool size (|Cd |) and average latency (Lat.) indicates that XS PLICER’s processing overhead is dominated by the complexity of bounding the destination search space, rather than native block intervals. When targeting Solana (e.g., ETH→SOL, BSC→SOL), high-frequency state updates and program/account-level unrolling inflate both the candidate pool (∼8 transactions) and processing latency (130–135s). Conversely, Bitcoin-bound transfers exhibit highly constrained candidate spaces (|Cd | < 3.5) and lower latencies (40–64s). Once the destination footprint is publicly visible, XS PLICER achieves rapid correlation, though total end-to-end discovery remains naturally bounded by Bitcoin’s native confirmation delays and bridge payout pacing. Ultimately, XS PLICER delivers near real-time monitoring capabilities, bounding even the most complex Solana forensics to a minute-level resolution.
Given these architectural assumptions, the baselines are not directly applicable to non-EVM models such as Bitcoin or Solana. For a fair comparison, we restrict the evaluation to EVM-to-EVM scenarios and run the baselines under their default configurations. We evaluate the tools on Celer cBridge [29, 31] along two routes: ETH→Polygon (7,296 pairs) and ETH→BSC (600 pairs). TABLE 4 shows that XS PLICER achieves higher conditional accuracy (Acccov ) in the baselines’ natural EVM setting. The hard-evidence availability metric (ρh ) further distinguishes the approaches: XS PLICER reconstructs verifiable protocol invariants for evidence-backed correspondence rather than relying primarily on trace/log-pattern heuristics.
5.4
Component Analysis
5.4.1
Influence of the LLM Backbone
Stage I is the primary phase in which XS PLICER explicitly relies on LLMs, so its output quality bounds downstream rule generation and correspondence recovery. We compare foundational models on 70 samples (10 transaction pairs per bridge) using uniform prompts and document slices across three dimensions:
Insight 2: Cross-chain traceability is directional and asymmetric. XS PLICER supports low-latency forensic analysis when public invariants tightly bound the destination search space. In contrast, high-throughput models that obscure destination intent can reduce discriminative precision and increase system latency.
5.3
ETH → POLY Acccov (%)
• Destination-side spec correctness (F1dst ): Accuracy of extracting destination-chain identifiers and address constraints, which affect candidate coverage (Cov.); • Cross-chain shared spec correctness (F1cross ): Accuracy of recovering cross-chain mapping keys and invariant logic, which affect conditional accuracy (Acccov );
Baseline Comparison
• Groundedness (Gnd): Whether the generated spec is anchored to the provided documents and traces, severely penalizing unverified content drawn from the LLM’s parametric memory.
We compare XS PLICER with representative EVM-focused cross-chain tracing tools that rely on EVM-specific observability signals: • C ONNECTOR [29]: Processes EVM traces and event logs using heuristics but relies on explicit, predefined address references and outputs only raw hash pairs.
Appendix I gives the detailed formulations. The F1 metrics measure semantic alignment with Gold Specs manually curated by two independent security researchers. TABLE 5 reports the reconstruction results.
• ABCTracer [30]: Combines event-log mining, Named 10
Retention Rate (%)
Table 5: Comparative performance of LLM backbones on protocol semantic reconstruction. Model
F1dst
F1cross
Gnd
GPT-5.4
0.835
0.667
0.977
DeepSeek-Chat
0.744
0.538
0.924
Qwen3-max
0.683
0.500
0.920
Qwen3.6-plus
0.766
0.573
0.903
Gemini-3-Pro
0.671
0.531
0.842
eth→sol bsc→sol eth→btc bsc→btc btc→eth sol→eth
50
0
12
4
8
k
16
Figure 8: The rapid degradation of retention rates for soft evidence samples across various routes, as the number of injected amount-identical distractors k increases.
The results reveal a consistent trend across all models: proficiency in destination-side spec systematically outpaces crosschain-shared spec. For instance, while GPT-5.4 achieves a robust F1dst of 0.835 for destination recognition, its performance drops to 0.667 when synthesizing complex pairing logic. This discrepancy highlights a fundamental LLM limitation: parsing routing intent is semantically simpler than deducing execution semantics, which demands rigorous logical reasoning. This phenomenon precisely explains the results in Section 5.2, where XS PLICER maintains near-perfect coverage, yet its final accuracy remains naturally bounded by the structural complexity of protocol-specific hard evidence. Overall, GPT-5.4 achieves the highest scores across all three metrics, including an F1cross score 0.094 higher than that of the runner-up, Qwen3.6-plus. XS PLICER employs GPT-5.4 as the underlying LLM in our experiments. Consequently, employing a state-of-the-art model is critical for robustly capturing protocol invariants, ensuring high-fidelity decision anchors for Stage III.
Simulating an adverse environment, a minimum-coverage trace yields a mere 1.66% Acccov , requiring 8 traces to recover to 96.54%. In contrast, a maximum-coverage strategy achieves 86.58% Acccov with a single representative trace. Traces thus function strictly to anchor declarative semantics to concrete ledger architectures. The full results are reported in Appendix G. Insight 4: Cross-chain traceability relies on the semantic complementarity between documentation and execution traces. Documentation provides declarative schemas, while traces ground these abstractions in concrete ledger layouts. Representative traces are more useful than large numbers of structurally redundant samples for finalizing forensic evidence.
5.5
Robustness to Adversarial Ambiguity
This part evaluates XS PLICER’s resilience against maliciously injected noise. Adversaries can artificially inflate destinationside ambiguity by broadcasting distractor transactions with identical amounts and approximate timestamps. We evaluate robustness by artificially injecting k ∈ {1, 2, 4, 8, 16} amount-identical distractors into the candidate windows of verified samples (randomly selecting up to 50 hard-evidence and 50 soft-evidence cases per route from Section 5.2). We measure resilience via the Retention Rate: the percentage of samples where XS PLICER correctly isolates the ground-truth transaction from the polluted candidate pool. The experiment results show that hard-evidence samples maintain a 100% retention rate across all routes and k values. Protocol-level invariants (e.g., sequence numbers or hash references) enabled the verifier to retain the correct correspondence as amount-identical distractors were added. Conversely, as shown in Fig. 8, soft-evidence retention rate degrades precipitously as ambiguity scales. The ETH→SOL retention drops from 96% to 10% at k = 16. In inherently ambiguous routes like BTC→ETH (characterized by high ρs ), retention collapses to zero at merely k = 2. These findings confirm the extreme vulnerability of heuristic matching in adversarial or high-concurrency settings.
Insight 3: Semantic recovery quality determines the upper bound of forensic reconstruction. LLMs are useful for extracting routing intent, but they can struggle with complex invariants. We therefore treat LLM outputs as heuristic evidence anchors, and rely on deterministic checks in subsequent stages to finalize forensic correspondence. 5.4.2
100
Functional Utility of Input Artifacts
Stage I uses protocol documentation and execution traces; we assess their contributions independently. Semantic contribution of documentation. Under the w/o Docs ablation, WanBridge BTC→ETH Candidate Coverage drops from 72.60% to 0% because critical settlement contract addresses become unavailable. For Wormhole ETH→SOL, hard-evidence availability (ρh ) drops from 99.86% to zero because cryptographic derivation of its composite identifiers from unstructured VAA metadata requires a textual schema [39]. Allbridge, which exposes hard evidence in raw logs, remains entirely unaffected. Structural impact of execution traces. Evaluating 4,999 Allbridge samples reveals that extraction efficacy relies strictly on structural pattern coverage rather than raw volume. 11
tions or intermediate routing hops. Across 1,381 Wormhole transfers, XS PLICER discovers 51 intermediate destinationside related transactions absent from the official API. By matching the cryptographic triplet (_emitter_chain_, _emitter_address_, and _sequence_), we verify these transactions as mandatory intermediate steps (e.g., VAA submission1 ). Consequently, XS PLICER does not simply mirror official APIs; instead, it pieces together unobservable trace fragments to provide a full-lifecycle execution view.
Insight 5: Hard-evidence verification accuracy is largely insensitive to candidate-pool size and ambiguity intensity. In contrast, the discriminative power of soft clues degrades rapidly as distractor density increases. This contrast supports protocol-level invariant reconstruction as a practical path toward forensic-grade traceability.
5.6
Practical Forensic Analysis
This part evaluates the forensic completeness of official bridge interfaces and XS PLICER’s utility in post-mortem and adversarial investigations. 5.6.1
5.6.2
Post-Mortem Forensics after the Multichain Shutdown
By contrast, Multichain’s July 2023 shutdown rendered its official tracing services unavailable [10]. To evaluate XS PLICER in this post-mortem setting, we select two Multichain contracts covering transfers across heterogeneous chains and between EVM-compatible chains. For the BTC→ETH direction, we analyze the anyBTC-related contract 0x5160...c404. For ETH→BSC/Arbitrum/Polygon directions, we analyze the contract 0xBa8D...0705. The system reconstructs 1,808 EVM-to-EVM and 116 BTC→ETH correspondence pairs. Two independent security researchers manually verify these recoveries. Notably, the BTC→ETH subset reveals extreme delays up to 144 days between source deposits and destination transactions (e.g., BTC 97e3...7ada → Ethereum 0xbb73...4519). Such massive temporal gaps would exponentially inflate the candidate space for heuristic algorithms. This case shows that protocol-level evidence can support correspondence verification even when temporal proximity is uninformative.
Limitations of Official Bridge Interfaces
We first examine whether third-party analysts can rely on official bridge explorers or APIs as stable and complete correspondence oracles. Our empirical analysis of real-world transactions shows that official interfaces exhibit systematic failure modes that limit their forensic completeness. To assess XS PLICER under these blind spots, we manually crosscheck its recovered correspondences against public on-chain evidence and protocol-specific invariants. In the following three failure modes, official interfaces remain operational but return incomplete correspondence records. Failure mode 1: Null results for historical transactions. Official APIs routinely fail to map historical cross-chain transfers. For instance, within a sample of 1,988 Orbiter SOL→ETH transactions, the official API silently drops 1,856 records (93.36%), yielding a mere 6.64% retrieval rate. Manual inspection confirms this stems from the explorer’s UIcentric design, which only indexes the “Latest Transactions.” XS PLICER successfully reconstructs these severed links using immutable on-chain evidence, demonstrating its critical utility for long-term forensic tracing. Failure mode 2: Blind spots in one-to-many correspondence. Although our core formulation focuses on the correspondence between a source transaction txs and the final destination-side settlement transaction txd , real bridge executions do not always produce a single destination-side transaction. Some protocols generate multiple destination-side related transactions trel around settlement, such as asset splitting or distribution. We refer to this pattern as one-to-many correspondence: one source-chain cross-chain action corresponds to one primary settlement target, or to a set of destination-side related transactions derived from the same protocol execution path. We provide a representative one-to-two case in Appendix F. This case is drawn from our analysis of the THORChain attack [42], where we identify 17 associated records that are not fully displayed by the official explorer, including transaction 0x4f61...bb55. Failure mode 3: Omission in multi-step executions. Official interfaces typically highlight only the final asset settlement, systematically ignoring prerequisite verifica-
Insight 6: Official bridge interfaces do not always provide complete cross-chain transaction visibility due to limitations in indexing and service availability. XS PLICER complements them by reconstructing protocol-level semantics across heterogeneous chains. 5.6.3
Adversarial Flow Analysis: The Bybit Hacker
We analyze funds routed through THORChain during the Bybit Hack [7, 37] to assess reconstruction efficacy in adversarial environments. The system accurately isolates two distinct routing topologies: Completed swaps. XS PLICER successfully recovers 754 ETH→BTC correspondence pairs totaling approximately 105.6 million USD. Cross-referencing against native THORChain logs confirms 100% destination hash accuracy. Protocol invariants encoded in the cross-chain memo provide hard evidence linking the corresponding source and destination transactions. We present the details of the top 10 cross-chain trading pairs involved in asset transfers in Appendix E. 1 In the Wormhole protocol, a Verifiable Action Approval (VAA) [39] is a cryptographically signed message that attests to an event on the source chain, which is required to complete the cross-chain transfer.
12
Refunded paths. The analysis identifies 743 ETH→ETH records representing protocol refunds rather than successful transfers (e.g., 0x446F...0EA7 → 0x89FA...641E). We suspect these records represent adversaries’ path redirections via THORChain’s refund mechanism (which allows custom refund addresses via memo) rather than noise. XS PLICER correctly classifies them as related destination-side transactions (txrel ), distinct from successful settlements (txd ). Overall, the evaluation shows that XS PLICER can reconstruct cross-chain correspondence from public artifacts without requiring bridge-internal mappings, including in postmortem settings where official services are unavailable. Its explicit modeling of settlement, intermediate execution, refund, and return states further reduces false-positive links during adversarial fund tracing.
6
teroperability infrastructure [2, 20]. Recent studies examine their architectures, transaction patterns, and economic effects [8, 21]. Because bridges hold large assets and implement complex cross-chain logic, their security has received sustained attention. Prior work systematizes security and privacy issues in interoperability protocols, including attack surfaces, architectural flaws, and failure modes [2, 48]. Other studies propose defenses, such as malicious transaction detection from known attack patterns [42, 47], fine-grained static analysis for contract vulnerabilities [28], and runtime monitoring of bridge business logic [16]. These works focus on bridge vulnerabilities and defenses. In contrast, we study how a third-party analyst can recover cross-chain transaction correspondence under incomplete observability and without privileged bridge interfaces. Multi-chain Transaction Forensics and Tracing. Blockchain forensics has traditionally focused on singlechain fund flows, using transaction features, heuristics, and graph mining to characterize laundering and asset-transfer behavior [41]. Surveys further organize these tracking techniques as blockchain forensics evolves [23]. Some work extends beyond a single chain by exploiting address consistency across EVM-compatible chains [43] or tracing flows across cryptocurrency ledgers [45]. Recent systems address cross-chain DeFi transfers by pruning semantic search spaces with large language models [27] or constructing logical relations from multi-chain data to detect anomalies [3]. These studies provide useful foundations for cross-chain tracing. Our work differs in its problem definition and evidence model: rather than matching transactions in homogeneous settings or specific protocols [29, 30], we recover evidencebacked correspondence across heterogeneous environments, including EVM, Bitcoin, and Solana.
Discussion
Applicability boundaries. Because its effectiveness depends on public protocol invariants, XS PLICER applies to decentralized bridges and contract-driven DeFi flows whose ledgers retain explicit or implicit destination intents and shared evidence. It cannot reconstruct correspondence for custodial bridges with private-backend mappings or anonymity protocols that remove cross-chain identifiers via zero-knowledge proofs. Such cases return unresolved rather than an unevidenced correlation. Evidence boundaries. Without protocol-level hard evidence, XS PLICER outputs a weighted soft-clue lead only when a single candidate matches both time and amount with extremely high confidence. Multiple matches or excessive noise yield unresolved. Appendix B discusses the corresponding ethical considerations. Functional boundaries. XS PLICER reconstructs transaction-level correspondence, not end-to-end multi-hop entity recognition. Its evidence chains supply foundational metadata for address clustering and illicit-flow analysis, but entity attribution and legal conclusions require off-chain intelligence and manual investigation. Extensibility. Onboarding a new bridge only requires collecting public protocol documentation and a transaction example. XSPLICER then automatically generates the corresponding Analyzer and Verifier without manually implementing bridge-specific rules. Future work. We plan to automate invariant extraction from bytecode to reduce documentation dependence, improve autonomy, and extend correspondence reconstruction to mixing bridges [40].
7
8
Conclusion
The proliferation of heterogeneous bridges has precipitated a severe observability crisis, with only 16.79% of 131 surveyed bridge protocols providing verifiable tracking. To address this, we present XS PLICER, a protocol-evidence compilation system for cross-chain correspondence reconstruction in a non-privileged third-party setting. XS PLICER synthesizes public protocol artifacts into a unified semantic specification, compiles the specification into executable analyzers and verifiers, and produces evidence-linked forensic decisions. Across seven evaluated bridge protocols spanning EVM, Solana, and Bitcoin, XS PLICER achieves 87.92%–98.61% oracle-assisted conditional accuracy. Its hard-evidence verification supports post-mortem traceability even when official services are unavailable and remains resilient to adversarial noise. The Multichain and Bybit case studies further demonstrate its practical forensic value in reconstructing historical cross-chain correspondences and tracing illicit fund flows.
Related Work
Cross-chain Interoperability and Bridge Security. Multichain architectures have made cross-chain bridges core in13
References
[11] deBridge. Cross-chain call lifecycle. https://docs.d ebridge.com/dmp-details/dev-guides/cross-c hain-call-lifecycle, 2026. Accessed: 2026-05-04.
[1] Across Protocol. Across Developer Documentation: API Reference. https://docs.across.to/referen ce/api-reference, 2026. Accessed: 2026-08-24.
[12] deBridge. debridge liquidity network deployed contracts. https://docs.debridge.com/dln-details /overview/deployed-contracts, 2026. Accessed: 2026-05-04.
[2] André Augusto, Rafael Belchior, Miguel Correia, André Vasconcelos, Luyao Zhang, and Thomas Hardjono. SoK: Security and privacy of blockchain interoperability. In 2024 IEEE Symposium on Security and Privacy (SP), pages 3840–3865. IEEE, 2024. doi:10.1109/SP5426 3.2024.00255.
[13] deBridge. debridge liquidity network overview. https: //docs.debridge.com/dln-details/overview/in troduction, 2026. Accessed: 2026-05-04. [14] DefiLlama. Defillama bridges dashboard. https://de fillama.com/bridges, 2026. Accessed: 2026-01-13.
[3] André Augusto, Rafael Belchior, Jonas Pfannschmidt, André Vasconcelos, and Miguel Correia. Xchainwatcher: Identifying anomalies in cross-chain bridges. In Proceedings of the International Middleware Conference, pages 413–426, 2025. doi:10.1145/3721462. 3770781.
[15] Elliptic. The state of cross-chain crime 2025. https: //www.elliptic.co/resources/the-state-of-c ross-chain-crime-2025, 2025. Accessed: 2026-0504. [16] Mojtaba Eshghie, Cyrille Artho, Hans Stammler, Wolfgang Ahrendt, Thomas Hildebrandt, and Gerardo Schneider. Highguard: Cross-chain business logic monitoring of smart contracts. In Proceedings of the IEEE/ACM International Conference on Automated Software Engineering, pages 2378–2381, 2024. doi: 10.1145/3691620.3695356.
[4] Rafael Belchior, André Vasconcelos, Sérgio Guerreiro, and Miguel Correia. A survey on blockchain interoperability: Past, present, and future trends. ACM Computing Surveys, 54(8), 2022. doi:10.1145/3471140. [5] Bitcoin Developer Documentation. Transactions. http s://developer.bitcoin.org/devguide/transac tions.html, 2026. Accessed: 2026-05-04.
[17] Ethereum Foundation. Ethereum transactions. https: //ethereum.org/developers/docs/transaction s/, 2026. Accessed: 2026-05-04.
[6] Tom B. Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, et al. Language models are few-shot learners. In Advances in Neural Information Processing Systems, volume 33, pages 1877–1901, 2020.
[18] Vincent Gramlich, Tobias Guggenberger, Marc Principato, Benjamin Schellinger, and Nils Urbach. A multivocal literature review of decentralized finance: Current knowledge and future research avenues. Electronic Markets, 33(1):11, 2023. doi:10.1007/s12525-023-006 37-4.
[7] Bybit. Bybit security incident: Timeline of events and faqs. https://learn.bybit.com/en/this-week-i n-bybit/bybit-security-incident-timeline, 2025. Accessed: 2026-05-04.
[19] Panpan Han, Zheng Yan, Wenxiu Ding, Shufan Fei, and Zhiguo Wan. A survey on cross-chain technologies. Distributed Ledger Technologies: Research and Practice, 2(2):1–30, 2023. doi:10.1145/3573896.
[8] Yiyue Cao, Mingzhe Zheng, Lin William Cong, Siguang Li, and Xuechao Wang. The price of interoperability: Exploring cross-chain bridges and their economic consequences. In Proceedings of the ACM on Measurement and Analysis of Computing Systems, 2026. doi:10.1145/3805650.
[20] Xiaohui Hu, Hang Feng, Pengcheng Xia, Gareth Tyson, Lei Wu, Yajin Zhou, and Haoyu Wang. Piecing together the jigsaw puzzle of transactions on heterogeneous blockchain networks. Proceedings of the ACM on Measurement and Analysis of Computing Systems, 8(3):1–27, 2024. doi:10.1145/3700424.
[9] Chainspot. Chainspot: Bridges. https://chainspot. io/portal/bridges, 2024. Accessed: 2026-08-24.
[21] Chuanshan Huang, Tao Yan, and Claudio J. Tessone. Seamlessly transferring assets through layer-0 bridges: An empirical analysis of stargate bridge’s architecture and dynamics. In Companion Proceedings of the ACM Web Conference 2024, pages 1776–1784, 2024. doi: 10.1145/3589335.3651964.
[10] CoinDesk. Recently Exploited Crypto Bridge Shuts, Says China Detained CEO and His Sister. https:// www.coindesk.com/business/2023/07/14/crypt o-bridging-protocol-multichain-ceases-ope rations, 2023. Accessed: 2026-08-24. 14
[22] Stefan Kitzler, Friedhelm Victor, Pietro Saggese, and Bernhard Haslhofer. Disentangling decentralized finance (DeFi) compositions. ACM Transactions on the Web, 17(2):1–26, 2023. doi:10.1145/3532857.
and trace: Automatically uncovering cross-chain transactions in the multi-blockchain ecosystems. IEEE Transactions on Services Computing, 18(6):4291–4303, 2025. doi:10.1109/TSC.2025.3618729.
[23] Ayush Kumar and Vrizlynn L. L. Thing. A survey of transaction tracing techniques for blockchain systems. arXiv preprint arXiv:2510.09624, 2025. URL: https: //arxiv.org/abs/2510.09624.
[31] ScaleSphere Foundation Ltd. . Celer network: Bring internet scale to every blockchain. https://celer.ne twork/doc/celernetwork-whitepaper.pdf, Jun. 2018. [32] Solana Foundation. Transactions. https://solana .com/docs/core/transactions, 2026. Accessed: 2026-05-04.
[24] LayerZero Labs. Value transfer api. https://docs.l ayerzero.network/v2/developers/value-trans fer-api/start, 2026. Accessed: 2026-05-04.
[33] Stargate Finance. Stargate api. https://docs.sta rgate.finance/developers/api-docs/overview, 2025. Accessed: 2026-05-04.
[25] Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Küttler, Mike Lewis, Wen-tau Yih, Tim Rocktäschel, Sebastian Riedel, and Douwe Kiela. Retrieval-augmented generation for knowledge-intensive nlp tasks. In Advances in Neural Information Processing Systems, volume 33, pages 9459–9474, 2020. URL: https://proc eedings.neurips.cc/paper_files/paper/2020/ file/6b493230205f780e1bc26945df7481e5-Pap er.pdf.
[34] THORChain. THORChain Dev Docs. https://dev. thorchain.org/. Accessed: 2026-05-07. [35] THORChain. Sending transactions. https://dev.th orchain.org/concepts/sending-transactions. html, 2026. Accessed: 2026-05-04. [36] THORChain. Transaction memos. https://dev.thor chain.org/concepts/memos.html, 2026. Accessed: 2026-05-04.
[26] Wenqing Li, Zhenguang Liu, Jianhai Chen, Zhe Liu, and Qinming He. Towards blockchain interoperability: A comprehensive survey on cross-chain solutions. Blockchain: Research and Applications, 6(3):100286, 2025. doi:10.1016/j.bcra.2025.100286.
[37] TRM Labs. Bybit hack update: North korea moves to next stage of laundering. https://www.trmlabs.co m/resources/blog/bybit-hack-update-north -korea-moves-to-next-stage-of-laundering, 2025. Accessed: 2026-05-04.
[27] Hanzhong Liang, Yue Duan, Xing Su, Xiao Li, Yating Liu, Yulong Tian, Fengyuan Xu, and Sheng Zhong. Connex: Automatically resolving transaction opacity of cross-chain bridges for security analysis. arXiv preprint arXiv:2511.01393, 2025. URL: https://arxiv.org/ abs/2511.01393.
[38] Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Brian Ichter, Fei Xia, Ed Chi, Quoc Le, and Denny Zhou. Chain-of-thought prompting elicits reasoning in large language models. In Proceedings of International Conference on Neural Information Processing Systems, volume 35, pages 24824–24837, 2022.
[28] Zeqin Liao, Yuhong Nan, Henglong Liang, Sicheng Hao, Juan Zhai, Jiajing Wu, and Zibin Zheng. Smartaxe: Detecting cross-chain vulnerabilities in bridge smart contracts via fine-grained static analysis. Proceedings of the ACM on Software Engineering, pages 249–270, 2024. doi:10.1145/3643738.
[39] Wormhole Foundation. Wormhole Documentation: Fetch a Signed VAA. https://wormhole.com/d ocs/products/token-transfers/wrapped-tok en-transfers/guides/fetch-signed-vaa/, 2026. Accessed: 2026-08-24.
[29] Dan Lin, Jiajing Wu, Yuxin Su, Ziye Zheng, Yuhong Nan, Qinnan Zhang, Bowen Song, and Zibin Zheng. Connector: Enhancing the traceability of decentralized bridge applications via automatic cross-chain transaction association. IEEE Transactions on Information Forensics and Security, 20:7588–7601, 2025. doi: 10.1109/TIFS.2025.3588249.
[40] Fajie Wu, Jiajing Wu, Zhiying Wu, Jun Chen, Tao Wang, Longjian He, Bowen Song, and Weiqiang Wang. Tgweaver: Synthesizing transaction graphs for deanonymization analysis. In Proceedings of the ACM Web Conference, pages 2835–2845, 2026. doi:10.114 5/3774904.3792318. [41] Jiajing Wu, Dan Lin, Qishuang Fu, Shuo Yang, Ting Chen, Zibin Zheng, and Bowen Song. Toward understanding asset flows in crypto money laundering through
[30] Dan Lin, Ziye Zheng, Jiajing Wu, Jingjing Yang, Kaixin Lin, Huan Xiao, Bowen Song, and Zibin Zheng. Track 15
the lenses of ethereum heists. IEEE Transactions on Information Forensics and Security, 19:1994–2009, 2024. doi:10.1109/TIFS.2023.3346276.
operational scripts facilitating evasion tactics. Following responsible disclosure principles, we have proactively emailed the respective development teams regarding the systematic oracle failures and observability blind spots identified in Section 5.6.1.
[42] Jiajing Wu, Kaixin Lin, Dan Lin, Bozhao Zhang, Zhiying Wu, and Jianzhong Su. Safeguarding blockchain ecosystem: Understanding and detecting attack transactions on cross-chain bridges. In Proceedings of the ACM Web Conference 2025, pages 4902–4912, 2025. doi:10.1145/3696410.3714604.
B
Our cross-chain forensic methodology strictly complies with Menlo Report guidelines. Data privacy. All utilized artifacts derive exclusively from public repositories. We strictly eschew private records including centralized KYC data, internal backend mappings, and proprietary relayer states. While XS PLICER enhances cross-chain linkability, its scope remains strictly confined to logical transaction correspondence. We perform zero natural person de-anonymization, address ownership inference, or legal attribution. All benign user addresses remain fully anonymized. Non-intrusive methodology. We employ purely passive observation. The methodology involves zero active probing, adversarial transaction submissions, or stress testing against live bridge protocols. Official APIs serve exclusively as evaluation oracles rather than system inputs. This completely offline paradigm guarantees zero interference with production services. False positive mitigation. Erroneous correlations severely undermine compliance tracking. XS PLICER mitigates this via an evidence-driven architecture outputting three strict decision states: hard-evidence confirmation, soft-clue support, and unresolved. This tripartite model structurally prevents probabilistic guesswork in forensic conclusions. Responsible disclosure. We recognize the dual-use potential of exposing protocol tracing mechanics. We deliberately omit operational scripts facilitating evasion tactics. Following responsible disclosure protocols, we proactively emailed the respective bridge developers regarding the systematic API blind spots identified in Section 5.6.1.
[43] Tao Yan, Chuanshan Huang, and Claudio J. Tessone. Tracing cross-chain transactions between EVM-based blockchains: An analysis of Ethereum-Polygon bridges. Ledger, 10:113–134, 2025. doi:10.5195/ledger.2 025.433. [44] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. React: Synergizing reasoning and acting in language models. In International Conference on Learning Representations, 2023. URL: https://arxiv.org/pdf/2210.03629. [45] Haaroon Yousaf, George Kappos, and Sarah Meiklejohn. Tracing transactions across cryptocurrency ledgers. In USENIX Security Symposium, pages 837–850, Aug. 2019. doi:10.5555/3361338.3361396. [46] Alexei Zamyatin, Mustafa Al-Bassam, Dionysis Zindros, Eleftherios Kokoris-Kogias, Pedro Moreno-Sanchez, Aggelos Kiayias, and William J. Knottenbelt. SoK: Communication across distributed ledgers. In Financial Cryptography and Data Security, volume 12675 of Lecture Notes in Computer Science, pages 3–36. Springer Nature, 2021. doi:10.1007/978-3-662-64331-0_1. [47] Jiashuo Zhang, Jianbo Gao, Yue Li, Ziming Chen, Zhi Guan, and Zhong Chen. Xscope: Hunting for crosschain bridge attacks. In Proceedings of the IEEE/ACM International Conference on Automated Software Engineering, pages 1–4, 2022. doi:10.1145/3551349.35 59520. [48] Mengya Zhang, Xiaokuan Zhang, Yinqian Zhang, and Zhiqiang Lin. Security of cross-chain bridges: Attack surfaces, defenses, and open problems. In Proceedings of the International Symposium on Research in Attacks, Intrusions and Defenses, pages 298–316, 2024. doi: 10.1145/3678890.3678894.
A
Ethical Considerations
C
Implications and Recommendations
Our findings have implications for three stakeholder groups. Bridge developers should document cross-chain invariants and retain public evidence anchors to support independent audits and post-mortem reconstruction. Forensic analysts and compliance systems can use protocol-level evidence to complement time-and-amount heuristics in heterogeneous crosschain investigations. Finally, users should assess a bridge’s privacy properties from its protocol design and on-chain evidence rather than from the opacity of its interface.
Open Science
The core XS PLICER implementation, benchmark subsets, and illicit-flow traces will be made publicly available upon publication to support reproducibility and further research. To mitigate privacy risks and dual-use concerns, we withhold largescale transaction dumps containing benign user addresses and 16
D
Cross-Chain Bridge Survey
Table 6: Top 10 high-value cross-chain transaction pairs reconstructed during the Bybit hack money laundering.
To comprehensively substantiate the pervasive “observability crisis” discussed in Section 2.3, TABLE 8 provides the complete empirical survey results of 131 cross-chain bridges and interoperability protocols. These targets were systematically sourced from the cross-chain aggregator Chainspot [9]. Utilizing an industry-recognized aggregator ensures that our empirical sample is highly representative of the actively utilized DeFi ecosystem, strictly mitigating subjective selection bias. It is crucial to emphasize that the mere existence of an official explorer or a developer API does not equate to forensic traceability. In this survey, a feature is positively marked (✓) strictly if it provides a stable, public, and verifiable mapping from a source transaction hash (txs ) to its exact destination transaction hash (txd ). We apply a hierarchical strategy: features failing this standard are marked inadequate (✗). Conversely, if foundational infrastructure is absent, dependent checks are omitted and marked with a dash (–). The table systematically details each protocol’s official documentation links, block explorer accessibility, support for heterogeneous execution environments (EVM, Bitcoin, Solana), and API mapping capabilities. The extensive prevalence of missing or inadequate tracking interfaces across these 131 protocols constitutes the empirical foundation for our assertion that third-party analysts frequently lack stable and complete official source-to-destination mappings, motivating the evidence-backed reconstruction approach of XS PLICER.
Source Asset
Source Tx
1 2 3 4 5 6 7 8 9 10
ETH.ETH ETH.ETH ETH.ETH ETH.ETH ETH.ETH ETH.ETH ETH.ETH ETH.ETH ETH.ETH ETH.ETH
0x219F. . . A76E 0x5B49. . . 017A 0xD48D. . . 9E75 0x6284. . . F982 0xBF87. . . 0D41 0x7468. . . 5FCB 0xD423. . . D43F 0xF10D. . . 262F 0xCCBC. . . 3D06 0xC890. . . D2BE
Destination Asset
Destination Tx
BTC
BTC.BTC BTC.BTC BTC.BTC BTC.BTC BTC.BTC BTC.BTC BTC.BTC BTC.BTC BTC.BTC BTC.BTC
206B. . . 2DD0 73A8. . . 27FB DB957. . . DBDE D51F. . . 114C 4EBB. . . ED67 12A8. . . 33D7 97F7. . . 4AE7 7DC3. . . 7E81 2839. . . CFE5 DCCA. . . 08BF
7.5071 7.3861 7.286 7.2355 7.2041 7.1175 7.037 6.9575 6.9313 6.9302
Destination: Ethereum (SUSHI) Dst Transaction1
Source: Ethereum (ETH) Src Transaction 0x5b6...ffacfa6 Tx hash: 12833218 Block: 0x3A1...085C031 From: Interacted With: 0x4A3...48e3c9C Internal Transfer: 14.165 ETH Fee: 0.00308084 ETH
0x327…506798e Tx hash: 12833221 Block: 0x028... C870503 From: Interacted With: 0xC14…Ca8c2cE Internal Transfer: 5.979506 ETH Fee: 0.00638766 ETH
Dst Transaction2 0x4fb...0b52692 Tx hash: 12833221 Block: 0xD36…8B13533 From: Interacted With: 0xC14…Ca8c2cE Internal Transfer: 8.185494 ETH Fee: 0.00484866 ETH
Figure 9: A representative one-to-two correspondence observed in the THORChain attack analysis.
block and interacted with the same destination-side contract. Their amounts sum to the source-side internal transfer amount, excluding transaction fees. This case illustrates why explorer-level mappings may be incomplete. A public bridge interface may display only one outbound transaction or collapse the transfer into a simplified status view, thereby omitting part of the asset-distribution path. XS PLICER does not rely on the explorer display logic. It instead reconstructs the correspondence from protocol-level hard evidence, including the THORChain memo and the Inbound/Outbound Tx ID linkage.
E Cross-chain Transactions in Bybit Hack Laundering To further illustrate the real-world tracking capabilities of XS PLICER in high-value adversarial scenarios, TABLE 6 details the top 10 cross-chain transaction pairs recovered during the Bybit hack analysis. By deterministically matching the source transactions on Ethereum with their corresponding destination settlements on Bitcoin, the table demonstrates the system’s ability to reconstruct the precise illicit fund flows and verify the exact transfer amounts without relying on official bridge interfaces.
F
#
G
THORChain cross-chain attack
Impact of Public Examples
We further evaluate how the number of public examples affects protocol knowledge reconstruction. Using Allbridge ETH→SOL as a representative case, we compare different numbers of input examples over 4,999 test samples. We consider two extreme selection strategies: the least-covering strategy selects, at each step, the example that covers the fewest remaining similar-pattern samples, simulating an unfavorable selection; the most-covering strategy selects the example that covers the most similar-pattern samples, estimating the upper bound provided by representative examples.
Figure 9 shows a representative one-to-two correspondence observed in the THORChain attack analysis. The sourceside transaction was initiated on Ethereum and transferred 14.165 ETH into THORChain. Instead of producing a single destination-side settlement transaction, the flow was split into two destination-side transactions on Ethereum: one transferring 5.979506 ETH and the other transferring 8.185494 ETH. The two outgoing transfers occurred in the same destination 17
Table 7: Protocol-specific evidence rules generated by XSPLICER across the seven evaluated bridges. Bridge
Hard Evidence Rules
Allbridge
Destination: Chain from destinationChainId, destinationDomain, or dst_chain_id; recipient from mintRecipient/recipient, or recipient bytes in SwapAndBridge. Shared Evidence: Two-tiered strong evidence: message_id/message_hash → CCTP nonce; otherwise, recipient, token, amount, and time as soft evidence.
deBridge
Destination: Chain from CreatedOrder.order.takeChainId; recipient candidates: receiverDst, orderAuthorityAddressDst, and allowedTakerDst (often the target-side account for Solana). Shared Evidence: An exact order_id match on both sides directly confirms the pair; otherwise amount/time soft matching with capped confidence.
Orbiter
Destination: Chain from c/dstChainId in memo/extData; recipient from t, to, recipient, receiver, or dstreceiver. Shared Evidence: Source transaction identifier is strongest: h=<solana_signature> for Solana→EVM; for EVM→Solana, check 0x<evm_txhash> or h=<evm_txhash> in Solana memo/obt. Otherwise recipient + amount/time.
Symbiosis
Destination: Chain/recipient from dstChain and dstAddress in SwapToken; currently dstChain=5 denotes Solana. Fallback fields include dstAddress, recipient, and _receiver. Shared Evidence: No stable shared identifier; pairing uses the exact intersection of the source-recovered Solana recipient and destination-side recipient, with amount as auxiliary evidence.
Figure 10: Ablation study on system inputs with varying numbers of cross-chain transaction pairs sampled via different strategies.
H Protocol-Specific Evidence Rules Generated by XS PLICER TABLE 7 summarizes the protocol-specific rules reconstructed in Stage I and compiled into the Analyzer and Verifier in Stage II for the seven-bridge benchmark. It lists the destination-side constraints used to bound candidate sets and the cross-chain evidence used to assess candidate correspondences.
I
THORChain Destination: Chain/recipient from THOR memo structures (SWAP/=:, asset-tail, and channel-tail address clues). Shared Evidence: OUT:<source_tx_hash> is strongest; transferOut/router semantics, memo structure, and destination-address/amount relations provide strong auxiliary evidence.
Stage I Evaluation Metrics
Cross-chain bridge protocols often use different terms for semantically equivalent entities, such as recipient and to_address. We therefore define a semantic equivalence mapping operator σ to align the predicted set S with the ground-truth specification set G (Gold Specs), using a predefined dictionary of protocol synonyms for reproducibility. We evaluate knowledge reconstruction using three metrics: Destination-spec correctness: This metric evaluates the capability of the system to identify destination chain boundaries and address conventions. We compute the F1 score between the predicted field set Sdst and the baseline set Gdst as follows: 2 · |Sdst ∩σ Gdst | F1dst = (1) |Sdst | + |Gdst | where ∩σ denotes the semantic intersection under the mapping operator σ. This metric facilitates the assessment of the system’s confidence in delineating on-chain search boundaries. Cross-chain shared-spec correctness: This metric measures the recovery of protocol invariants and relational mappings, such as cross-chain transaction identifiers and valueconversion formulas: 2 · |Scross ∩σ Gcross | F1cross = (2) |Scross | + |Gcross |
WanBridge
Destination: Chain from tokenPairID and, for CCTP, destinationDomain; recipient from userAccount, toAccount, receiver, toAddress, or mintRecipient. BTC→EVM may additionally use candidate bridge contracts. Shared Evidence: uniqueId and source hash in Bitcoin OP_RETURN are strongest; tokenPairID, smgID, and userAccount are strong auxiliary evidence; amount/time are weak evidence. BTC→EVM relies more on amount when structured identifiers are absent.
Wormhole
Destination: Chain from recipientChain/toChain; recipient from recipient/recipient_b32; NTT directly uses recipientChain+recipient. Shared Evidence: Core identifier: message_id=(emitter_chain_id, emitter_address, sequence); CCTP additionally uses messageBody, nonce, and sourceDomain.
Groundedness (Gnd): Groundedness measures whether semantically correct predictions are supported by the provided evidence rather than model priors. Let H = S ∩σ G denote the set of correct predictions. We divide H by evidence prove1 Hstrong : directly supported by explicit text or nance into: ⃝ 2 Hweak : supported by transaction JSON (Direct Evidence); ⃝ partial contextual clues requiring moderate inference (Partial 3 Hnone : unsupported by the provided context Evidence); ⃝ and thus attributable to model-internal knowledge (Hallucination). The Gnd metric is the proportion of correct predictions supported by verifiable evidence: Gnd =
The overlap between Scross and Gcross reflects how accurately Stage I recovers the invariants and mappings used by downstream verifiers. 18
|Hstrong ∪ Hweak | . |H |
(3)
Table 8: Surveyed cross-chain bridges, documentation, explorers, and crawlability. Bridge / # Docs 1 Across 2 Adaever 3 Allbridge Core 4 Altitude 5 Aptos Bridge 6 Arbitrum Bridge 7 Base Bridge 8 Binance Bridge 2.0 9 Boba Gateway 10 BoringDAO oPortal 11 Celer cBridge 12 ChainPort 13 Chainspot 14 Connext Bridge 15 Core Avalanche Bridge 16 Core Bitcoin Bridge 17 Counterstake Bridge 18 Cross-Chain Bridge 19 CroxSwap Bridge 20 DAFI dBridge 21 Decimalchain 22 deSwap 23 DLN (Powered by deBridge) 24 ElkNet Bridge 25 EVODeFi Token Bridge 26 EYWA Token Bridge 27 Floki Bridge 28 Glitter Bridge 29 Gravity Bridge 30 Harmony Bridge 31 Hashbon Rocket 32 Helix Bridge 33 Holograph 34 Hop.Exchange 35 Hot Cross Multi-Chain Bridge 36 Hyphen 37 HyperBridge 38 iCrosschain 39 Instant Cross 40 Interlay 41 Interport Finance 42 ioTube 43 Jumper Exchange 44 KCC Bridge 45 KCCPad Bridge 46 Kintsugi 47 Layerswap 48 Magpie Protocol 49 Manta Pacific Bridge 50 Mantle Bridge 51 Mayan Finance 52 Meson 53 Meter Passport 54 Metis Bridge 55 MultiBaas Bridge BETA 56 Multichain (previously Anyswap) 57 MVM Bridge 58 NFT OmniBridge 59 Nomad 60 Octus Bridge 61 OKX IBC Transfer 62 OmniBridge 63 Omnisea 64 opBNB Bridge 65 OpenSwap 66 Optimism Bridge
Explorer
EVM/BTC/ API Note SOL
– – Allbridge Explorer – – Arbitrum Bridge Explorer – – – – Celer cBridge Explorer ChainPort Explorer – – – – – – – DAFI dBridge Explorer Decimalchain Explorer – DLN (Powered by deBridge) Explorer – – – – – – – – – – – –
– – ✓ – – ✗ – – – – ✗ ✗ – – – – – – – ✓ ✗ – ✓
– – ✓ – – – – – – – – – – – – – – – – ✓ – – ✓
– – Allbridge – – – – – – – – – – – – – – – – deBridge – – deBridge
– – – – – – – – – – – –
– – – – – – – – – – – –
– – – – – – – – – – – –
– HyperBridge Explorer – – – Interport Finance Explorer – – – – – – – – – Mayan Finance Explorer Meson Explorer – – MultiBaas Explorer Multichain Explorer
– ✗ – – – ✗ – – – – – – – – – ✓ ✗ – – ✗ ✓
– – – – – – – – – – – – – – – ✗ – – – – ✗
– – – – – – – – – – – – – – – – – – – –
– – – – – – – – – –
– – – – – – – – – –
– – – – – – – – – –
– – – – – – – – – –
#
Bridge / Docs
67 Orbit Bridge 68 Orbiter Finance 69 Orion Bridge 70 Owlto 71 Pandorum BETA 72 PepeBridge 73 Pheasant Network 74 pNetwork dApp 75 PolyBridge 76 Polygon Portal 77 Polygon zkEVM Bridge 78 Portal Token Bridge (previously Wormhole) 79 PROM Bridge 80 Radar Bridge 81 Rainbow Bridge 82 Relay Bridge 83 Relay Chain Bridge 84 RenBridge 85 Retrobridge 86 rhino.fi 87 Ronin Bridge 88 Router Nitro 89 RSK Token Bridge 90 Rubic 91 SafeBridge 92 Satellite by Axelar 93 Scroll Bridge 94 Secret Tunnel 95 Sifchain Bridge 96 SKALE Portal Bridge 97 SolarBeam Bridge 98 Sovryn Bridge 99 SOY Bridge 100 SpookySwap Bridge 101 Squid 102 Stargate 103 SushiSwap 104 Suter Bridge ALPHA 105 Swim Protocol 106 Symbiosis 107 Synapse Protocol 108 Terra Bridge 109 The Voyager 110 THORSwap 111 ThunderCore Bridge 112 TIME Bridge 113 TON Bridge 114 Transit Swap 115 Trantor 116 TronPad 117 txSync Bridge 118 Umbrella Token Bridge 119 Umbria Narni Bridge 120 Via Protocol Exchange 121 Vires.Finance 122 Voltage Bridge 123 VoltSwap 124 WanBridge 125 WAX ETH Bridge 126 xDai Bridge 127 XP.NETWORK NFT Multi-Chain Bridge 128 XY Finance 129 Zapper 130 ZigZag Bridge 131 zkBridge
Explorer
EVM/BTC/ API Note SOL
– Orbiter Finance Explorer – – – PepeBridge Explorer – – – – – Wormhole Explorer
– ✓ – – – ✗ – – – – – ✓
– ✓ – – – – – – – – – ✓
– Orbiter – – – – – – – – – Wormhole
– Radar Bridge Explorer – – – – – – – – – – – – – – – SKALE Portal Bridge Explorer – – – – – – – – – Symbiosis Explorer – – – THORSwap Explorer – – – Transit Swap Explorer – – – – – – – – – WanBridge Explorer – – –
– ✗ – – – – – – – – – – – – – – – ✗
– – – – – – – – – – – – – – – – – –
– – – – – – – – – – – – – – – – – –
– – – – – – – – – ✓ – – – ✓ – – – ✓ – – – – – – – – – ✓ – – –
– – – – – – – – – ✓ – – – ✓ – – – ✗ – – – – – – – – – ✓ – – –
– – – – – – – – – Symbiosis – – – THORChain – – – – – – – – – – – – – WanBridge – – –
– – – –
– – – –
– – – –
– – – –
Note. The bridge name is hyperlinked to its documentation. When an explorer is available, the explorer column is hyperlinked and displayed as “Bridge Explorer”. ✓ and ✗ denote available and unavailable support, respectively; “–” denotes unreported information.
19