BridgeShield: Cross-chain Attack Detection

• BridgeShield is a graph-mining-based detection framework that reconstructs heterogeneous cross-chain operation graphs for end-to-end attack analysis.
• It employs relation-aware message passing with hierarchical meta-path attention to integrate source-chain, off-chain, and destination-chain data.
• The framework demonstrates significant improvements over baselines, achieving an average F1-score of 92.58% in detecting real-world cross-chain attacks.

Searching arXiv for the target paper and closely related context. BridgeShield is a graph-mining-based detection framework for cross-chain bridge decentralized applications that reconstructs the complete cross-chain execution path—source chain, off-chain coordination, and destination chain—inside a unified heterogeneous graph in order to identify attack behaviors (Lin et al., 28 Aug 2025). It is designed for transaction-level detection of end-to-end cross-chain “operation” graphs and combines relation-aware message passing with hierarchical meta-path attentions: intra-meta-path attention learns fine-grained dependencies along cross-chain paths, while inter-meta-path attention highlights discriminative multi-chain patterns. On 51 real-world cross-chain attack events, it reports an average F1-score of 92.58%, with a 24.39-point improvement over the best baseline and a 26.32-point recall gain (Lin et al., 28 Aug 2025).

1. Problem setting and detection objective

Cross-chain bridges move assets and messages between heterogeneous blockchains, addressing value silos and enabling DeFi composability across chains. At the same time, they concentrate large amounts of value and stitch together multi-chain semantics through off-chain coordinators such as relayers, validators, and oracles. Design flaws or misconfigurations in verification, relay, mint/burn, and event routing therefore create attack surfaces that include fake deposit proofs, validator compromise, replay or infinite mint, misuse of bridge functions, double spending, and oracle or relayer manipulation (Lin et al., 28 Aug 2025).

BridgeShield is motivated by the observation that existing detectors remain constrained by a predominantly single-chain viewpoint. Most tools and machine-learning models operate on single-chain transaction graphs, ignore off-chain coordination and destination-chain semantics, and therefore miss attacks that become visible only when the end-to-end cross-chain logic is reconstructed. Rule-based detectors such as Xscope and XChainWatcher are described as protocol-specific and brittle to new attack variants, while graph baselines such as RGCN, HGT, and HEAT do not reconstruct cross-chain paths or robustly integrate off-chain evidence (Lin et al., 28 Aug 2025).

The stated objective is end-to-end, transaction-level detection of cross-chain bridge attacks by reconstructing heterogeneous, multi-relational paths across source, off-chain, and destination layers. The detection scope is framed as the first framework that jointly models source-chain, off-chain coordination, and destination-chain behaviors in one detection process. This objective determines both the data representation and the model architecture: BridgeShield treats a cross-chain operation not as an isolated transaction on one chain, but as a semantically linked multi-stage execution trace.

2. Threat model and prediction target

BridgeShield targets malicious behaviors at any stage of a cross-chain flow (Lin et al., 28 Aug 2025). On the source chain, the threat model includes forged or abused lock events, approvals or allowances misuse, and misrouted calls to rogue contracts. In off-chain coordination, it includes validator compromise, oracle or relayer manipulation, acceptance of fake proofs or messages, and replay or infinite mint enabled by off-chain mischecks. On the destination chain, it includes reentrancy during mint or unlock, double-mint, misuse of bridge, router, or token functions, and improper verification leading to unauthorized mint or unlock.

Detection is posed as graph-level classification over an end-to-end cross-chain operation graph consisting of one source-side deposit or lock, one off-chain relay, and one destination-side mint or unlock. Internally, the model aggregates node-level, relation-level, and meta-path-level signals to predict one of four classes: normal, source-chain attack, off-chain attack, or destination-chain attack.

This formulation is narrower than protocol verification and broader than transaction anomaly scoring on a single chain. It does not attempt to prove bridge correctness; instead, it classifies realized behavior after reconstructing the multi-layer path that connects source-chain events, off-chain evidence, and destination-chain consequences.

3. Cross-chain Behavior Heterogeneous Graph

For each cross-chain operation, BridgeShield constructs a Cross-chain Behavior Heterogeneous Graph, denoted $G=(V,E,\mathcal{T}_V,\mathcal{T}_E)$ (Lin et al., 28 Aug 2025). The graph integrates source-chain execution traces, off-chain relay or validator activity, and destination-chain execution into a shared representation.

Component	Types	Brief role
Node types $\mathcal{T}_V$	$U, R, T, O, L, D$	User, router contract, token contract, other account, log/event, relay/off-chain
Edge types $\mathcal{T}_E$	$E_t, E_c, E_e, E_x, E_a, E_d$	Transaction, function call, log record, transfer, authorization, cross-chain interaction

The node types are defined as follows. $U$ denotes user nodes, covering initiators on the source chain and recipients on the destination chain. $R$ denotes router contracts. $T$ denotes token contracts for lock, mint, and burn logic. $O$ denotes unmarked EOAs or contracts. $L$ denotes emitted on-chain events and their decoded function signature or parameters. $\mathcal{T}_V$0 denotes relayer, validator, or oracle nodes that link source and destination via off-chain proof or message passing. The edge types encode from-to transactions, caller-callee function calls, contract-to-log relations, asset transfers, token authorizations, and off-chain interactions between $\mathcal{T}_V$1 nodes and router contracts on both chains.

Feature construction is heterogeneous. Node degrees contribute in-degree and out-degree. Function and log nodes use textual features: function signatures and parameters are embedded by CodeBERT into 512-d vectors. For each node type $\mathcal{T}_V$2, original features $\mathcal{T}_V$3 are projected into a shared latent dimension by

$\mathcal{T}_V$4

with $\mathcal{T}_V$5. Relation-specific adjacency matrices $\mathcal{T}_V$6 and neighbor sets $\mathcal{T}_V$7 are maintained for every relation $\mathcal{T}_V$8.

The graph assembly follows the operational flow. On the source chain, the segment is $\mathcal{T}_V$9 with a lock event $U, R, T, O, L, D$0, while approvals and allowances $U, R, T, O, L, D$1 and transfers $U, R, T, O, L, D$2 are retained. In the off-chain segment, a relay, validator, or oracle node $U, R, T, O, L, D$3 consumes the source event and forwards a verified message, represented through $U, R, T, O, L, D$4 edges linking $U, R, T, O, L, D$5. On the destination chain, $U, R, T, O, L, D$6 performs mint or unlock, emits $U, R, T, O, L, D$7, and transfers $U, R, T, O, L, D$8 to a user $U, R, T, O, L, D$9. Source and destination records are aligned by decoding traces, events, and transfers, and by matching off-chain logs that reference source transaction hashes or event identifiers via $\mathcal{T}_E$0 nodes. Time windows are handled by assembling all records of a cross-chain operation across chains and relay messages, after which heterogeneous schemas are normalized through the type-specific projections.

4. Relation-aware message passing and hierarchical meta-path attentions

BridgeShield combines a heterogeneous graph attention mechanism with meta-path modeling tailored to cross-chain semantics (Lin et al., 28 Aug 2025). For a relation $\mathcal{T}_E$1 and an edge $\mathcal{T}_E$2, relation-specific projections $\mathcal{T}_E$3 and attention parameters $\mathcal{T}_E$4 are used: $\mathcal{T}_E$5

$\mathcal{T}_E$6

$\mathcal{T}_E$7

Multi-head attention may be used per relation, with heads concatenated before $\mathcal{T}_E$8.

The architecture then imposes higher-order cross-chain structure through meta-paths over node-type sequences. Examples include source-side transaction-to-router-to-token-to-log paths, end-to-end paths $\mathcal{T}_E$9, authorization-to-token-call patterns, and paths passing through unlabeled accounts that ultimately lead to events. The paper identifies $E_t, E_c, E_e, E_x, E_a, E_d$0, $E_t, E_c, E_e, E_x, E_a, E_d$1, and $E_t, E_c, E_e, E_x, E_a, E_d$2 as frequent in attack-labeled graphs, whereas $E_t, E_c, E_e, E_x, E_a, E_d$3 and $E_t, E_c, E_e, E_x, E_a, E_d$4 are frequent in normal-labeled graphs.

Intra-meta-path attention captures fine-grained dependencies within a given path type. For a meta-path $E_t, E_c, E_e, E_x, E_a, E_d$5 with path-instance embeddings $E_t, E_c, E_e, E_x, E_a, E_d$6,

$E_t, E_c, E_e, E_x, E_a, E_d$7

$E_t, E_c, E_e, E_x, E_a, E_d$8

The node-centric formulation in BridgeShield is

$E_t, E_c, E_e, E_x, E_a, E_d$9

$U$0

$U$1

A multi-head variant is also defined.

Inter-meta-path attention then scores and fuses different meta-path representations: $U$2

$U$3

In the graph-level pipeline, BridgeShield shares inter-meta-path parameters across meta-paths: $U$4

$U$5

A central design feature is that meta-paths crossing $U$6 nodes explicitly encode off-chain verification and relay behavior, thereby connecting source and destination semantics within the same learned representation. Differential meta-path extraction (DME) further filters meta-paths by label-discriminative frequency difference, with $U$7 reported as the best setting for F1.

5. Learning objective, pooling, and inference pipeline

BridgeShield performs graph-level multi-class classification with four labels: normal, source-chain attack, off-chain attack, and destination-chain attack (Lin et al., 28 Aug 2025). After node embedding and graph aggregation, the classifier produces softmax probabilities

$U$8

Class imbalance is handled with weighted cross-entropy: $U$9 Global graph aggregation is instantiated through three pooling variants: $R$0

$R$1

$R$2

Training uses five repetitions with 80/20 train-test splits and varying random seeds. Baselines use learning rate 0.01 and cross-entropy optimization, while BridgeShield learns the weighted loss, type-specific projections, and attention parameters end-to-end. At inference time, given a decoded cross-chain operation, the system builds its xBHG, runs inference, and emits an alert tagged with the predicted stage—source, off-chain, or destination. No threshold tuning is required because the output class is given directly by softmax argmax.

This pipeline is notable for operating at the level of a reconstructed cross-chain operation rather than on isolated transactions. The graph is the detection object, and the prediction is correspondingly a stage-localized interpretation of the operation’s anomalous component.

6. Dataset, baselines, and empirical results

The evaluation uses 51 real-world cross-chain attack events dated from June 2021 to December 2024, including two new cases: GemPad reentrancy at the destination chain and FEGtoken off-chain fake deposit validation (Lin et al., 28 Aug 2025). The dataset contains 21,105 normal operation graphs, 85 source-chain attack graphs, 45 off-chain attack graphs, and 30 destination-chain attack graphs. Each graph includes execution traces, events or logs, transfers, and authorizations on both chains, together with matched off-chain relayer, validator, or oracle messages through $R$3 nodes.

The baselines span homogeneous graph methods, heterogeneous graph methods, and bridge-specific detectors: GAT and Graph2vec; RGCN, HGT, and HEAT; and Xscope and BridgeGuard. Under the reported best configuration, which uses max pooling, BridgeShield attains an overall average across attack classes of Precision $R$4, Recall $R$5, and F1 $R$6. Xscope records Precision $R$7, Recall $R$8, and F1 $R$9. The resulting improvement is F1 $T$0 points and Recall $T$1 points (Lin et al., 28 Aug 2025).

Per class, BridgeShield reports the following. For source-chain attacks $T$2, Precision is $T$3, Recall $T$4, and F1 $T$5. For off-chain attacks $T$6, Precision is $T$7, Recall $T$8, and F1 $T$9. For destination-chain attacks $O$0, Precision is $O$1, Recall $O$2, and F1 $O$3. For normal graphs $O$4, Precision is $O$5, Recall $O$6, and F1 $O$7.

The reported reasons for the performance gap are architectural rather than purely representational. End-to-end modeling integrates source, off-chain, and destination behavior through $O$8 nodes and $O$9 edges; intra-meta-path attention emphasizes informative neighbors such as routers versus tokens; inter-meta-path attention fuses multiple workflows while suppressing noisy paths; and DME removes non-discriminative higher-order structures. Ablation studies report noticeable performance degradation when DME is removed and a significant drop when hierarchical attention is removed.

Configuration analysis further shows that $L$0 in DME, which keeps all meta-paths, increases recall but introduces noise, whereas $L$1 best balances precision and recall and maximizes F1. Pooling also matters under imbalance: average attack F1 is 92.58% with max pooling, 87.88% with mean pooling, and 78.03% with self-attention pooling.

The case studies illustrate how the attentional hierarchy localizes attack semantics. In the FEGtoken off-chain fake deposit case from 2024-12-29, BridgeShield selected DME meta-paths traversing $L$2 between $L$3 and $L$4, assigned higher inter-meta-path weights to cross-chain verification sequences, emphasized the off-chain $L$5 and destination router nodes through intra-meta-path attention, and produced an $L$6 alert. In the GemPad destination-chain reentrancy case from 2024-12-17, paths involving rapid repeated function calls and event emissions on destination token or LP contracts showed abnormal frequency, and attention concentrated on the call sequence yielding successive unlock or collect events, producing an $L$7 prediction.

7. Deployment characteristics, explainability, and limitations

BridgeShield is intended as a monitoring pipeline for decoded cross-chain operations rather than a protocol-embedded verifier (Lin et al., 28 Aug 2025). The data path is to decode and normalize source and destination EVM traces, events, transfers, and approvals; ingest off-chain relay, validator, or oracle logs; construct $L$8 edges linking matched source and destination operations through $L$9 nodes; and then perform graph inference. The framework can retain partially connected xBHGs when off-chain messages are delayed or missing and update them as new evidence arrives. Inference can therefore run incrementally to flag suspicious patterns early, including anomalous source-chain locks without valid downstream verification.

Explainability is built into the architecture. Inter-meta-path weights $\mathcal{T}_V$00 identify which cross-chain workflows were most discriminative, such as $\mathcal{T}_V$01-linked verification paths versus direct user-to-router-to-token flows. Intra-meta-path attention scores $\mathcal{T}_V$02 identify influential neighbors, such as routers, token contracts, or unlabeled $\mathcal{T}_V$03 accounts, for a given classification. Analysts can inspect the top-weighted meta-paths and edges to interpret alerts and trace root causes.

The practical complexity is nontrivial because meta-path enumeration grows combinatorially with path length and the number of node types. With six node types, the counts are 36 meta-paths of length 2, 216 of length 3, 1,296 of length 4, and 7,776 of length 5. BridgeShield therefore restricts the search to lengths 2–4 and applies DME with $\mathcal{T}_V$04 to control noise and cost. Relation-specific attentions scale with $\mathcal{T}_V$05, and xBHG size depends on decoded traces and matched off-chain messages.

The implementation assumptions delimit the method’s current scope. Full cross-chain reconstruction assumes accessible off-chain coordinator logs; missing or proprietary logs reduce visibility. The present implementation is EVM-centric, so non-EVM ecosystems such as Solana require new decoders and schema normalization. New bridge designs may also introduce novel entities and relations; the heterogeneous graph design is described as adaptable, but DME and attention components must be retrained. The open-source implementation is available at the repository reported by the paper, and the reported best configuration uses type-specific projections, relation-specific attention, DME with $\mathcal{T}_V$06, and max pooling.

In comparative terms, BridgeShield is positioned as complementary to formal verification and cryptographic proof systems such as light-client bridges and zk-proofs, which reduce protocol-level vulnerabilities but do not cover misconfigurations or off-chain operational failures in already deployed bridges. It is likewise contrasted with on-chain watchers and rule engines, which provide fast pattern checks but lack learned end-to-end semantics, and with single-chain graph mining systems, which surface local anomalies without incorporating off-chain and destination-chain behavior. Within that framing, BridgeShield’s defining contribution is the use of a unified heterogeneous execution graph together with hierarchical meta-path attentions to detect attacks whose semantics span multiple execution layers.