pith. sign in

arxiv: 2604.04890 · v1 · submitted 2026-04-06 · 💻 cs.DC · cs.NI

Towards Policy-Enabled Multi-Hop Routing for Cross-Chain Message Delivery

Amin Rezaei , Solomon L. Davidson , Bernard Wong This is my paper

Pith reviewed 2026-05-10 18:42 UTC · model grok-4.3

classification 💻 cs.DC cs.NI
keywords cross-chain routingblockchain interoperabilitymulti-hop message deliverydecentralized relayersrouting policiesIBC protocolscalabilitydecentralization
0
0 comments X

The pith

xRoute routes cross-chain messages over multiple hops using decentralized relayers and destination-chain policy checks.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper introduces a routing system that lets messages travel between blockchains not directly linked, by having applications declare policies for path selection and letting the receiving chain confirm the path meets its security rules. A network of independent relayers handles route computation and delivery instead of passing everything through a single hub. This setup aims to increase the number of reachable chains, reduce central points of failure, and maintain performance when message volume grows. If the design works, cross-chain applications could operate across larger sets of chains without the slowdowns or single-entity risks seen in hub-only models.

Core claim

xRoute brings routing, name resolution, and policy-based delivery to the blockchain setting. Applications specify routing policies, destination chains verify that selected routes satisfy security requirements, and a decentralized relayer network computes routes and delivers messages without a trusted hub. Experiments on chains supporting the Inter-Blockchain Communication protocol show improved connectivity, decentralization, and scalability compared to hub-based designs, particularly under heavy load.

What carries the argument

xRoute, a cross-chain routing framework that combines application-specified policies, destination-chain verification of routes, and a decentralized relayer network for computing and forwarding multi-hop messages.

If this is right

  • Applications can direct messages along preferred paths by setting explicit policies.
  • Receiving chains gain the ability to reject routes that fail their security criteria before messages arrive.
  • Message traffic spreads across many relayers rather than concentrating at one hub, supporting higher volumes.
  • More pairs of chains become reachable without requiring every pair to maintain a direct link.
  • The overall network gains resilience because no single operator controls all routing decisions.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Chains could adopt this style of routing to support richer cross-chain applications that span many ecosystems at once.
  • Relayer incentives would need to be designed so that participants continue to provide accurate routes even when load varies.
  • The same policy-and-verification pattern might apply to other interoperability protocols if their message formats can express route metadata.
  • Under extreme conditions the system might still require fallback mechanisms if the decentralized relayer set temporarily shrinks.

Load-bearing premise

A decentralized network of relayers can reliably select and deliver messages along secure routes at large scale without creating new bottlenecks or security gaps that the destination chain's policy checks miss.

What would settle it

A measurement on IBC chains showing that under sustained high message load the relayer network produces higher latency, lower success rates, or undetected route violations compared with a hub-based system.

Figures

Figures reproduced from arXiv: 2604.04890 by Amin Rezaei, Bernard Wong, Solomon L. Davidson.

Figure 1
Figure 1. Figure 1: Sequence Diagram illustrating a multi-hop packet’s flow [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: xRoute architecture. xRoute Core modules run on-chain (application services, policy enforcement, governance, and multi-path). Relayers run off-chain [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Relayer Network Architecture. The coordination network is a BFT blockchain where relayers stake tokens and collaborate on route computation and [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Effect of utilizing xRoute on Connectivity, when chains with smaller [PITH_FULL_IMAGE:figures/full_fig_p007_4.png] view at source ↗
Figure 6
Figure 6. Figure 6: Packet Delivery Time in Hub-and-Spoke compared to xRoute [PITH_FULL_IMAGE:figures/full_fig_p008_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Gas costs of xRoute vs Manual Multi-Hop usually long-lived and reused, so we amortized the cost of establishing the channel over multiple messages [PITH_FULL_IMAGE:figures/full_fig_p009_7.png] view at source ↗
read the original abstract

Blockchain ecosystems face a significant issue with liquidity fragmentation, as applications and assets are distributed across many public chains with each only accessible by subset of users. Cross-chain communication was designed to address this by allowing chains to interoperate, but existing solutions limit communication to directly connected chains or route traffic through hubs that create bottlenecks and centralization risks. In this paper, we introduce xRoute, a cross-chain routing and message-delivery framework inspired by traditional networks. Our design brings routing, name resolution, and policy-based delivery to the blockchain setting. It allows applications to specify routing policies, enables destination chains to verify that selected routes satisfy security requirements, and uses a decentralized relayer network to compute routes and deliver messages without introducing a trusted hub. Experiments on the chains supporting the Inter-Blockchain Communication (IBC) protocol show that our approach improves connectivity, decentralization, and scalability compared to hub-based designs, particularly under heavy load.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The paper introduces xRoute, a cross-chain routing and message-delivery framework that enables applications to specify routing policies, allows destination chains to verify route security, and employs a decentralized relayer network for multi-hop route computation and delivery. It positions this as an improvement over hub-based designs for addressing liquidity fragmentation, with experiments on IBC-supporting chains claiming gains in connectivity, decentralization, and scalability under heavy load.

Significance. If the design's security properties and experimental results hold, the work could meaningfully advance blockchain interoperability by reducing hub-induced bottlenecks and centralization risks while incorporating policy controls from traditional networking. The decentralized relayer approach and destination-chain verification represent a concrete step toward scalable multi-chain systems, though validation of the assumptions is essential for impact.

major comments (2)
  1. [§5 (Experiments)] §5 (Experiments): The manuscript claims quantitative improvements in connectivity, decentralization, and scalability from experiments on IBC chains, particularly under heavy load, but provides no methodology details, specific metrics (e.g., how decentralization is quantified via node degree or path diversity), baseline definitions for hub-based comparisons, load parameters, or error analysis. This directly undermines assessment of the central empirical claim.
  2. [Design section on decentralized relayer network (likely §3 or §4)] Design section on decentralized relayer network (likely §3 or §4): The claim that the relayer network computes secure multi-hop routes without new centralization or bottlenecks rests on unanalyzed assumptions about route discovery (e.g., no shared state or gossip favoring high-degree nodes) and the timing of policy checks. If verification occurs only after selection, as implied by the architecture, destination policies cannot prevent unsafe or centralizing routes from being chosen, weakening the security and decentralization advantages over hubs.
minor comments (2)
  1. [Abstract and introduction] Abstract and introduction: The term 'xRoute framework' and key components like 'name resolution' are introduced without a concise overview or diagram reference, reducing accessibility for readers unfamiliar with IBC.
  2. [Related work] Related work: Missing explicit comparison table or citations to prior multi-hop routing proposals in cross-chain literature (e.g., specific IBC relayer papers) to clarify novelty.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for their constructive and detailed comments. We address each major comment below, providing clarifications where possible and committing to revisions that strengthen the presentation of our results and design without altering the core contributions.

read point-by-point responses

  1. Referee: [§5 (Experiments)] §5 (Experiments): The manuscript claims quantitative improvements in connectivity, decentralization, and scalability from experiments on IBC chains, particularly under heavy load, but provides no methodology details, specific metrics (e.g., how decentralization is quantified via node degree or path diversity), baseline definitions for hub-based comparisons, load parameters, or error analysis. This directly undermines assessment of the central empirical claim.

    Authors: We agree that §5 would benefit from substantially more detail to support evaluation of the reported improvements. In the revised manuscript we will expand the experimental section with a full methodology description. This will include: explicit definitions of all metrics (connectivity as fraction of reachable chain pairs; decentralization via node-degree distribution, path-length entropy, and relayer-participation fairness; scalability via throughput and latency curves); precise baseline configurations for the hub-based comparisons (standard IBC hub topologies with equivalent relayer counts); the concrete load parameters (message arrival rates, network sizes, and congestion levels used for the heavy-load regime); and error analysis (standard deviations across repeated runs together with any statistical tests). These additions will make the empirical claims reproducible and directly address the referee’s concern. revision: yes

  2. Referee: [Design section on decentralized relayer network (likely §3 or §4)] Design section on decentralized relayer network (likely §3 or §4): The claim that the relayer network computes secure multi-hop routes without new centralization or bottlenecks rests on unanalyzed assumptions about route discovery (e.g., no shared state or gossip favoring high-degree nodes) and the timing of policy checks. If verification occurs only after selection, as implied by the architecture, destination policies cannot prevent unsafe or centralizing routes from being chosen, weakening the security and decentralization advantages over hubs.

    Authors: We thank the referee for identifying this point of potential ambiguity. The architecture description states that destination-chain policy verification is performed on the candidate route before the message is accepted for delivery, allowing the destination to reject routes that violate its security or decentralization requirements. Nevertheless, we acknowledge that the assumptions underlying the decentralized route-discovery process—particularly the absence of persistent shared state and the use of gossip mechanisms that do not systematically favor high-degree nodes—were not accompanied by a dedicated analysis. In the revision we will add a new subsection to the design section that (1) formalizes the route-discovery protocol, (2) explains why the chosen gossip and state-management approach avoids the identified centralization risks, and (3) clarifies that policy checks are integrated into the selection phase rather than occurring only after a route has already been chosen. This will make the security and decentralization arguments explicit and directly responsive to the referee’s critique. revision: yes

Circularity Check

0 steps flagged

No significant circularity; system design with external experiments

full rationale

The paper is a system-design proposal for xRoute that introduces routing, name resolution, and policy-based delivery without mathematical derivations, equations, fitted parameters, or predictions. Claims of improved connectivity, decentralization, and scalability rest on experiments with IBC-supporting chains rather than any internal definitions or self-referential reductions. No load-bearing steps match the enumerated circularity patterns, as there are no self-definitional constructs, fitted inputs renamed as predictions, or uniqueness theorems imported via self-citation. The analysis is self-contained against external benchmarks.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 2 invented entities

The proposal rests on domain assumptions about relayer reliability and blockchain interoperability rather than new mathematical axioms or fitted parameters.

axioms (1)
  • domain assumption Decentralized relayer networks can be organized to compute and deliver cross-chain routes without introducing trusted intermediaries or performance bottlenecks.
    Invoked in the description of the xRoute design and its claimed advantages over hub-based systems.
invented entities (2)
  • xRoute framework no independent evidence
    purpose: To provide policy-based multi-hop routing and message delivery across blockchains.
    New system introduced by the paper.
  • decentralized relayer network no independent evidence
    purpose: To compute routes and deliver messages without a trusted hub.
    Core architectural component of the proposed design.

pith-pipeline@v0.9.0 · 5456 in / 1269 out tokens · 40285 ms · 2026-05-10T18:42:41.550046+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

  • IndisputableMonolith/Foundation/RealityFromDistinction.lean reality_from_one_distinction unclear
    ?
    unclear

    Relation between the paper passage and the cited Recognition theorem.

    xRoute constructs routes over existing direct connections without introducing additional trust assumptions. These routes meet user-specified policies; We distinguish between (1) security policies, which must hold and are enforced on-chain such as a minimum Nakamoto coefficient for intermediate chains...

  • IndisputableMonolith/Cost/FunctionalEquation.lean washburn_uniqueness_aczel unclear
    ?
    unclear

    Relation between the paper passage and the cited Recognition theorem.

    The policy module has two functions. First, it allows a user to store policies on their preferred blockchain... Second, when receiving a packet, the policy module verifies if the received packet’s policies match those that are expected on the destination chain.

What do these tags mean?
matches
The paper's claim is directly supported by a theorem in the formal canon.
supports
The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends
The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses
The paper appears to rely on the theorem as machinery.
contradicts
The paper's claim conflicts with a theorem or certificate in the canon.
unclear
Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Reference graph

Works this paper leans on

45 extracted references · 45 canonical work pages

  1. [1]

    All Chains Bridged TVL - DefiLlama,

    “All Chains Bridged TVL - DefiLlama,”https://defillama.com/bridged, September 2024

    work page 2024

  2. [2]

    7 Cross-Chain Bridge Vulnerabilities Explained — Chainlink,

    “7 Cross-Chain Bridge Vulnerabilities Explained — Chainlink,” https://chain.link/education-hub/cross-chain-bridge-vulnerabilities, September 2024

    work page 2024

  3. [3]

    Ibc specification: Multi-hop communication (ics-033),

    C. Network, “Ibc specification: Multi-hop communication (ics-033),” 2024, accessed: 2024-08-16. [Online]. Available: https://github.com/ cosmos/ibc/blob/main/spec/core/ics-033-multi-hop/README.md

    work page 2024

  4. [4]

    Axelar: Connecting applications with blockchain ecosys- tems,

    Axelar, “Axelar: Connecting applications with blockchain ecosys- tems,” Jan 2021, https://www.axelar.network/whitepaper [Accessed 22/08/2024]

    work page 2021

  5. [5]

    B. S. Srinivasan. (2017) Quantifying decentralization. Ac- cessed: 2023-10-25. [Online]. Available: https://news.earn.com/ quantifying-decentralization-e39db233c28e

    work page 2017

  6. [6]

    Ibc specification: Fee payment (ics-029),

    C. Network, “Ibc specification: Fee payment (ics-029),” 2024, accessed: 2024-12-07. [Online]. Available: https://github.com/cosmos/ibc/blob/ main/spec/app/ics-029-fee-payment/README.md

    work page 2024

  7. [7]

    Analyzing the perfor- mance of the inter-blockchain communication protocol,

    J. O. Chervinski, D. Kreutz, X. Xu, and J. Yu, “Analyzing the perfor- mance of the inter-blockchain communication protocol,” in2023 53rd Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), 2023, pp. 151–164

    work page 2023

  8. [8]

    Lynch, and Larry J

    C. Dwork, N. Lynch, and L. Stockmeyer, “Consensus in the presence of partial synchrony,”J. ACM, vol. 35, no. 2, p. 288–323, Apr. 1988. [Online]. Available: https://doi.org/10.1145/42282.42283

    work page doi:10.1145/42282.42283 1988

  9. [9]

    “Simpy,” https://gitlab.com/team-simpy/simpy/

    work page

  10. [10]

    Cosmos chain registry,

    C. Network, “Cosmos chain registry,” 2024, accessed: 2024-08-16. [Online]. Available: https://github.com/cosmos/chain-registry

    work page 2024

  11. [11]

    Cosmos sdk,

    “Cosmos sdk,” https://github.com/cosmos/cosmos-sdk

    work page

  12. [12]

    Tendermint: Byzantine fault tolerance in the age of blockchains,

    E. Buchman, “Tendermint: Byzantine fault tolerance in the age of blockchains,” Ph.D. dissertation, University of Guelph, 2016

    work page 2016

  13. [13]

    Insights

    L. Insights. Usdc depeg highlights importance of fed to banking system. Https://www.ledgerinsights.com/usdc-depeg-fed-federal-reserve/

    work page

  14. [14]

    Risc zero api documentation,

    R. Zero, “Risc zero api documentation,” 2024, accessed: 2024-08-16. [Online]. Available: https://dev.risczero.com/api

    work page 2024

  15. [15]

    Sok: Security and privacy of blockchain interoperability,

    A. Augusto, R. Belchior, M. Correia, A. Vasconcelos, L. Zhang, and T. Hardjono, “Sok: Security and privacy of blockchain interoperability,” in2024 IEEE Symposium on Security and Privacy (SP), 2024, pp. 3840– 3865

    work page 2024

  16. [16]

    Benchmarking blockchain bridge aggregators,

    S. Subramanian, A. Augusto, R. Belchior, A. Vasconcelos, and M. Cor- reia, “Benchmarking blockchain bridge aggregators,” in2024 IEEE International Conference on Blockchain (Blockchain), 2024, pp. 37–45

    work page 2024

  17. [17]

    ACM Comput

    R. Belchior, A. Vasconcelos, S. Guerreiro, and M. Correia, “A survey on blockchain interoperability: Past, present, and future trends,” ACM Comput. Surv., vol. 54, no. 8, Oct. 2021. [Online]. Available: https://doi.org/10.1145/3471140

    work page doi:10.1145/3471140 2021

  18. [18]

    Chain interoperability,

    V . Buterin, “Chain interoperability,” R3, Tech. Rep., September 2016, accessed: 2025-01-31. [Online]. Available: https://cognizium.io/uploads/resources/R3%20-%20Chain% 20Interoperability%20-%202016%20-%20Sep.pdf

    work page 2016

  19. [19]

    A brief history of blockchain interoperability,

    R. Belchior, J. S ¨ußenguth, Q. Feng, T. Hardjono, A. Vasconcelos, and M. Correia, “A brief history of blockchain interoperability,”Commun. ACM, vol. 67, no. 10, p. 62–69, Sep. 2024. [Online]. Available: https://doi.org/10.1145/3648607

    work page doi:10.1145/3648607 2024

  20. [20]

    A survey on cross-chain technologies,

    P. Han, Z. Yan, W. Ding, S. Fei, and Z. Wan, “A survey on cross-chain technologies,”Distrib. Ledger Technol., vol. 2, no. 2, Jun. 2023. [Online]. Available: https://doi.org/10.1145/3573896

    work page doi:10.1145/3573896 2023

  21. [21]

    IET Blockchain 3(3), 149–158 (2023)

    L. Li, J. Wu, and W. Cui, “A review of blockchain cross-chain technology,”IET Blockchain, vol. 3, no. 3, pp. 149–158, 2023. [Online]. Available: https://ietresearch.onlinelibrary.wiley.com/doi/abs/ 10.1049/blc2.12032

    work page doi:10.1049/blc2.12032 2023

  22. [22]

    Inter blockchain communication: A survey,

    I. A. Qasse, M. Abu Talib, and Q. Nasir, “Inter blockchain communication: A survey,” inProceedings of the ArabWIC 6th Annual International Conference Research Track, ser. ArabWIC 2019. New York, NY , USA: Association for Computing Machinery, 2019. [Online]. Available: https://doi.org/10.1145/3333165.3333167

    work page doi:10.1145/3333165.3333167 2019

  23. [23]

    Introducing the cross-chain interoperability protocol (ccip) for decentralized inter-chain messaging and token movements,

    Chainlink, “Introducing the cross-chain interoperability protocol (ccip) for decentralized inter-chain messaging and token movements,” https://blog.chain.link/introducing-the-cross-chain-interoperability- protocol-ccip/ [Accessed 21/08/2024]

    work page 2024

  24. [24]

    Hyperlane official website,

    Hyperlane, “Hyperlane official website,” https://hyperlane.xyz/, 2025, accessed: 2025-01-31

    work page 2025

  25. [25]

    Lay- erzero,

    R. Zarick, B. Pellegrino, I. Zhang, T. Kim, and C. Banister, “Lay- erzero,” https://layerzero.network/publications/LayerZero Whitepaper V2.1.0.pdf, Jan 2024

    work page 2024

  26. [26]

    Layerzero official website,

    LayerZero, “Layerzero official website,” https://layerzero.network/, 2025, accessed: 2025-01-31

    work page 2025

  27. [27]

    Omnity network official website,

    O. Network, “Omnity network official website,” https://www.omnity. network/, 2025, accessed: 2025-01-31

    work page 2025

  28. [28]

    Omnity: The cross-chain endgame for a modular blockchain world,

    Omnity, “Omnity: The cross-chain endgame for a modular blockchain world,” Omnity Network, Tech. Rep., January 2025, accessed: 2025-01-31. [Online]. Available: https://docs.google.com/document/d/ 10RSrGfj2Z-LmVhuAXX0Jon-9P9CO6k5ZNfS2hrQB72I/edit?pli=1& tab=t.0#heading=h.5qlvro4pcib6

    work page 2025

  29. [29]

    Chain key cryptography,

    D. Foundation, “Chain key cryptography,” https://internetcomputer.org/ how-it-works/#Chain-key-cryptography, 2025, accessed: 2025-01-31

    work page 2025

  30. [30]

    Kwon and E

    J. Kwon and E. Buchman, “Cosmos,” https://github.com/cosmos/ cosmos/blob/master/WHITEPAPER.md, Jan 2019, [Accessed 22/08/2024]

    work page 2019

  31. [31]

    Polkadot: Vision for a heterogeneous multi-chain frame- work,

    G. Wood, “Polkadot: Vision for a heterogeneous multi-chain frame- work,” https://assets.polkadot.network/Polkadot-whitepaper.pdf, Nov 2016

    work page 2016

  32. [32]

    Blockchain router: A cross-chain communication protocol,

    H. Wang, Y . Cen, and X. Li, “Blockchain router: A cross-chain communication protocol,” inProceedings of the 6th International Conference on Informatics, Environment, Energy and Applications, ser. IEEA ’17. New York, NY , USA: Association for Computing Machinery, 2017, p. 94–97. [Online]. Available: https://doi.org/10.1145/ 3070617.3070634

    work page arXiv 2017

  33. [33]

    Anlink whitepaper,

    Z. Tech., “Anlink whitepaper,” https://alicliimg.clewm.net/049/389/ 1389049/1484820492640c2baf37ea3e4f9fd77bd52c2a1e9bbbe1484820484. pdf, 2017, accessed: 2025-01-31

    work page 2017

  34. [34]

    Interchain : A framework to support blockchain interoperability,

    D. Ding, “Interchain : A framework to support blockchain interoperability,” 2018. [Online]. Available: https://api.semanticscholar. org/CorpusID:51991936

    work page 2018

  35. [35]

    A multiple blockchains architecture on inter-blockchain communica- tion,

    L. Kan, Y . Wei, A. Hafiz Muhammad, W. Siyuan, L. C. Gao, and H. Kai, “A multiple blockchains architecture on inter-blockchain communica- tion,” in2018 IEEE International Conference on Software Quality, Reliability and Security Companion (QRS-C), 2018, pp. 139–145

    work page 2018

  36. [36]

    Susy: a blockchain-agnostic cross-chain asset transfer gateway protocol based on gravity,

    A. Pupyshev, E. Dzhafarov, I. Sapranidi, I. Kardanov, S. Khalilov, and S. Laureyssens, “Susy: a blockchain-agnostic cross-chain asset transfer gateway protocol based on gravity,” 2020. [Online]. Available: https://arxiv.org/abs/2008.13515

    work page arXiv 2020

  37. [37]

    Hyperservice: Interoperability and programmability across heterogeneous blockchains,

    Z. Liu, Y . Xiang, J. Shi, P. Gao, H. Wang, X. Xiao, B. Wen, and Y .-C. Hu, “Hyperservice: Interoperability and programmability across heterogeneous blockchains,” inProceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’19. New York, NY , USA: Association for Computing Machinery, 2019, p. 549–566. [Online]. Availa...

    work page doi:10.1145/3319535.3355503 2019

  38. [38]

    Ibex: Privacy-preserving Ad Conversion Tracking and Bid- ding

    T. Xie, J. Zhang, Z. Cheng, F. Zhang, Y . Zhang, Y . Jia, D. Boneh, and D. Song, “zkbridge: Trustless cross-chain bridges made practical,” inProceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’22. New York, NY , USA: Association for Computing Machinery, 2022, p. 3003–3017. [Online]. Available: https://doi.org/1...

    work page doi:10.1145/3548606.3560652 2022

  39. [39]

    Trustless, privacy-preserving blockchain bridges,

    D. Stone, “Trustless, privacy-preserving blockchain bridges,” 2021. [Online]. Available: https://arxiv.org/abs/2102.04660

    work page arXiv 2021

  40. [40]

    0x official website,

    0x, “0x official website,” https://0x.org/, 2025, accessed: 2025-01-31

    work page 2025

  41. [41]

    0x white paper,

    0x Project, “0x white paper,” 0x Project, Tech. Rep., January 2025, accessed: 2025-01-31. [Online]. Available: https://github.com/0xProject/ whitepaper/blob/master/0x white paper.pdf

    work page 2025

  42. [42]

    Blockchain gateways, bridges and delegated hash-locks,

    T. Hardjono, “Blockchain gateways, bridges and delegated hash-locks,”

    work page

  43. [43]

    Available: https://arxiv.org/abs/2102.03933

    [Online]. Available: https://arxiv.org/abs/2102.03933

    work page arXiv

  44. [44]

    Tombolo: To- wards a decentralized interconnected blockchain ecosystem using cross- chain payment channels,

    S. Maurya, N. Awathare, V . J. Ribeiro, and U. Bellur, “Tombolo: To- wards a decentralized interconnected blockchain ecosystem using cross- chain payment channels,” in2025 IEEE 45th International Conference on Distributed Computing Systems (ICDCS), 2025, pp. 1044–1054

    work page 2025

  45. [45]

    Ark official website,

    ARK Association, “Ark official website,” https://ark.io/, 2025, accessed: 2025-01-31

    work page 2025