XIR: A Framework for Interoperability across Cross-Chain Protocols Based on a Verifiable Intermediate Representation Yushen Li
a,b
, Linpeng Jia
a,¡
, Jiaying Feng
a,c
, Ziliang Liao
a,c
and Yi Sun
a,b,c,d,e
a Institute of Computing Technology, Chinese Academy of Sciences, Beijing, 100190, China b Hangzhou Institute for Advanced Study, University of Chinese Academy of Sciences, Hangzhou, 310024, China c School of Computer Science and Technology, University of Chinese Academy of Sciences, Beijing, 100049, China d Beijing Advanced Innovation Center for Future Blockchain and Privacy Computing, Beihang University, Beijing, 100191, China
arXiv:2609.20010v1 [cs.CR] 17 Sep 2026
e Shandong Key Laboratory of Blockchain Finance, Shandong University of Finance and Economics, Jinan, 250014, China
ARTICLE INFO
ABSTRACT
Keywords: Blockchain Cross-chain Interoperability Reachability
Cross-chain protocols enable applications to exchange messages across blockchains. Under point-to-point configurations, communication depends on a direct connection between the source and destination blockchains, limiting blockchain reachability and requiring additional configurations to connect more blockchains. To quantify this problem, this paper analyzes approximately 25 million mainnet cross-chain transaction events collected from six protocols (Axelar, CCIP, Hyperlane, LayerZero, Relay, and Wormhole) between January and October 2025. The resulting graph covers 286 active blockchains and 11,935 directly connected ordered blockchain pairs. These connections provide a direct reachability of 14.64%, while full direct connectivity would require 81,510 point-to-point configurations. We present XIR, a framework for interoperability across cross-chain protocols based on a verifiable intermediate representation. This representation binds an application message to an ordered record of authenticated cross-chain protocol deliveries, preserving message identity and verification history across protocol boundaries. XIR Gateways and XIR Adapters use this representation to compose existing connections into same-protocol and cross-protocol multi-hop paths. We implement an XIR prototype integrating Hyperlane and LayerZero and evaluate it in local and public-testnet environments1 . Theoretical analysis and evaluation show that, with correctly configured cross-chain protocol connections, XIR avoids 67,018 additional point-to-point configurations, equivalent to 84.88% of the total required by a point-to-point configuration baseline serving the same reachable pairs, and increases reachability from 14.64% to 96.86% of all ordered blockchain pairs.
1. Introduction Blockchain applications increasingly use multiple networks to access assets, liquidity, computation, and users. Cross-chain protocols provide the communication layer between these networks. A source endpoint sends an application cross-chain message, a verification mechanism authenticates the source event, and a destination endpoint executes the requested operation [13, 37, 6]. Protocols use different trust models and endpoint interfaces [6]. Related approaches include zkBridge [34], cross-chain integrated execution [36], SightCVC [35], and MAP [8]. The point-to-point configuration model makes direct communication depend on an explicitly configured source–destination pair. LayerZero OApps [21] register a trusted peer for an endpoint identifier, Hyperlane routers [16] register remote domains, and other protocols register emitters [32], receivers, or equivalent endpoints [30]. For an application on blockchain A to reach blockchain C directly, this model requires an A → C configuration. Reusing existing A → B and B → C connections instead requires an intermediate ¡ Corresponding author.
handoff that preserves the application operation and the verification results from both deliveries. When the connections use different protocols, the handoff must also bridge their message formats and verifier interfaces. The extent of this opportunity appears in activity feeds from Axelar [4], CCIP [9], Hyperlane [14], LayerZero [20], Relay [27], and Wormhole [33]. After resolving network identities and retaining mainnet events between different blockchains, the January–October 2025 snapshot contains 24,983,410 events from 286 active blockchains. Its 15,965 protocol-labeled directed edges represent 11,935 directly connected ordered pairs, or 14.64% of the 286 İ 285 = 81,510 possible pairs. Full direct connectivity through one protocol would require 81,510 point-to-point configurations. Composing the observed connections offers a way to reach additional pairs through intermediate blockchains. IBC multi-hop channels [29] and xRoute [28] support path composition within IBC. Axelar General Message Passing [3] exposes a common messaging service, while service-mesh interoperability [19] coordinates cross-chain transactions through mesh services. The remaining problem is to combine existing direct
E-mail address: [email protected] (L. Jia). 1 XIR implementation: https://github.com/lysrain21/XIR.
Yushen Li et al.: Preprint submitted to Blockchain: Research and Applications
Page 1 of 19
Y. Li, L. Jia, J. Feng, Z. Liao and Y. Sun
protocol connections into same-protocol and crossprotocol paths while preserving verification and execution across protocol boundaries. Combining direct connections across protocol boundaries creates two research challenges. Challenge 1: verification continuity. Each protocol authenticates its own messages using a specific verifier configuration and evidence format. The final protocol authenticates the last delivery. Establishing the earlier verification history requires each preceding result to be bound to the same operation and path. For example, two individually valid receipts from different executions must be rejected when presented as one history. Challenge 2: execution continuity. Protocols use different message formats, endpoint identifiers, callbacks, and replay checks. A message that leaves one protocol must retain the same application identity, destination, path position, and replay identity when it enters the next protocol. To address these challenges, this paper proposes XIR, a framework that composes existing cross-chain protocol connections through a verifiable intermediate representation. This representation binds one application cross-chain message to an ordered record of authenticated protocol deliveries, preserving verification evidence across protocol boundaries. XIR comprises XIR Gateways that manage this record, XIR Adapters that connect protocol interfaces, an XIR Registry that stores configurations, and an XIR Router that selects paths. On the source blockchain, an XIR Gateway authenticates the application and creates the record. On each intermediate blockchain, an XIR Gateway verifies the incoming delivery and extends the record. On the destination blockchain, an XIR Gateway verifies the complete history before execution. These operations provide verification continuity (Challenge 1) by linking each delivery to the preceding history, and execution continuity (Challenge 2) by maintaining stable message identity across protocols. Under the stated assumptions, the analysis establishes source authorization, ordered evidence integrity, per-hop policy enforcement, and at-most-once delivery. With XIR Gateways and XIR Adapters at the required intermediate blockchains, same-protocol composition over the cumulative graph reaches 46,187 ordered pairs. Allowing protocol switches expands this set to 78,953 pairs, or 96.86% of the 81,510-pair maximum. Hyperlane has the largest same-protocol closure at 27,059 pairs (33.20%). Figure 1 shows how the two forms of composition expand reachability over the existing direct connections. Figure 2 next compares direct protocol configuration with XIR path composition from the application user’s perspective.
Blockchain: Research and Applications
Reproducing the 78,953-pair target with direct connections requires 78,953 point-to-point protocol configurations, including 67,018 configurations for pairs that are not directly connected in the measured graph. XIR composes the 15,965 existing protocol connections through one XIR Gateway placement on each of the 286 blockchains. The observed protocol coverage also contains 493 blockchain–protocol integrations, one for each protocol available on each blockchain. Point-topoint configurations, XIR Gateway deployments, and blockchain–protocol integrations are separate units. Section 5.2 reports these architecture counts separately and compares deployment cost in gas. The XIR prototype integrates Hyperlane and LayerZero, and its implementation is open source.2 It completes 40,000 local deliveries and 780 adversarial case-runs, with seven successful deliveries recorded on public testnets. A separate campaign of 22,000 executions measures the cost of verification history and multi-hop paths. Section 6 presents the experimental settings, cost models, and results. This paper develops a framework for composing cross-chain protocols while preserving message identity and verification history. Its main contributions are summarized as follows. • Verifiable intermediate representation. XIR binds the application cross-chain message to an ordered record of authenticated protocol deliveries, enabling the destination to verify evidence accumulated across protocol boundaries. Sections 3 and 4 define the representation and its verification procedure. • Protocol composition with explicit guarantees. XIR Gateways and XIR Adapters reuse configured connections for same-protocol and cross-protocol paths while preserving the application record. Section 5 establishes source authorization, ordered evidence integrity, per-hop policy enforcement, and at-most-once delivery under the stated assumptions. • Open-source implementation and evaluation. We developed an XIR prototype system based on the Go, integrated with Hyperlane and LayerZero cross-chain protocols. Based on an analysis of 25 million cross-chain transactions, we evaluated the reachability of XIR and validated its functionality and overhead. Experimental results show that XIR achieves 96.86% reachability on the cross-chain transaction graph. Compared with existing cross-chain protocols, XIR reduces the deployment overhead by 67,018 cross-chain contract pairs. Sections 5.2 and 6 present these results. 2 XIR implementation: https://github.com/lysrain21/XIR.
Yushen Li et al.: Preprint submitted to Blockchain: Research and Applications
Page 2 of 19
Y. Li, L. Jia, J. Feng, Z. Liao and Y. Sun
Blockchain: Research and Applications
Axelar · Direct 816 pairs (1.001%)
Axelar · Same-protocol 4,289 pairs (5.262%)
CCIP · Direct 26 pairs (0.03190%)
CCIP · Same-protocol 109 pairs (0.1337%)
Hyperlane · Direct 6,457 pairs (7.922%)
Hyperlane · Same-protocol 27,059 pairs (33.20%)
LayerZero · Direct 5,682 pairs (6.971%)
LayerZero · Same-protocol 19,740 pairs (24.22%)
Relay · Direct 2,325 pairs (2.852%)
Relay · Same-protocol 3,306 pairs (4.056%)
Wormhole · Direct 659 pairs (0.8085%)
Wormhole · Same-protocol 1,640 pairs (2.012%)
XIR closure · 15,965 protocol-labeled edges → 78,953 ordered pairs (96.86%) 11,935 direct → 46,187 same-protocol → 78,953 cross-protocol Axelar CCIP Hyperlane LayerZero Relay
Cross-protocol addition: 32,766
Same-protocol addition: 34,252
Same-protocol Direct
Wormhole Direct: 11,935 0
10
20
30
Reachability (%)
Figure 1: Reachability in the measured 286-blockchain graph. The 15,965 protocol-labeled directed edges connect 11,935 pairs directly. Same-protocol composition reaches 46,187 pairs, and cross-protocol composition reaches 78,953 pairs.
2. Background and Problem Formulation 2.1. Cross-Chain Protocols and Protocol Interoperability Blockchain interoperability allows different blockchains to exchange and use information [13, 6]. A cross-chain protocol provides three common functions:
a source endpoint emits an application cross-chain message, a verification mechanism authenticates the source event, and a relayer, executor, or solver submits the cross-chain message for execution at the destination [37, 11]. Table 1 maps these functions to the six protocols in the measured dataset and to XIR.
Yushen Li et al.: Preprint submitted to Blockchain: Research and Applications
Page 3 of 19
Y. Li, L. Jia, J. Feng, Z. Liao and Y. Sun
Blockchain: Research and Applications
Table 1 Cross-chain protocol functions and the corresponding XIR components. System
Message verification
Axelar [1]
Validator-authorized Gateway commands
CCIP v1.6 [10] Hyperlane [15] LayerZero [22] Relay [26] Wormhole [32] XIR
Delivery and execution
Endpoint configuration
Relayer submission and AxelarExecutable callback Oracle network running the Commit plu- Executing plugin, OffRamp, and receiver callgin back Recipient-selected Interchain Security Relayer calls Mailbox.process [17] Module Decentralized Verifier Networks and Mes- Executor, Endpoint, and lzReceive sage Library Oracle attestations of deposits and fills Solver fill and Hub settlement Guardian-signed [31] Verified Action Ap- Relayer submission and receiver execution proval Ordered verification evidence from cross- XIR Gateway forwarding and application exchain protocols ecution
(a) Direct cross-chain protocol
Chain, Gateway, and destination identifiers [2] Router, OnRamp/OffRamp, lane, and receiver [30] Domain and remote router [16]; hook and ISM [15] EID, peer, Message Library, DVN, and Executor [21] Depository, Hub, solver, and target action Trusted emitter, receiver, and consistency level [32] Existing protocol configurations, XIR Gateways, and XIR Adapters
configure protocol p for A → C protocol p
A
User
B
C
existing A → B Blockchain A
Blockchain B
(b) XIR over existing protocol connections
A
User
one request
Blockchain C
no new A → C protocol configuration
Blockchain A
B
Blockchain B
C
Blockchain C
p
p G_A XIR Gateway A
App C
existing B → C
G_B
G_C
XIR Gateway B
q
App C
XIR Gateway C
Protocol p
Protocol q
Figure 2: Cross-chain communication with and without XIR. Direct delivery requires an A → C protocol configuration. XIR carries the request over existing A → B and B → C connections, using the same protocol (p → p) or different protocols (p → q).
Protocol interoperability allows different crosschain protocols to carry one message along a pair-topair path. Here, pair-to-pair refers to communication from the source blockchain to the destination blockchain, including any intermediate hops. At an intermediate blockchain, an XIR Gateway receives a message through one XIR Adapter and sends the same application operation through another. This step is a handoff. A same-protocol handoff uses the same protocol for the incoming and outgoing connections. A protocol switch uses different protocols. XIR records the incoming and outgoing protocols at each handoff. Each connection retains its protocol endpoint, point-to-point configuration, and verifier. Figure 2 shows the interaction from the application user’s perspective. The application submits one request with a destination and a policy. Direct delivery requires an A → C protocol configuration. XIR instead selects existing A → B and B → C connections and returns the execution status from C. The two connections may use the same protocol or different protocols.
2.2. Reachability across Blockchains Reachability is a standard property of directed graphs: a vertex v is reachable from u if a directed path connects u to v [5]. Let G = .V, E, λ/ be a protocollabeled directed multigraph. Each vertex represents a blockchain, each edge represents an observed direct protocol connection, and λ.e/ Ë identifies the edge protocol. Let s.e/ and t.e/ denote the source and destination vertices of edge e. For protocol p, define Ep = ˆ.s.e/, t.e// Ý e Ë E á λ.e/ = p‘.
(1)
Let ∆V = ˆ.v, v/ Ý v Ë V ‘ be the set of self pairs. The direct, same-protocol, and cross-protocol reachability relations are Ep ⧵ ∆ V , direct = pË same = Ep+ ⧵ ∆V , pË
XIR = Yushen Li et al.: Preprint submitted to Blockchain: Research and Applications
+
pË
Ep
⧵ ∆V ,
(2) Page 4 of 19
Y. Li, L. Jia, J. Feng, Z. Liao and Y. Sun
Blockchain: Research and Applications
where .⊙/+ denotes transitive closure. The last relation describes composition over the cumulative observed graph, with XIR Gateways and XIR Adapters at the intermediate blockchains required by each path. For any relation containing only non-self ordered pairs, the reachability ratio is . ρ./ = V .V * 1/
(3)
For V = 286, the denominator is 286 İ 285 = 81,510. The observed relations give 11,935 = 14.64˜, 81,510 ρ.same / = 56.66˜, ρ.XIR / = 96.86˜.
ρ.direct / =
(4)
Same-protocol composition adds 34,252 pairs beyond direct connections. Protocol switches add another 32,766 pairs. These values describe potential reachability over connections observed during the ten-month window. Each edge records activity within that window, and composition assumes XIR Gateway and XIR Adapter coverage along the path. Temporal snapshots show how the result changes with the observation window: monthly protocol-switching reachability ranges from 46.4% to 65.7%, and the final rolling-90-day union reaches 74.2%. The cumulative reference is 96.9%. All three use the same 286blockchain population. Raising the minimum activity per directed protocol edge from one to 1,000 distinct events reduces the cumulative protocol-switching result from 78,953 to 18,913 pairs. These analyses describe the dependence of reachable paths on observation duration and edge activity. For N = V blockchains, direct connectivity requires one point-to-point protocol configuration for every ordered pair, or N .N * 1/ = O.N 2 / configurations. XIR uses one XIR Gateway deployment per blockchain, giving N = O.N / deployments. It also requires one integration for each incident blockchain–protocol pair. Let Vp be the set of blockchains incident to an edge labeled p. Then IXIR = pË Vp = O.N / integrations are required for a fixed protocol set. Applied to the measured graph, this architecture requires 286 XIR Gateway placements and 493 blockchain–protocol integrations. Section 5.2 reports these units separately and compares deployment gas.
2.3. Hop Count One hop is a directed cross-chain protocol connection between adjacent blockchains, consistent with the terminology of multi-hop IBC [29]. A path P = .v0 , e1 , v1 , ğ , eh , vh /
(5)
has h hops and h * 1 intermediate blockchains. Both p p p q A ←←→ ← B ←←→ ← C and A ←←→ ← B ←←→ ← C contain two hops. A protocol switch performed by an XIR Gateway at
an intermediate blockchain does not add a hop; it is counted separately. Hop count and protocol-switch count describe different path properties. Writing pi = λ.ei /, the number of protocol switches is c.P / = h 1[pi ≠ pi*1 ]. i=2
(6)
The first example has c.P / = 0, and the second has c.P / = 1. Experiments 2 and 3 use this distinction to separate the number of earlier protocol deliveries from the number of protocol switches. Among the 78,953 finite ordered pairs reached by cross-protocol composition in the measured graph, the shortest-path hop distribution is 11,935 at one hop (15.12%), 59,711 at two hops (75.63%), 7,186 at three hops (9.102%), and 121 at four hops (0.1533%). The cumulative percentages are 15.12%, 90.75%, 99.85%, and 100.0%. Nearest-rank P50 , P95 , and P99 are two, three, and three hops, respectively. The directed diameter over these finite pairs is four hops and is attained by 121 ordered pairs; the other 2,557 ordered pairs are unreachable. Figure 3 shows the cumulative distribution. Paths of one to four hops span the complete crossprotocol shortest-path range. Individual same-protocol closures can contain longer paths: CCIP has nine reachable pairs whose shortest same-protocol path has five hops. The concentration at two hops motivates the threeblockchain topology in Experiment 1, and the cross-protocol range motivates the path lengths in Experiment 3. Existing same-protocol systems also reuse connections through path composition. IBC ICS-033 [29] chains proofs across existing IBC connections, and xRoute [28] adds policy-aware selection to IBC routes. Axelar [3] exposes a common messaging interface across its supported networks, while service-mesh work [19] coordinates cross-chain transactions through mesh services. XIR composes direct protocol connections across protocol domains and carries the accepted evidence into a single destination decision.
2.4. The Verification Problem Cross-chain protocols authenticate messages through different authorities and evidence formats, including validator committees, light clients, oracle networks, configurable verifier sets, and signed attestations [37, 25]. A one-hop destination observes the evidence authenticated by its protocol endpoint. A cross-protocol path adds an intermediate handoff whose inbound verifier belongs to another protocol. The destination must bind every receipt to the same application operation and ordered path. It must also bind each receipt to the protocol verification result, the selected verifier configuration, and the next handoff. The binding covers the payload and replay identity. Analyses of bridge failures show the importance of
Yushen Li et al.: Preprint submitted to Blockchain: Research and Applications
Page 5 of 19
Y. Li, L. Jia, J. Feng, Z. Liao and Y. Sun
endpoint authentication, configuration integrity, and inherited trust assumptions [23, 38]. Related work also addresses atomic asset exchange and transaction scheduling. Chuchu [39] coordinates cross-chain swap completion and refunds through asset locking state transitions and linked hashlock groups. Concordia [24] shares predicted account-access signals among shards to guide transaction packing and reduce conflicts in a sharded blockchain. Systems that strengthen verification improve one protocol boundary. zkBridge [34] proves remote consensus state, while CAVer [12] uses cross-chain-specific accumulators to reduce message-proof size and destination verification overhead. XIR records the verification evidence accepted from each protocol, links the evidence in path order, and authenticates the complete record at the destination. This representation supports cross-protocol multi-hop execution while preserving the verifier of each protocol connection. The task is to compose existing protocol connections while maintaining verification continuity and execution continuity. The former binds the verifier sequence and its configuration. The latter binds the stable application operation, payload, path state, and replay identity. Sections 3 and 4 introduce the XIR components and protocol steps that realize these properties.
3. System Model XIR combines existing direct protocol connections while preserving one application operation and its verified execution history. The running example is p q A ←←→ ← B ←←→ ← C, where protocols p and q have active endpoints and point-to-point configurations, as in Hyperlane routers [16] and LayerZero OApps [21].
3.1. Entities, Roles, and State An application submits a cross-chain message, destination, and security requirement to a source XIR Gateway. An XIR Gateway connects an application to XIR on one blockchain. The source XIR Gateway authenticates the caller and creates the XIR operation. An intermediate XIR Gateway verifies one protocol delivery and starts the next. The destination XIR Gateway verifies the complete path before invoking the receiver. The XIR Router reads the XIR Registry and returns an admissible path. The XIR Registry stores protocol endpoints, point-to-point configurations, XIR Adapters, verification profiles, validity windows, security levels, and approved incoming XIR Adapters. An XIR Adapter connects XIR to one cross-chain protocol. Its incoming side records an authenticated protocol callback. Its outgoing side verifies that record before sending the next message. Relayers submit messages, and a root signer certifies a finalized source event.
Blockchain: Research and Applications
The XIR Registry maintains versioned configuration. XIR Adapters store accepted evidence and approved prior verifiers. XIR Gateways maintain application nonces and consumed message identifiers. Route selection does not change this state. Message acceptance uses the on-chain configuration and authenticated XIR Adapter state. Figure 4 summarizes how these components execute one request. The source creates one application record, the XIR Router selects configured protocol connections, each protocol verifies its own delivery, and the destination verifies the ordered record before invoking the application.
3.2. Records, Identifiers, and Path Execution XIR carries the following verifiable intermediate representation (V-IR): X = R, ctx, cert, [C1 , ğ , Ch ],
(7)
The application record R identifies the operation, and ctx carries its security requirement and policy commitment. The certificate cert authorizes the source record. Each receipt Ci identifies an authenticated delivery over protocol connection i. The source also derives a root identifier rid and a message identifier mid: the former binds the authorized record, and the latter identifies its destination execution. Section 4 defines these encodings. ph p1 A path is a directed sequence v0 ←←←←←→ ← vh in ← v1 ▽ ←←←←←→ the XIR Registry view. Each edge contributes one hop. A protocol switch occurs when pi ≠ pi+1 . The handoff at the intermediate XIR Gateway does not add a hop. Verified evidence from connection i produces Ci and extends a commitment to the path history. The XIR Gateway then uses an XIR Adapter to continue through the same protocol or switch to another protocol.
3.3. Adversary, Trust, and Required Properties An adversary controlling a submitter or the communication network may delay, duplicate, reorder, or alter unauthenticated inputs; replay a completed request; splice evidence from another execution; or present an expired profile. The destination accepts a message only when its application record is authorized and every protocol delivery satisfies the selected policy. The analysis uses four assumptions. A1, protocoldelivery soundness: an authenticated protocol callback binds its endpoint, remote XIR Adapter, message, and evidence identifier. A2, XIR-component soundness: XIR Gateways, XIR Adapters, and the root signer execute the specified checks. A3, configuration authenticity: the XIR Registry contains the intended roots, profiles, XIR Adapters, endpoint configurations, validity windows, and approved incoming XIR Adapters. A4, cryptographic binding: canonical
Yushen Li et al.: Preprint submitted to Blockchain: Research and Applications
Page 6 of 19
Y. Li, L. Jia, J. Feng, Z. Liao and Y. Sun
encodings are injective, domain-separated hashes resist collisions, and root signatures resist forgery. Under A1–A4, destination acceptance provides four properties. G1, source authorization: the accepted record and context match the certified source root. G2, ordered evidence integrity: the receipt sequence is endpoint-continuous and bound to one final protocol delivery. G3, policy enforcement: every receipt resolves to an active profile whose security level meets ctx. G4, at-most-once delivery: one message identifier commits at most one destination effect. Section 5 establishes them under A1–A4. Combining protocol connections raises the two challenges introduced in Section 1. Verification continuity requires separate protocol callbacks to form one ordered history that the destination can verify. The callback for the last connection authenticates the final delivery. XIR carries earlier verification results forward by linking one receipt to each accepted delivery and binding the complete sequence to that final message. Execution continuity requires one application operation to retain its identity across different protocol formats and callbacks. XIR keeps R, ctx, rid, and mid stable while XIR Gateways and XIR Adapters perform each handoff.
3.4. Pair-to-Pair Workflow Algorithm 1 details the workflow in Figure 4. The inputs vsrc and vdst identify the source and destination blockchains, adst identifies the destination application, m is the message payload, and π specifies the security policy. The source XIR Gateway authenticates the caller and creates R, storing adst as R.destinationApp. The XIR Router returns a path P = .v0 , e1 , ğ , eh , vh / and its verification profiles Φ = .Φ1 , ğ , Φh /. Here, Gi is the registered XIR Gateway on blockchain vi . Let Ti = [C1 , ğ , Ci ] denote the history after i deliveries. The algorithm maintains this list in T and its commitment qi in pref ix, starting with T0 = [ ] and q0 . Each iteration represents an asynchronous protocol delivery and its authenticated reception. Route selection uses one XIR Registry view; each on-chain step checks the configuration available when it executes. A failed assertion aborts the current operation. The final consume-and-invoke step is atomic within the destination transaction. The ordered verification records and final commitment provide verification continuity. Stable operation identifiers, approved incoming XIR Adapters, and XIR Adapters provide execution continuity. Section 4 defines these operations in execution order.
4. XIR Design XIR binds each protocol delivery to one application operation and its source-certified XIR Registry version. XIR Gateways check profile activity and approved XIR Adapters against the configuration available when they
Blockchain: Research and Applications
Algorithm 1 XIR path composition and delivery Input: source blockchain vsrc , destination blockchain vdst , destination application adst , payload m, policy π Output: execution result on successful completion 1: .R, ctx, rid, mid/ ← CreateRecord.vsrc , vdst , adst , m, π/ 2: cert ← CertifyFinalizedRoot.rid/ 3: .P, Φ/ ← ResolvePath.vsrc , vdst , ctx/ 4: assert P ≠ É 5: h ← P.edges 6: .G0 , ğ , Gh / ← ResolveGateways.P / 7: T ← [ ] 8: pref ix ← H.XIR_ROOT_V1 SS rid/ 9: for i ← 1 to h do 10: ei ← P.edges[i] 11: assert ValidProfile(Φi , Gi*1 , Gi , ctx) 12: body ← EncodeMessage.R, ctx, cert, T, pref ix/ 13: evidencei ← ExecuteProtocolConnection.ei , body/ ▷ At the receiving XIR Adapter on Gi ’s blockchain 14: acceptedi ← Authenticate.ei , evidencei / 15: assert acceptedi 16: Ci ← MakeReceipt.ei , evidencei , pref ix, R, ctx/ 17: assert Ci .srcGateway = Gi*1 á Ci .dstGateway = Gi 18: RecordAcceptedEvidence(Ci , acceptedi ) 19: T ← T [Ci ] 20: pref ix ← ExtendPrefix.pref ix, Ci / 21: if i < h then 22: assert ApprovedIngress(T, P.edges[i + 1], Φi+1 ) 23: end if 24: end for ▷ At the destination XIR Gateway Gh 25: assert VerifySource(R, ctx, rid, mid, cert) 26: assert VerifyOrderedReceipts(T, pref ix, R, ctx) 27: assert VerifyFinalBundle(T, Gh ) 28: assert Żconsumed[mid] 29: return AtomicConsumeAndInvoke( mid, R.destinationApp, m)
execute. This section follows the execution order: source initialization, protocol sends, XIR Gateway handoffs, and destination execution. Figure 5 shows the complete lifecycle. The upper part shows the protocol path. The middle part shows how the application record gains one verified delivery record at each blockchain. The lower part shows the checks performed by the destination.
4.1. Route and Representation Initialization The source XIR Gateway authenticates the application and creates R = sourceGateway, sourceApp, destinationApp, nonce, payloadHash, ctx = requiredSecurity, policyHash. (8) XIR Gateway and application identifiers are typed pairs kind, value. The XIR Gateway increments a percaller nonce; the payload determines payloadHash. Two stable identifiers connect source authorization to destination execution. The root identifier binds the record, context, and XIR Registry version; the message identifier binds that root to the destination application.
Yushen Li et al.: Preprint submitted to Blockchain: Research and Applications
Page 7 of 19
Y. Li, L. Jia, J. Feng, Z. Liao and Y. Sun
Blockchain: Research and Applications
Domain-separated hashes distinguish these uses:
4.3. XIR Gateway Handoff and XIR Adapter Conversion
dR = H.XIR_RECORD_V1 SS Encode.R//,
At an intermediate XIR Gateway, the incoming XIR Adapter passes the accepted receipt and accumulated p p rid = H.XIR_RID_V1 SS sourceGateway V-IR state to the outgoing XIR Adapter. For A ←←→ ← B ←←→ ← p q C, both XIR Adapters integrate p. For A ←←→ ← B ←←→ ← C, SS dR SS dctx SS registryV ersion/, the inbound XIR Adapter integrates p and the outgoing mid = H.XIR_MID_V1 SS rid SS destinationApp/. XIR Adapter integrates q. In both cases, R, ctx, rid, (9) and mid remain unchanged. The outgoing XIR Adapter changes only the protocol encoding and endpoint used The root signer validates the finalized RootCreated for the next connection. event and signs rid; the certificate cert carries the An outgoing XIR Adapter must establish which incorresponding XIR Registry version. coming XIR Adapter accepted the preceding evidence. For each direct protocol connection, the XIR RegThe XIR Registry records the XIR Adapter that verifies istry resolves a verification profile each profile, and the outgoing XIR Adapter enforces Φi = srcHash, dstHash, adapter, securityLevel, this binding through its approved verifier mapping. (10) validAf ter, validU ntil, enabled. The outgoing XIR Adapter receives a ForwardRequest containing the V-IR state and its verifier, profile, The XIR Registry administrator assigns security levels evidence, and transition arrays. For each preceding on the policy’s ordered scale. A profile is eligible when receipt Ci , the incoming XIR Adapter ain must satisfy its endpoint hashes match the edge, it is enabled within its validity window, and approvedPriorVerifiers[Ci .prof ileHash] Φi .securityLevel ≥ ctx.requiredSecurity. (11) = ain , dctx = H.XIR_CONTEXT_V1 SS Encode.ctx//,
The XIR Router selects eligible protocol connections and XIR Adapters in path order; XIR Gateways enforce the corresponding XIR Registry entries during execution.
4.2. Cross-Chain Protocol Send and Evidence Acceptance Before protocol connection i, the outgoing XIR Adapter encodes the V-IR state for protocol pi . The protocol endpoint sends this state over the configured direct connection. The incoming XIR Adapter receives the message through an authenticated protocol callback, such as a Hyperlane Mailbox callback [17] or a LayerZero endpoint callback [21]. The incoming XIR Adapter records enough information to associate the accepted delivery with its endpoints, verifier profile, and application operation. This information forms one hop receipt: Ci = srcGateway, dstGateway, prof ileHash, evidenceHash, transitionHash, priorP ref ix. (12) The protocol message digest or GUID supplies evidenceHash; profileHash identifies Φi ; and transitionHash binds dR , dctx , and adjacent XIR Gateways. The XIR Adapter records κi = H.Ci .prof ileHash, Ci .evidenceHash, Ci .transitionHash/
(13)
in acceptedEvidence. This entry identifies the authenticated protocol callback used by Ci .
(14)
ain .verify.Ci .prof ileHash, Ci .evidenceHash, Ci .transitionHash/ = true.
The next protocol send can extend the operation only from an incoming XIR Adapter that is approved by the XIR Registry and recorded the preceding evidence. The receipt chain binds each new delivery to the history already accepted. Its initial commitment starts at q0 = H.XIR_ROOT_V1 SS rid/ and advances as qi = H.XIR_PREFIX_V1 SS qi*1 SS H.XIR_HOP_V1 SS Encode.Ci ///.
(15)
The priorPrefix field in Ci must equal qi*1 , and the destination XIR Gateway in Ci must equal the source XIR Gateway in Ci+1 . Every handoff preserves two invariants: the application identity remains stable, and the accepted evidence extends exactly one ordered history. The final delivery must authenticate the same receipt sequence that the destination checks. This binding prevents accepted evidence from separate executions from being combined into a new history. On the final hop, the destination XIR Adapter authenticates the ordered evidence tuples through bh = BundleCommit.C1 , ğ , Ch /.
(16)
Here, BundleCommit binds the list length and each indexed .prof ileHash, evidenceHash, transitionHash/ tuple in receipt order. The prefix commits to receipt order, while bh binds that order to the final protocol delivery.
Yushen Li et al.: Preprint submitted to Blockchain: Research and Applications
Page 8 of 19
Y. Li, L. Jia, J. Feng, Z. Liao and Y. Sun
4.4. Destination Verification, Replay Protection, and Execution The destination XIR Gateway first recomputes the payload hash, rid, and mid and verifies the source certificate. It scans the receipts in path order and, for each Ci , checks endpoint continuity, priorPrefix, the transition binding, profile activity, Eq. (11), and the exact accepted-evidence tuple in XIR Adapter state. It then requires the final XIR Gateway identity and the locally recomputed bh to match the values authenticated by the destination XIR Adapter. After these checks succeed, the XIR Gateway rejects an existing consumed entry for mid, marks mid as consumed, and invokes xirReceive. If the receiver call fails, the XIR Gateway reverts the transaction; EVM reversion rolls back the associated state changes [7]. A committed delivery retains the consumed marker and one destination application effect. These operations establish G1–G4 in the order defined in Section 3.3.
5. Analysis This section proves the destination properties defined in Section 3, analyzes how path information grows, and evaluates configuration and deployment cost.
5.1. Correctness under A1–A4 An accepted delivery is a transaction in which the destination XIR Gateway completes every check in Section 4, consumes mid, and commits the receiver invocation. Lemma 1 (Prefix and bundle invariant). After the destination verifies receipt Ci , the prefix commits exactly to [C1 , ğ , Ci ], adjacent receipt endpoints are continuous, and the bundle accumulator commits to the evidence tuples of the same length. Proof. For i = 0, q0 commits to the certified rid, and both the receipt list and the evidence list are empty. Assume the invariant holds after Ci*1 . Verification of Ci checks Ci .priorP ref ix = qi*1 , the source and destination XIR Gateways, the registered profile and XIR Adapter, the transition hash, and the accepted evidence tuple. At a handoff, the XIR Adapter approval check binds that tuple to the incoming XIR Adapter. Equations (15) and (16) then add the same receipt and evidence tuple to the two commitments. Collision resistance preserves their contents and order, so the invariant holds after Ci . Induction gives the result for all h receipts. Theorem 1 (Conditional XIR delivery). If an XIR destination commits delivery under A1–A4, then G1 source authorization, G2 ordered evidence integrity, G3 per-hop policy enforcement, and G4 at-most-once delivery hold.
Blockchain: Research and Applications
Proof. Root verification recomputes dR , dctx , rid, and mid from the accepted record and validates the registered source signer. Under A2–A4, these checks establish G1. By Lemma 1, the prefix and bundle commitments contain one endpoint-continuous sequence of authenticated protocol deliveries. The destination also verifies the final XIR Adapter and bundle, establishing G2 under A1–A4. Each receipt resolves to an enabled profile in its validity window, names the receipt endpoints, and satisfies Eq. (11); these checks establish G3 under A3. Finally, the XIR Gateway rejects an existing consumed[mid] entry, sets the entry, and invokes the receiver in one transaction. A failed invocation reverts the state update under EVM semantics [7]; after a committed invocation, the consumed entry rejects every later use of mid. These steps establish G4 under A2. A1 defines accepted protocol evidence, A2 covers XIR Gateway and XIR Adapter execution, A3 authenticates profiles and ingress, and A4 binds identifiers, prefixes, signatures, and bundles. Section 6.2 exercises 780 malformed or replayed executions against these checks.
5.2. Cost Analysis 5.2.1. Path Information and Verification Work Let h be the number of cross-chain protocol connections in a path P , s = c.P / the number of protocol switches, and k the number of earlier deliveries recorded at one handoff. By definition, 0 ≤ s ≤ h * 1. A ForwardRequest carries variable-length arrays of fixedsize entries for the prior verifier, profile, evidence, and transition values. Let B0 be the fixed message size in bytes and BC the bytes per prior receipt. Verification work W assumes a fixed amount of work per receipt. The information and verification work at one handoff are Bhandoff .k/ = B0 + kBC = Θ.k/,
(17)
Whandoff .k/ = Θ.k/.
The final receipt list Th contains h receipts, and the destination scans them once: Th = h,
Wdestination .h/ = Θ.h/.
(18)
The current encoder retransmits the complete path history on every later connection. Total XIR information carried across all connections is Broute .h/ = h B0 + .i * 1/BC / = O.h2 /. i=1
(19)
Experiment 2 measures the local cost of one more earlier delivery at a fixed final handoff. Experiment 3 measures the contribution of a protocol switch to the complete path while controlling for h and the starting protocol. Equations (18) and (19) separate destination verification from repeated transmission of the path history.
Yushen Li et al.: Preprint submitted to Blockchain: Research and Applications
Page 9 of 19
Y. Li, L. Jia, J. Feng, Z. Liao and Y. Sun
Blockchain: Research and Applications
5.2.2. Reachability Provisioning Let ¡ be a target set of reachable ordered blockchain pairs. A direct-connectivity baseline creates one point-to-point protocol configuration for each pair in ¡ . Full directed coverage over N blockchains requires Dpair = N .N * 1/ = O.N 2 /.
(20)
For N = 286, this expression gives 81,510 pointto-point protocol configurations. The cross-protocol closure in Eq. (4) contains 78,953 ordered pairs (96.86% of full directed coverage). Matching that target with direct connections requires 78,953 configurations. Of these, 67,018 establish pairs that are not directly connected in the measured graph. XIR forms these paths from the existing connections and adds no direct pointto-point configuration between the newly reachable blockchain pairs. The XIR architecture has two separate deployment units. It places one XIR Gateway on each participating blockchain and adds one integration for every protocol attached to that blockchain: GXIR = N,
IXIR =
pË
Vp .
(21)
For a fixed protocol set, IXIR ≤ N . XIR Gateway deployments and protocol integrations therefore each grow as O.N /. In the measured graph, GXIR = 286 and IXIR = 493. These components combine 15,965 existing protocol-labeled directed connections into 78,953 reachable ordered pairs. Every path uses XIR Gateways, XIR Adapters, accepted application paths, and correctly configured protocol connections.
5.2.3. Measured Deployment Units Deployment gas provides one common cost unit for the measured contracts. Figure 6 organizes the deployment counts and measured per-blockchain costs. The calculations below distinguish XIR core contracts, protocol stacks, XIR Adapters, and endpoint configuration. One XIRGateway and one XIRRegistry consume 2,134,905 gas. Across 286 blockchains, the XIR core total is 610,582,830 gas. The measured Hyperlane [17] and LayerZero [22] protocol stacks consume 5,529,809 and 27,881,442 gas per blockchain. Their observed coverage gaps are 118 and 144 blockchains, giving modeled expansion totals of 652,517,462 and 4,014,927,648 gas. These extrapolations describe the core and protocolstack deployment components under their respective coverage assumptions. A complete reachability deployment also includes XIR Adapters and endpoint configuration. Measured XIR Adapters for Hyperlane and LayerZero add 1,750,897 and 1,899,585 gas, respectively, outside the 286-blockchain XIR core total. In the configuration benchmark, 100 first writes to unique remote identifiers yield median costs of 95,894 gas
for Router.enrollRemoteRouter [16] and 47,387 gas for OAppCore.setPeer [21]. The local path-isolation matrix records 125,583,834 gas across 79 contract deployments and 137,989,270 gas across 264 deployment and configuration transactions. The measurements use three- and five-blockchain deployments with protocolspecific XIR Adapters; the 286-blockchain totals apply these units to Eq. (21). Section 6 next measures path-dependent execution cost.
6. Implementation and Evaluation The evaluation addresses three questions. Q1: Can XIR deliver messages over same-protocol and crossprotocol paths while enforcing its verification checks? Q2: How do earlier same-protocol deliveries change the cost of one fixed final protocol switch? Q3: How do path length and the number of protocol switches affect total execution cost?
6.1. Prototype and Experimental Setup The prototype includes Solidity XIR Gateways, an XIR Registry, XIR Adapters for Hyperlane [17] and LayerZero [21], destination applications, and a stateful Python orchestrator. The implementation computes the same hashes in Solidity, Python, and Rust and connects to Hyperlane Mailbox callbacks [17] and LayerZero endpoint callbacks [21]. The artifact contains contract sources, deployment configurations, protocolmessage records, generated aggregates, and analysis scripts. The controlled environment has three or five blockchains running Besu QBFT [18], with four validators each. Every blockchain runs XIR, Hyperlane, and LayerZero stacks. The Hyperlane stack contains a Mailbox, MerkleTreeHook, MessageIdMultisigIsm, validator, and relayer; the LayerZero stack contains EndpointV2, SendUln302, ReceiveUln302, DVN, Executor, fee library, price feed, and treasury. The public-testnet executions use OP Sepolia, Arbitrum Sepolia, Base Sepolia, and Solana Devnet. Figure 7 maps the experiments to these environments. The toolchain uses Solidity 0.8.28, Foundry 1.5.1, Python 3.13.11, Node.js 24.11.1, Hyperlane Core 11.3.1, Hyperlane SDK 36.0.0, and LayerZero V2 3.0.168. The workloads fix the path, payload schedule, and concurrency limit. Each successful request must have a unique nonce, records for every protocol message, and exactly one destination effect. The Experiment 2/3 campaign contains 22,000 completed executions: 2,000 for each of 11 protocol paths. Experiment 2 uses three matched path groups, and Experiment 3 uses eight principal paths. The measured graph has directed diameter four among finite reachable pairs (Section 2.3); Experiment 3 covers all four path lengths, while Experiment 2 varies the number of earlier deliveries before a fixed final switch.
Yushen Li et al.: Preprint submitted to Blockchain: Research and Applications
Page 10 of 19
Y. Li, L. Jia, J. Feng, Z. Liao and Y. Sun
Blockchain: Research and Applications
Table 2 Experimental settings and workloads. Settings are grouped by the experiment to which they apply. The Experiment 1 delivery settings follow its frozen profile; the adversarial workload is evaluated separately. Scope
Setting
Value
Local experiments
Consensus and protocols
Besu QBFT; four consensus validators per blockchain; Hyperlane and LayerZero
Experiment 1 Delivery
Blockchains and paths
Three blockchains; native HH and LL; XIR cross-protocol HL and LH
Requests and payload
10,000 requests per path; application payloads of 32, 64, 96, and 128 bytes Zero warm-up requests; retries excluded from the designated request denominator MessageIdMultisigIsm; one validator per origin, threshold one; one relayer One required DVN, zero optional DVNs, one Executor; one source confirmation; self-hosted research worker
Warm-up and retries Hyperlane verification LayerZero verification Experiment 2
Blockchains and paths Matched workload Latency equivalence
Experiment 3
Adversarial workload
Blockchains and paths Workload and factors
Five blockchains; HL, HHL, HHHL; one to three earlier deliveries before the final switch 2,000 requests per path, matched by route sequence Margin of ,0.5 seconds per earlier delivery; 90% confidence intervals
Cost-model intervals
Five blockchains; H, HH, HHH, HHHH, HL, HLH, HLHL, LHLH 2,000 requests per path; one to four protocol connections, zero to three protocol switches 95% confidence intervals for regression coefficients
Cases and repetitions
13 classes; HL and LH; 30 repetitions per class and direction
Table 2 summarizes the controlled workloads. H denotes Hyperlane and L denotes LayerZero. In Experiment 1, HH and LL use native same-protocol forwarding; HL and LH use XIR for the protocol handoff. Protocol verification roles are separate from the four QBFT consensus validators on each blockchain. Figure 8 summarizes the cost and latency measurements in Experiments 2 and 3. Experiment 1 is reported directly in Section 6.2.
6.2. Experiment 1: Pair-to-Pair Feasibility Experiment 1 varies the protocols used by a twohop path and measures delivery, single destination effects, receipt order, and rejection checks. The threeblockchain environment executes two same-protocol paths, HH (Hyperlane–Hyperlane) and LL (LayerZero– LayerZero), and two cross-protocol paths, HL and LH. Each path carries 10,000 requests under one schedule. A conformance workload runs 13 adversarial classes in both cross-protocol directions, with 30 repetitions per class and direction. All 40,000 local requests complete with exactly one destination effect. Every cross-protocol request records the verification result of both protocol deliveries and the protocol switch. Across 20,000 records, the source XIR Gateway step averages 49,370.9 gas and 596 calldata bytes; across 20,000 records, the protocolswitch step averages 136,508.7 gas and 1,812 bytes.
The 780 adversarial case-runs exhibit the expected rejection behavior for payload, context, profile, trace, evidence, bundle, approved-ingress, and replay checks. Rejected submissions leave consumption and application state unchanged; replay cases retain the initial application effect and reject duplicate execution. The public-testnet ledger contains eleven attempts: seven delivered and four encountered protocol failures. The seven deliveries comprise one Hyperlane EVM path, three Hyperlane-to-LayerZero EVM paths, and three Hyperlane-to-LayerZero EVM-to-Solana paths. Table 3 gives the destination transaction or signature for every successful execution. Together, the local delivery workload, adversarial cases, and selected public-testnet paths establish execution feasibility and conformance to the implemented verification checks.
6.3. Experiment 2: Local Cost at the Final Protocol Switch Experiment 2 measures the local cost of earlier deliveries at one fixed final protocol switch. The independent variable is the number of earlier sameprotocol deliveries, k Ë ˆ1, 2, 3‘. The corresponding paths are HL, HHL, and HHHL. Each delivery adds one verification record to the XIR message. The dependent variables are gas, calldata, and handoff latency. The incoming XIR Adapter lookup, evidence query, bundle update, and outgoing protocol send remain fixed. The
Yushen Li et al.: Preprint submitted to Blockchain: Research and Applications
Page 11 of 19
Y. Li, L. Jia, J. Feng, Z. Liao and Y. Sun
Blockchain: Research and Applications
Table 3 Successful public-testnet executions. Each link resolves to the complete destination transaction or Solana signature. Blockchain path
Protocol path
Terminal network
Outcome
Transaction or signature
OP Sepolia → Arbitrum Sepolia OP Sepolia → Arbitrum Sepolia → Base Sepolia OP Sepolia → Arbitrum Sepolia → Base Sepolia OP Sepolia → Arbitrum Sepolia → Base Sepolia OP Sepolia → Arbitrum Sepolia → Solana Devnet OP Sepolia → Arbitrum Sepolia → Solana Devnet OP Sepolia → Arbitrum Sepolia → Solana Devnet
Hyperlane Hyperlane → LayerZero Hyperlane → LayerZero Hyperlane → LayerZero Hyperlane → LayerZero Hyperlane → LayerZero Hyperlane → LayerZero
Arbitrum Sepolia Base Sepolia Base Sepolia Base Sepolia Solana Devnet Solana Devnet Solana Devnet
Delivered Delivered Delivered Delivered Delivered Delivered Delivered
0x8ba2...0497 0x23e7...b1b5 0x1e86...2074 0xd54c...736e 2Ed9...j5KBc 5bUV...UBeUQ 58JF...mujvu2
matched sample contains 6,000 handoff observations, with 2,000 observations for each number of earlier deliveries. One more earlier delivery adds exactly 480 calldata bytes and approximately 32,791 gas (90% CI: 32,791– 32,792) to the final handoff. The handoff-latency slope is *0.0083 seconds per earlier delivery, with a 90% interval of [*0.0122, *0.0043] seconds; it lies within the prespecified ,0.5-second equivalence margin. Each earlier delivery therefore adds a fixed amount of history and verification work at the final handoff. Across the three measured history lengths, gas and calldata grow linearly, while the latency slope remains within the prespecified equivalence margin.
Figure 8(c) separates cross-chain protocol delivery from XIR processing. A Hyperlane delivery has a median latency of 4.015 seconds, and a LayerZero delivery has a median latency of 3.175 seconds. The XIR protocol-switch and destination-verification stages have median latencies of 0.826 and 0.780 seconds. The complete path has a median latency of 15.987 seconds.
6.4. Experiment 3: Pair-to-Pair Cost of Protocol Switches Experiment 3 measures how each protocol switch contributes to total path cost. The five-blockchain deployment evaluates H, HH, HHH, HHHH, HL, HLH, HLHL, and LHLH. These eight paths span h Ë ˆ1, 2, 3, 4‘ hops and s Ë ˆ0, 1, 2, 3‘ protocol switches. Each path has 2,000 executions, for 16,000 observations in total. For each path-level dependent variable Y , the additive model is Y = β0 + βh h + βs s + βL 𝟙[starts with L] + ϵ. (22) The predictors are h, s, and the starting protocol. One additional protocol connection contributes 344,658 gas (95% CI: 344,548–344,767) and 2,130 calldata bytes. For paths of the same length and starting protocol, one additional protocol switch contributes 312,075 gas (95% CI: 311,973–312,177) and 2,887 calldata bytes. The gas and calldata models explain the observed variation with R2 = 0.996 and R2 = 0.997, respectively. This coefficient includes coordination and verification across the complete path. Experiment 2 instead measures one more earlier delivery at a fixed handoff. Across the measured one-to-four-hop paths, total gas and calldata are approximately additive in path length and protocolswitch count. The complete-history encoding still incurs the quadratic aggregate transmission term derived in Eq. (19); the fitted coefficients describe the evaluated path lengths and protocol combinations. Yushen Li et al.: Preprint submitted to Blockchain: Research and Applications
Page 12 of 19
Reachable pairs (%)
Y. Li, L. Jia, J. Feng, Z. Liao and Y. Sun
Blockchain: Research and Applications
100.0%
100 90.75%
80
99.85%
60 40 15.12%
20 0 1
2
3
4
Protocol connections in shortest path
Figure 3: Shortest paths in the measured graph. The curve shows the cumulative fraction of the 78,953 reachable ordered pairs. All shortest paths use at most four protocol connections.
Yushen Li et al.: Preprint submitted to Blockchain: Research and Applications
Page 13 of 19
Y. Li, L. Jia, J. Feng, Z. Liao and Y. Sun
1
Create record
App A
2
XIR Gateway A request G_A
Blockchain: Research and Applications
Resolve route
XIR Registry
3
XIR Router
Use cross-chain protocols A
B
C
G_A Application request
B
policy · message hash
Receive via p
policy · source certificate
Send via p/q
XIR Adapters
Selected protocol path
message ID · certificate
ordered protocol evidence
G_C
q
p → p or p → q
source · destination
application message
G_B
C
Verify and deliver
Complete XIR record
p
p A
4
Verify complete path
A→B→C
After A → B
After B → C
protocols p/p or p/q
message
message
protocol p evidence
protocol p/q evidence
A → B verified
B → C verified
App C execute once
A2
XIR checks the source
submit
A3
XIR Registry settings
select
A1
protocol verifies each delivery
A4
send
hashes bind the path
deliver
Figure 4: XIR workflow. The XIR Router selects configured protocol connections. XIR Gateways and XIR Adapters record the verification result of each delivery. The destination verifies the ordered record before invoking the application.
Execution path
the second connection may use protocol p or q
A
Blockchain A
B
Blockchain B
protocol p App A
G_A
C
G_B
XIR Gateway A
Blockchain C
p→p G_C p→q
XIR Gateway B Receive via p
App C
XIR Gateway C
Send via p/q
verify the protocol p message at B
Messages and verification evidence
each protocol contributes one verified delivery
Application message
Protocol p: A → B
Protocol p/q: B → C
Complete XIR record
source · destination
message verified
message verified
same application message
policy · message hash
protocol evidence 1 linked to application message
protocol evidence 2 linked after A → B
ordered protocol evidence
message ID · certificate
delivery recorded once
Destination verification
1
2
3
4
5
Root source signature
Order delivery sequence
Policy protocol verification
Final last protocol message
Replay execute once
The same XIR record supports paths that use one protocol or different protocols.
Figure 5: Execution and verification in XIR. The same application record crosses each protocol connection. An XIR Gateway records the verification evidence produced by each protocol. The destination checks the source, delivery order, verification policy, final protocol message, and replay state before executing the application.
Yushen Li et al.: Preprint submitted to Blockchain: Research and Applications
Page 14 of 19
Y. Li, L. Jia, J. Feng, Z. Liao and Y. Sun
Blockchain: Research and Applications
Direct protocol configuration
XIR deployment G
78,953
G
G
G
G
same target
point-to-point configurations for 96.86% reachability
G
reuse existing protocol connections Existing protocol connections
N(N - 1) = O(N^2)
286 XIR Gateway deployments 493 blockchain–protocol integrations
each count grows as O(N) Deployment-gas model
measured gas per blockchain
XIR core
deployments ×286
610.6 M
gap ×118
652.5 M
gap ×144
4,014.9 M
2.135 M
Hyperlane stack
5.530 M
LayerZero stack
27.881 M 0M
10 M
20 M
modeled total
30 M
XIR Adapter: 1.751–1.900 M gas per measured integration
modeled total = gas per blockchain × deployments
Figure 6: Configuration and deployment cost. The upper part reports point-to-point protocol configurations, XIR Gateway deployments, and protocol integrations as separate units. The lower part compares deployment cost in gas by multiplying each measured per-blockchain cost by its deployment count.
Local Besu QBFT blockchains 4 validators
4 validators
A
4 validators
B
C
H
H
G
G
D
L
Experiment 1 · 3 blockchains · 40,000 requests
E
H
H
G
L
Hyperlane (H) LayerZero (L) 4 validators
4 validators
G
G
L
L
Experiment 3 · 8 paths · 2,000 observations each
Experiment 2 · 3 levels · 2,000 matched observations each
Recorded public-testnet executions
7 delivered LayerZero ×3
Hyperlane ×7
OP OP Sepolia
Base Sepolia
AR Arbitrum Sepolia
BA
LayerZero ×3
SO Solana Devnet
Figure 7: Experimental environments. Experiment 1 uses three local blockchains for same-protocol and cross-protocol paths. Experiments 2 and 3 use five local blockchains. The seven successful public-testnet executions use OP Sepolia, Arbitrum Sepolia, Base Sepolia, and Solana Devnet.
Yushen Li et al.: Preprint submitted to Blockchain: Research and Applications
Page 15 of 19
Y. Li, L. Jia, J. Feng, Z. Liao and Y. Sun
Blockchain: Research and Applications
(a) Cost at the final protocol switch
(b) Total path cost H = Hyperlane; L = LayerZero Each letter denotes one protocol connection
1.0
250
20
100
Latency (s)
Calldata (B)
2000
0.6
0.4
1.8
1.2
15
10
1000 0.2
50
5
0.6 R² = 0.996 n = 16,000
R² = 0.997 n = 16,000
Protocol path
HH H LH L LH L H
HH
H
H LH
HL
3
H
2
Earlier protocol deliveries
HH
1
HH
Earlier protocol deliveries
HH H LH L LH L H
3
HH
2
H
0.0 1
H LH
Earlier protocol deliveries
3
HL
2
HH
0 1
H
0
HH
Gas (thousand)
150
Gas (million)
0.8
200
Calldata (kB)
3000
2.4
Protocol path
(c) Workflow stage latency 0.86 s
Record creation
dot: median line: P5–P95
1.08 s
Root certificate
4.01 s
Hyperlane delivery
3.18 s
LayerZero delivery Protocol switch
0.83 s
Destination verification
0.78 s 0.02 s
Result confirmation
15.99 s
Pair to pair 10
−2
10
−1
10
0
10
1
Latency (s, log scale)
Figure 8: Execution cost and workflow latency. (a) Experiment 2 uses 6,000 matched observations, with 2,000 at each number of earlier deliveries. (b) Experiment 3 reports mean costs for eight paths across 16,000 executions; each letter denotes one protocol connection (H: Hyperlane; L: LayerZero). The displayed R2 values describe the additive models. Teal denotes aggregate measurements in (a) and (b). (c) Stage latencies use all recorded instances from the 22,000-execution campaign; blue denotes Hyperlane delivery and orange denotes LayerZero delivery. Points show medians; lines show the 5th–95th percentiles.
Yushen Li et al.: Preprint submitted to Blockchain: Research and Applications
Page 16 of 19
Y. Li, L. Jia, J. Feng, Z. Liao and Y. Sun
7. Discussion 7.1. Applying XIR to Cross-Chain Messages XIR is useful when an application can reach its destination through existing protocol connections and can accommodate intermediate execution. Each additional connection contributes protocol delivery work; each handoff preserves the operation and checks its accumulated evidence. The application therefore gains access to a larger reachable set while paying for the selected path. The graph analysis describes this opportunity, and the prototype measurements quantify its execution cost for Hyperlane [17] and LayerZero [21]. A deployment requires an XIR Gateway on each participating blockchain and XIR Adapters for the protocols used along its paths. Adding a protocol involves mapping its message identifiers, authenticated callbacks, and verifier configuration into the common representation. The current prototype supplies these mappings for Hyperlane and LayerZero, including selected EVM-to-Solana paths. The six-protocol graph provides the broader deployment model.
7.2. Verification and Delivery Conditions Each connection retains its native verification mechanism. XIR links the accepted results through approved XIR Adapters and checks the complete history at the destination. The delivery theorem consequently depends on sound protocol callbacks, correct XIR components and source certification, authentic configuration, and cryptographic binding. In the implemented policy, every receipt must resolve to an active profile with a sufficient security level; the policy hash binds the accompanying policy metadata. Execution uses the configuration available at each step. A profile change can therefore stop a path that was eligible when selected. Operational route selection must account for profile validity, intermediate availability, and protocol delivery conditions. At the destination, atomic consumption of the message identifier ensures at-most-once committed execution. Successful completion additionally depends on the participating blockchains, protocol services, and forwarding components making progress.
Blockchain: Research and Applications
The controlled experiments characterize the deployed protocol stacks on local Besu QBFT [18] blockchains. Public-testnet records demonstrate selected paths across EVM networks and Solana Devnet. Further deployments can evaluate how network delay, protocol service availability, and additional XIR Adapter implementations affect the same verification and execution workflow.
8. Conclusion This paper presents XIR, a framework that composes existing cross-chain protocol connections. XIR uses a verifiable intermediate representation that binds one application cross-chain message to an ordered record of authenticated protocol deliveries. XIR comprises XIR Gateways, XIR Adapters, an XIR Registry, and an XIR Router. On the source blockchain, an XIR Gateway authenticates the application and creates the record. On each intermediate blockchain, an XIR Gateway verifies the incoming delivery and extends the record. On the destination blockchain, an XIR Gateway verifies the complete history before execution. Theoretical analysis and evaluation show that XIR preserves source authorization and evidence order, enforces per-hop policies, and prevents duplicate delivery. With XIR Gateways and XIR Adapters, composition over the measured 286-blockchain graph reaches 78,953 ordered pairs (96.86% of all possible pairs), compared with 14.64% direct reachability. The opensource Hyperlane–LayerZero prototype demonstrates executable delivery and measures the cost of carrying verification history across multi-hop paths. Future work will extend protocol coverage and reduce history cost.
Funding This work was supported in part by the National Key R&D Program of China under Grant 2023YFB2704803, in part by the National Natural Science Foundation of China under Grants 62602642 and U22B2032, and in part by the Beijing Advanced Innovation Center for Future Blockchain and Privacy Computing under Grant GJJ-24-025.
Data availability 7.3. Path Length and Deployment The measured graph concentrates reachable pairs at short distances: two-hop shortest paths account for 75.63% of reachable pairs, and all finite shortest paths use at most four hops. This distribution motivates the evaluated path lengths. Longer paths carry more history, increasing destination verification linearly and aggregate history transmission quadratically in the current encoding. Compressing the authenticated history is a natural extension for applications that require longer paths.
Implementation and experimental data: https:// github.com/lysrain21/XIR.
References [1] Axelar, n.d. Learn about axelar. https://docs.axelar. dev/learn/. Official network overview. Accessed 2026-0916. [2] Axelar contributors, 2026. Axelar IAxelarGateway.sol: General message passing interface. https://github. com/axelarnetwork/axelar-cgp-solidity/blob/ 105f5017ef4b30033e5000a1950a95e8dd0fb7d8/contracts/ interfaces/IAxelarGateway.sol. Official source-code snapshot, commit dated 2026-06-01. Accessed 2026-07-16.
Yushen Li et al.: Preprint submitted to Blockchain: Research and Applications
Page 17 of 19
Y. Li, L. Jia, J. Feng, Z. Liao and Y. Sun [3] Axelar Network, 2024. Axelar general message passing. URL: https://docs.axelar.dev/dev/ general-message-passing/overview. axelar cross-chain messaging protocol. [4] Axelarscan, n.d. Axelarscan api documentation. https:// docs.axelarscan.io/. Public explorer API documentation. Accessed 2026-07-16. [5] Bang-Jensen, J., Gutin, G.Z., 2009. Digraphs: Theory, Algorithms and Applications. 2 ed., Springer London. doi:10.1007/978-1-84800-998-1. [6] Belchior, R., Vasconcelos, A., Guerreiro, S., Correia, M., 2021. A survey on blockchain interoperability: Past, present, and future trends. ACM Computing Surveys 54, 1–41. doi:10.1145/3471140. article 168. [7] Beregszaszi, A., Mushegian, N., 2017. EIP-140: REVERT instruction. https://eips.ethereum.org/EIPS/eip-140. Ethereum Improvement Proposal 140. Accessed 2026-09-02. [8] Cao, Y., Cao, J., Bai, D., Wen, L., Liu, Y., Li, R., 2025. MAP the blockchain world: A trustless and scalable blockchain interoperability protocol for cross-chain applications, in: Proceedings of the ACM Web Conference 2025, pp. 717–726. doi:10.1145/3696410.3714867. [9] Chainlink Labs, n.d.a. CCIP explorer atlas transaction feed. https://ccip.chain.link/api/h/atlas/ transactions. Public JSON interface used by the dataset collector. Accessed 2026-07-16. [10] Chainlink Labs, n.d.b. Chainlink CCIP: Offchain architecture – overview. https://docs.chain.link/ccip/ concepts/architecture/offchain/overview. Version 1.6 Role DON and its Commit and Executing plugins. Accessed 2026-09-16. [11] Falazi, G., Breitenbücher, U., Leymann, F., Schulte, S., 2024. Cross-chain smart contract invocations: A systematic multi-vocal literature review. ACM Computing Surveys 56, 1–38. doi:10.1145/3638045. [12] Guo, Y., Wang, Y., Huang, J., Duan, T., Jia, L., Zhang, H., Sun, Y., 2025. CAVer: Compacting accumulation to reduce cross-chain verification overhead. Blockchain: Research and Applications , 100381doi:10.1016/j.bcra.2025.100381. [13] Hardjono, T., Lipton, A., Pentland, A., 2018. Towards a design philosophy for interoperable blockchain systems. arXiv:1805.05934, https://arxiv.org/abs/1805. 05934. doi:10.48550/arXiv.1805.05934. [14] Hyperlane, n.d.a. Hyperlane explorer GraphQL api. https://docs.hyperlane.xyz/docs/reference/explorer/ graphql-api. Public explorer query interface used by the dataset collector. Accessed 2026-07-16. [15] Hyperlane, n.d.b. Hyperlane: Interchain security modules. https://docs.hyperlane.xyz/docs/protocol/ISM/ modular-security. Accessed 2026-08-07. Applicationconfigurable and composable security modules. [16] Hyperlane, n.d.c. Router library. https://docs.hyperlane. xyz/docs/reference/developer-tools/libraries/router. Official documentation and Router source code; documents remote-router enrollment and sender checks. Accessed 2026-09-14. [17] Hyperlane contributors, 2026. Hyperlane Mailbox.sol: Dispatch, verification, and delivery. https: //github.com/hyperlane-xyz/hyperlane-monorepo/blob/ f57a2aaf031a990512acd602443a9468f753925f/solidity/ contracts/Mailbox.sol. Official source-code snapshot, commit dated 2026-07-16. Accessed 2026-07-16. [18] Hyperledger Besu contributors, 2026. Configure QBFT consensus. URL: https://docs.besu-eth.org/ private-networks/how-to/configure/consensus/qbft. official Besu documentation, accessed 2026-08-26. [19] Kapsoulis, N., Jamulkar, S., Psychas, A., Litke, A., Varvarigou, T., 2026. Service mesh interoperability for crosschain transactions. Blockchain: Research and Applications , 100538doi:10.1016/j.bcra.2026.100538. [20] LayerZero Labs, n.d.a. Layerzero scan swagger api. https: //docs.layerzero.network/v2/tools/layerzeroscan/api. Public message interface used by the dataset collector. Accessed 2026-07-16. [21] LayerZero Labs, n.d.b. Layerzero v2: Omnichain application overview and peer configuration. https://docs.layerzero.
Blockchain: Research and Applications network/v2/developers/evm/oapp/overview. Accessed 2026-08-25. Documents per-EID peer configuration for application messaging channels. [22] LayerZero Labs, n.d.c. Layerzero v2: Protocol overview. https://docs.layerzero.network/v2/home/protocol/ protocol-overview. Accessed 2026-07-16. Applicationconfigurable X-of-Y -of-N DVN security stack. [23] Lee, S.S., Murashkin, A., Derka, M., Gorzny, J., 2023. SoK: Not quite water under the bridge: Review of cross-chain bridge hacks, in: 2023 IEEE International Conference on Blockchain and Cryptocurrency (ICBC), pp. 1–14. doi:10. 1109/ICBC56567.2023.10174993. [24] Liu, Y., Jia, L., Yang, X., Li, Z., Sun, Y., 2026. Concordia: Enabling low-conflict distributed transaction scheduling in sharding blockchain via cooperative perception, in: Proceedings of the ACM Web Conference 2026, Association for Computing Machinery. pp. 5493–5502. doi:10.1145/ 3774904.3792469. [25] Notland, J.S., Li, J., Nowostawski, M., Haro, P.H., 2026. SoK: Cross-chain bridging architectural design flaws and mitigations. Blockchain: Research and Applications 7, 100315. doi:10.1016/j.bcra.2025.100315. [26] Relay, 2026. Relay settlement protocol: How it works. https://docs.relay.link/references/protocol/ how-it-works. Official protocol documentation. Accessed 2026-08-25. [27] Relay, n.d. Relay api overview. https://docs.relay.link/ references/api/overview. Public API documentation. Accessed 2026-07-16. [28] Rezaei, A., Davidson, S.L., Wong, B., 2026. Towards policy-enabled multi-hop routing for cross-chain message delivery. arXiv:2604.04890, https://arxiv.org/abs/2604. 04890. doi:10.48550/arXiv.2604.04890. arXiv preprint, submitted 2026-04-06. Accessed 2026-07-16. [29] Shiell, D., Xiong, W., Du, B., 2022. ICS-033: Multihop channel. https://github.com/cosmos/ibc/blob/main/ spec/core/ics-033-multi-hop/README.md. Draft specification, created 2022-11-11, modified 2022-12-16. Accessed 2026-09-16. [30] SmartContractKit contributors, 2026. Chainlink CCIP OffRamp.sol: Inbound verification and execution. https://github.com/smartcontractkit/chainlink-ccip/ blob/c08e039d74cab99f9e0cba6948579120d7bb3804/ chains/evm/contracts/offRamp/OffRamp.sol. Official source-code snapshot, commit dated 2026-07-15. Accessed 2026-07-16. [31] Wormhole Foundation, n.d.a. Wormhole documentation: The guardian network. https://wormhole.com/docs/ protocol/infrastructure/guardians/. Accessed 2026-0716. 13-of-19 guardian signing threshold. [32] Wormhole Foundation, n.d.b. Wormhole documentation: Verified action approvals (VAAs). https://wormhole.com/ docs/protocol/infrastructure/vaas/. Accessed 2026-0716. VAAs carry no destination chain and are effectively multicast. [33] WormholeScan, n.d. Wormholescan api documentation. https://docs.wormholescan.io/. Public operations interface used by the dataset collector. Accessed 2026-07-16. [34] Xie, T., Zhang, J., Cheng, Z., Zhang, F., Zhang, Y., Jia, Y., Boneh, D., Song, D., 2022. zkBridge: Trustless cross-chain bridges made practical, in: Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security (CCS 2022), ACM. pp. 3003–3017. doi:10.1145/ 3548606.3560652. [35] Yang, H., Zhang, T., Ying, Z., Yang, R., Zhou, W., 2025. SightCVC: An efficient and compatible multi-chain transaction protocol in heterogeneous blockchain systems. IEEE Transactions on Information Forensics and Security 20, 10203–10218. doi:10.1109/TIFS.2025.3607247. [36] Yin, C., Li, M., Zhang, J., Lin, Y., Wei, Q., Goh, S.M.R., 2025. Atomic smart contract interoperability with high efficiency via cross-chain integrated execution. IEEE Transactions on Parallel and Distributed Systems 36, 2635–2651. doi:10.1109/TPDS.2025.3614374. [37] Zamyatin, A., Al-Bassam, M., Zindros, D., Kokoris-Kogias, E., Moreno-Sanchez, P., Kiayias, A., Knottenbelt, W.J.,
Yushen Li et al.: Preprint submitted to Blockchain: Research and Applications
Page 18 of 19
Y. Li, L. Jia, J. Feng, Z. Liao and Y. Sun
Blockchain: Research and Applications
2021. SoK: Communication across distributed ledgers, in: Financial Cryptography and Data Security (FC 2021), Springer. pp. 3–36. doi:10.1007/978-3-662-64331-0_1. iACR ePrint 2019/1128. [38] Zhang, M., Zhang, X., Zhang, Y., Lin, Z., 2024. Security of cross-chain bridges: Attack surfaces, defenses, and open problems, in: Proceedings of the 27th International Symposium on Research in Attacks, Intrusions and Defenses (RAID 2024), ACM. pp. 298–316. doi:10.1145/3678890. 3678894. [39] Zhuo, F., Guo, Y., Zhang, H., Li, Z., Wang, X., Jia, L., Sun, Y., 2026. Chuchu: A hashlock group protocol for cross-chain swaps. IEEE Transactions on Dependable and Secure Computing 23, 7026–7042. doi:10.1109/TDSC.2026. 3670858.
Yushen Li et al.: Preprint submitted to Blockchain: Research and Applications
Page 19 of 19