SoK: Cross-Chain Transaction Identification and Matching

SoK: Cross-Chain Transaction Identification and Matching Hang Zheng∗ , Qishuang Fu∗ , Joseph Liu∗ , Qin Wang† , Weiqing Wang∗ , and Tsz Hon Yuen∗ ∗ Monash University, Australia

arXiv:2608.17532v1 [cs.CR] 18 Aug 2026

† CSIRO, Australia

Abstract—Cross-chain bridges, instant cryptocurrency exchanges, and centralized cross-ledger platforms move assets across an increasingly multi-chain ecosystem. However, these systems have repeatedly become targets of high-value attacks and channels for cross-chain money laundering. Cross-chain transactions are substantially harder to analyze than singlechain transactions: no single ledger records an entire cross-chain transfer, its evidence is scattered across the source chain, the destination chain, and off-chain systems, and the availability and reliability of that evidence vary widely across systems. In this paper, we present a systematization of knowledge (SoK) on cross-chain transaction identification and matching. First, we classify deposit and withdrawal identification methods into four approaches and transaction matching methods into three mechanisms: deterministic identifier matching, field-constraint heuristics, and model-assisted matching. We find that their applicability and reported performance are shaped mainly by the evidence the underlying system exposes, and we further examine how matched pairs support downstream attack detection and fund tracing. Second, we assess the availability of existing datasets and artifacts, finding that fewer than half remain obtainable, and distill three artifact failure modes. Finally, we outline four open challenges toward auditable, reproducible, and actionable crosschain analysis. Index Terms—Cross-chain bridge, Cross-chain transaction, Transaction matching, Systematization of knowledge

I. I NTRODUCTION Over the past few years, the blockchain ecosystem has evolved from isolated chains into a multi-ledger environment comprising Layer-1 networks, Layer-2 networks, and sidechains, and assets increasingly move across chains through bridges and cross-ledger exchange services [1]–[4]. As of July 2026, the total cryptocurrency market capitalization is $2.2 trillion [5], and monthly cross-chain transfer volume exceeds $12 billion [6]. Cross-chain services have also repeatedly become targets of major attacks. Cumulative losses from bridge attacks have reached approximately $2.8 billion, accounting for about 40% of the value stolen in Web3 [7]– [9]. Cross-chain services are also used to obscure fund flows. Elliptic [10] estimates that more than $21.8 billion of illicit and high-risk funds have moved through DEXs, bridges, and swap services without know-your-customer (KYC) checks. The Lazarus Group, for example, laundered the Bybit proceeds by rapidly hopping across chains [11]. Consequently, crosschain transactions have become an important object of study Corresponding author: Qishuang Fu (qishuang.fu@monash.edu).

for understanding fund flows and the attack surface of the multi-chain ecosystem. However, cross-chain transactions are substantially harder to analyze than single-chain transactions, because no single blockchain records an entire cross-chain transfer. The evidence is scattered across the source chain, the destination chain, and off-chain systems, and its availability and reliability vary considerably across platforms. Some bridges record an identifier that uniquely links the two ends of a transfer. In other systems, the deposit and withdrawal appear on-chain as two ordinary transactions sharing only time, amount, and addresses. Existing studies have developed a range of methods for cross-chain transaction matching. These methods first identify cross-chain-related transactions among massive on-chain data, and then associate the two ends into transaction pairs or paths. The resulting matches provide important inputs to downstream applications, including attack detection and fund tracing. Although cross-chain transaction matching has attracted increasing research attention, existing SoKs on crosschain systems [12]–[18] focus on protocol design, attack surfaces, and architectural flaws, and they do not systematize how transaction-level evidence is used to match cross-chain transactions. The closest effort, the survey of transaction tracing techniques [19], centers on single-chain tracing and does not compare the evidence strength of matching mechanisms. To fill this gap, we systematize research on cross-chain transaction identification and matching. Our contributions are as follows. We organize deposit and withdrawal identification into four approaches and transaction matching into three mechanisms (deterministic identifier matching, fieldconstraint heuristics, and model-assisted matching), comparing their evidence sources, applicability conditions, and failure modes (§III and §IV). • We compare public datasets and artifacts and verify their actual availability one by one (§V). • We distill four open challenges: interpreting missing counterparts under partial evidence; one-to-many and many-to-many matching; ground truth, benchmarks, and artifact availability; and verifiable use of models and agents (§VI). •

Scope and paper selection: This SoK targets transaction data produced by deployed cross-chain systems, covering contract bridges (including canonical L1–L2 bridges and cross-

chain messaging protocols) as well as instant cryptocurrency exchanges and other centralized cross-ledger platforms. We include works published between 2019 and 2026 that analyze transaction data from such systems, collected through keyword search over major security, measurement, and blockchain venues and citation snowballing from seed papers. Works on protocol design, contract-level vulnerability analysis (static analysis and fuzzing), and single-chain-only transaction analysis are excluded from the survey and cited only where relevant. Detection-only works are not part of the core taxonomy and are cited only where they show downstream use or evidence limits. II. BACKGROUND Cross-chain refers to the techniques that reliably move assets, data, or messages between different blockchain networks. Chains such as Bitcoin [20], Ethereum [21], and BNB Chain [22] are independent ledgers that cannot interoperate directly. Cross-chain techniques address this problem, and the services that implement them are cross-chain systems. A. Cross-Chain Systems and Their Evidence This paper groups cross-chain systems by the form of service they provide, because the forms differ in what they leave on chain, and hence in what evidence is available for analysis. The first form, the smart-contract bridge, runs a contract on each of the two chains and moves assets through this pair, so both ends leave contract events. Bridges differ in who confirms that the source-chain deposit really happened [23]: a notary or committee, an optimistic challenge window, or the destination chain itself via a light client or proof. The second form covers instant cryptocurrency exchanges, ShapeShiftstyle cross-ledger swap services [24], centralized exchanges, and other virtual asset service providers: they all run the exchange itself off chain, so the public chains see only the deposit and withdrawal transfers themselves. The third form, the aggregator, runs no exchange of its own: it hands a transfer to whichever bridges or swap services currently offer the best rate, sometimes splitting it among several, so one deposit no longer needs to correspond to one withdrawal. For a contract-based bridge, one user-level cross-chain transfer can be abstracted into three stages (Fig. 1): the user initiates the transfer on the source chain by locking, burning, or depositing the asset; an off-chain component, typically the bridge’s verifier or a relayer, attests to that event and passes a message; and the destination-chain contract settles the transfer by minting, releasing from custody or a liquidity pool, or waiting for the user to claim. A bridge’s settlement mechanism [25]–[27] takes one of three forms: lock the asset and mint a wrapped copy on the other chain (lock-and-mint), burn it on the source chain and mint it on the destination (burn-and-mint), or pay out of pre-funded pools on both chains (liquidity pools). The two directions of the same bridge can also differ: some withdrawals need a second, user-timed claim transaction on the original chain.

An instant exchange or cross-ledger service follows the same three stages, but the attestation and the settlement are hidden inside the platform: the user sends an ordinary transfer to a deposit address that the platform assigns off-chain; the platform matches the request internally; and on the other chain it pays the user from its funds. Because no bridge contract is involved, neither transaction writes any bridge event, and the two look like unrelated ordinary transfers. The link is still there, however: a swap executes one quoted request at a time, so each deposit is usually paid out by one withdrawal within minutes. Any difference between the two amounts comes only from the quoted rate and the fee. A centralized exchange breaks this coupling too: a deposit only tops up an account balance, the user may trade, wait, or split the money, and withdrawals leave from the same shared hot wallets, so a traced fund path often stops at the exchange’s deposit address. Cross-chain analysis relies first on on-chain records: the transaction itself, the event logs written by bridge and token contracts, the execution traces that show what actually happened, and the contract ABI and source code that give fields their business semantics. How much these records reveal varies by bridge: some bridges write an identifier usable directly for pairing into their events, while others expose only generic fields such as receiver, token, amount, and timestamp. Beyond on-chain records, existing work also uses off-chain and external evidence. The first is the platform’s records: bridge ledgers, official bridge explorers (transaction-lookup websites analogous to a block explorer such as Etherscan), and platform APIs. Where a platform exposes them, these records name the transactions on both ends of a transfer together with its status, amount, and time. The second is external labels: entity tags that name an address’s owner (an exchange, a service, a known attacker), incident reports, and third-party risk annotations. Analyses also consult market prices and exchange rates when amounts must be compared across assets. B. Analysis Tasks Cross-chain transaction analysis involves two core tasks. The first is deposit and withdrawal identification: out of the full transaction stream of a chain, decide which transactions are cross-chain deposits or withdrawals at all. The second is transaction matching: given the deposits on one chain and the withdrawals on another, decide which two belong to the same cross-chain operation. A matched deposit–withdrawal pair is called a cross-chain transaction (cctx) [14], [28]. Tracing, which strings matched pairs and ordinary transfers into an end-to-end fund path, and anomaly detection, which flags the transactions or accounts that break a system’s rules or deviate from normal behavior, build on these results. This SoK discusses both only as downstream applications of recovered cross-chain evidence. III. I DENTIFYING C ROSS -C HAIN T RANSACTIONS Cross-chain analysis starts from identification: before any pair can be matched, the deposits and withdrawals must first be found among a chain’s transactions. Existing work identifies

Fig. 1. Lifecycle of a cross-chain transfer and where its evidence is recorded. A transfer moves through a source-chain action, an off-chain attestation and relay, and a destination-chain settlement. Each stage leaves a different kind of evidence, and depending on the system, the two ends may be linked by explicit identifiers, platform records, or inferred business invariants.

cross-chain deposits and withdrawals in four ways: officialrecord lookup, signature matching, address aggregation, and learned classification. Official-record lookup. The ledger of a bridge or platform already stores the hash and status of deposit and withdrawal transactions. Yan et al. [29] obtain bridge ledgers through the transaction-info interfaces of four bridges, Yousaf et al. [30] poll ShapeShift’s public interface, and CLTracer [31] calls its transaction-status interface (txstat) to verify candidate deposits. This class depends entirely on whether the platform offers an interface: among the thirty bridges surveyed by Yan et al., only four provide a usable API. Signature matching. An analyst audits the bridge contract’s source code, enumerates the dedicated events and function selectors of its deposit and withdrawal functions, and scans on-chain logs. The Ethereum–Polygon tracing [32] identifies deposits through LockedEther-family events, Jigsaw [33] compiles such signature lists for thirteen bridges, and CONNECTOR [34], XChainWatcher [28], and XScope [35] maintain equivalent decoders. This class requires the contract to be open source, and a bridge upgrade that renames an event invalidates the hand-written rules. Address aggregation. A centralized service leaves only ordinary transfers on chain, but its fund management forms a funnel-shaped topology in which many one-off deposit addresses aggregate into a few central addresses or hot wallets. CLTracer locates the shared central address from seed transactions and collects in reverse the transactions paid into it, recovering 1.77 million deposits; the ICE study [24] confirms a service’s hot wallet with real exchange requests and infers deposit addresses backward from the aggregation transactions. This class presupposes a central-aggregation architecture, and CLTracer’s survey of nineteen alternative platforms maps its boundary: roughly half can be traced the same way, while the rest either hand the received funds to traditional exchanges (the aggregation edge leads into an exchange wallet) or, like the

privacy-conscious Flyp.me, leave deposits unspent (the edge never appears). Learned classification. This class casts identification as a classification task over a transaction’s execution structure and textual semantics. XSema [36] classifies transactions into deposit, withdrawal, and non-cross-chain from the transaction’s transfer structure and event-log text. CONNECTOR combines textual and structural features: it embeds the function text so that deposit functions named differently across bridges read as the same intent, and builds a call graph of the internal calls and asset transfers the deposit triggers. The two feature families together identify nearly 100% of deposit behaviors, while structure alone reaches 74.43%. Both works build their training labels from official bridge explorers, so a learning-based method still depends on platform cooperation. The dependence merely moves from inference time to training time. The real value of this class lies in cross-bridge generalization: trained on four of ten bridges, XSema reaches a 94.85% macro F1 on the six unseen during training. IV. M ATCHING C ROSS -C HAIN T RANSACTIONS Matching takes over from identification: it decides which deposit and which withdrawal complete the same transfer across chains. Existing methods fall into three classes by the evidence they rely on: deterministic identifier matching, fieldconstraint heuristics, and model-assisted matching (§IV-A– §IV-C). Table I summarizes the works. A. Deterministic Identifier Matching Deterministic identifier matching relies on an association clue that the system or platform records explicitly. By where the identifier resides, existing methods split into two subclasses: off-chain platform records, which give the pairing directly, and on-chain event identifiers, which the bridge contract writes into events as a message identifier, a source transaction hash, or a deposit identifier.

TABLE I C ROSS -C HAIN D EPOSIT /W ITHDRAWAL I DENTIFICATION AND M ATCHING W ORKS Matching

Identification only

Deterministic identifier matching

Field-constraint heuristic matching

Model-assisted matching

Method

Yr

Sys

Identifi.

Mech

Pairing evidence

Outcome Addr

Gen.

Pairs

Performance

Code

XSema [36]

2024

BR

L

–

–

–

✓

–

94.85% ident. F1

◦

CLTracer [31]

2022

ICE

R,A

Doff (H)

platform record

–

✗

–

–

◦

Empirical Study [29]

2025

BR

R

Doff

platform record

–

✗

543K

–

•

Jigsaw [33]

2024

BR

E

Don (H)

on-chain identifier

–

✗

–

99.8% match rate

◦

XChainWatcher [28]

2025

BR

E

Don

on-chain identifier

–

✗

81K

–

•

Arbitrage [37]

2025

L2

E

Don (H)

on-chain identifier

reuse

✗

–

–

◦

XChainDataGen [38]

2025

BR

E

Don

on-chain identifier

–

✗

11.29M

–

•

Yousaf et al. [30]

2019

ICE

R

H (Doff )

amt/time

reuse

✗

1.38M

–

◦

ICE Study [24]

2024

ICE

A

H

addr/amt/time

reuse

✗

194K

80.8–91.9% match rate

◦

Eth-Polygon [32]

2025

L2

E

H

addr/amt/time/token

reuse

✗

2M

67.55–92.78% match rate

◦

CONNECTOR [34]

2025

BR

E,L

H

time/token/fee

decl.

✗

24K

95.95% match rate

•

LOCARD [39]

2026

BR

R,E

H (Agent)

amt/time/fee

–

✗

151K

–

•

ABCTRACER [40]

2025

BR

L

M

learned + explicit clues

decl.

✓

29K

91.75% F1

•

ConneX [41]

2025

BR

E,L

M (H)

LLM-selected fields + rules

decl.

✓

–

97.46% F1

◦

Sys: BR = contract bridge, ICE = instant exchange, L2 = L1–L2 bridge. Identification: R = record lookup, E = signature matching, A = address aggregation, L = learned classification. Mech: Doff /Don = deterministic off-/on-chain, H = field heuristic, M = model-assisted; parentheses mark a secondary mechanism. Field lists are ordered addr, amt, time, token, fee. Addr: decl. = protocol-declared receiver, reuse = same-address assumption. Gen.: ✓ = demonstrated reduced per-bridge adaptation (unseen-bridge tests or automatic field discovery), ✗ = per-bridge manual rules. Pairs = cross-chain transaction pairs the work reports collecting or matching; – = not reported at pair granularity. Performance: match rate = share of transactions successfully matched, with the denominator and correctness check defined by each work; F1 = precision–recall harmonic mean on labeled pairs; ident. = identification task. Figures are as stated by each work and not comparable across papers. Code: • = code released, ◦ = not released; dataset availability is in Table III.

Off-chain platform records provide already-matched transactions: a ledger entry or an API response (§III) names the transactions on both ends. The remaining work is to pull the named transactions from the two chains and to check that the record and the chain agree. Such records fail in three ways. The first is a correctness failure: when Yan et al. [29] compared four bridges’ ledgers with the chains, 9,956 transactions differed in amount and 308 were marked successful but had failed on chain. The second is an availability failure: after Multichain collapsed in 2023, the works that depend on its official explorer data, CrossAAD [42] and GMMCCT [43], can no longer be reproduced. The third is a coverage failure: a platform record covers only activity inside that platform, and CLTracer [31] found that phishing- and hacker-related addresses completed their last cross-ledger transaction the day before ShapeShift’s mandatory KYC took effect. ShapeShift’s usage then declined drastically. Off-chain records give a strong pairing clue within a platform, but their coverage decays as platform policy and user behavior change. On-chain event identifiers are unique fields a bridge contract writes into its event logs for the correctness, so that the same message cannot be executed twice. Because they live on chain, anyone can re-verify them at any time, and they do not disappear when a platform does. Jigsaw [33] pairs with such fields on ten of thirteen bridges (the srcTxHash in Multichain’s LogAnySwapIn, for example) and, with a heuristic fallback for the other three, reaches a 99.8% overall matching rate on about eighty million transactions, the largest matching study we survey. XChainWatcher [28] and the cross-

chain arbitrage study [37] join on the same kind of key (a deposit_id, a message number), and XChainDataGen [38] extracts 11.29M cctx from five protocols across eleven chains using such identifiers alone, released as a public dataset (§V). Insight 1: Beyond strength, evidence differs in verifiability and durability; the most dependable pairing evidence is a publicly verifiable join key on chain. Both deterministic sources give the pairing outright, but a record can be wrong, go offline, or lose coverage, whereas a key, wherever the contract writes it, stays on chain for anyone to re-check. B. Field-Constraint Heuristics When neither record nor identifier exists, only the ordinary fields of a transfer remain (addresses, amounts, timestamps, tokens), and field-constraint heuristics match with these fields. Such heuristics first narrow the candidate set by address: the receiver recorded in the deposit event, the same user address appearing on both chains, or an address that platform records associate with the user. When no address clue is available, they treat every transfer within a time window as a candidate. They then retain only the candidates whose timing, post-fee amount, token, and destination chain are consistent with the deposit. The two ends never agree exactly. The withdrawal arrives later than the deposit and, after fees, for a smaller amount. Every rule therefore needs a tolerance, and the analyst must decide its size, such as the width of the time window and the allowed deviation in amount. Table II summarizes the evidence constraints matching relies on, what each checks, and when each breaks.

TABLE II E VIDENCE C ONSTRAINTS IN C ROSS -C HAIN M ATCHING Evidence

What it checks

Typical signal

Breaks when

Protocol identifier

direct pairing

srcTxHash; deposit id; message number

bridge writes no key

Declared address

named recipient matches

receiver field

field not emitted

Reused address

same user on both chains

same EOA or platform address

recipient differs from sender

Amount

value conservation

exact amount; post-fee amount; FX-converted amount

units, fees, and rates vary

Time

deposit precedes withdrawal

time window; finality bound

user-timed claims stretch window

Asset and route

token and chain correspondence

token mapping; token ID

hand-kept mappings go stale

Representative settings: amount tolerance 0.5% [37], fee ∈ [0, 3%] [34], 20% [41], FX rate [39]; time window 5 min [24], 30 min [34], 2 h [41], 24.2 min / 6.4 d [32]. Identifier keys: srcTxHash [33], deposit id [28], message number [37]. Field location can itself be learned: NER [40], LLM selection [41].

The same heuristics perform very differently as the evidence changes. In the Ethereum–Polygon tracing of Yan et al. [32], deposit matching exceeds 93%, but the ERC20 withdrawal matching rate is only 67.55%, because the bridge produces no dedicated event for an ERC20 withdrawal (only a standard Transfer), which makes a bridge withdrawal indistinguishable at the log level from an exchange withdrawal or an ordinary transfer; an ERC721 withdrawal, which has a dedicated event and a unique token identifier, reaches 92.78%. A withdrawal on this bridge also completes in two steps: the user burns the wrapped copy on Polygon, then claims the funds on Ethereum with a second transaction, whenever they choose. The best time window therefore widens from about 24.2 minutes for deposits to about 6.4 days, leaving the time constraint with almost no filtering power. Heuristics also serve as every system’s fallback layer: the basic version of Yousaf et al. [30] works without the platform interface, and Jigsaw [33] drops to field heuristics on the three bridges that write no identifier. Among the works that match with fields alone, the ICE study [24] reaches 80.8%– 91.9% and CONNECTOR [34] 95.95%. LOCARD [39] runs the same kind of heuristics inside an agent workflow. Despite these rates, such heuristics share a weak point: filtering often leaves more than one candidate standing. Existing works disambiguate with rules chosen by hand, and each chooses differently: ConneX [41] takes the candidate with the earliest timestamp, CONNECTOR tightens the time window, ABCTRACER [40] and LOCARD score the candidates, and Yan et al. keep a match only when exactly one candidate passes. C. Model-Assisted Matching Model-assisted matching uses learning models in two ways: some works let a model find the useful fields and clues, and others train a model on data to pair the two ends directly. Both aim to lower the cost of adapting to bridges where an explicit identifier is missing and field semantics are heterogeneous. Model-assisted matching faces two kinds of field heterogeneity. The first is naming: the useful fields (the destination chain, the receiver address) appear in every bridge’s events, but each bridge names them differently. ABCTRACER [40], which targets automated, bidirectional tracing on DeFi bridges, uses named-entity recognition to identify a field by its meaning

(its explicit clues); ConneX [41] is more conservative with its LLM, which only identifies, among many candidate fields, the five-tuple that may carry cross-chain semantics, while a deterministic examiner with six rules completes verification and pairing, for an overall F1 of 0.9746, against only 0.71 when a baseline lets the LLM choose the paired transaction directly. The second is the clues themselves: what links the two ends differs from bridge to bridge. On Allbridge, for example, a deposit and its withdrawal carry the same recipient, nonce, and messenger values. ABCTRACER trains a Siamese network, a model that compares two transactions as a pair, on known matched pairs to uncover such patterns (its implicit clues). Combining the two kinds of clue, it reaches a 91.75% bidirectional F1 on twelve bridges; trained on only 25% of the bridges, it still reaches a 93.95% F1 on unseen ones. The main value of a learning-based method thus lies in reducing the manual cost per bridge. The evaluation of a learning-based method should therefore consider, besides single-point F1, cross-bridge generalization, manual annotation cost, and whether the final pairing remains verifiable: F1 alone ranks ABCTRACER’s 91.75% below Jigsaw’s 99.8% deterministic matching. ConneX’s division of labor, in which the model assists and deterministic rules decide, also holds for agents, programs that use a large language model (LLM) as their decision core, plan steps, and call external tools: in LOCARD [39], agents plan the queries, collect the evidence, and track the investigation state, and the pairing decision still comes from its deterministic rules. Across these designs the model reads the heterogeneous fields and organizes the evidence; the pairing itself is still decided by logs, amounts, times, and rules. Insight 2: In every surveyed work, the role of LLMs and agents is to lower adaptation cost; the final decision is still made by deterministic rules over verifiable evidence. D. Cross-Mechanism Analysis: The Evidence Hierarchy Ranked by evidence strength, the three mechanisms form a chain that degrades step by step: an identifier gives the pair directly, generic fields only shrink the candidate set, and models serve the remaining bridges whose field semantics vary. Systems therefore use strong evidence first and fall back only where it is missing: Jigsaw [33] pairs with the

identifier on bridges whose events carry a unique field and uses heuristics on the rest, and the arbitrage study [37] joins on the message number on native bridges such as Arbitrum, Base, and Optimism, falling back to token-transfer scanning on Polygon, which leaves none (the Mech column of Table I records these combinations). The gap in matching rates is also set by the evidence level. Within one heuristic framework, for example, the Ethereum-Polygon tracing [32] reaches 92.78% on ERC721 withdrawals but 67.55% on ERC20 withdrawals (§IV-B). Insight 3: The three matching mechanisms are ordered by the strength of their evidence; the ceiling of matching performance is set by the evidence the cross-chain system leaves behind. E. Downstream Security Applications Matching results feed two security tasks: attack detection and fund tracing. Jigsaw’s CrossAlert [33] runs three rules over the matching results of about 80.05 million transactions and flags 94 abnormal matching transactions, of which 47 unmatched ones involve over $605M in losses; ABCTRACER [40] identifies 20 attack transaction pairs and separately recovers 10 laundering-related cross-chain paths; ConneX [41] traces Bybit-related stolen funds across a bridge to Solana. These applications also leave three issues unsettled. First, detectors disagree on whether pairing should be a premise: BridgeGuard [44] does not require pairing, finding that 65.7% of attack transactions have no counterpart on the other chain, whereas BridgeShield [45] builds its detection graph on paired transactions. Second, a missing counterpart is ambiguous: it can be the mark of an attack (a fake deposit releases assets with no real deposit behind them [46]) or a gap in the collected data (§VI). Third, evaluation is not comparable across these systems: label sources and sample units differ, and systems that claim real-time operation report throughput but no end-to-end alert latency [47], [48]. Insight 4: Matched pairs feed attack detection and fund tracing, but whether pairing should be a detection premise and how a missing counterpart should be read, remain disputed. V. DATASET AVAILABILITY AND R EPRODUCIBILITY This section compares the cross-chain transaction datasets built by existing research along coverage, scale, label source, and actual availability. We checked each paper’s stated data or artifact release one by one, including dataset links, code repositories, and external data sources, and rated availability on the two levels defined in the notes of Table III (checked July 2026). Seven of the fifteen surveyed works provide an obtainable data artifact, fewer than half, and not every artifact carries task labels. The failures fall into three modes. The first is promised-only: Jigsaw [33] states that it will release its eightymillion-transaction dataset, but no link can be found now. The second is a missing link: the ICE study [24] calls its dataset open-source but gives no URL anywhere in the paper. The third is an expired anonymous review repository: ConneX [41]

placed its data in an anonymous repository built for doubleblind review, and once it expired the data was gone. The remaining five papers make no public-release claim. Among them, XSema [36] states that it built “the first cross-chain semantic dataset” yet gives no way to obtain it. Among the truly obtainable datasets, the main difference lies in the label source. The matching ground truth of Yan et al. [29], CONNECTOR [34], ABCTRACER [40], and LOCARD [39] comes from bridge ledgers, explorers, or official execution records, which ultimately depend on platform cooperation; XChainDataGen [38] builds its cctx ground truth by joining deposit and withdrawal events on the identifiers the bridge contracts write on chain, so it does not depend on platform cooperation. Beyond matching truth, XChainWatcher [28] marks the transactions involved in two real bridge attacks (Ronin and Nomad), a label that serves downstream detection, and the Price of Interoperability dataset [49] carries no security labels at all. In coverage, public datasets concentrate on the EVM ecosystem and the 2021– 2025 period: LOCARD’s dataset is the only one targeting native-asset chains (BTC, DOGE, LTC), and the ICE and cross-ledger-service direction has no usable public dataset. Overall, a cross-chain dataset stays reproducible only as long as every source it depends on stays available: the archive that stores it, the platform records behind its ground truth, and the chain data itself. Future works should archive all three together, so that a matching result can still be re-checked after the platform changes or disappears. VI. O PEN C HALLENGES Building on the systematization above, we summarize four open challenges. Interpreting missing counterparts under partial evidence. When a transaction’s counterpart cannot be found, there are two possible reasons: the counterpart exists but lies outside the collected data, or it never existed. The second is exactly what a fake deposit looks like: the destination chain releases an asset although no real deposit was ever made (§IV). Future matching should make the distinction explicit: check how well the collected data covers the bridge, the chains, and the time window in question, and report how likely the missing counterpart is a data gap rather than an attack, instead of a hard verdict. How much a missing counterpart means also depends on how complete the matching is. When identifiers match nearly every transaction, as in Jigsaw [33], the few that remain unmatched deserve individual inspection; when heuristics leave a third of withdrawals unmatched (§IV-B), an unmatched withdrawal by itself signals nothing. A verdict on a missing counterpart should therefore state how complete the matching behind it is. Matching one-to-many and many-to-many transfers. Existing matching generally assumes one deposit corresponds to one withdrawal (§IV), while aggregators [50], liquidity pools, and pooled settlement produce one-to-many and manyto-many correspondences that weaken amount conservation, the time window, and address constraints at the same time.

TABLE III C ROSS -C HAIN T RANSACTION DATASETS , S ORTED BY V ERIFIED AVAILABILITY ( AS OF J ULY 2026) Work

Scope

Size

Period

Label source

Availability ✓ GitHub+Zenodo

XChainDataGen [38]

5 bridges, 11 chains

11.29M pairs

2024.06–2024.12

on-chain identifier

Empirical Study [29]

4 bridges, 11 chains

543K pairs

2023

platform record

✓ Zenodo

XChainWatcher [28]

2 bridges, 3 chains

81K pairs

2022

attack event

✓ GitHub

CONNECTOR [34]

3 bridges, 3 chains

24K pairs

2020.09–2023.04

platform record

✓ GitHub

ABCTRACER [40]

12 bridges, 2 chains

29K pairs

2021.04–2024.03

platform record

✓ GitHub

1 bridge, 4 chains

151K pairs

2025

platform record

✓ GitHub

16 bridges, 20 chains

9M pairs

2022–2025

–

✓ GitHub

LOCARD [39] Price of Interop. [49]

13 bridges, 7 chains

80.05M tx

2021.03–2024.01

–

✗ promised only

ICE [24]

9 bridges

–

2023.01–2023.09

–

✗ no link

ConneX [41]

5 bridges

504K tx

2021.02–2024.03

platform record

✗ expired anon repo

Jigsaw [33]

-

Size: “pairs” denotes linked deposit–withdrawal units, while “tx” denotes individual one-sided transactions. For availability, ✓ indicates that the data and key labels remain obtainable, whereas ✗ indicates that the dataset was claimed to be public but its link is missing or empty, or points to an expired anonymous repository. Works that make no public-release claim are discussed in the text. -

Correspondences that span several pairs also occur: scanning 34.8 million bridge transactions across twelve networks, the N-hop study [51] finds ten arbitrage routes that cross two or three bridges in a row, and such a route is recovered only when the time and amount constraints hold at every hop. Future matching should relax one-to-one matching into set-toset matching: constraints such as amount conservation should be checked over sets of transactions, candidate combinations scored by evidence strength, and multiple candidates reported with confidence instead of a fixed rule selecting one and discarding the alternatives. Ground truth, benchmarks, and artifact availability. Matching ground truth ranges from official platform records to attack events, and a substantial share of artifacts claimed to be public are unobtainable (§V). The most direct fix is durable storage: data and labels should live in archives that outlast the platform and the review process (the Zenodo archives of Yan et al. [29] and XChainDataGen [38] are ready examples). Two papers that both report a matching rate are not comparable if their ground-truth sources differ. A shared test set would fix this. It should hold transactions from several bridges; each matched pair should state where its label came from (a platform record, an on-chain identifier, or an attack report); and a few bridges should be held back from development, so every method also reports how it does on a bridge it has never seen. XSema [36] and ABCTRACER [40] already test on unseen bridges, but each on its data, so their numbers still cannot be compared. Until a shared set exists, releasing the ground truth next to the code, as the seven obtainable artifacts in Table III do, is the practical minimum. Verifiable use of models and agents. Existing systems confine LLMs and agents to components: field discovery and forensic orchestration. The final conclusion still rests on deterministic rules, economic constraints, or auditable evidence (§IV). The open question is whether such a component adds enough value over a deterministic script or a humanwritten procedure to outweigh its nondeterminism and the extra verification it requires. Future work should evaluate the

component on three dimensions: task quality (does precision or F1 improve), adaptation cost (do rules, annotation, and analysis time decrease), and auditability (can the prompts, tool calls, and final judgment be replayed and independently checked). No surveyed system measures all three. VII. C ONCLUSION This paper systematizes research on cross-chain transaction identification and matching. We organize identification into four approaches and matching into three mechanisms whose performance is bounded mainly by the strength of the evidence the underlying system leaves, summarize what matched pairs supply to downstream attack detection and fund tracing, verify the actual availability of existing datasets and artifacts one by one, and distill four open challenges. The core bottleneck of cross-chain transaction analysis lies beyond the choice of algorithm: whether the evidence exists, whether the ground truth is credible, whether the data is reproducible, and whether analysis can deliver a verifiable judgment under incomplete evidence. Future work should move from offline case studies toward evaluation that answers these four questions directly. R EFERENCES [1] L. Gudgeon, P. Moreno-Sanchez, S. Roos, P. McCorry, and A. Gervais, “Sok: Layer-two blockchain protocols,” in International Conference on Financial Cryptography and Data Security (FC). Springer, 2020, pp. 201–226. [2] M. Qi, Q. Wang, Z. Wang, M. Schneider, T. Zhu, S. Chen, W. Knottenbelt, and T. Hardjono, “Sok: Bitcoin layer two (L2),” ACM Computing Surveys, vol. 58, no. 3, pp. 1–37, 2025. [3] M. Zhang, X. Zhang, Y. Zhang, and Z. Lin, “Security of cross-chain bridges: Attack surfaces, defenses, and open problems,” in International Symposium on Research in Attacks, Intrusions and Defenses (RAID), 2024, pp. 298–316. [4] N. Li, M. Qi, Z. Xu, X. Zhu, W. Zhou, S. Wen, and Y. Xiang, “Blockchain cross-chain bridge security: Challenges, solutions, and future outlook,” Distributed Ledger Technologies: Research and Practice (ACM DLT), vol. 4, no. 1, pp. 1–34, 2025. [5] CoinGecko, “Global cryptocurrency market cap charts,” https://www. coingecko.com/en/global-charts, 2026, accessed July 2026. [6] DefiLlama, “Bridges,” https://defillama.com/bridges, 2026, accessed 10 June 2026.

[7] ——, “Total value hacked in DeFi,” https://defillama.com/hacks, 2026, accessed July 2026. [8] Chainalysis, “Vulnerabilities in cross-chain bridge protocols emerge as top security risk,” 2022, blog post. [Online]. Available: https: //www.chainalysis.com/blog/cross-chain-bridge-hacks-2022/ [9] Q. Wang, R. Li, Q. Wang, S. Chen, M. Ryan, and T. Hardjono, “Exploring web3 from the view of blockchain,” arXiv preprint arXiv:2206.08821, 2022. [10] Elliptic, “The state of cross-chain crime 2025,” Elliptic, Tech. Rep., 2025, industry report. [11] TRM Labs, “2026 crypto crime report,” https://www.trmlabs.com/ reports-and-whitepapers/2026-crypto-crime-report, 2026, accessed July 2026. [12] A. Zamyatin, M. Al-Bassam, D. Zindros, E. Kokoris-Kogias, P. MorenoSanchez, A. Kiayias, and W. J. Knottenbelt, “SoK: Communication across distributed ledgers,” in International Conferences on Financial Cryptography and Data Security (FC), vol. 12675, 2021, pp. 3–36. [13] M. Zhang, X. Zhang, Y. Zhang, and Z. Lin, “Cross-chain bridges: Attack taxonomy, defenses, and open problems,” in Proceedings of the International Symposium on Research in Attacks, Intrusions and Defenses (RAID), 2024, pp. 298–316. [14] A. Augusto, R. Belchior, M. Correia, A. Vasconcelos, L. Zhang, and T. Hardjono, “Sok: Security and privacy of blockchain interoperability,” in IEEE Symposium on Security and Privacy (SP). IEEE, 2024, pp. 3840–3865. [15] G. Wang, Q. Wang, and S. Chen, “Exploring blockchains interoperability: A systematic survey,” ACM Computing Surveys, vol. 55, no. 13s, pp. 1–38, 2023. [16] J. S. Notland, J. Li, M. Nowostawski, and P. H. Haro, “SoK: Crosschain bridging architectural design flaws and mitigations,” Blockchain: Research and Applications, vol. 7, no. 1, p. 100315, 2026. [17] S.-S. Lee, A. Murashkin, M. Derka, and J. Gorzny, “Sok: Not quite water under the bridge: Review of cross-chain bridge hacks,” in Proc. IEEE International Conference on Blockchain and Cryptocurrency (ICBC), 2023. [18] N. Belenkov, V. Callens, A. Murashkin, K. Bak, M. Derka, J. Gorzny, and S.-S. Lee, “Sok: A review of cross-chain bridge hacks in 2023,” arXiv preprint arXiv:2501.03423, 2025. [19] A. Kumar and V. L. L. Thing, “A survey of transaction tracing techniques for blockchain systems,” arXiv preprint arXiv:2510.09624, 2025. [20] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” https: //bitcoin.org/bitcoin.pdf, 2008. [21] G. Wood, “Ethereum: A secure decentralised generalised transaction ledger,” Ethereum Project Yellow Paper, https://ethereum.github.io/ yellowpaper/paper.pdf, 2014. [22] BNB Chain, “BNB Chain documentation,” https://docs.bnbchain.org, 2026, accessed 15 July 2026. [23] R. Belchior, A. Vasconcelos, S. Guerreiro, and M. Correia, “A survey on blockchain interoperability: Past, present, and future trends,” ACM Computing Surveys, vol. 54, no. 8, pp. 1–41, 2022. [24] Y. Hu, Y. Sun, L. Wu, Y. Zhou, and R. Chang, “Towards understanding and analyzing instant cryptocurrency exchanges,” Proceedings of the ACM on Measurement and Analysis of Computing Systems (POMACS), vol. 8, no. 3, pp. 1–24, 2024, article 48. [25] P. Han, Z. Yan, W. Ding, S. Fei, and Z. Wan, “A survey on cross-chain technologies,” Distributed Ledger Technologies: Research and Practice (DLT), vol. 2, no. 2, pp. 1–30, 2023. [26] Y. Zhang, Y. Geng, Q. Wang, B. Qin, Q. Wu, W. Huang, W. Shi, and W. Susilo, “Atomxross: Towards general cross-chain transaction,” IEEE Transactions on Information Forensics and Security (TIFS), 2026. [27] Y. Geng, B. Qin, Q. Wang, W. Shi, and Q. Wu, “Subsidy bridge: Rewarding cross-blockchain relayers with subsidy,” in International Conference on Information and Communications Security (ICICS). Springer, 2023, pp. 571–589. [28] A. Augusto, R. Belchior, J. Pfannschmidt, A. Vasconcelos, and M. Correia, “XChainWatcher: Identifying anomalies in cross-chain bridges,” in Proceedings of the ACM/IFIP International Middleware Conference (Middleware), 2025. [29] K. Yan, B. Lu, P. Agrawal, J. Li, W. Diao, and X. Zhang, “An empirical study on cross-chain transactions: Costs, inconsistencies, and activities,” in ACM Asia Conference on Computer and Communications Security (AsiaCCS), 2025. [30] H. Yousaf, G. Kappos, and S. Meiklejohn, “Tracing transactions across cryptocurrency ledgers,” in 28th USENIX Security Symposium (USENIX

Sec). USENIX Association, 2019, pp. 837–850. [Online]. Available: https://www.usenix.org/conference/usenixsecurity19/presentation/yousaf [31] Z. Zhang, J. Yin, B. Hu, T. Gao, W. Li, Q. Wu, and J. Liu, “CLTracer: A cross-ledger tracing framework based on address relationships,” Computers & Security, vol. 113, p. 102558, 2022. [32] T. Yan, C. Huang, and C. J. Tessone, “Tracing cross-chain transactions between EVM-based blockchains: An analysis of Ethereum-Polygon bridges,” Ledger, 2025. [33] X. Hu, H. Feng, P. Xia, G. Tyson, L. Wu, Y. Zhou, and H. Wang, “Piecing together the jigsaw puzzle of transactions on heterogeneous blockchain networks,” ACM on Measurement and Analysis of Computing Systems (POMACS), vol. 8, no. 3, 2024. [34] D. Lin, J. Wu, Y. Su, Z. Zheng, Y. Nan, Q. Zhang, B. Song, and Z. Zheng, “CONNECTOR: Enhancing the traceability of decentralized bridge applications via automatic cross-chain transaction association,” IEEE Transactions on Information Forensics and Security (TIFS), 2025. [35] J. Zhang, J. Gao, Y. Li, Z. Chen, Z. Guan, and Z. Chen, “XScope: Hunting for cross-chain bridge attacks,” in IEEE/ACM International Conference on Automated Software Engineering (ASE), 2022, pp. 1–4. [36] Z. Zheng, J. Wu, D. Lin, Q. Li, and N. Ruan, “XSema: A novel framework for semantic extraction of cross-chain transactions,” in IEEE International Conference on High Performance Computing and Communications (HPCC). IEEE, 2024, pp. 673–680. [37] B. Öz, C. Ferreira Torres, C. Schlegel, B. Mazorra, J. Gebele, F. Rezabek, and F. Matthes, “Cross-chain arbitrage: The next frontier of MEV in decentralized finance,” Proceedings of the ACM on Measurement and Analysis of Computing Systems (POMACS), vol. 9, no. 3, pp. 1–33, 2025, article 51. [38] A. Augusto, A. Vasconcelos, M. Correia, and L. Zhang, “XChainDataGen: A cross-chain dataset generation framework,” arXiv:2503.13637, 2025, preprint. [39] X. Yu and W. Knottenbelt, “LOCARD: An agentic framework for blockchain forensics,” arXiv:2604.04211v2, 2026, preprint, version 2. [40] D. Lin, Z. Zheng, J. Wu, J. Yang, K. Lin, H. Xiao, B. Song, and Z. Zheng, “Track and trace: Automatically uncovering cross-chain transactions in the multi-blockchain ecosystems,” IEEE Transactions on Services Computing (TSC), 2025. [41] H. Liang, Y. Duan, X. Su, X. Li, Y. Liu, Y. Tian, F. Xu, and S. Zhong, “ConneX: Automatically resolving transaction opacity of cross-chain bridges for security analysis,” arXiv:2511.01393, 2025, preprint. [42] Y. Lin, P. Jiang, F. Guo, and L. Zhu, “CrossAAD: Cross-chain abnormal account detection,” in Information Security and Privacy, 2024, pp. 84– 104. [43] Y. Lin, P. Jiang, and L. Zhu, “Cross-chain abnormal transaction detection via graph-based multi-model fusion,” in ACM International Symposium on Blockchain and Secure Critical Infrastructure (BSCI@AsiaCCS), ser. 2024, 2025, pp. 1–9. [44] J. Wu, K. Lin, D. Lin, B. Zhang, Z. Wu, and J. Su, “Safeguarding blockchain ecosystem: Understanding and detecting attack transactions on cross-chain bridges,” in Proceedings of the ACM Web Conference (WWW), 2025. [45] D. Lin, S. Lu, Z. Liu, J. Wu, J. Fang, K. Lin, B. Song, and Z. Zheng, “BridgeShield: Enhancing security for cross-chain bridge applications via heterogeneous graph mining,” arXiv:2508.20517, 2025, preprint. [46] K. Lin, D. Lin, Z. Zheng, Y. Tan, and J. Wu, “Detecting fake deposit attacks on cross-chain bridges from a network perspective,” in 2024 IEEE International Symposium on Circuits and Systems (ISCAS). IEEE, 2024, pp. 1–5. [47] R. Wiputra, C. I. Halim, B. A. Suraperwata, K. Wangsa, and R. P. Agustin, “BADS: Real-time anomaly detection and reporting for crosschain bridges using large language models,” in International Conference on Artificial Intelligence Science and Applications in Industry and Society (CAISAIS). IEEE, 2025, pp. 1–6. [48] T.-D. Tran, D. K. Nguyen, Q. T. Do, and V.-H. Pham, “VeriBridge: Real-time cross-chain bridge attack detection through static-informed graph anomaly learning,” in 2025 2nd International Conference On Cryptography And Information Security (VCRIS). IEEE, 2025, pp. 1–6. [49] Y. Cao, M. Zheng, L. W. Cong, S. Li, and X. Wang, “The price of interoperability: Exploring cross-chain bridges and their economic consequences,” Proceedings of the ACM on Measurement and Analysis of Computing Systems, vol. 10, no. 2, pp. 1–29, 2026, article 52. [50] S. Subramanian, A. Augusto, R. Belchior, A. Vasconcelos, and M. Correia, “Benchmarking blockchain bridge aggregators,” in Proceedings of

the IEEE International Conference on Blockchain (Blockchain), 2024, pp. 37–45. [51] D. Mancino, H. O. Sevim, and O. Saguillo Gonzalez, “Bunny hops and blockchain stops: Cross-chain MEV detection with N-hops,” in 2025 7th Conference on Blockchain Research & Applications for Innovative Networks and Services (BRAINS), 2025, pp. 1–4.

Related documents

• SiNMULI: Novel Signed Network Approach for Malicious URL Identification#467065
• NIST SP 800-168: Approximate Matching: Definition and Terminology#2917
• IBAKE: Identity-Based Authenticated Key Exchange#220731
• Application-agnostic Provenance Auditing for HPC Systems Using libc Interposition#411699
• Definitions of Object Identifiers for Identifying Ethernet Chip Sets#136789