1
CATs: Secure Blockchain Interoperability with Cross-chain Atomic Transactions
arXiv:2607.05387v1 [cs.DC] 6 Jul 2026
Andreas Penzkofer Move Industries San Francisco, USA
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.
I. I NTRODUCTION Blockchain systems are increasingly evolving into multichain and multi-layered ecosystems, offering new scalability and specialization benefits at the cost of significant interoperability challenges. In a rollup-centric Ethereum landscape, dozens of Layer-2 (L2) networks now operate in parallel, while alternative Layer-1 (L1) chains proliferate. This proliferation has introduced fundamental issues: fragmented liquidity, crosschain transaction latency, and a lack of atomicity in interchain operations. While transactions may be faster and cheaper on individual chains, the overall user experience and capital efficiency suffer dramatically from this fragmentation. A. Multi-Chain Interoperability In the following, we outline the challenges and opportunities in multi-chain interoperability. Fragmentation of Liquidity Across Chains and Layers: Scaling via multiple chains or rollups inherently fragments liquidity and state. Each L2 operates as a separate execution environment with its own asset instances and protocols. Consequently, capital that was once pooled on L1 becomes
Franck Cassez Movement Labs Sydney, Australia
trapped in isolated silos across chains, dramatically reducing market depth and efficiency. DeFi protocols struggle to maintain deep liquidity across all networks, forcing users into suboptimal pricing or complex multi-step maneuvers. A simple token purchase may require network switching, asset bridging, and fee payments across multiple chains, creating significant friction and risk. This maze of isolated chains fundamentally undermines the composability and seamlessness expected from a unified platform. Fragmented liquidity has emerged as a critical scaling trade-off, where throughput gains and specialized execution come at the expense of capital efficiency and user convenience. To address this, projects like AggLayer [1] propose a neutral cross-chain execution layer that unifies liquidity, users, and state across sovereign chains, using Ethereum as the base for finality [2], [3]. By introducing a shared execution layer and unified bridge model, such designs aim to concentrate liquidity and support seamless crosschain interactions without manual bridging. The Ethereum community also explores standards, which allow applications to operate across multiple chains through a single abstracted interface. ERC-7683 in particular defines a way for users to express an intent (e.g. swap assets across chains) as one highlevel request, which a network of relayers then executes across chains on the user’s behalf [4]. This and other standards [5], [6] seek to give users the impression of a unified liquidity pool and one-step access to all chains. The solutions recognize that a multi-chain ecosystem needs to restore composability and liquidity of a single network, most prominently through a common coordination layer. Latency in Cross-Chain Transactions: Cross-chain transactions can introduce significant latency, which hampers user experience and protocol composability. Unlike single-chain operations, they involve multi-step processes—such as locking assets, relaying messages, and unlocking or minting on the target chain—with added confirmation delays for security. For example, moving assets from Ethereum to a rollup can take minutes, while withdrawals from optimistic rollups may take days due to finality or challenge periods. This latency prevents atomic execution of multi-chain DeFi strategies (for instance, collateralizing an asset on one chain to borrow on another, or arbitraging price differences across exchanges on two chains), forcing developers to break interactions into separate steps vulnerable to market changes. As a result, users avoid cross-chain workflows, and composability suffers. Emerging solutions like Espresso aim to address this by enabling fast interim confirmations and near-instant cross-rollup
2
communication without waiting for full L1 settlement [3]. Such protocols rely on a confirmation layer to provide fast “finality”, often utilizing a separate consensus mechanism. Lack of Atomicity in Multi-Chain Interactions: Cross-chain operations typically lack atomicity, meaning that a single logical transaction spanning multiple blockchains cannot be executed in an all-or-nothing fashion. Unlike single-chain transactions, there is no shared view or transaction manager to guarantee coordinated commits. This creates failure scenarios where one part of a trade might succeed while another fails, leaving users in inconsistent or loss-bearing states. Even protocols like hash-time-lock contracts (HTLCs), designed to enforce mutual exchange or refund, rely on timeouts and can fail under delays or crashes, undermining atomic guarantees [7]. The absence of atomicity complicates dApp design, requiring developers to simulate rollback mechanisms across independent chains, which introduces security risks and implementation complexity. Research proposals such as decentralized witness networks and cryptographic commit protocols offer potential solutions [7], [8], but they are not yet widely adopted. For now, the inability to ensure atomic multi-chain interactions remains a major barrier to seamless cross-chain composability. Optimistic Concurrency Control: OCC [9] is a concurrency paradigm in transactional systems that assumes conflicts are rare and allows transactions to execute speculatively without locks. Transactions proceed independently and are validated only at commit time, where conflicting ones are aborted and retried. This approach has been adopted in high-performance blockchain systems such as Aptos, where the Block-STM engine [10] leverages OCC to parallelize simulation of execution before commitment while ensuring determinism. Our protocol shares conceptual similarities—such as partially ordered execution and deferred resolution of outcomes. It does not rely on speculative rollback, but takes into account all relevant state transitions. It also embeds causal dependencies directly into the scheduling and confirmation layers, using explicit postponement or skipping rules and synchronization guarantees to ensure atomicity, liveness, and efficient composability across chains. The similarity is not coincidental, and e.g., [8] implements a cross-chain atomic transaction protocol based on OCC, for instance.
design enables atomic, low-latency, and composable crosschain interactions without requiring speculative rollback or relying fully on centralized coordination. The protocol ensures correctness through explicit dependency tracking and synchronization guarantees, while maintaining liveness under chain-level asynchrony and partial failures. We detail the architecture, formalize the protocol’s guarantees, and evaluate its performance under realistic network conditions and adversarial scenarios. Through simulation, we show that the protocol is performant and practical even under high load and a great degree of contention on state key accesses. The remainder of the paper is structured as follows: Sec. II introduces an exemplary motivation for the protocol; Sec. III introduces the system model and assumptions; Sec. IV describes the protocol in detail; Sec. V analyzes its correctness and liveness properties; Sec. VI presents an empirical evaluation; and Sec. VII discusses related work and key distinctions. We conclude in Sec. VIII. II. M OTIVATION To illustrate the need for cross-chain transaction protocols that ensure atomicity, are minimally blocking, and guarantee liveness, we walk through a concrete scenario with two chains, Chain 1 and Chain 2, and a unique asset (token) that exists with a corresponding representation on both chains. A. Regular transactions. Let us assume, for simplicity, that each chain offers a single type of transaction Send(sender, recipient, amount), where amount is the amount of the asset to be transferred from sender to recipient. The state of the chain is a function that maps each account to its balance. The execution of a transaction on a chain either succeeds or fails, and the status of the execution of a transaction is either success or failure. When a transaction is successful, the state of the chain is updated accordingly. If it fails the state of the chain is left unchanged. The status of the execution of a transaction depends on the state of the chain. For instance, Send(Bob, Charlie, 200) succeeds from a state s if and only if s(Bob) ≥ 200 i.e., Bob’s balance is at least 200. If it succeeds, Bob’s balance is decreased by 200 and Charlie’s balance is increased by 200. If Bob’s balance is less than 200 in state s, the execution of the transaction fails.
B. Contributions and Paper Structure Fragmented liquidity, high latency, and non-atomic operations limit blockchain interoperability. As can be seen in the related work Sec. VII, solutions like AggLayer and Espresso aim to bridge these gaps in Ethereum, while other L1s, such as Polkadot and Cosmos, integrate interoperability more natively, albeit at the cost of other constraints. A path forward will blend infrastructure coordination, cryptographic assurance, and protocol design to achieve scalable, seamless multi-chain ecosystems. In this paper, we present a novel protocol for atomic multichain execution that overcomes the limitations of existing interoperability solutions by embedding causal dependencies directly into the scheduling and confirmation process. Our
B. Multi-chain transactions. For simplicity, assume we have a shared sequencer that can order and schedule pairs of transactions on the two chains. We use the pair [t, Skip] for a transaction t on Chain 1 and no counterparty on Chain 2. Users submit pairs of transactions (which may contain Skip) directly to the sequencer, and the sequencer will order the tuple of transactions to be executed on the two chains. We consider a scenario involving several participants: Alice, Bob, Charlie, Dave, and Eve, see Figure 1. The sequence of transactions to execute is shown in Table I. The semantics of CATs is that either all parts of a CAT succeed or none do [11]–[13]. As a result, the status of τ2 depends on the status of the two sides Send(Bob, Charlie,
3
Chain 1
Chain 2
Initial: A:100 B:100 C:0 D:0 E:0
Initial: A:0 B:100 C:200 D:400 E:0
τ1 : Send(Alice, Bob, 100) depends on τ2 : Send(Bob, Charlie, 200)
synchronize
Our protocol must ensure atomicity. This means that either all constituent transactions of a CAT succeed, or all fail. No partial execution is allowed, maintaining consistency across all involved chains.
τ2 : Send(Charlie, Bob, 200) depends on τ3 : Send(Bob, Eve, 300) τ4 : Send(Dave, Eve, 400)
C. Minimally-blocking protocol.
Some transactions depend on the outcome of other transactions. As shown in BlockSTM [10], even in the case where Fig. 1. A scenario with 5 participants and a cross-chain atomic transaction (CAT) that swaps assets between Bob and Charlie on execution could be optimistically parallelized, the application two chains. Time evolves from top to bottom. Examples of balances of a transaction (i.e., its change set) to the state has to await are shown for an initial state and after the transactions are executed, other transactions it depends on. For example, in Sec. II, for the case where all transactions succeed. Dependencies are shown τ3 (Send(Bob, Eve, 300)) depends on the outcome of τ2 with dashed lines. (Send(Charlie, Bob, 200)). We say a transaction is blocking if it prevents other transactions from being executed until its Tx Type Chain 1 Chain 2 execution outcome is known. τ1 Regular Send(Alice, Bob, 100) Skip One way to implement a protocol for CATs is, in prinτ2 Cross-chain Send(Bob, Charlie, 200) Send(Charlie, Bob, 200) τ3 Regular Skip Send(Bob, Alice, 300) ciple, to synchronize at each CAT and block entirely until τ4 Regular Skip Send(Dave, Eve, 400) resolved. However, this approach is not optimal as it introduces TABLE I unnecessary delays. A better approach is to minimize the S EQUENCE OF TRANSACTIONS TO EXECUTE . blocking of transactions and allow transactions to be executed (and accepted) out of order, as long as they are independent transactions, see Sec. IV-D for a description of the transaction 200) and Send(Charlie, Bob, 200) on their respective chains. flow. Without coordination between the two chains, there are two For example, consider the scenario in Figure 1 where τ4 possible classes of outcomes for each side of τ2 : on Chain 1, could be blocked because of τ3 . This is not optimal as this Send(Bob, Charlie, 200) succeeds or fails, and on Chain 2, transaction is independent of τ2 and τ3 . Maintaining the exact Send(Charlie, Bob, 200) succeeds or fails. order of transactions is blocking and may delay every other This is the source of several difficulties in implementing transaction ordered after a CAT. For instance, the transactions τ3 and τ4 can only be processed after τ2 has been completed. cross-chain atomic transactions: 1) No trusted interchain communication. The two chains This may be unavoidable for some transactions like τ3 as its are independent and cannot directly communicate their execution depends on the outcome of τ2 . However, τ4 does not depend on the result of τ2 . states and transactions’ statuses. 2) Rollback complexity. For a cross-chain transaction τ2 = The CAT protocol should be minimally-blocking. This [t1 , t2 ], once t1 is confirmed on Chain 1, but t2 fails means that transactions that are independent of blocking on Chain 2, rolling back t1 is non-trivial (especially in transactions should be allowed to be executed without chains where transactions are supposed to be final once any delay. included in a block) and may lead to loss of user funds1 . 3) Independent simulation. Our protocol addresses this through simulation and coordination before commitD. Eventual progress. ment [13]. More specifically, we have to first determine The chains have to synchronize (and agree) on transaction the status of a transaction on each chain (i.e., simulate outcomes that affect multiple chains. In reality, the two chains it) but cannot commit it yet. may run at different speeds, and one chain may have to wait for 4) Necessity of a shared confirmation layer. Next, a the other before committing its new state. This synchronization consensus has to be reached on the combined outcome. requirement can lead to significant delays, as faster chains If both sides of a cross-chain transaction succeed, the must wait for slower ones to complete their operations. For results can be committed. If at least one side of a crossthis reason, we must ensure liveness of the protocol, which can chain transaction fails, the chains should agree on the be achieved by introducing a timeout mechanism and using a failure and skip it. Without a shared confirmation layer, shared confirmation layer. parts of a CAT may be committed on one chain before the other part is executed on the other chain, or vice The CAT protocol must ensure liveness. This means versa. This motivates the need for a common confirmaall transactions eventually reach a final status (success tion layer that coordinates execution across chains. or failure) within a bounded time, preventing indefinite blocking and ensuring the system can make progress even 1 For example in the example in Table I, if the first part of τ succeeds, but 2 in the presence of failures or extreme network delays. the second part fails, Bob would lose 200 tokens. Final: A:0 B:0 C:200 D:0 E:0
Final: A:0 B:0 C:0 D:0 E:700
4
III. T RANSACTION AND C OMPUTATION M ODEL In this section, we formalize the semantics of transactions, their computation, and the dependencies between them. We define the mathematical foundation for transaction execution, state transitions, and dependency relationships that will be used throughout the paper. We assume homogeneous chains sharing the same VM architecture; the Transaction Processor (TP) is a native component of each chain, not an external addon. Heterogeneous chain integration is feasible in principle given appropriate VM-level adaptations, but is outside the scope of this work. While we use cross-chain atomic transactions (CATs) as examples, the focus here is on the transaction model itself rather than the multi-chain aspects. The multichain coordination and atomicity properties are addressed in Section IV. A. Maps and sequences A partial map is a partial function m : K ⇀ V that may not be defined on all of K. The domain of m, dom(m) ⊆ K, is the set of keys on which m is defined. The codomain of m, codom(m) ⊆ V, is the set of values that m can take. We write [k1 7→ v1 , k2 7→ v2 , · · · , kn 7→ vn ] for the partial map that maps ki to vi for 1 ≤ i ≤ n, where n is the total number of key-value pairs in the map. The empty map [ ] is the partial map with dom([ ]) = ∅, i.e., defined nowhere. A total map is a partial map defined everywhere i.e., with dom(m) = K. We write m : K → V (→ instead of ⇀) for a total map. Given two partial maps m1 : K ⇀ V and m2 : K ⇀ V, the update of m1 with m2 denoted m1 ⊕ m2 is a partial map defined on dom(m1 ) ∪ dom(m2 ) as: ( m2 (k) if k ∈ dom(m2 ) (m1 ⊕ m2 )(k) = m1 (k) otherwise For a sequence σ = e1 .e2 . · · · .en , we let |σ| = n be the length of the sequence. The empty sequence is ε and has length |ε| = 0. We denote σ1 .σ2 as the concatenation of sequences. For 1 ≤ i ≤ |σ|, we write σ[i] for ei . For 1 ≤ i ≤ j ≤ |σ|, σ[i..j] is the sequence ei . · · · .ej . B. Transactions We assume both chains offer the set T of transactions. We require that T contains a special transaction Skip ∈ T that has no effect. A CAT is a pair (t1 , t2 ) with tj ∈ T , j ∈ {1, 2}, where t1 ̸= Skip and t2 ̸= Skip. If t1 = Skip or t2 = Skip, the transaction is a regular transaction (involving only one chain). This definition enables us to use the same notation for regular transactions and CATs. Transactions, regular or CAT, are submitted to the network N as pairs of transactions, one for each chain. C. States, change sets, and state transitions A state s of chain Ci , i = 1, 2 is a total map s : K → V. The set K can be thought of as the set of memory locations or global storage locations of chain Ci , and the set V as the set of values that can be stored in these locations. We assume
that both chains have the same type of memory locations K and the same type of values V. The initial state of the chain is the genesis state G(Ci ). A change set is a partial map from K to V. The semantics of the execution of a transaction t ∈ T from a state s is defined by a change set function ChangeSet(s, t) : K ⇀ V, and we require that: ChangeSet(s, Skip) = [ ] The function Next defines the state obtained after executing t from s: Next(s, t) = s ⊕ ChangeSet(s, t) We extend Next to sequences of transactions: Next(s, ε) = sNext(s, t.σ) = Next(Next(s, t), σ) To capture the status of the execution of a transaction, we t/α define the state transition function s −−−→ s′ as follows: α ∈ {success, failure} is the status of the execution of transaction t from state s, and s′ = Next(s, t). The transition function must satisfy the following requirements: t/failure
s −−−−−−→ s′ =⇒ ChangeSet(s, t) = [ ] Skip/α
s −−−−−→ s′ =⇒ α = success ∧ ChangeSet(s, Skip) = [ ] t/failure
A consequence of the above is that s −−−−−−→ s′ implies Next(s, t) = s, and that Next(s, Skip) = s. Given a sequence of transactions σ = t1 .t2 . · · · .tn , the execution γ of the sequence is a sequence of state transitions: t1 /α1
t2 /α2
tn /αn
γ : s0 −−−−−→ s1 −−−−−→ · · · −−−−−→ sn where αi , 1 ≤ i ≤ n, is the status of the execution of transaction ti . The trace of γ is: trace(γ) = t1 /α1 .t2 /α2 . · · · .tn /αn D. Reads and writes, memory traces The execution of a transaction t from a given state s may read or write a set of memory locations in K. We define the following operations: reads(k) to denote a read operation that reads the value of location k ∈ K and writes(k, v) to denote a write operation that writes the value v ∈ V to location k. There are several other operations performed during the computation of a transaction (e.g., arithmetic, control flow, etc.), but we do not need to consider them for the purpose of this discussion. The memory trace, MemTr(s, t), resulting from the execution of a transaction t from a state s is a sequence of reads(·) and writes(·, ·) operations. For instance, assuming K and V are the set of non-negative integers, the sequences of operations µi , 1 ≤ i ≤ 6 in Table II each represent a memory trace. The memory access pattern for these transactions is visualized in Figure 2. Given a state s and a sequence of transactions σ, MemTr(s, σ) is the concatenation of sequences of reads and
5
Transaction
Memory Trace
Range
t1 = σ[1]
µ1 = reads(10).writes(20, v1 ).reads(30)
[1, 3]
t2 = σ[2]
µ2 = reads(40).writes(50, v2 ).reads(60)
[4, 6]
t3 = σ[3]
µ3 = reads(20).writes(60, v3 )
[7, 8]
t4 = σ[4]
µ4 = writes(60, v4 ).reads(50)
[9, 10]
t5 = σ[5]
µ5 = writes(70, v5 )
[11, 11]
t6 = σ[6]
µ6 = writes(80, v6 )
[12, 12]
TABLE II R EFERENCE TRANSACTION SET USED THROUGHOUT THE PAPER . C OLORED NUMBERS INDICATE THE MEMORY LOCATIONS OF READ ( WRITE ) OPERATIONS . vi IS THE VALUE WRITTEN TO THE MEMORY LOCATION . F OR A MORE VISUAL REPRESENTATION , SEE F IGURE 2 AND F IGURE 4.
Memory location
t1
t2
t3
t4
t5
t6
10 20 30 40 50 60 70 80
(s, σ[1])
(Next(s, σ[1]), σ[2])
(10)
(20, v1 )
(30)
(40)
(50, v2 )
(60)
1
2
3
4
5
6
(s, σ, 1) = [1, 3]
(s, σ, 2) = [4, 6]
Fig. 3. Memory traces µ1 and µ2 with ranges, as shown in Figure 2 and Table II. Read (Write) operations are shown with their value written to the memory location.
F. External reads and writes Given a memory trace µ, we define the external reads xReads(µ) as the set of memory locations that are read but not preceded by a write to the same location within the trace. These definitions use the indexing structure of memory traces as formalized in the previous section on memory ranges: xReads(µ) = {k ∈ K | ∃i ∈ [1, |µ|] : µ[i] = reads(k)∧ ∀j < i : µ[j] ̸= writes(k, ·)}
reads
writes
xReads
xWrites
Similarly, we define the external writes xWrites(µ) as a partial map that captures the final key-value pair written to each memory location in the trace:
Fig. 2. Memory locations matrix showing read and write operations for each transaction from Table II. Each row represents a memory location, and each column represents an operation in the memory trace of the transaction. External reads and writes for the sequence σ = t1 .t2 .t3 .t4 .t5 .t6 are highlighted with borders.
writes to locations in K over each transaction σ[i], 1 ≤ i ≤ |σ|. We extend MemTr to sequences of transactions: MemTr(s, ε) = ε
xWrites(µ) = [k 7→ v | ∃i ∈ [1, |µ|] : µ[i] = writes(k, v)∧ ∀j > i : µ[j] ̸= writes(k, ·)] Let µ′ = µ1 .µ2 .µ3 .µ4 .µ5 .µ6 be the concatenated memory trace of the transactions from Table II. The external reads are xReads(µ′ ) = {10, 30, 40, 60} because reads(20) in t3 is preceded by a write to 20 (in t1 ) and reads(50) in t4 is preceded by a write to 50 (in t2 ), so neither are external reads. We have xWrites(µ′ ) = {20 7→ v1 , 50 7→ v2 , 60 7→ v4 , 70 7→ v5 , 80 7→ v6 }, since t4 writes to 60 again after t3 ; see Figure 2.
MemTr(s, t.σ) = MemTr(s, t).MemTr(Next(s, t), σ) G. Dependencies E. Memory ranges The range of each transaction in MemTr(s, σ) is the section of reads and writes occurring when executing the transaction. We can define the function Range(s, σ, i) that returns a (convex) interval of indices (range) of MemTr(s, σ) that corresponds to the execution of the transaction σ[i]. For instance, assume the memory trace of the sequence of transactions σ = σ[1].σ[2] (see Table II) from state s is MemTr(s, σ) = MemTr(s, σ[1].σ[2]) = MemTr(s, σ[1]) . MemTr(Next(s, σ[1]), σ[2]) {z } | {z } | µ1
µ2
= µ1 .µ2 The range of σ[1] in MemTr(s, σ) is Range(s, σ, 1) = [1, 3] and the range of σ[2] is Range(s, σ, 2) = [4, 6] as shown in Figure 3.
Given a sequence of transactions σ and a range index 0 ≤ i < |MemTr(σ)| such that there is a read at this location i.e., MemTr(σ)[i] = reads(ℓ) for some ℓ ∈ K, we define LastWrite(σ, i) to be the most recent write to this location in the memory trace. Let K = {j < i | MemTr(σ)[j] = writes(ℓ, −)}. The function LastWrite(σ, i) is defined2 by maxk∈K k. Given a state s, the result of the execution of σ from s is given by the Next function as defined in Section III-C. This assumes that we execute the transactions in sequence. However, for performance reasons, we may want to compute some of them in parallel (as is the case with BlockSTM), or as we will later see in Sec. IV-D, we may want to execute some of them out of order. For the latter to be possible, we need to make sure that transactions executed out of order give the same results as if they were executed in sequence. This can be formalized by a notion of dependency between transactions. 2 With the convention that max ∅ = −∞.
6
1) Read-Write dependency.: A transaction σ[j] depends directly on a transaction σ[i] if i < j and σ[j] reads from a location that was written by σ[i]. This is a read-write dependency. Given a state s and i < j, we define the dependency relation · →R s · between transactions in a sequence of transactions σ by: let µ = MemTr(s, σ),
external reads and writes of σ[i] are completely disjoint from the external reads and writes of σ[j], i.e., :
σ[j] →R s σ[i] ⇐⇒
Proof. By definition, σ[j] ̸↔s σ[i] means σ[j] does not read or write to any location written by σ[i]. For direct independence, both σ[j] ̸↔s σ[i] and σ[i] ̸↔s σ[j] must hold, which requires that external reads and writes are completely disjoint in both directions. Conversely, if external reads and writes are completely R W disjoint, then σ[j] ̸→R s σ[i], σ[i] ̸→s σ[j], σ[j] ̸→s σ[i], W and σ[i] ̸→s σ[j], establishing direct independence.
2) Write-Write dependency.: A transaction σ[j] has a writewrite dependency on transaction σ[i] if i < j and both transactions write to the same memory location. We define this as: σ[j] →W s σ[i] ⇐⇒ ∃k ∈ K, [a memory location] ∃n ∈ Range(s, σ, j), [an operation in σ[j]] ∃m ∈ Range(s, σ, i), [an operation in σ[i]] µ[n] = writes(k, ·), [which is a writes(k, ·)] µ[m] = writes(k, ·), [and σ[i] also writes to k] A write-write dependency is, for example, relevant if we consider the final value written to a location. Note that nonce ordering is itself a dependency: nonce n+1 from the same account depends on nonce n, which is a special case of a write-write dependency on the account’s nonce storage slot. Monotonicity is thus enforced naturally by the dependency mechanism. 3) dependsOn.: We can define the dependsOn relation as the combination of the direct read-write dependency and the direct write-write dependency. n W σ[j] →s σ[i] ⇐⇒ σ[j] →R s σ[i] ∧ σ[j] →s σ[i] We can define the transitive closure, dependsOn, · →+ s · of the direct dependency relation as the smallest relation that satisfies: σ[j] →s σ[k] =⇒ σ[j] →+ s σ[k] + σ[j] →s σ[k] ∧ σ[k] →s σ[i] =⇒ σ[j] →+ s σ[i] A transaction σ[j] depends on a transaction σ[i] if σ[j] →+ s σ[i]; otherwise, we say that σ[j] does not depend on σ[i] and write σ[j] ̸→+ s σ[i]. 4) Independence.: We define the mutual dependency relation as the case where two transactions depend on each other in either direction: σ[i] ↔+ s σ[j]
⇐⇒
σ[i] →+ s σ[j]
∨
σ[j] →+ s σ[i]
Similarly, we say that two transactions σ[i] and σ[j] are independent if they are not mutually dependent, i.e., + + σ[i] ̸↔+ s σ[j] ⇐⇒ σ[i] ̸→s σ[j] ∧ σ[j] ̸→s σ[i]
Lemma 1 (Independence and disjoint memory access). Two transactions σ[i] and σ[j] are directly independent iff their
(xReads(MemTr(s, σ[i])) ∪ xWrites(MemTr(s, σ[i]))) ∩ (xReads(MemTr(s, σ[j])) ∪ xWrites(MemTr(s, σ[j]))) = ∅
Intuitively, we can extend this to sequences. I.e., instead of σ[i] being a transaction, we may also replace it by an entire sequence σ ′ . 5) Dependency graph.: The graph of the dependency relation in state s for sequence of transactions σ is the dependency graph D(s, σ), a directed acyclic graph (DAG), with set of nodes σ[j], 1 ≤ j ≤ |σ|, and the set of directed edges defined by the pairs (σ[j], σ[i]) such that σ[j] →R s σ[i]. From the definition of the dependency graph, it follows that σ[j] →+ s σ[i] if and only if there is a path from σ[j] to σ[i] in the dependency graph D(s, σ). For example, consider the sequence of transactions σ ′ = t1 .t2 .t3 .t4 , from Table II. The DAG is depicted in Figure 4, left. From state s0 , this sequence of transactions produces the execution: t1 /α1
t2 /α2
t3 /α3
t4 /α4
s0 −−−−−→ s1 −−−−−→ s2 −−−−−→ s3 −−−−−→ s4 In this example, t2 does not depend on any other transaction and is an end node. However, t3 →s t1 because t3 reads from location 20 which was last written by t1 . Similarly, t4 →s t3 as it writes to location 60 which was last written by t3 . Also, t4 →s t2 as it reads from location 50 which was last written by t2 . CAT dependency depth
[a memory location] ∃k ∈ K, ∃n ∈ Range(s, σ, j), [an operation in σ[j]] µ[n] = reads(k), [which is a reads(k)] LastWrite(µ, n) ∈ Range(s, σ, i), [Last write is by σ[i]]
σ[i] ̸↔s σ[j] ⇐⇒
t4
Regular transaction
t3
CAT
2
1 0
t1
t6 t2
t5
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. Fig. 4.
6) CAT dependency depth.: In a cross-chain transaction setting, whether any part of a CAT is committed or not depends on the successful computation of the other parts of the CAT (on the other chains). For regular transactions on a single chain,
7
this is not a problem, as in the description of our model, the other chain executes a Skip which is always successful. Hence, the result of the computation can be committed straightaway.3 In contrast, for a CAT T = (t1 , t2 ) we have to wait before committing the results of the involved transactions. This means that if there is a CAT in the sequence σ, we can execute all the regular transactions before the CAT, but the transactions after the CAT may be delayed and postponed to the next block or beyond. However, if we can determine that some transactions after the CAT are independent of the CAT, we can execute them. This has similarity to BlockSTM, where independent transactions are computed in parallel; however, it goes beyond this by allowing to execute transactions out of order.
impacted by memory locations that are not read. We denote s ≡K s′ if ∀k ∈ K, s′ [k] = s[k] i.e., the states s and s′ agree on the values of the keys in K.
Let us identify how we determine whether a transaction is independent of a CAT. Assume we have on Chain 1 the above CAT T , a sequence of regular transactions σ and a state s. There are two possible scenarios for T : success or failure. We, thus, must consider two sequences of transactions: one in which T succeeds, resulting in sequence σsuccess = t1 .σ, and one in which T fails, resulting in sequence σfailure = Skip.σ. As one may expect, as the number of CATs increases, this could result in an exponentially growing number of scenarios. Efficient algorithms for managing multiple conflicting states have been presented, for example, in [14]. However, it remains important to limit the number of scenarios. A useful metric that can be utilized to limit the number of branching scenarios is to limit the number of CATs that can be pending and dependent on each other.
If a transaction σ[j] ̸→+ s σ[i] (see Sec. III-G) with respect to a state s, then the change sets of the two transactions can be computed in parallel. If two transactions are independent (i.e., σ[i] ̸↔+ s σ[j], see Sec. III-G) with respect to a state s, then the change sets of the two transactions can also be applied out of order.
We define the CAT dependency depth depths,σ of a transaction σ[i] ∈ σ on s recursively as follows: Let Di = { j < i | σ[i] ↔+ s σ[j] } be the set of prior transactions in σ that σ[i] mutually depends on with respect to s. Then: depths,σ (σ[i]) = ( max { depths,σ (σ[j]) | j ∈ Di } ∪ {0} +
1 0
σ[i] is CAT, otherwise.
In Figure 4, we show the CAT dependency depths for the transactions in Table II. H. Change Sets and External Writes In the semantics of transactions, there should be a natural correspondence between the change set of a transaction and the external writes of its memory trace. The change set of a transaction t describes the updates after the transaction has been executed, whereas the external writes of the memory trace of t describe the memory locations that are written to by t. The resulting sets are identical. Observation 1 (Change sets are external writes). For any state s and a transaction t, ChangeSet(s, t) = xWrites(MemTr(s, t)) Symmetrically, the semantics of a transaction can only depend on the memory it reads during the execution and is not 3 Unless it depends on a CAT, in which case it is added to a pending list.
Observation 2 (State equivalence and external reads). Let s be a state and t a transaction. Let K = xReads(MemTr(s, t)). For any state s′ ≡K s we have: MemTr(s′ , t) = MemTr(s, t)
(1)
Combined with Observation 1, we have: ChangeSet(s′ , t) = ChangeSet(s, t)
(2)
I. Independent transactions and change sets
In BlockSTM [15], the term execution of incarnations is used for what we call computed. In literature, execution is frequently considered to be a successful application of a transaction to a state. Hence, we choose to say a transaction is executed if it is computed, successfully validated, and applied to the state. Lemma 2 (Parallel computation of non-dependent transactions). Let σ = t1 .t2 be a sequence of two transactions and s0 a state. Assume t2 ̸→s0 t1 and the execution of σ from s t t produces the execution s0 −−1→ s1 −−2→ s2 . Then ChangeSet(s1 , t2 ) = ChangeSet(s0 , t2 ) Proof. Let µ1 = MemTr(s0 , t1 ) and µ2 = MemTr(s1 , t2 ) denote the memory traces of t1 and t2 from the initial state s0 and the state s1 , respectively. Let K2 = xReads(µ2 ). If K2 = ∅, then s0 ≡K2 s1 and by Observation 2, we have ChangeSet(s0 , t2 ) = ChangeSet(s1 , t2 ). Otherwise let k ∈ K2 . Then k cannot be written to in µ1 . The proof is by contradiction. Assume writes(k, v) ∈ xWrites(µ1 ). Then t2 →s0 t1 which is a contradiction. As a result, writes(k, v) ̸∈ xWrites(µ1 ), by Observation 1 writes(k, v) ̸∈ ChangeSet(s0 , t1 ) and, therefore, s0 [k] = s1 [k] by definition of Next and s1 = Next(s0 , t1 ) ⊕ ChangeSet(s0 , t1 ). This implies s0 ≡K2 s1 , and by Observation 2 we have ChangeSet(s0 , t2 ) = ChangeSet(s1 , t2 ). In BlockSTM [15], the change sets of transactions are computed optimistically in parallel. Once the change sets are computed, they await to be applied to the source state s to obtain the next state s′ . In order to be applied, they must pass a validation step. This validation step ensures that the order of transactions is respected. For a transaction for which it is later discovered that it has dependencies on other transactions, the change set is not applied and the transaction has to be recomputed. In the example of Figure 4, this would imply that the transactions t1 and t2 can be successfully computed in parallel
8
because they do not depend on each other. The transaction t3 depends on t1 and must be re-computed (if it would be computed in parallel). The transaction t4 also depends on both t1 and t2 . We now take this approach one step further. In our model, we permit to apply transactions out of order, i.e., permit to change the order of transactions if the final state remains the same. An application of this, as we will see in Sec. IV-D, is that we can assign transactions to different output streams. Lemma 3 (Out-of-order execution of independent transactions). Let σ = t1 .t2 be a sequence of two transactions and s0 a state. Assume t2 ̸↔s0 t1 and the execution of σ from s0 t t produces the execution s0 −−1→ s1 −−2→ s2 . Then Next(s0 , t1 .t2 ) = Next(s0 , t2 .t1 ) Proof. By definition of independence, we have both t2 ̸→s0 t1 and t1 ̸→s0 t2 . From Lemma 2, since t2 ̸→s0 t1 , we have ChangeSet(s1 , t2 ) = ChangeSet(s0 , t2 ). Similarly, since t1 ̸→s0 t2 , we have ChangeSet(s0 , t1 ) = ChangeSet(Next(s0 , t2 ), t1 ). Now we can compute both execution orders: t t Order 1: s0 −−1→ s1 −−2→ s2 s2 = s1 ⊕ ChangeSet(s1 , t2 ) = s0 ⊕ ChangeSet(s0 , t1 ) ⊕ ChangeSet(s0 , t2 ) t
t
Order 2: s0 −−2→ s′1 −−1→ s′2 s′2 = s′1 ⊕ ChangeSet(s′1 , t1 ) = s0 ⊕ ChangeSet(s0 , t2 ) ⊕ ChangeSet(s0 , t1 ) Since the change sets are the same in both orders and the two ChangeSet operations are commutative, we have s2 = s′2 , which means Next(s0 , t1 .t2 ) = Next(s0 , t2 .t1 ).
IV. C ROSS - CHAIN ATOMIC TRANSACTIONS PROTOCOL In this section, we describe the CAT protocol. First, we define the requirements for a CAT protocol in Sec. IV-A. We then identify the components that are required for a minimal version of the CAT protocol in Sec. IV-C. In Sec. V, we address safety and liveness, as well as non-blocking properties. A. Requirements We clarify the requirements for a CAT protocol to deliver correct behavior for CATs. This involves identifying the conditions under which transactions should succeed or fail. Our goal is to describe the operational behavior informally and to move toward a precise problem formulation that can guide protocol design and correctness reasoning. An informal definition of the requirements for a CAT protocol is then as follows: • Simulation and Proposals. Each chain reports (i.e., proposes) the best effort status of its part of a CAT. A best effort status means the chain simulates the execution of the transaction for a given state and reports whether the transaction would have success or failure, without
actually committing any state changes to persistent storage. This allows chains to determine the transaction’s status without prematurely modifying their permanent state before consensus is reached. [8] introduces the term dirty state layer to describe the non-permanent storage that can be reverted once the status is determined. We propose a similar data storage layer; however, we require that it supports nesting. Thus, our data storage layer may support several instances—one for each possibility of a CAT’s status, see e.g., [14]. • Coordination. The protocol ensures coordination on the status of the CATs. • Confirmation. The protocol ensures consensus on the success or failure of all CATs: – success. A CAT should succeed if and only if all involved chains report successful execution of their respective parts and consensus is reached on the Status (before any potential timeout). – failure. A CAT should fail in all other cases: if any of the involved chains reports failed execution of their respective parts, or if consensus cannot be reached on the status before the timeout expires, then consensus must be reached on failure. On a fundamental level, our CAT protocol can be viewed in the context of Byzantine State Machine Replication [16], [17], where the replicated state spans multiple chains and agreement is required on the success or failure of coordinated atomic transactions. In this setting, we adopt the following definitions:4 1) Safety: If two honest chains decide on the Status of a given CAT T , they must decide identically. That is, if one chain confirms success for T , no other honest chain may confirm failure for T or remain undecided. 2) Liveness: If the confirmation layer operates correctly and a sequencer submits a well-formed CAT T to the confirmation layer, then the protocol must eventually decide success or failure of T and deliver that decision to the chain. 3) Non-blocking (optional): Transactions that do not depend on the outcome of a pending CAT must be able to proceed without delay. This ensures that CAT-related coordination does not unnecessarily penalize independent execution. Cross-chain atomic commitment is also a special case of the well-studied Non-Blocking Atomic Commitment (NBAC) problem [18], which addresses crash-tolerant consensus among processes that must all commit or all abort. However, NBAC is defined for the crash fault model and requires a perfect failure detector—an oracle that detects crashed participants so that the protocol can abort rather than block indefinitely. Our protocol operates in a Byzantine setting, where such a detector is unavailable; instead, the CL timeout mechanism serves 4 We note that, e.g., [8] uses the terms authenticity for verifiability in the context of cross-chain transaction statuses, and reliability and termination for eventual delivery and commitment of cross-chain transaction statuses (or results more generally). These terms are similar to our definitions, but we use the terms safety and liveness, as they provide better intuition for the requirements.
9
this role: if a chain’s executor does not submit its proposal within the CAT lifetime, the coordinator treats it as failed and aborts the CAT. Our requirements map directly to NBAC properties: Safety to Agreement, Liveness to Termination, the coordinator’s commit logic to Commit-Validity, and the CL timeout-triggered abort to Abort-Validity.
accepted submit transaction transactions (6) Transaction Processor sequences (1) Sequencer
ordered transaction sequences
B. Atomicity Definition Before describing the protocol components, we formally define what it means for a cross-chain transaction to be atomic. This definition will be used throughout our analysis in Sec. V to establish correctness properties.
(5) Resolver
(3) Executor
Chain 1 proposals
transaction sequences and Status updates
(2) Confirmation Layer (CL)
Status updates (4) Coordinator Common Infrastructure
Definition 1 (Cross-Chain Atomicity). A cross-chain transaction T = (t1 , t2 , . . . , tk ) is atomic if and only if: ∀i, j ∈ [1, k] :
Status(ti ) = Status(tj )
where Status(ti ) ∈ {success, failure} denotes the execution status of transaction ti on chain Ci . That is, either all transactions in T succeed, or all fail. No partial execution is allowed. This definition ensures that the fundamental property of atomicity is maintained across all chains involved in a CAT. The protocol must guarantee that this property holds regardless of network conditions, Byzantine behavior, or component failures. C. Components We first identify the components that are required for the CAT protocol. We show an overview of the components that are involved in Figure 5. We note that this is a minimal set of components, some of which may be merged, such as the executor and the resolver. 1) Sequencer: In order to submit a CAT, the user passes a transaction to the sequencer of a chain. We assume this sequencer has the right to propose a sequence of transactions to be executed, including CATs. Note that this implies the sequencer of a given chain may also propose transactions for other chains that it interoperates with, as a CAT contains transactions for multiple chains.5 2) Confirmation layer (CL): Transactions that are provided by the sequencers are recorded on a confirmation layer. Moreover, since CATs live across multiple chains, we require that the confirmation layer spans all involved chains, and we require consensus on inclusion of transactions from all chains.6 We also record the status of the CAT on the confirmation layer. We assume the CL operates as a BFT replicated state machine [16], [17], [19] under partial synchrony [20], with three minimal assumptions: 5 We do not address how such a sequencer scheme is implemented; however, a simple approach would be to operate a shared sequencer. A shared sequencer also provides censorship resistance: if an individual chain’s sequencer censors a transaction, the CL can still include it. Safety derives from the CL and TP proofing, not the sequencer. 6 The confirmation layer may also be considered as a commitment layer, as the sequencer and, as we will see later, the coordinator, commit on this layer.
Sequencer submit transactions
Resolver
Executor
accepted transaction sequences
Chain 2
Fig. 5. High-level overview of the involved system components in a CAT protocol with two chains.
1) Safety: BFT agreement among 2f +1 out of 3f +1 nodes ensures no two honest nodes disagree on CL state. 2) Liveness under partial synchrony: After GST, honest proposals are included within a bounded number of rounds. 3) Censorship resistance: Transactions observed by f +1 honest nodes are eventually included. Incentive alignment follows standard staking/slashing models as deployed in production BFT chains. 3) Executor: Each chain operates an executor that is responsible for executing transactions and updating the state. Since learning about the (potential) success or failure of a transaction requires execution (but not necessarily applying the changes to the state), the executor is essential to determining the status of CATs and relaying that information. We assume that the executor may deliver messages asynchronously. While asynchronous delivery could compromise liveness in a naive implementation of our protocol, it does not compromise safety. Moreover, through the introduction of timeouts, we can ensure that the protocol is live (dependent on the confirmation layer) even in the presence of asynchronous delivery. 4) Coordinator: An impossibility result by [21] shows that it is impossible to agree on the status of a CAT without a third party. We call this third party the coordinator. The coordinator is responsible for facilitating the resolution of CATs across chains. It takes as input proposals from the executors and returns a solution to the involved chains. One important aspect becomes apparent when considering the role of the coordinator. The sequencer-proposed transaction sequence is not final—the actual sequence of transactions that gets accepted and applied to the state depends on additional information, specifically the status response from
10
r
σ = t1 . · · · .tnr
New confirmation layer round r 1 Chain 1
2
Statusr r−1 σP
3
(5) Resolver
σ̃ r
σ̃ r .σ r
5
6
(3) Executor
4
(4) Coordinator
7
r σA = Accepted(σ̃ r .σ r )
8
r = Postponed(σ̃ r .σ r ) σP
9
Propose(σ̃ r .σ r )
10
Statusr
′
Off-chain
Fig. 6. High-level overview of transaction processing on a single chain. The 10 steps shown are described in detail in Sec. IV-D.
the coordinator. To reconstruct the current state of a chain, we need both the sequence of ordered transactions and a record of all coordinator decisions made for CATs, since these decisions determine which transactions were actually successful or skipped. As we will later see, the coordinator must provide the solution to the same confirmation layer as the sequencers, as we require strict consensus on the status delivery for all involved chains. We assume that the coordinator may deliver messages to the confirmation layer asynchronously. While asynchronous delivery could compromise liveness in a naive implementation of our protocol, it does not compromise safety. Moreover, through the introduction of timeouts, we can ensure that the protocol is live (dependent on the confirmation layer) even in the presence of asynchronous delivery. The coordinator is a third party that commits to the success (or failure) of executions of transactions. This is notably different from the sequencer, which commits “only” to the inclusion of transactions. 5) Resolver: Two types of information are passed to the chains at this point. First, the sequencer passes the sequence of transactions to be executed. However, these are not necessarily eligible for execution due to (dependencies on) CATs. Second, the coordinator passes the resolution of the CAT to the chains through the CL. Together, these two input streams provide an ultimate sequence of transactions which are accepted for execution. Since we would like the executor to be specialized on execution, we distinguish between the resolver and the executor, where the resolver is responsible for resolving the input stream provided by the coordinator and the sequencer. 6) Transaction Processor (TP): We define the transaction processor as the component that operates both a resolver and an executor. D. Naive CAT protocol We now describe the algorithms in detail for the components Resolver, Executor, and Coordinator. The Confirmation Layer orders the incoming messages into blocks, which is a component external to the core of the CAT protocol, and thus will not be discussed here. Figure 6 shows the transaction processing for one of the involved chains. The itemized list below corresponds with the
numbered steps in the figure. We also provide the corresponding algorithms for the Resolver (Algorithm 1), the Executor (Algorithms 2 and 3), and the Coordinator (Algorithm 4). The steps are as follows:
1) Round initialization. The consensus layer starts a new round r. It may have received any or none of the inputs mentioned in points 2. or 3. If there is no input, the round is skipped (or an empty block is produced). 2) Transaction input. A set of transactions S r = {t1 , .., tnr } with sequence σ r = t1 .t2 . · · · .tnr is provided by a sequencer. 3) Status updates. A status update Statusr−1 is provided by the coordinator and may indicate that the status of some CATs in the set SPr−1 has been decided (failure or success). 4) Pending transactions. The transactions that were left unprocessed/unfinalized at previous rounds (they are waiting for an CAT to be finalized) are in the set SPr−1 with the sequence σPr−1 . 5) Status resolution. We (informally) define transaction sequence σ̃ r to be the result of σPr−1 where the status of the transactions in SPr−1 is resolved: for instance if we had a transaction in SPr−1 that was either success/failure, we resolve its status to the one (success/failure) given by Statusr−1 . 6) Sequence construction. The sequence σ̃ r .σ r is built to be processed at round r. 7) Transaction reordering. The executor splits this sequence of transactions into two transaction sequences: r r The transaction set SA with sequence σA = r r Accepted(σ̃ .σ ), are transactions that can be finalized immediately in round r. The transaction set SPr with sequence σPr = Postponed(σ̃ r .σ r ), which are transactions that cannot be finalized in round r (they are CATs with a still unresolved status, or they depend on these).
This allows for new order of transactions as the one provided by the sequencer. However, it does not affect
11
Round
1
2
Blocks
t1 .t2
t3 .t4
Postponed sequence σP t1 Accepted sequence σA
t2
3
4
5
t5
6
7
t6
Statust1 = success
8
t1 .t3 .t4
t1 .t3 .t4
t1 .t3 .t4 .t6t3 .t4 .t6
t2
t2 .t5
t2 .t5
t2 .t5 .t1
Fig. 7. Example of chain activity with the naive CAT protocol. Transactions t1 , t3 , and t6 are part of CATs, whereas transactions t2 , t4 and t5 are normal transactions. t3 →s t1 , t4 →s t3 , and t4 →s t2 . The status of t1 , reported by the coordinator after 6 blocks, is success. The relationships between the transactions are further illustrated in Figure 4.
the outcome of the original sequence, see Lemma 2. 7 8) Postponed transactions. The sequence σPr is propagated for the next round. In practice the Resolver and the Executor are the same entity (i.e., the Transaction Processor) and thus the sequence is just updated locally. 9) Proposal provision. The executor computes a proposal Propose(σ̃ r .σ r ) for how to resolve CATs in σ̃ r .σ r . The proposal may take arbitrary forms, for example we may directly output success/failure for a CAT if its status can be computed, or also indirect dependencies including their possible outcomes could be computed and represented through a dependency graph, see Sec. III-G. The Propose(·) set is communicated to the coordinator, who is in charge of resolving the common outcome of CATs and can be combined with the other Propose(·) sets of the other chains to determine the status that will ′ be communicated to both chains via Statusr , r′ ≥ r. 10) Coordinator resolution. The coordinator combines the proposals from all chains to determine the statuses of the r′ ′ CATs. This results in a status update Status , r ≥ r, that is processed by the resolver at the next round (r+1) or some later round (if delivery to the confirmation layer is delayed). We illustrate the effects of the naive CAT protocol for the set of transactions from Table II in Figure 7. t1 is a CAT and thus gets postponed. t2 and t5 are independent regular transactions and are accepted and executed creating the accepted sequence t2 .t5 . In the scenario shown the delivery of the status update for the CAT t1 takes 6 blocks. t1 is then successfully executed and the accepted sequence is updated to t2 .t5 .t1 . E. Complete CAT protocol As we have seen in Sec. V, the CAT protocol can invoke a high level of blocking, if approached naively. Moreover, this blocking can lead to liveness issues, which is not acceptable. In this section we discuss possible improvements, at the cost of empowering the coordinator. This empowerment of the coordinator is to a degree, where it gains the ability to reorder some of the transactions in a way that could affect the outcome. Consequently, we must consider to incentivize and ensure honest behavior from the coordinator, see also Sec. V. 7 In Sec. IV-E we discuss improvements that permit the reordering by the coordinator in a way that could lead to different outcomes – a trade-off that gives the coordinator some control over the order of transactions in exchange for liveness guarantees.
1) Timeouts.: As can be seen in Figure 4, transactions may have deep indirect dependencies. If a transaction is blocking for a substantial amount of time, such as is the case in Figure 7, it may lead to a large number of transactions being postponed, which can lead to many transactions having to be kept in memory and long delays. Ultimately this may even result in liveness issues and an attack vector. For this reason, we impose a timeout ∆ for when the coordinator must reply. The detailed algorithm is provided in Algorithm 2. We must ensure that chains do not determine the outcome of a CAT based on these timeouts locally, as this would invalidate coordination between chains, and thus violate atomicity. This is similar to the approach described in Avalon [8], where chains communicate directly with each other. Similarly to our approach, chains can abort through timeouts, which could lead to inconsistencies when relying on local timestamps. To overcome this challenge, it is proposed to rely on an upper layer blockchain, which provides synchronized authenticated timestamps across all underlying chains. A timeout is triggered when the number of blocks from the upper chain exceeds a predetermined value before all relevant messages are published to the upper chain. Consequently, we propose that timeouts must be handled via the common CL. We note that this operation is safe, see Sec. V, since the CL, which operates across all chains, ensures that the transactions that are part of a CAT are skipped at all involved chains at the correct round. This approach permits us to overcome concerns with respect to the liveness of the coordinator. However, it does also add reliance on the coordinator, who may be Byzantine and could in principle utilize the timeout to reorder the transaction stream. Hence, particular care should be given to the configuration of the timeout ∆. We illustrate the effects of the timeout mechanism for the set of transactions from Table II in Figure 8. With a timeout of ∆ = 2 rounds, the CATs t1 and t3 time out and get skipped after 2 blocks, allowing t4 to be accepted and executed creating the accepted sequence t2 .t4 .t5 . This demonstrates how timeouts prevent indefinite blocking. 2) Limiting the dependency depth.: As can be seen in Figure 4, transactions may have several dependencies, and thus the dependency depth (which considers only the pending set σP ) may grow substantially if not resolved fast enough. Moreover, each CAT introduces a set of new outcomes, dependent on whether the outcome is success or failure. This can
12
Round
1
2
Blocks
t1 .t2
t3 .t4
Postponed sequence σP t1 Accepted sequence σA
t2
3
4
5
6
t5
7
8
t6
t1 .t3 .t4
Timeout Timeout t1 .t3 .t4 t3
t6
t2
t2
t2 .t4 .t5
t2 .t4 .t5
result in an exponential number of superposition states with the number of CATs, in particular if the CATs or transactions are highly dependent on each other. Not only could this result in long delays, but it could also enable resource-exhaustion attack vectors. As we show in the previous example, we may reorder the sequencer transaction stream in order to improve the protocol properties, such as liveness. Similarly, here we may reorder the transaction stream proposed by the sequencer in order to limit the dependency depth to prevent resource-exhaustion attacks. However, and analogously to the introduction of timeouts, the coordinator is given additional power, as it can invoke delays that result in reordering of the transaction stream. In Sec. III-G we introduced the dependency DAG D for a given state s and a sequence of transactions σ. We show an example of the dependency DAG including the CAT dependency depth in Figure 9. We only consider the pending set σP for the DAG, ı.e. D = D(s, σP ). Transactions that can be readily accepted are added to the accepted sequence σA , which we can ignore for the dependency DAG. For the algorithm, we add a new parameter maxDepth and a new sequence of ignored transactions I. The approach that we propose limits the CAT dependency depth and protects against resource-exhaustion attacks. It also reduces the number of transactions that need to be considered for postponement, which reduces the memory and latency of the protocol. We augment the executor with dependency depth limiting as shown in Algorithm 3. The changes are highlighted in blue. The following rules are applied for a given transaction t: 1) If t is a CAT and depthsr−1 ,σPr (t) > maxDepth we add t to the ignored set I. 2) If t is not a CAT and depthsr−1 ,σPr (t) > maxDepth we add it to the ignored set I. 3) Else if t is not a CAT and depthsr−1 ,σPr (t) > 0 we add it to the pending set σP . 4) Else we process t as normal. We show an example of the application of the algorithm in 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 .
CAT dependency depth
Fig. 8. Improvement through timeouts. Example as in Figure 7, but with a timeout of ∆ = 2 rounds. Since the coordinator did not respond two rounds after the blocking transaction t1 was added to the chain, the transaction is skipped. Similarly, t3 also times out shortly after. t4 is a regular transaction and not blocking, therefore, it is accepted and the accepted sequence is updated to t2 .t4 .
t4
2
t3
1
t1
is in I
2 t3
1
limit depth
t1
t4 0
0
t2
(a) no maxDepth Regular transaction
t2 (b) with maxDepth=1 CAT
Fig. 9. Effect of a depth limit maxDepth = 1 on the dependency graph from Figure 4. Since depth(s,t1 .t2 ) (t3 ) = 1, t3 is added to the ignored sequence I (gray dashed border). Thus, depth(s,t1 .t2 ) (t4 ) = 0.
V. A NALYSIS OF P ROTOCOL C ORRECTNESS The analysis of our CAT protocol focuses on three critical aspects: first, establishing the foundation that our protocol can be made minimally-blocking through safe reordering of independent transactions; second, formal safety and liveness guarantees with respect to trusted entities that verify protocol correctness; and third, detailed analysis of safety and liveness across the protocol components described in Section IV-C. We establish that the protocol provides strong safety guarantees through cryptographic protections and consensus mechanisms, while ensuring liveness through timeout mechanisms and independent execution of non-dependent transactions. A. Minimally-blocking protocol. Before defining safety and liveness properties, we establish a crucial foundation: our protocol achieves minimal blocking by safely reordering independent transactions. This means that transactions without dependencies can execute immediately with zero blocking time, while dependent transactions are guaranteed to complete within a bounded timeout. This property is essential for protocol efficiency and directly supports the safety analysis that follows, as it shows that regular transaction ordering can be optimized without compromising correctness.
13
Round
1
2
Blocks
t1 .t2
t3 .t4
3
4
5
t5
6
7
t6
Statust1 = success
Postponed sequence σP t1
maxDepth=1 t1
t1
t1 .t6
Ignored set
t3
t3
t3
t2 .t4
t2 .t4 .t5
t2 .t4 .t5
Accepted sequence σA
t2
8
t6 .t3 t2 .t4 .t5 .t1
Fig. 10. Improvement through limiting the CAT dependency depth with maxDepth = 1. We use the transactions from Table II, with dependency graph illustrated in Figure 9. Since depth(s,t1 .t2 ) (t3 ) = 2, we add t3 to the ignored sequence I. Since now depth(s,t1 .t2 ) (t4 ) = 0, it is directly added to the accepted sequence σA . Eventually t1 is accepted and t3 gets computed and added to the postponed sequence σP .
Proposition 1 (Minimally-blocking Protocol). Given a timeout mechanism, our protocol that permits reordering of independent transactions achieves minimal blocking with two aspects: Committed regular transactions: The blocking time for any transaction committed to the CL is bounded by ∆: ∀t ∈ T :
BlockingTime(t) ≤ ∆
Independent transactions: No blocking time at all: ∀t ∈ T :
Independent(t) =⇒ BlockingTime(t) = 0
where BlockingTime(t) is the time a transaction waits before being executed (failure or success), and Independent(t) is a predicate that is true if t has no dependencies. Proof. By Lemma 3 from Section III, independent transactions can be executed in parallel without affecting correctness and the final state. For any transaction t, the protocol achieves minimal blocking through: 1) Zero blocking for independent transactions: If t has no dependencies, it executes immediately with BlockingTime(t) = 0. 2) Bounded blocking for CATs: If t is part of a CAT T , the timeout mechanism ensures BlockingTime(t) ≤ ∆. 3) Bounded blocking for dependent transactions: If t has dependencies, the timeout mechanism ensures BlockingTime(t) ≤ ∆, since all CATs that are ordered before t are blocked at most until the timeout ∆. This ensures that independent transactions have no blocking time while dependent transactions are bounded by ∆, achieving true minimal blocking.
the TP. We will distinguish between nTPs on the same chain and nTPs on different chains. We, therefore, define NCi as the set of nTPs on chain Ci . We use the timeout parameter ∆ (already defined in Section IV-E1) which is measured in rounds and used in the algorithms (see Appendix B). State transitions follow the Next function defined in Section III. We now define key properties that our protocol must satisfy: Definition 2 (Safety). A protocol is safe if for any CAT T , all nTPs maintain consistent views of T ’s status, both within the same chain and across different chains. Specifically: Intra-chain consistency: For any chain Ci and any two nTPs N1 , N2 on Ci : ∀T, ∀Ci , ∀N1 , N2 ∈ NCi : StatusN1 (T ) = StatusN2 (T ) Inter-chain consistency: For any two nTPs N1 on chain Ci and N2 on chain Cj (where i ̸= j): ∀T, ∀Ci , Cj , ∀N1 ∈ NCi , ∀N2 ∈ NCj : StatusN1 (T ) = StatusN2 (T ) Definition 3 (Liveness). A protocol is live if for any CAT T , there exists a finite timeout threshold ∆ such that: ∀T :
∃∆ :
resolution(T ) ≤ ∆
where resolution(T ) is the time until T reaches a final state, measured in rounds. This liveness guarantee ensures that all nTPs will eventually observe a final status for T within ∆ rounds.
B. Formal Model and Definitions
C. Confirmation Layer
We build upon the formal model established in Section III. Before defining the key properties, we introduce the nonproposing Transaction Processor (nTP), which are client nodes with which we measure our safety and liveness properties. The nTP is in essence a TP but does not interact with the coordinator. It can be operated as trusted since any user may deploy it, and it only relies on read access to the CL. Moreover, since the nTP constitutes a subset of the tasks of the TP, all described guarantees derived herein hold true for
The CL is assumed to provide a decentralized Byzantine fault-tolerant consensus mechanism that secures both the order and content of all transactions (CATs and regular transactions). It determines time progress through rounds, and timeouts are measured in CL rounds. The CL serves as the authoritative source for all transaction-related decisions. All TPs and nTPs must read from the CL to determine the correct status of transactions and proceed with state transitions.
14
Proposition 2 (CAT Status Focus). Since the CL provides safe consensus on transaction content and order, it is sufficient to focus on whether nTPs maintain consistency on CAT statuses. Regular transaction ordering does not affect the safety properties that we require to prove for nTPs. Proof. By Proposition 1, independent regular transactions can be executed out of order without affecting final state consistency. Since the CL is safe and secures transaction order and content, for nTPs this means: 1) Regular transaction ordering is handled safely by the nTP’s executor’s reordering logic. 2) The safety of the state updates for all types of transactions follows from the nTP’s executor’s correctness. 3) We still need to prove that nTPs maintain consistency on CAT statuses. Therefore, nTP safety properties can focus exclusively on CAT status consistency. Proposition 3 (Safety with respect to the CL). The CL satisfies the safety property defined in Definition 2. Specifically, for any CAT T and any two nTPs N1 , N2 on any chain Ci , if both read the CL at round r, then: StatusN1 (T, r) = StatusN2 (T, r) where StatusN (T, r) denotes the status of CAT T as observed by nTP N at round r. Proof. By assumption, the CL implements a Byzantine faulttolerant consensus protocol with safety property S. For any CAT T , the CL records status updates through consensus. By the safety property S of the underlying consensus protocol: ∀N1 , N2 ∈ NCi , ∀r :
N2 1 CLN r = CLr
where CLN r is the CL state at round r as observed by nTP N . Since StatusN (T, r) is derived from CLN r , we have: StatusN1 (T, r) = StatusN2 (T, r) This ensures that all nTPs observe consistent CAT statuses, maintaining safety across the system. Proposition 4 (Liveness with respect to the CL). Let LCL be the liveness property of the CL consensus protocol. If LCL holds, then for any CAT T and any nTP N on any chain Ci , there exists a finite round rT such that: ∀r ≥ rT :
StatusN (T, r) ̸= ⊥
where ⊥ denotes an undefined status. Proof. By assumption, the CL implements a Byzantine faulttolerant consensus protocol with liveness property LCL . This means that for any valid input, the CL eventually produces an output within a finite number of rounds. For any CAT T , the CL must eventually record a status update. The absence of a Status update from the coordinator within timeout is equivalent to a Status update with failure. By the liveness property LCL : ∃rT :
∀r ≥ rT , ∀N ∈ NCi : CLN r contains the Status of T
Since StatusN (T, r) is derived from CLN r , we have: ∀r ≥ rT :
StatusN (T, r) ̸= ⊥
This ensures that all nTPs eventually observe defined CAT statuses, maintaining liveness across the system. The CL’s role as the authoritative source of truth enables a key system-wide property: atomicity across chains. Since all chains read from the CL to determine CAT statuses, the CL ensures that cross-chain transactions maintain atomicity. Proposition 5 (Atomicity Guarantee). For any CAT T , the protocol ensures that T satisfies the atomicity property defined in Definition 1. Proof. By Proposition 3, all nTPs eventually agree on the status α of T = (t1 , . . . , tk ) through the CL. For any chain Ci involved in T , the state transition follows: ti /α
si −−−−→ s′i where s′i = si if α = failure (no state change). By the CL’s global consistency (Proposition 3), all nTPs observe the same status α for T , and thus its constituent transactions ti have the same status α. Therefore: ∀i, j ∈ [1, k] :
Status(ti ) = α = Status(tj )
This ensures that T satisfies the atomicity property from Definition 1, maintaining consistency across all chains. D. Coordinator A third-party coordinator is required to agree on the status of CATs [21]. However, the coordinator may be faulty or Byzantine. To ensure safety, the coordinator must record its decisions on the CL for accountability as well as to ensure consistent global view. In addition, the decisions of the TPs must be protected by signature and these signatures must be contained in the status updates from the coordinator recorded on the CL. To ensure liveness and because the coordinator may become faulty, we require timeouts. Proposition 6 (Safety with respect to the Coordinator). Let Ccoord be the coordinator and Tcoord be the set of TPs involved in a CAT T . For any status proposal Status from TP i ∈ Tcoord , the coordinator can only: 1) Record Status on the CL: CLh ← Status 2) Ignore Status: CLh ̸← Status The coordinator cannot produce Status′ ̸= Status such that CLh ← Status′ . Proof. By Proposition 3, messages recorded on the CL are safe and cannot be altered by Byzantine actors. For any status proposal Status from TP i, the coordinator receives Status with cryptographic signatures sigi (Status). The coordinator can only: CLh ← Status
or
CLh ̸← Status
If the coordinator attempts to record Status′ ̸= Status, the cryptographic signatures sigi (Status) would not validate for Status′ , making the status update invalid. By the CL’s
15
safety properties, invalid updates are rejected. Therefore, the coordinator’s actions are limited to recording the original proposal or ignoring it, ensuring that only authentic status proposals are recorded. Proposition 7 (Liveness with respect to the Coordinator). For any CAT T , liveness is ensured through the CL’s timeout mechanisms, not through independent coordinator timeouts. Proof. By Proposition 4, the CL ensures that all CATs eventually reach a defined status within a finite number of blocks. The coordinator’s role is to facilitate agreement on CAT statuses, but the actual timeout enforcement and global consensus comes from the CL. If the coordinator fails to provide a status update, the timeout mechanism implemented in the nTP is enabled with the help of the CL consensus. Therefore, liveness is maintained through the CL’s guarantees, with the coordinator acting as a facilitator rather than the source of timeout enforcement.
TPs may become faulty. However, we require that the CAT protocol guarantees eventual liveness, even if individual TPs fail. Since we cannot enforce liveness on individual chains, we require that the coordinator employs a timeout mechanism measured in CL block heights. Proposition 9 (Liveness with respect to the TP). For any CAT T and faulty TP i, liveness is ensured through the CL’s timeout mechanisms, not through independent TP mechanisms. Proof. By Proposition 4, the CL ensures that all CATs eventually reach a defined status within a finite number of blocks. The TP’s role is to execute transactions and provide status proposals, but the actual timeout enforcement and global consensus comes from the CL. If a TP i fails to provide a status proposal for CAT T , the timeout mechanism implemented in the nTP is enabled with the help of the CL consensus. Therefore, liveness is maintained through the CL’s guarantees, with the TP acting as a facilitator for coordination rather than the source of timeout enforcement.
E. Transaction Processor If the TP proposes a status to the coordinator for a given CAT T , this status proposal must be correct.8 However, a centralized TP may become Byzantine. Thus, the correctness of the status proposals must be protected by providing a degree of finality, e.g. cryptographically (ZK) or crypto-economically (through attestations of a staked committee). Proposition 8 (Safety with respect to the TP). Let PTP be the protection mechanism (cryptographic or crypto-economic) for TP proposals. For any CAT T and TP i, if PTP is valid, then: ∀Status ∈ {success, failure}: VerifyPTP (Status, T, i) ∈ {true, false}
F. Summary Theorem 1 (CAT Protocol Safety and Liveness). Under the assumptions of Byzantine fault tolerance for the CL and valid protection mechanisms for TPs (ZK or staking), our CAT protocol provides: 1) Safety: All nTPs agree on CAT statuses and maintain atomicity 2) Liveness: All CATs are eventually resolved within bounded timeout periods 3) Minimal Blocking: Independent transactions execute in parallel, minimizing waiting time
If a TP attempts to propose an incorrect status Status′ ̸= Status, the verification will fail:
Proof. Safety: By Proposition 3, the CL provides consistent views to all nTPs given a secure consensus protocol. By Proposition 5, this ensures atomicity of CAT Status updates across all chains. By Proposition 6, the coordinator cannot produce an incorrect Status update, only ignore it. By Proposition 8, the TP cannot produce an incorrect status given a valid protection mechanism. Liveness: By Proposition 1 regular independent transactions can be executed without blocking, while dependent regular transactions and CATs are blocked for at most ∆ blocks given a valid timeout mechanism. By Proposition 4, the CL enables the required timeout mechanism and ensures that all CATs eventually reach a defined status within a finite number of blocks. By Proposition 7 and Proposition 9, the coordinator and the TP cannot impede this progress. Minimal Blocking: By Proposition 1 and Lemma 3 from Section III, independent transactions execute immediately, while dependent transactions are blocked for at most ∆ rounds.
VerifyPTP (Status′ , T, i) = false
VI. I MPLEMENTATION AND E VALUATION
where VerifyPTP validates the protection mechanism for proposal Status. Proof. By assumption, the protection mechanism PTP provides either: 1) Cryptographic protection: Zero-knowledge proofs or digital signatures that are computationally infeasible to forge. 2) Crypto-economic protection: Staked attestations where dishonest behavior results in economic penalties. For any status proposal Status from TP i, the verification function VerifyPTP ensures: VerifyPTP (Status, T, i) = true ⇐⇒ Status is honestly generated by TP i
This prevents violations of the CAT protocol by ensuring only honest status proposals are accepted. 8 For example, if the TP proposes success, although the execution by a nTP would fail, then a user could be exploited by giving up assets on another chain.
We have implemented the protocol described in this paper as an open-source project, Hyperplane9 . Hyperplane implements the protocol with timeouts and a maxDepth = 1, including 9 Available at https://github.com/movementlabsxyz/hyperplane
16
dependency management as formalized in our model. The codebase is organized to closely follow the formal definitions and dependency structures introduced in Section III. A. Experimental Setup Our experimental evaluation was conducted on an AWS t3.xlarge instance with 4 vCPUs and 16 GB of memory. We simulate two chains, each with 10000 accounts preloaded with sufficient tokens for experimentation. We randomly select accounts to send transactions, where each account uses the Send(sender, receiver, amount) function described in Section II to send tokens to another randomly selected account following a Zipf distribution P (k) ∝ 1/k z , where k is the account rank and z is the skewness parameter. Parameter
Default Value
Block interval (s)
1
Transactions per second (tps)
100
Zipf parameter (z)
0.8
Number of accounts
10000
CATs among total transactions Lifetime of CATs
50 tps (50%) 10 blocks
max CAT dependency depth
1
Delay of slowest chain (D)
5 blocks
TABLE III D EFAULT EXPERIMENT PARAMETERS
We set one chain to be fast with negligible delay and one chain to be slow. As the system performance is extensively affected by the slow chain, the content of the transactions in the fast chain is not relevant for the experiments, and we, thus, send transactions duplicated to both chains. Our protocol implements each communication path separately: user → sequencer, sequencer → CL, CL → TP, TP → coordinator, coordinator → CL. For simulation purposes, we combine all delays into a single parameter between TP and coordinator, where the slowest chain dominates system behavior. Due to the non-synchronous nature of the system, additional delays on the order of milliseconds exist on communication paths between other components due to computational limitations. The delay parameter D represents the combined message delays in this system. For default parameters in Table III, we set D to 50% of the CAT lifetime, which seems a pessimistic scenario for a production system. The block interval is set to 1 second, which is a common block interval for recent blockchains.10 The number of CATs per block is set to 50% of the throughput, which simulates a system under high cross-chain load. We set z = 0.8 to create a distribution skewed towards top accounts, which reflects common patterns in cryptocurrency systems; see e.g. [23]. Each data point in the following figures is calculated by repeating the same simulation several times and calculating 10 In a production system, the confirmation layer produces blocks approximately every second, and execution is expected to be faster than a second [22].
the average value at the end. We then display the mean, min, and max values. B. Results In this section we present the results of our experiments evaluating the performance and scalability of our CAT protocol. Our results demonstrate that the protocol successfully resolves CATs in a timely manner and with a good success rate, with performance characteristics that adapt well to various network conditions and workload distributions. a) Comparison with Avalon.: Avalon [8] is the only directly comparable cross-chain atomic transaction protocol. Both protocols require a constant number of coordination rounds. However, Avalon relies on per-pair IBC relayers, resulting in quadratic message complexity in the number of chains. The authors report that this causes latency to scale almost linearly in practice, as relayers slow down under the growing message load—15.1s at 3 chains, 34.7s at 6, and 59.2s at 9 chains without conflicts. Our protocol avoids this bottleneck: each chain’s executor sends a proposal directly to the coordinator, which aggregates all proposals in one step and publishes a single decision to the CL, with linear message complexity. At ∼1s CL block intervals, this yields block-level finality independent of chain count. The two-chain experimental setup is sufficient because per-chain protocol behavior is identical regardless of participant count; adding more chains does not change the per-chain communication pattern. b) Relation to standard benchmarks.: Cross-shard and cross-chain coordination are structurally similar problems. TPC-C [24] is the industry-standard benchmark for evaluating online transaction processing systems; its cross-warehouse transactions directly map to CATs: each touches state on two independent partitions that must commit atomically. The TPCC standard specifies a natural cross-partition rate of approximately 11% of total traffic (45% NewOrder transactions with ∼10% cross-warehouse, 43% Payment transactions with 15% cross-warehouse). Our evaluation already covers and exceeds this regime: Figure 11 varies rC from low values (where success rates exceed 90%) through our stress-test default of 50%—far beyond what standard workloads prescribe. 1) Number of CATs per block.: We modify nC (the number of CATs per block) by varying rC (the CAT ratio), which defines the number of CATs among the total number of transactions. Figure 11 shows the effect on the success ratio of CATs. We display a secondary axis to indicate that we vary nC up to 100 tps, at which point only CATs are sent. The success ratio is significantly higher for low nC and decreases as nC increases. This is expected, as the protocol is designed to provide a non-interruptive experience for each chain’s native transactions: regular transactions always make progress, at most after a short delay, regardless of pending CATs. This prioritization is enforced by the CAT timeout—a deliberately short window after which a CAT is aborted so that blocked native transactions can immediately proceed. The declining success rate under high contention is not a cross-chain phenomenon—it is universal even on single
17
Fig. 11. Average success of CATs with the number of CATs per block (nC ). We also display a secondary axis to put nC into context with the ratio of CATs to the total number of transactions (rC ).
blockchains. Large-scale empirical analysis of Solana shows overall transaction failure rates exceeding 75% during peak congestion and contention [25]. Figure 12 shows the impact of nC on different types of postponed transactions. As nC increases, we observe three distinct effects: (a) more regular transactions remain pending due to them waiting for a CAT to be resolved. Eventually, the number of postponed regular transactions decreases as most of the transactions are CATs. (b) More CATs remain in a resolving state as nC increases. (c) Increasingly more transactions are ignored due to dependency conflicts, highlighting the trade-off between CAT throughput and success rate. 2) CAT lifetime.: As the CAT lifetime increases, CATs have an increased amount of time to get resolved. However, this implies that they are also blocking for an extended amount of time. In turn a large CAT lifetime exposes regular transactions that have a dependency on a pending CAT to increased latency to finality. This can be seen in Figure 13, where the average time of regular transactions that enter the pool of pending transactions spend in that same pool (i.e., the latency) increases with the CAT lifetime. We note that regular transactions that are not dependent on a pending CAT are not affected in their latency, and that transactions that are dependent are maximally delayed by the CAT lifetime. This trade-off is the central design tension of the timeout parameter: the timeout must balance CAT resolution probability against native transaction blocking time. A shorter timeout prioritizes native transaction liveness at the cost of lower CAT success rates, while a longer timeout improves CAT completion but increases worst-case latency for dependent regular transactions, bounded by the lifetime. 3) Chain delay.: Figure 14 shows the effect of the chain delay D on the success rate of CATs. The success rate slowly decreases as we increase the chain delay to the CAT lifetime. When D is close to the CAT lifetime, mainly CATs are successful that access non-contended keys, while most other CATs would fail due to timeout. This is because a CAT that has to wait for a contended key for δ blocks would require D + δ blocks to propose and resolve, which would likely be larger than the CAT lifetime. When D is larger than the CAT lifetime, the success rate is 0, as no CATs can be resolved in
Fig. 12. Impact of the number of CATs per block on average number of postponed transactions: (a) regular transactions, (b) resolving CATs, and (c) temporarily ignored CATs.
Fig. 13. Impact of CAT lifetime on the average latency of regular transactions that have a dependency on a CAT.
time. 4) Number of regular transactions per block.: Figure 15 shows the success rate of CATs with the number of total transactions per block. We keep the average number of CATs per block constant to the value of 50. As the throughput increases, the success rate of CATs is decreasing. Since regular transactions that depend on a CAT also block keys temporarily, the footprint of a CAT on locked keys is increasing with the throughput of regular transactions, which is one of the key reasons to keep lifetimes of CATs short. 5) Centralization of key accesses.: Figure 16 shows the effect of the centralization of key accesses on the success rate of CATs. We vary the centralization of key accesses by varying the skewness parameter z of the Zipf distribution.
18
Fig. 14. Average success of CATs with the chain delay.
Fig. 15. Average success of CATs with the throughput, and while keeping the average number of CATs per block constant as per Table III.
The success rate of CATs is high for low centralization, and decreases as the centralization increases, due to increased contention for higher ranked keys (see also the discussion of contention effects in Sec. VI-B1). We also compare for different values of rC , the ratio of CATs to the total number of transactions. We see the protocol performs particularly well at low centralization of account access, even if rC is high.
Fig. 16. Impact of the centralization of key accesses on the average success rate of CATs. We compare for different values of rC , the ratio of CATs to the total number of transactions. Maximal variance of data points is less than 3%.
VII. R ELATED W ORK In the following, we highlight state-of-the-art blockchain interoperability across several ecosystems. 1) Ethereum: Ethereum is retrofitting interoperability onto a fragmented ecosystem of rollups. Solutions like AggLayer and Espresso aim to coordinate execution and liquidity through shared sequencing and unified bridging, while anchoring security to Ethereum L1. AggLayer provides a shared execution layer between rollups and Ethereum, using zk-proofs to post batched state changes [2], [3]. Espresso [26] provides a shared sequencing layer using BFT consensus (HotShot) that
produces a unified transaction log across participating chains, aiming to enable cross-chain composability [27]. The HotShot protocol, including its threat model and data-availability layer (Tiramisu), is described in an ePrint preprint [26]; however, it focuses on consensus and data availability rather than crosschain execution semantics. Espresso’s CIRC protocol adds inbox/outbox coordination for cross-rollup communication, but to our knowledge has no formal specification or peerreviewed publication that would permit comparative study. A HotShot-like confirmation layer could serve as the infrastructure underneath our protocol. 2) General Message Passing: General Message Passing (GMP) protocols such as LayerZero [28] provide crosschain message delivery with verification. However, it does not guarantee atomic execution of interdependent operations across chains: if the destination-side action fails, there is no coordinated abort on the source side. Hash-time-lock contracts (HTLCs) can extend GMP to atomic asset swaps, but are limited to pairwise exchanges and require extensive timelocks. Neither GMP alone nor GMP+HTLC supports atomic execution of general transactions with shared-state dependencies across chains. Lu et al. [11] build a two-phase commit (2PC) protocol on top of GMP bridges, achieving atomic execution of general cross-chain transactions. Their protocol uses coarse-grained pessimistic locking: all state variables of affected contracts are locked, blocking even unrelated transactions that access different variables of the same contract. By contrast, our protocol tracks fine-grained read/write dependencies (Sec. III-G), postponing only truly dependent transactions. Moreover, no timeout or fallback mechanism is specified if the proposer becomes unresponsive, leaving liveness without guarantees. 3) Polkadot: Polkadot provides interoperability via its Relay Chain, which coordinates shared consensus and security across parachains [29], [30]. Cross-chain communication uses XCM, an asynchronous message format that follows a fire-and-forget model [31]: the sender does not block on completion, and if destination-side execution fails, there is no automatic rollback on the source chain. Error-handling instructions operate only on the destination chain and cannot trigger a coordinated abort across chains. Thus, despite being a multi-chain system with native cross-chain communication, Polkadot does not provide atomic cross-chain execution. 4) Cosmos: Cosmos uses the IBC protocol for asynchronous, trust-minimized messaging across sovereign chains [32]. IBC provides message passing but not atomic execution; each chain maintains its own validators and consensus. Avalon [8] builds on IBC to achieve complete atomicity across Cosmos zones, introducing a dirty state layer for caching state changes before commit and applying optimistic concurrency control (OCC) with a state synchronization protocol. While similar in intent, Avalon’s dirty queue commits transactions in strict order: all subsequent transactions in the dirty queue are aborted, even if they access disjoint state. By contrast, our protocol builds an explicit dependency graph that enables independent transactions to proceed in parallel past pending CATs, and bounds cascading dependencies via the maxDepth parameter
19
(Sec. III). We compare latency and scaling characteristics in Sec. VI-B. 5) Relation to Cross-chain Atomicity and Sharding: Herlihy [33] formalizes the cross-chain atomicity problem and shows that under semi-synchronous communication - a realistic assumption for blockchain systems - a globally shared ledger is required for coordination; our confirmation layer is precisely such a ledger. The same coordination challenge arises in sharded blockchains, where independent partitions must agree on joint commit-or-abort decisions. CAPER [34] addresses cross-application transactions in permissioned blockchains but conflates ordering and execution trust in permissioned chain nodes; we separate them - execution correctness is enforced via ZK proofs or staking on the transaction processor, while ordering is the confirmation layer’s exclusive responsibility. ByShard [35] validates the coordinator-thenlocal-execution pattern in a Byzantine cross-shard setting: their Orchestrate-Execute Model applies a similar structure - a coordinator decides commit/abort atomically, then each shard executes locally. Our protocol unifies these insights: it applies the shared-ledger requirement established by Herlihy via the confirmation layer, while adopting the coordinatorthen-execute pattern validated by ByShard, in a permissionless cross-chain setting. 6) Comparison of Cross-chain Approaches: Table IV compares protocols that target atomic cross-chain execution and have published protocol details. Polkadot and Cosmos/IBC are excluded as they provide message passing but not atomic execution; we could not identify peer-reviewed protocol specifications or performance studies for AggLayer or Espresso/CIRC ( [26] covers consensus and DA but not cross-chain execution). GMP+HTLC denotes GMP combined with hash-time-lock contracts; GMP+2PC denotes the two-phase commit protocol of Lu et al. CATs (ours)
Avalon [8]
GMP+2PC [11]
GMP+HTLC
Generic atomic exec. Dependency tracking11 Liveness guarantee Comm. complexity
✓ ✓ ✓ O(n) ∼1-2s
✓ × × O(n) ∼300s (2 chains)
Swaps × Time-locks Pairwise
Reported latency
✓ × ✓ O(n2 ) 15s (3 chains)
Time-locks
TABLE IV C OMPARISON OF CROSS - CHAIN COORDINATION APPROACHES . C OMMUNICATION COMPLEXITY IS GIVEN IN THE NUMBER OF PARTICIPATING CHAINS n.
VIII. C ONCLUSION We have presented a novel protocol for cross-chain atomic transactions that addresses the fundamental challenges of blockchain interoperability: fragmented liquidity, high latency, 11 Explicit tracking of read/write dependencies between cross-chain and regular transactions (Sec. III-G). This allows independent transactions to proceed in parallel past pending CATs, while only truly dependent transactions are postponed. See the Avalon comparison above for the contrasting approach.
and lack of atomicity. Our approach introduces a shared coordination layer with executors, coordinators, and a confirmation layer that enables deterministic, secure cross-chain execution while preserving chain autonomy. The protocol’s key innovations include simulation before commitment to avoid rollback complexity, dependency tracking to enable independent transaction execution, and timeout mechanisms to ensure liveness under asynchronous conditions. Through our implementation in Hyperplane, we demonstrate that the protocol efficiently achieves atomicity without centralized coordination or speculative rollback. Our experimental evaluation reveals critical performance characteristics and trade-offs. The protocol maintains robust performance as the proportion of CATs increases, provided that access pattern centralization remains moderate. This resilience to transaction pattern variations makes the protocol suitable for diverse real-world applications. We find that CAT success rates are sensitive to chain delays when delays approach the CAT lifetime threshold. On the other hand, while increasing CAT lifetime would improve success rates, it would increase pending regular transaction backlogs, which in turn extends finality times for dependent regular transactions, highlighting the importance of careful parameter tuning for specific use cases. Our analysis establishes strong safety and liveness guarantees, showing that the protocol provides Byzantine fault tolerance while maintaining minimal blocking through dependency-aware scheduling. The protocol provides a foundation for truly composable cross-chain applications, enabling the seamless multi-chain experience that users expect while maintaining the security and decentralization properties of blockchain systems. a) Future work.: Several directions remain for future investigation. First, while maxDepth = 1 is the motivated operating point, an experimental sweep over varying dependency-depth bounds would further characterize the tradeoff between blocking reduction and CAT success rate. Second, extending the evaluation to more than two chains would empirically confirm the protocol’s constant-round scaling property. Third, evaluating the protocol under standardized database benchmarks such as TPC-C would enable direct comparison with the cross-shard literature. A PPENDIX This appendix provides detailed algorithmic descriptions of the key components of our CAT protocol. These algorithms implement the theoretical framework described in Section IV of the main text and provide concrete implementations for the resolver, executor, and coordinator components. The algorithms are designed to work together in a coordinated manner, where each component has specific responsibilities: • Resolver: Processes pending transactions and resolves their status based on coordinator decisions • Executor: Manages transaction execution, reordering, and dependency resolution • Coordinator: Orchestrates cross-chain coordination and resolves CAT outcomes
20
Algorithm 1: Resolver Algorithm
Algorithm 2: Executor Algorithm with Timeout
Input: Resolved statuses Statusr and pending sequence σPr−1 , where r is the current round Output: Resolved transaction sequence σ̃ r
Input: State sr−1 , Transaction sequence σ = σ̃ r .σ r with new CATs in σ r marked pending, timeout threshold ∆ and current round r, map timestamp(T ) which provides the received round for CAT T r Output: Accepted sequence σA , postponed sequence σPr , proposal map Propose, updated state sr
Initialize empty sequence σ̃ r ← [ ]; for each transaction t in σPr−1 do if t is not a CAT then Append t to σ̃ r ; else Let T be the CAT identifier in t; if Statusr [T ] = success then Append t to σ̃ r ; // the CAT becomes a regular transaction else if Statusr [T ] = failure then Append Skip to σ̃ r ; else Append t to σ̃ r (with flag pending); return σ̃ r ;
A. Resolver Algorithm The resolver is responsible for processing the pending transaction set from previous rounds and updating transaction statuses based on coordinator decisions, recorded at the Confirmation Layer. This algorithm implements the resolver component described in Section IV of the main text. Algorithm 1 shows the complete resolver implementation.
r Initialize empty sequences σA ← [ ], σPr ← [ ], and empty map Propose ← [ ]; for each transaction t in σ, in order do Compute local outcome result ∈ {success, failure}; if t is regular then if t ̸↔+ σ r [i] for all i then sr−1 P r Append t to σA ; else Append t to σPr ;
else if t is a pending CAT then Let T be the CAT identifier in t; if timestamp(T ) ≤ r − ∆ then r ; // forced Append Skip to σA resolution via timeout else if T has not been proposed in any earlier round then Insert (T, result) into Propose; Append t to σPr ; r ); Compute updated state: sr ← Next(sr−1 , σA r r r return σA , σP , Propose, s ;
B. Executor with Timeouts Algorithm This version of the executor introduces timeout mechanisms to prevent indefinite blocking and ensure protocol liveness. The timeout mechanism is crucial for maintaining system responsiveness while preserving the safety guarantees of the CAT protocol. This algorithm implements the timeout mechanism described in Section IV-E1 of the main text. Algorithm 2 shows the complete executor with timeouts implementation. The timeout-related additions are marked in red. C. Executor with Dependency Depth Limiting Algorithm This version of the executor introduces dependency depth limiting to prevent resource exhaustion attacks and improve system scalability. This algorithm implements dependency management strategies that balance performance with security considerations. This algorithm implements the dependency depth limiting approach described in Section IV-E2 of the main text. Algorithm 3 shows the complete executor with dependency depth limiting implementation. The depth-limiting additions are marked in blue. D. Coordinator Algorithm The coordinator serves as the component where proposals are aggregated from the executor of all participating chains and which forwards a status to the Confirmation Layer once all required proposals are received.
This algorithm implements the coordinator component described in Section V-D of the main text. Algorithm 4 shows the complete coordinator implementation. R EFERENCES [1] AggLayer, “Agglayer documentation,” 2025, accessed: 2025-09-02. [Online]. Available: https://docs.agglayer.dev/ [2] P. Labs, “Clearing up agglayer misconceptions,” Nov. 2024, accessed: 2025-07-24. [Online]. Available: https://polygon.technology/ blog/clearing-up-agglayer-misconceptions [3] EspressoSystems, “Espresso is solving rollup interoperability with the agglayer and polygon labs,” https://medium.com/@espressosys/espresso-is-solving-rollupinteroperability-with-the-agglayer-and-polygon-labs-b3a7d2f8f7cf, May 2024, accessed: 2025-07-24. [4] ERC-7683 Contributors, “Erc-7683: Standard for crosschain intents,” https://www.erc7683.org/, 2024, accessed: 2025-07-25. [5] Paradigm, “Intent-Based Architecture and Their Risks,” Paradigm blog, 2023, accessed: 2025-08-14. [Online]. Available: https://www.paradigm. xyz/2023/06/intents [6] A. Foundation, “Intents and the Intent Gossip Network,” https://anoma. net/blog/intents-and-intent-gossip-network, 2022, accessed: 2025-0814. [7] 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 [8] 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 [9] 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: State sr−1 , Transaction sequence σ = σ̃ r .I r−1 .σ r with new CATs in σ r marked pending, and maximum depth maxDepth r Output: Accepted sequence σA , postponed sequence σPr , ignored sequence I r , proposal map Propose, updated state sr r Initialize empty sequences σA ← [ ], σPr ← [ ], I r ← [ ], and empty map Propose ← [ ]; for each transaction t in σ, in order do Compute local outcome result ∈ {success, failure}; Compute depthsr−1 ,σr (t); P if t is a CAT and depthsr−1 ,σr (t) > maxDepth then P Add t to the ignored set I r ; else if t is not a CAT and depthsr−1 ,σr (t) > maxDepth then P Add t to the ignored set I r ; else if t is regular then if t ̸↔+ σ r [i] for all i then sr−1 P r ; Append t to σA else Append t to σPr ;
else if t is a pending CAT then Let T be the CAT identifier in t; if T has not been proposed in any earlier round then Insert (T, result) into Propose; Append t to σPr ; r ); Compute updated state: sr ← Next(sr−1 , σA r r r r return σA , σP , Propose, I , s ;
Algorithm 4: Event-Driven CAT Status Resolution by Coordinator Input: Proposal Proposerc from chain c for round r, which is a partial map: T 7→ Status for some CATs T Initialize empty queue Q ← [ ]; for each CAT T ∈ domain(Proposerc ) do Store proposed Status for T from chain c; if proposals from all chains for T are received then if all chains propose success then Statusr [T ] ← success; else Statusr [T ] ← failure; Insert (T, Statusr [T ]) into Q; if Q is not empty then Send all entries in Q to the Confirmation Layer (CL);
[10] 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 [11] 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 [12] 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 [13] 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
[14] S. Müller, A. Penzkofer, N. Polyanskii, J. Theis, W. Sanders, and H. Moog, “Reality-based utxo ledger,” 2023. [Online]. Available: https://arxiv.org/abs/2205.01345 [15] 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,” in Proceedings of the 28th ACM SIGPLAN Annual Symposium on Principles and Practice of Parallel Programming, ser. PPoPP ’23. New York, NY, USA: Association for Computing Machinery, 2023, pp. 232–244. [Online]. Available: https://doi.org/10.1145/3572848.3577524 [16] 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 [17] 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. [18] 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 [19] 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 [20] 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 [21] A. Zamyatin, M. Al-Bassam, D. Zindros, E. Kokoris-Kogias, P. MorenoSanchez, A. Kiayias, and W. J. Knottenbelt, “Sok: Communication across distributed ledgers,” in Financial Cryptography and Data Security, N. Borisov and C. Diaz, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2021, pp. 3–36. [22] 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 [23] B. Kuśmierz, S. Müller, and A. Capossele, “Committee selection in dag distributed ledgers and applications,” Intelligent Computing, 2021. [24] Transaction Processing Performance Council, “TPC benchmark C: Standard specification, revision 5.11,” TPC, Tech. Rep., 2010. [Online]. Available: https://www.tpc.org/tpc documents current versions/pdf/tpc-c v5.11.0.pdf [25] 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 [26] J. Bearer, B. Bünz, 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: https://eprint.iacr.org/2024/1189 [27] Espresso Systems, “Espresso systems and catalyst collaborate to improve interoperability,” https://medium.com/@espressosys/espresso-systemsand-catalyst-collaborate-to-improve-interoperability-239addbe2c2b, 2023, accessed 2025-07-24. [28] LayerZero Labs, “LayerZero: An omnichain interoperability protocol,” https://layerzero.network/, 2024, accessed: 2025-07-24. [29] 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. [30] Polkadot Developers, “Overview: Polkadot chain architecture,” 2023, accessed: 2025-07-24. [Online]. Available: https://docs.polkadot.com/ polkadot-protocol/architecture/polkadot-chain/overview [31] G. Wood, “XCM part III: Execution and error management,” Polkadot Blog, 2021, accessed: 2026-0308. [Online]. Available: https://medium.com/polkadot-network/ xcm-part-iii-execution-and-error-management-ceb8155dd166 [32] J. O. Chervinski, D. Kreutz, and J. Yu, “Analyzing the performance of the inter-blockchain communication protocol,” in Proceedings 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 [33] 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 [34] M. J. Amiri, D. Agrawal, and A. E. Abbadi, “CAPER: A crossapplication permissioned blockchain,” in Proceedings 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 [35] 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