Pith. sign in

REVIEW 4 major objections 6 minor 37 references

A shared coordination layer can make multi-chain transactions atomic while leaving independent work unblocked.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · grok-4.5

2026-07-11 07:03 UTC pith:ZGTLUKZB

load-bearing objection Solid, usable protocol for atomic cross-chain txs with clean formal reduction and open code; the CL-liveness assumption is real but already stated, not a hidden flaw. the 4 major comments →

arxiv 2607.05387 v1 pith:ZGTLUKZB submitted 2026-07-06 cs.DC

CATs: Secure Blockchain Interoperability with Cross-chain Atomic Transactions

Andreas Penzkofer , Franck Cassez This is my paper
classification cs.DC
keywords cross-chain atomicityblockchain interoperabilitydependency trackingconfirmation layerminimal blockingByzantine fault tolerancetimeout mechanisms
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

Cross-chain operations today usually lack all-or-nothing atomicity: one side of a trade can succeed while the other fails, leaving users with inconsistent or lost funds. This paper proposes a protocol, called CATs, that lets several autonomous blockchains run a single logical transaction so that either every part commits or every part aborts. The design keeps each chain’s own execution engine intact and adds only a lightweight shared layer of sequencers, transaction processors, a coordinator and a confirmation layer. Transactions that do not depend on a pending CAT continue immediately; dependent ones are postponed for at most a fixed timeout measured in confirmation-layer rounds. Formal proofs claim safety (all honest observers see the same success or failure) and liveness (every CAT eventually finishes) under Byzantine actors and asynchronous links. Simulations show high success rates when cross-chain traffic is a modest fraction of total load, and they quantify the trade-off between longer CAT lifetimes and the latency felt by dependent regular transactions.

Core claim

Under a Byzantine-fault-tolerant confirmation layer and cryptographically or crypto-economically protected status proposals, the CAT protocol guarantees that every cross-chain atomic transaction reaches a single, identical success or failure decision on all honest participants within a bounded number of confirmation-layer rounds, while independent transactions experience zero blocking and dependent transactions are blocked for at most the configured timeout.

What carries the argument

The accepted/postponed split together with an explicit dependency graph and a confirmation-layer timeout: independent transactions are moved into the accepted stream and applied at once; CATs and their dependents stay postponed until the coordinator (or the timeout) writes a final status onto the shared confirmation layer.

Load-bearing premise

Everything rests on the confirmation layer remaining live and uncensored for the duration of the CAT lifetime; if that layer itself stalls or partitions longer than the timeout, every pending CAT is forced to abort.

What would settle it

Run the open-source Hyperplane simulator (or a two-chain deployment) with a deliberately stalled confirmation layer that exceeds the configured CAT lifetime and check whether any CAT still appears as success on one chain and failure on another, or whether independent transactions remain blocked after the timeout.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • Multi-chain DeFi strategies that today must be broken into unsafe sequential steps can be expressed as single atomic CATs.
  • Independent regular traffic on each chain continues at full speed even while CATs are pending, removing a major source of cross-chain latency for non-dependent users.
  • Parameter choices (CAT lifetime versus max dependency depth) give operators an explicit dial between success probability and worst-case blocking time for dependents.
  • The same coordination pattern can sit under existing shared-sequencing or confirmation layers without rewriting individual chain VMs.
  • Because safety reduces to reading a single BFT log, light clients or non-proposing observers can verify CAT outcomes without trusting any individual chain.

Where Pith is reading between the lines

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

  • The same accepted/postponed split and dependency-depth bound could be applied inside a single sharded chain to obtain non-blocking cross-shard atomicity without a full two-phase commit lock.
  • If confirmation-layer block times continue to fall below one second, the practical latency of a CAT approaches ordinary single-chain finality, making the multi-chain UX indistinguishable from a monolithic ledger for modest cross-chain ratios.
  • The coordinator’s ability to force reordering via timeouts creates a new incentive surface that future staking or reputation designs will need to police.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper proposes CATs, a protocol for atomic cross-chain transactions that coordinates sequencers, per-chain transaction processors (executor+resolver), a coordinator, and a shared BFT confirmation layer (CL). Transactions are partitioned into accepted, postponed, and ignored sets using read/write dependency tracking; independent transactions execute with zero blocking (Lemma 3), while CATs and dependents are resolved within a CL-round timeout Δ and a CAT-dependency-depth bound maxDepth. Safety (identical Status across honest nTPs) and liveness (resolution within Δ, possibly forced abort) are reduced to standard BFT CL assumptions plus cryptographic/crypto-economic protection of TP proposals (Theorem 1, Props. 1–9). A Hyperplane simulation with two homogeneous chains reports CAT success rates under Zipf contention, CAT ratio, lifetime, and delay, and compares message complexity favorably to Avalon.

Significance. If the stated assumptions hold, the work supplies a clean, dependency-aware alternative to coarse locking and pairwise HTLC/GMP schemes for atomic multi-chain execution, with an explicit minimal-blocking guarantee and open-source implementation. The formal model (change sets, external reads/writes, CAT dependency depth) and the reduction of atomicity to CL consensus are reusable. Experimental trade-off curves (lifetime vs. dependent latency; CAT ratio vs. success) are useful for parameter selection. The main practical caveat is that successful commits, not merely all-or-nothing aborts, require CL progress within Δ; under prolonged asynchrony the protocol correctly aborts but does not deliver the composable multi-chain applications advertised in the abstract.

major comments (4)
  1. Abstract and §I claim “fast, secure, and deterministic atomic cross-chain execution” and a foundation for composable multi-chain apps. Theorem 1 and Props. 4, 7, 9 only guarantee that every CAT reaches a final Status (success or failure) within Δ CL rounds; when CL inclusion latency exceeds Δ (partition or censorship past GST+Δ), Algorithms 2–3 force failure on all sides. Atomicity (Def. 1) is preserved, but the stronger informal claim collapses to deterministic abort. The paper should explicitly separate “eventual resolution” from “successful commit under timely CL” in the abstract, introduction, and conclusion, and state the abort-only regime as a first-class limitation rather than only in the timeout discussion.
  2. §III opens by assuming homogeneous chains (identical VM, key/value model) so that ChangeSet, MemTr, and the dependency relation →_s are well-defined across participants; heterogeneous integration is declared out of scope. The abstract and §VIII nevertheless present the protocol as a foundation for scalable blockchain interoperability across the multi-chain landscape (rollups, L1s). Homogeneity is load-bearing for the dependency lemmas and for the TP simulation layer; without a concrete path or even a sketch of VM-level adapters, the interoperability claim overreaches the formal model. Either restrict the claim to homogeneous (or same-VM) deployments or add a discussion of what must be adapted for heterogeneous chains.
  3. §VI evaluates only two chains with maxDepth fixed at 1 and all path delays collapsed into a single TP–coordinator parameter D. The Avalon comparison (§VI-B) asserts O(n) message complexity and block-level finality independent of chain count, yet no experiment varies n>2. Future work acknowledges multi-chain and maxDepth sweeps; until those exist, claims of superior scaling and of “constant-round” behavior relative to Avalon’s reported 15–59 s latency should be qualified as asymptotic/architectural rather than empirically demonstrated. At minimum, report wall-clock latency and success for n=3–4 under the same Zipf/contention regime used for n=2.
  4. §IV-E and Prop. 6: timeouts and maxDepth empower the coordinator to reorder the effective transaction stream (skipping timed-out CATs, ignoring deep dependents). Prop. 6 only prevents forging of Status values; selective delay of Status publication is still possible and converts pending CATs into forced failures, which is a liveness/censorship vector even under a live CL. The paper should either (a) bound the reordering power (e.g., via CL-enforced proposal deadlines independent of the coordinator) or (b) give an incentive/slashing argument that makes systematic delay unprofitable, analogous to the TP protection mechanism of Prop. 8.
minor comments (6)
  1. Fig. 1 and Table I: τ3 is listed as Send(Bob, Eve, 300) in the figure caption narrative but as Send(Bob, Alice, 300) in Table I; align the example.
  2. §III-G: the dependsOn definition writes “→_s ∧ →_W” where the intended relation is the disjunction of read-write and write-write; fix the connective.
  3. Algorithms 2–3: the nested dirty-state / multi-outcome simulation layer mentioned in §IV-A is not reflected in the pseudocode; a short note on how pending CAT outcomes are stored (or a pointer to the Hyperplane implementation) would help reproducibility.
  4. Table IV: “Reported latency ∼1–2 s” for CATs is an architectural claim from CL block interval, not a measured end-to-end figure from §VI; label it as such.
  5. Related work: Espresso/CIRC and AggLayer are discussed as lacking peer-reviewed cross-chain execution specs; a one-sentence pointer to any public specs or code would strengthen the comparison.
  6. Notation: Status_r vs Status_r' and σ_P vs S_P are used interchangeably for sequences vs sets; pick one convention early in §IV-D.

Circularity Check

0 steps flagged

No load-bearing circularity: safety/liveness follow from stated BFT/CL assumptions and standard dependency lemmas; one non-central self-citation only.

full rationale

The central claims (Theorem 1 and Propositions 1–9) are derived from explicit assumptions that the confirmation layer is a live BFT state machine under partial synchrony (Section IV-C) plus cryptographic or crypto-economic protection of TP proposals. Atomicity (Definition 1) is proved from CL consistency (Proposition 5), not by redefining Status in terms of itself. Minimal-blocking (Proposition 1) rests on the independence lemmas (Lemmas 2–3) that are proved from the memory-trace definitions of Section III; those lemmas do not presuppose the protocol’s timeout or maxDepth parameters. Experimental free parameters (CAT lifetime, Zipf z, delay D, r_C) are swept and reported as trade-offs (Figures 11–16), never fitted and then re-presented as predictions. The single self-citation ([14], co-authored by Penzkofer) is used only for an optional remark on multi-state management and is not invoked in any safety or liveness argument. Consequently the derivation chain is self-contained against its stated assumptions; the only residual circularity risk is the ordinary (and non-load-bearing) self-reference, justifying a score of 1 rather than 0.

Axiom & Free-Parameter Ledger

3 free parameters · 4 axioms · 2 invented entities

The central safety and liveness claims rest on standard distributed-systems assumptions about the confirmation layer and on a small set of protocol parameters that are chosen by the designer rather than derived. No new physical entities are postulated; the ‘invented’ pieces are engineering components of the protocol itself.

free parameters (3)
  • CAT lifetime / timeout Δ (rounds) = 10 blocks (default)
    Chosen by the operator; directly trades CAT success probability against blocking time of dependent transactions. Default 10 blocks in experiments.
  • maxDepth (CAT dependency depth bound) = 1
    Hard limit introduced to prevent exponential state explosion and resource-exhaustion attacks; fixed at 1 in the evaluated implementation.
  • Zipf skewness z for account access = 0.8 (default)
    Controls contention in the simulation; varied experimentally but not derived from first principles.
axioms (4)
  • domain assumption The confirmation layer is a live BFT replicated state machine under partial synchrony that eventually includes every transaction observed by f+1 honest nodes and provides a consistent total order to all honest readers.
    Stated in Section IV-C and used as the foundation for Propositions 3–5 and Theorem 1.
  • domain assumption Transaction-processor status proposals are protected by either unforgeable cryptographic proofs (ZK) or crypto-economic staking such that an incorrect proposal is rejected or slashable.
    Required by Proposition 8; without it a Byzantine TP can break atomicity.
  • ad hoc to paper Chains are homogeneous (identical VM and key/value model) so that ChangeSet and dependency relations are well-defined across participants.
    Explicitly assumed in Section III; heterogeneous integration is declared out of scope.
  • standard math A third-party coordinator is necessary and sufficient for agreement on CAT status (citing the classic impossibility result).
    Invoked in Section IV-C via reference [21]; standard distributed-computing fact.
invented entities (2)
  • Accepted / postponed / ignored transaction partitions together with the nested dirty-state simulation layer no independent evidence
    purpose: Allow independent transactions to commit while CATs remain unresolved, and to support multiple possible CAT outcomes without permanent state mutation.
    These data structures are introduced by the protocol; they have no independent existence outside the design.
  • CAT dependency depth metric and maxDepth bound no independent evidence
    purpose: Bound the number of pending dependent CATs so that the number of superposition states remains manageable and resource-exhaustion attacks are mitigated.
    Defined recursively in Section III-G; the bound is a protocol parameter, not an observed natural quantity.

pith-pipeline@v1.1.0-grok45 · 34249 in / 3192 out tokens · 31155 ms · 2026-07-11T07:03:35.923444+00:00 · methodology

0 comments
read the original abstract

We propose a protocol for cross-chain atomic transactions (CATs), enabling composable atomic execution across different blockchains. The protocol addresses the key interoperability challenge of providing atomicity guarantees in the presence of asynchronous communication and Byzantine actors. It preserves chain autonomy by allowing each blockchain to maintain its own execution model while participating in coordinated cross-chain operations. The design introduces a shared coordination layer involving sequencers, transaction processors, a coordinator, and a confirmation layer which together ensure that either all parts of a CAT succeed or none do. To prevent unnecessary blocking, we separate transaction execution into accepted and postponed sets, with the coordination layer resolving the outcomes of CATs within a few rounds. We further introduce timeouts and dependency-depth bounds for liveness and mitigation of cascading delays. Our formal analysis establishes strong safety and liveness guarantees and demonstrates that the protocol achieves minimal blocking for independent transactions while ensuring bounded blocking time for dependent transactions. Experimental evaluation shows high CAT success when cross-chain transactions are a modest share of traffic, and characterizes the CAT-lifetime trade-off between success and dependent-transaction latency. This protocol enables fast, secure, and deterministic atomic cross-chain execution while preserving chain autonomy, providing a foundation for scalable blockchain interoperability solutions.

Figures

Figures reproduced from arXiv: 2607.05387 by Andreas Penzkofer, Franck Cassez.

Figure 1
Figure 1. Figure 1: A scenario with 5 participants and a cross-chain atomic transaction (CAT) that swaps assets between Bob and Charlie on two chains. Time evolves from top to bottom. Examples of balances are shown for an initial state and after the transactions are executed, for the case where all transactions succeed. Dependencies are shown with dashed lines. Tx Type Chain 1 Chain 2 τ1 Regular Send(Alice, Bob, 100) Skip τ2 … view at source ↗
Figure 3
Figure 3. Figure 3: Memory traces µ1 and µ2 with ranges, as shown in [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figure 2
Figure 2. Figure 2: Memory locations matrix showing read and write operations for [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 4
Figure 4. Figure 4: Dependencies between transactions in σ displayed in a dependency graph D if all transactions are successful. If σ[j] →s σ[i] there is an edge from σ[j] to σ[i]. Transactions t1, t3, and t6 are each part of (separate) CATs and increment the CAT dependency depths. For transaction details, see Table II. 6) CAT dependency depth.: In a cross-chain transaction setting, whether any part of a CAT is committed or n… view at source ↗
Figure 5
Figure 5. Figure 5: High-level overview of the involved system components in a CAT [PITH_FULL_IMAGE:figures/full_fig_p009_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: High-level overview of transaction processing on a single chain. The 10 steps shown are described in detail in Sec. IV-D. [PITH_FULL_IMAGE:figures/full_fig_p010_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Example of chain activity with the naive CAT protocol. Transactions [PITH_FULL_IMAGE:figures/full_fig_p011_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: Improvement through timeouts. Example as in [PITH_FULL_IMAGE:figures/full_fig_p012_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: Effect of a depth limit maxDepth = 1 on the dependency graph from [PITH_FULL_IMAGE:figures/full_fig_p012_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: With a depth limit of maxDepth = 1, the CAT t3 is added to the ignored sequence I and t4 is directly added to the accepted sequence σA. Eventually t1 is accepted and t3 gets computed and added to the postponed sequence σP . t1 t2 t3 t4 0 1 2 (a) no maxDepth limit depth t1 t2 t3 t4 is in I 0 1 2 (b) with maxDepth=1 Regular transaction CAT CAT dependency depth [PITH_FULL_IMAGE:figures/full_fig_p012_10.png] view at source ↗
Figure 10
Figure 10. Figure 10: Improvement through limiting the CAT dependency depth with maxDepth = 1. We use the transactions from Table II, with dependency graph illustrated in [PITH_FULL_IMAGE:figures/full_fig_p013_10.png] view at source ↗
Figure 11
Figure 11. Figure 11: Average success of CATs with the number of CATs per block ( [PITH_FULL_IMAGE:figures/full_fig_p017_11.png] view at source ↗
Figure 12
Figure 12. Figure 12: Impact of the number of CATs per block on average number of [PITH_FULL_IMAGE:figures/full_fig_p017_12.png] view at source ↗
Figure 13
Figure 13. Figure 13: Impact of CAT lifetime on the average latency of regular transactions [PITH_FULL_IMAGE:figures/full_fig_p017_13.png] view at source ↗
Figure 14
Figure 14. Figure 14: Average success of CATs with the chain delay. [PITH_FULL_IMAGE:figures/full_fig_p018_14.png] view at source ↗
Figure 15
Figure 15. Figure 15: Average success of CATs with the throughput, and while keeping [PITH_FULL_IMAGE:figures/full_fig_p018_15.png] view at source ↗
Figure 16
Figure 16. Figure 16: Impact of the centralization of key accesses on the average success [PITH_FULL_IMAGE:figures/full_fig_p018_16.png] view at source ↗

Review history (2 revisions) →

discussion (0)

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

Reference graph

Works this paper leans on

37 extracted references · 2 canonical work pages

  1. [1]

    Agglayer documentation,

    AggLayer, “Agglayer documentation,” 2025, accessed: 2025-09-02. [Online]. Available: https://docs.agglayer.dev/

    2025

  2. [2]

    Clearing up agglayer misconceptions,

    P. Labs, “Clearing up agglayer misconceptions,” Nov. 2024, accessed: 2025-07-24. [Online]. Available: https://polygon.technology/ blog/clearing-up-agglayer-misconceptions

    2024

  3. [3]

    Espresso is solving rollup inter- operability with the agglayer and polygon labs,

    EspressoSystems, “Espresso is solving rollup inter- operability with the agglayer and polygon labs,” https://medium.com/@espressosys/espresso-is-solving-rollup- interoperability-with-the-agglayer-and-polygon-labs-b3a7d2f8f7cf, May 2024, accessed: 2025-07-24

    2024

  4. [4]

    Erc-7683: Standard for crosschain intents,

    ERC-7683 Contributors, “Erc-7683: Standard for crosschain intents,” https://www.erc7683.org/, 2024, accessed: 2025-07-25

    2024

  5. [5]

    Intent-Based Architecture and Their Risks,

    Paradigm, “Intent-Based Architecture and Their Risks,” Paradigm blog, 2023, accessed: 2025-08-14. [Online]. Available: https://www.paradigm. xyz/2023/06/intents

    2023

  6. [6]

    Intents and the Intent Gossip Network,

    A. Foundation, “Intents and the Intent Gossip Network,” https://anoma. net/blog/intents-and-intent-gossip-network, 2022, accessed: 2025-08- 14

    2022

  7. [7]

    Atomic commitment across blockchains,

    V . Zakhary, D. Agrawal, and A. El Abbadi, “Atomic commitment across blockchains,”Proceedings of the VLDB Endowment, vol. 13, no. 9, pp. 1319–1331, 2020. [Online]. Available: https://www.vldb.org/ pvldb/vol13/p1319-zakhary.pdf

    2020

  8. [8]

    Enabling complete atomicity for cross-chain applications through layered state commitments,

    Y . Cai, R. Cheng, Y . Zhou, S. Zhang, J. Xiao, and H. Jin, “Enabling complete atomicity for cross-chain applications through layered state commitments,” Cryptology ePrint Archive, Paper 2024/1084, 2024. [Online]. Available: https://eprint.iacr.org/2024/1084

    2024

  9. [9]

    On optimistic methods for concurrency control,

    H. T. Kung and J. T. Robinson, “On optimistic methods for concurrency control,”ACM Transactions on Database Systems (TODS), vol. 6, no. 2, pp. 213–226, 1981. 21 Algorithm 3:Executor Algorithm with Dependency Depth Limit Input:States r−1, Transaction sequenceσ= ˜σ r.I r−1.σr with new CATs inσ r markedpending, and maximum depthmaxDepth Output:Accepted seque...

    1981

  10. [10]

    Block-stm: Scaling blockchain execution by turning ordering curse to a performance blessing,

    R. Gelashvili, A. Spiegelman, Z. Xiang, G. Danezis, Z. Li, D. Malkhi, Y . Xia, and R. Zhou, “Block-stm: Scaling blockchain execution by turning ordering curse to a performance blessing,” 2022. [Online]. Available: https://arxiv.org/abs/2203.06871

    Pith/arXiv arXiv 2022

  11. [11]

    Atomicity and abstraction for cross-blockchain interactions,

    H. Lu, A. Jajoo, and K. S. Namjoshi, “Atomicity and abstraction for cross-blockchain interactions,”arXiv preprint arXiv:2403.07248, 2024. [Online]. Available: https://arxiv.org/abs/2403.07248

    Pith/arXiv arXiv 2024

  12. [12]

    Performance Overhead of Atomic Crosschain Transactions,

    P. Robinson, “Performance Overhead of Atomic Crosschain Transactions,” arXiv preprint arXiv:2005.10684, 2020, published 19 May 2020. [Online]. Available: https://arxiv.org/abs/2005.10684

    Pith/arXiv arXiv 2005

  13. [13]

    Layer 2 Atomic Cross-Blockchain Function Calls,

    P. Robinson and R. Ramesh, “Layer 2 Atomic Cross-Blockchain Function Calls,” arXiv preprint arXiv:2005.09790, 2020, published 19 May 2020. [Online]. Available: https://arxiv.org/abs/2005.09790

    Pith/arXiv arXiv 2005

  14. [14]

    Reality-based utxo ledger,

    S. M ¨uller, A. Penzkofer, N. Polyanskii, J. Theis, W. Sanders, and H. Moog, “Reality-based utxo ledger,” 2023. [Online]. Available: https://arxiv.org/abs/2205.01345

    Pith/arXiv arXiv 2023

  15. [15]

    Block-stm: Scaling blockchain execution by turning ordering curse to a performance blessing,

    R. Gelashvili, A. Spiegelman, Z. Xiang, G. Danezis, Z. Li, D. Malkhi, Y . Xia, and R. Zhou, “Block-stm: Scaling blockchain execution by turning ordering curse to a performance blessing,” inProceedings of the 28th ACM SIGPLAN Annual Symposium on Principles and Practice of Parallel Programming, ser. PPoPP ’23. New York, NY , USA: Association for Computing M...

    doi:10.1145/3572848.3577524 2023

  16. [16]

    The part-time parliament,

    L. Lamport, “The part-time parliament,”ACM Trans. Comput. Syst., vol. 16, no. 2, p. 133–169, May 1998. [Online]. Available: https://doi.org/10.1145/279227.279229

    doi:10.1145/279227.279229 1998

  17. [17]

    Practical byzantine fault tolerance,

    M. Castro and B. Liskov, “Practical byzantine fault tolerance,” in Proceedings of the Third Symposium on Operating Systems Design and Implementation, ser. OSDI ’99. USA: USENIX Association, 1999, p. 173–186

    1999

  18. [18]

    Non-blocking atomic commit in asynchronous distributed systems with failure detectors,

    R. Guerraoui, “Non-blocking atomic commit in asynchronous distributed systems with failure detectors,”Distributed Computing, vol. 15, no. 1, pp. 17–25, 2002. [Online]. Available: https://link.springer.com/article/ 10.1007/s00446-002-8027-4

    work page doi:10.1007/s00446-002-8027-4 2002

  19. [19]

    Implementing fault-tolerant services using the state machine approach: A tutorial,

    F. B. Schneider, “Implementing fault-tolerant services using the state machine approach: A tutorial,”ACM Computing Surveys, vol. 22, no. 4, pp. 299–319, 1990. [Online]. Available: https: //www.cs.cornell.edu/fbs/publications/SMSurvey.pdf

    1990

  20. [20]

    Consensus in the presence of partial synchrony,

    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

    doi:10.1145/42282.42283 1988

  21. [21]

    Sok: Communication across distributed ledgers,

    A. Zamyatin, M. Al-Bassam, D. Zindros, E. Kokoris-Kogias, P. Moreno- Sanchez, A. Kiayias, and W. J. Knottenbelt, “Sok: Communication across distributed ledgers,” inFinancial Cryptography and Data Secu- rity, N. Borisov and C. Diaz, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2021, pp. 3–36

    2021

  22. [22]

    Raptr: Prefix consensus for robust high-performance bft,

    A. Tonkikh, B. Arun, Z. Xiang, Z. Li, and A. Spiegelman, “Raptr: Prefix consensus for robust high-performance bft,” 2025. [Online]. Available: https://arxiv.org/abs/2504.18649

    Pith/arXiv arXiv 2025

  23. [23]

    Committee selection in dag distributed ledgers and applications,

    B. Ku ´smierz, S. M ¨uller, and A. Capossele, “Committee selection in dag distributed ledgers and applications,”Intelligent Computing, 2021

    2021

  24. [24]

    TPC benchmark C: Standard specification, revision 5.11,

    Transaction Processing Performance Council, “TPC benchmark C: Standard specification, revision 5.11,” TPC, Tech. Rep.,

  25. [25]

    Available: https://www.tpc.org/tpc documents current versions/pdf/tpc-c v5.11.0.pdf

    [Online]. Available: https://www.tpc.org/tpc documents current versions/pdf/tpc-c v5.11.0.pdf

  26. [26]

    Why does my transaction fail? A first look at failed transactions on the Solana blockchain,

    X. Zheng, Z. Wan, D. Lo, D. Xie, and X. Yang, “Why does my transaction fail? A first look at failed transactions on the Solana blockchain,”Proceedings of the ACM on Software Engineering, vol. 2, no. ISSTA, 2025. [Online]. Available: https: //dl.acm.org/doi/abs/10.1145/3728943

    work page doi:10.1145/3728943 2025

  27. [27]

    The espresso sequencing network: HotShot consensus, Tiramisu data-availability, and builder-exchange,

    J. Bearer, B. B ¨unz, P. Camacho, B. Chen, E. Davidson, B. Fisch, B. Fish, G. Gutoski, F. Krell, C. Lin, D. Malkhi, K. Nayak, K. Shen, A. Xiong, N. Yospe, and S. Long, “The espresso sequencing network: HotShot consensus, Tiramisu data-availability, and builder-exchange,” Cryptology ePrint Archive, Paper 2024/1189, 2024, preprint. [Online]. Available: http...

    2024

  28. [28]

    Espresso systems and catalyst collaborate to improve interoperability,

    Espresso Systems, “Espresso systems and catalyst collaborate to improve interoperability,” https://medium.com/@espressosys/espresso-systems- and-catalyst-collaborate-to-improve-interoperability-239addbe2c2b, 2023, accessed 2025-07-24

    2023

  29. [29]

    LayerZero: An omnichain interoperability protocol,

    LayerZero Labs, “LayerZero: An omnichain interoperability protocol,” https://layerzero.network/, 2024, accessed: 2025-07-24

    2024

  30. [30]

    Overview of Polkadot and its design considerations,

    J. Burdges, A. Cevallos, P. Czaban, R. Habermeier, S. Hosseini, F. Lama, H. K. Alper, X. Luo, F. Shirazi, A. Stewart, and G. Wood, “Overview of Polkadot and its design considerations,”arXiv preprint arXiv:2005.13456, 2020

    Pith/arXiv arXiv 2005

  31. [31]

    Overview: Polkadot chain architecture,

    Polkadot Developers, “Overview: Polkadot chain architecture,” 2023, accessed: 2025-07-24. [Online]. Available: https://docs.polkadot.com/ polkadot-protocol/architecture/polkadot-chain/overview

    2023

  32. [32]

    XCM part III: Execution and error management,

    G. Wood, “XCM part III: Execution and error management,” Polkadot Blog, 2021, accessed: 2026-03-

    2021

  33. [33]

    Available: https://medium.com/polkadot-network/ xcm-part-iii-execution-and-error-management-ceb8155dd166

    [Online]. Available: https://medium.com/polkadot-network/ xcm-part-iii-execution-and-error-management-ceb8155dd166

  34. [34]

    Analyzing the performance of the inter-blockchain communication protocol,

    J. O. Chervinski, D. Kreutz, and J. Yu, “Analyzing the performance of the inter-blockchain communication protocol,” inProceedings of the 53rd Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). IEEE, 2023, pp. 53–65. [Online]. Available: https://arxiv.org/abs/2303.10844

    Pith/arXiv arXiv 2023

  35. [35]

    Cross-chain deals and adversarial commerce,

    M. Herlihy, B. Liskov, and L. Shrira, “Cross-chain deals and adversarial commerce,”Proceedings of the VLDB Endowment, 22 vol. 13, no. 2, pp. 100–113, 2019. [Online]. Available: https: //www.vldb.org/pvldb/vol13/p100-herlihy.pdf

    2019

  36. [36]

    CAPER: A cross- application permissioned blockchain,

    M. J. Amiri, D. Agrawal, and A. E. Abbadi, “CAPER: A cross- application permissioned blockchain,” inProceedings of the VLDB Endowment, vol. 12, no. 11. VLDB Endowment, 2019, pp. 1385–1398. [Online]. Available: https://www.vldb.org/pvldb/vol12/p1385-amiri.pdf

    2019

  37. [37]

    ByShard: Sharding in a byzantine environment,

    J. Hellings and M. Sadoghi, “ByShard: Sharding in a byzantine environment,”The VLDB Journal, vol. 32, pp. 1343–1367, 2023, conference version: https://vldb.org/pvldb/vol14/p2230-hellings. pdf. [Online]. Available: https://link.springer.com/article/10.1007/ s00778-023-00794-0

    2023