Pith. sign in

REVIEW 4 major objections 3 minor 58 references

$\mathsf{CRATE}$: Cross-Rollup Atomic Transaction Execution

T0 review · 4 major / 3 minor · reviewed 2026-08-08 · deepseek-v4-flash

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

Pith's one-line read CRATE makes cross-rollup transactions atomic and order-preserving across two rollups on different L1 chains, with finality in four L1 rounds.

desk verdict CRATE has a real attack and a plausible chain-CRT fix, but the DAG-CRT contract as printed cannot pass its own 2PC check, leaving Theorem 2 unsupported. read the letter →

arxiv 2502.04659 v1 pith:3E7GO2R4 submitted 2025-02-07 cs.CR

Ioannis Kaklamanis , Fan Zhang This is my paper · ORCID
classification cs.CR
keywords cross-rollupcomposabilityatomicityserializabilitytwo-phasecommitrollupvalidityproofscross-chaininteroperabilityGeneralSystemContract
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

The paper proposes CRATE, a protocol that lets a user execute a sequence of transactions spanning two rollups on different layer-1 chains as one atomic, order-preserving operation. Existing rollup-to-rollup schemes either break serializability for transactions longer than two steps or rely on a trusted shared sequencer. CRATE claims to restore both all-or-nothing execution and ordering using only the security of the underlying L1s, liveness of the L2s, and a trustless bridge between the L1s. The paper also formalizes two programming models for cross-rollup transactions and proves atomicity in both.

What carries the argument

The load-bearing machinery is a modified General System Contract (GSC) on each rollup that records triggered actions in a Merkle trigger tree and executed actions in a Merkle action tree, while maintaining a session nonce, an entry nonce, and an active flag to tie each triggered action to its session. The L1-side Validator Smart Contracts (VSMs) run a leader-follower two-phase commit: one VSM pre-commits, the other pre-commits after seeing proof, the leader commits after seeing matching GSC roots and nonce equality, and the follower commits after seeing the leader's decision. Cross-L1 evidence is verified against finalized headers relayed by a trustless bridge.

What would settle it

Set up two rollups and a malicious executor, submit a chain CRT of length 3, and have the executor run the actions in reverse order; if the VSM commit checks pass (equal GSC Merkle roots and equal nonce sums) for the reversed batch, Theorem 1 is wrong. Conversely, running an honest batch and checking that the four L1 transactions always settle in the claimed four rounds would confirm the latency claim.

Watch

Extended reading notes

Core claim

CRATE's central claim is that atomicity for cross-rollup transactions can be reduced to two checks that L1 validator contracts can enforce: matching Merkle roots of trigger/action trees between the two rollups' general system contracts, and a session-nonce accounting rule that forces actions to execute in the intended order. A two-phase commit between the two validator contracts makes the state-digest update all-or-nothing even though the rollups live on distinct L1s. The paper proves Theorem 1 for chain CRTs and Theorem 2 for the more expressive DAG CRTs, both for two rollups.

Load-bearing premise

The protocol depends on a trustless bridge between the two L1s that relays only finalized headers to both validator contracts; if that bridge stalls or relays non-final state, the two-phase commit evidence cannot prove atomicity across the chains.

Editorial extensions

If this is right

  • Cross-rollup flash loans and arbitrage become possible without trusting a shared sequencer or bridge operator.
  • Rollups on separate L1s can interoperate with constant, four-round L1 latency independent of CRT length.
  • The session-nonce design blocks the reordering attack that breaks the prior trigger-action scheme for CRTs longer than two actions.
  • The DAG model lets one action fan out to multiple triggered sub-actions, matching applications like flash loans where several contracts must act on the other rollup.
  • With SNARK-based membership proofs, the added L1 gas is about 32 to 75 percent of a vanilla zk-rollup's observed batch submission cost.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The same leader-follower two-phase commit structure could in principle be extended to more than two rollups, but the paper only proves the two-rollup case; that extension is my inference, not a paper claim.
  • A testable prediction following from the proof structure is that any violation of atomicity must appear either as a GSC root mismatch or a nonce-sum violation; monitoring those two values in a live deployment would catch an attack.
  • If bridge relay latency or non-final header risk materializes, the four-round estimate is optimistic; the protocol's actual security depends on bridge finality, an assumption the paper explicitly flags.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 3 minor

Summary. The paper proposes CRATE, a protocol for executing cross-rollup transactions (CRTs) atomically across two rollups on distinct L1 chains. It defines two formal CRT models (chain-CRT and DAG-CRT), gives a security definition of atomicity, and proves two theorems: Theorem 1 for chain-CRTs and Theorem 2 for DAG-CRTs. The protocol uses a modified General System Contract (GSC) with sessions and nonces, plus a Two-Phase Commit (2PC) protocol between Validator Smart Contracts (VSMs) to achieve all-or-nothing, order-preserving execution in four L1 rounds. The paper also reports an implementation and gas-cost evaluation compared with Zksync Era, and a cross-rollup flash loan application.

Significance. If the identified gaps are repaired, CRATE would be a valuable contribution. It gives the first formal treatment of cross-rollup composability in the trigger–action framework, identifies a real serializability attack on the prior SVS proposal, and provides a concrete 2PC-based design with a plausible constant-round finality argument. The open-source implementation and gas benchmarks are useful evidence of practicality, and the explicit trust assumptions (L1 safety/liveness and bridge liveness) are mostly stated clearly, though the abstract understates them.

major comments (4)
  1. [Appendix A, Algorithm 3] In Algorithm 3, line 30, the ACTION function executes each triggered sub-action and then calls trigTree.insert(msgHash). In the chain-CRT GSC (Algorithm 1, line 33) the analogous hash is inserted into actTree, and Claim 2 explicitly requires a.desc ⊆* actTree and a.descnext ⊆* trigTree. As printed, Algorithm 3 never writes actTree, so the VSM commit check (Algorithm 4, lines 29–30, requiring trigRt' = oVSM.actRt' and actRt' = oVSM.trigRt') can succeed only when trigTree is also empty, i.e., when no CRT is present. Theorem 2 therefore cannot be derived from the DAG-CRT contract as specified.
  2. [Section 7.1, Theorem 1 proof] The proof claims 'using an inductive argument across all CRTs present in batch1 and batch2, at least one of (I,II,III) is not preserved.' Lemma 1 and Lemma 3, however, are stated for a single CRT instance. The induction is not supplied, and it is not immediate that the tree-equality and nonce-sum predicates compose over multiple CRTs in a batch. Because the theorem claims atomicity for arbitrary batches, this missing induction is load-bearing.
  3. [Section 6 and Algorithm 4] Algorithm 4's VERCOMEVD verifies trigRt' = oVSM.actRt', actRt' = oVSM.trigRt', and entryNonce' + oVSM.entryNonce' = sessionNonce' (lines 29–31). It does not verify that oVSM.sessionNonce' equals this same value, even though Lemma 3's condition (II) requires sessionNonce1 = sessionNonce2 = entryNonce1 + entryNonce2. The proof of Theorem 1 states that the VSM 'must see that all three properties (I,II,III) are preserved,' but the pseudocode as printed checks only one of the two session nonces.
  4. [Abstract and Remark 1] The abstract states that CRATE 'only relies on the underlying L1s and the liveness of L2s,' but Remark 1 requires a trustless bridge between the L1s and assumes that a VSM only accepts bridge-relayed final state; the contributions bullet correctly lists 'liveness of a bridge.' The abstract should be corrected to include the bridge liveness assumption, since the formal theorems inherit this dependency.
minor comments (3)
  1. [Section 7.1, before Claim 1] The sentence preceding Claim 1 says a.desc and a.descnext are inserted into the trigger and action trees, respectively; the correct order is action and trigger trees, as Claim 1 states.
  2. [Appendix F] The trigger calls in the flash-loan Solidity code pass a hard-coded value 10_000 as an argument, but its meaning (e.g., a gas limit) is not explained in the text.
  3. [Section 4.1, Definition 1] The phrase 'immediate next accepted after running CRAT protocol' is ambiguous for local state digests; consider clarifying that the definition refers to the first accepted digest pair after the CRT's submission.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: security proof reduces to Merkle-root consistency invariants; the printed DAG pseudocode has a correctness typo but that is not a circularity.

full rationale

The paper's central claim is not circular. Atomicity is defined in Definition 1 before the protocol is introduced, and the proof of Theorem 1 reduces the property to invariant (I): trigTree1 = actTree2 and trigTree2 = actTree1, together with nonce conditions (II) and (III). These invariants are derived from GSC insertion logic via Claim 1 and the lemmas, not assumed as the target conclusion. The 2PC VSM checks verify exactly these tree roots, which is a standard soundness argument rather than a self-definitional reduction. No parameter is fitted to the target result, and the protocol is not benchmarked against itself. The only author self-citation is [51] in related work, which is not load-bearing. The bridge-liveness and finality assumptions are stated explicitly in Remark 1 and used as assumptions, not disguised as conclusions. One notable defect exists but is a correctness issue, not circularity: in Appendix A, Algorithm 3's ACTION function inserts executed sub-action hashes into trigTree (line 30) instead of actTree, which is inconsistent with Claim 2 and the commit checks in Algorithm 4; this would invalidate the DAG proof as printed, but it does not make the derivation circular. Overall, the paper's derivation chain is self-contained with respect to the claims it actually proves, and no circular step can be exhibited.

Assumptions & free parameters 0 free parameters · 8 assumptions · 2 invented entities

The central claim rests on standard blockchain liveness/safety, a trustless bridge, cryptographic soundness, and a custom EVM execution model. There are no fitted constants or free parameters in the security argument; protocol artifacts are implemented in the shipped code.

assumptions (8)
  • domain assumption Underlying L1 chains are live and safe, meaning finalized blocks are consistent and eventually include transactions.
    Stated in Section 3.1 threat model; needed for the VSM 2PC transactions to finalize.
  • domain assumption Participating rollups maintain liveness and the Executor is always online processing transactions.
    Stated in Section 3.1; needed for off-chain XEVM execution and for the leader VSM to eventually commit or abort.
  • domain assumption A trustless bridge relays finalized L1 block headers between the distinct L1s, and VSMs only accept finalized state.
    Remark 1; the 2PC evidence verification in Algorithm 4 uses bridge-relayed attributes.
  • standard math Cryptographic hash functions are collision resistant and Merkle/MPT membership proofs are sound.
    Used in Claim 1 and Lemma 1 to equate tree-root equality with equality of inserted action descriptions.
  • standard math SNARKs used for validity proofs and MPT verification satisfy completeness and knowledge soundness.
    Stated in Section 2; needed for the Executor's validity proof and the VSM verifier.
  • domain assumption Each action description a.desc uniquely determines its trace and its triggered next-action descriptions.
    Section 4.1; the model relies on this to bundle desc, trace, and descnext into one atomic unit.
  • domain assumption EVM execution is deterministic and a failed transaction reverts atomically, allowing the Executor to roll back L2 state checkpoints.
    Algorithm 5 ENTRY POINT restores checkpoints on failure; this underpins all-or-nothing off-chain execution.
  • domain assumption One-time setup: each VSM knows its rollup GSC address and the other VSM's address and ID.
    Remark 2; needed for leader determination and root checks.
invented entities (2)
  • GSC session and entry nonces with sessionActive flag independent evidence
    purpose: Track CRT sessions off-chain so that a malicious Executor cannot reorder actions of a length>2 CRT while keeping Merkle roots consistent.
    Implemented in the Solidity GSC contract (Algorithms 1 and 3) and exercised by the flash loan evaluation; the nonce equality checks are what the VSM verifies on L1.
  • VSM 2PC status machine (Free/Paired status and decisions mapping) independent evidence
    purpose: Coordinate the two L1 validator contracts so both rollups commit or abort the new state digests together.
    Implemented in the Solidity VSM contract and driven by the Python Executor in the evaluation; its commit/abort decisions are part of the protocol specification.

how reviews work

0 comments
Cite this review

Pith. "Pith review of $\mathsf{CRATE}$: Cross-Rollup Atomic Transaction Execution." pith.science (2026). https://pith.science/paper/3E7GO2R4

@misc{pith2026250204659,
  author       = {Pith},
  title        = {Pith review of: $\mathsfCRATE$: Cross-Rollup Atomic Transaction Execution},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/3E7GO2R4}},
  note         = {Machine review of arXiv:2502.04659}
}
abstract

Blockchains have revolutionized decentralized applications, with composability enabling atomic, trustless interactions across smart contracts. However, layer 2 (L2) scalability solutions like rollups introduce fragmentation and hinder composability. Current cross-chain protocols, including atomic swaps, bridges, and shared sequencers, lack the necessary coordination mechanisms or rely on trust assumptions, and are thus not sufficient to support full cross-rollup composability. This paper presents $\mathsf{CRATE}$, a secure protocol for cross-rollup composability that ensures all-or-nothing and serializable execution of cross-rollup transactions (CRTs). $\mathsf{CRATE}$ supports rollups on distinct layer 1 (L1) chains, achieves finality in 4 rounds on L1, and only relies on the underlying L1s and the liveness of L2s. We introduce two formal models for CRTs, define atomicity within them, and formally prove the security of $\mathsf{CRATE}$. We also provide an implementation of $\mathsf{CRATE}$ along with a cross-rollup flash loan application; our experiments demonstrate that $\mathsf{CRATE}$ is practical in terms of gas usage on L1.

Figures

Figures reproduced from arXiv: 2502.04659 by the authors.

Figure 1
Figure 1. SVS [50] trigger-action paradigm. Here “CALL(f)” denotes that the (smart contract) function f will be executed. Atomic Transactions (CRAT) protocol that (a) is as secure as existing zk-rollups, (b) is efficient in terms of layer 1 trans￾actions, (c) places minimal or zero trust on any third-party, and (d) is practical in terms of on-chain (L1) gas usage. Defining Cross-Rollup Transaction (CRT). For the rest of this … view at source ↗
Figure 2
Figure 2. Serializability attack on SVS [50]. A malicious Executor (shown on the right in red) can execute a3 before a ′ 1 , flipping the order of steps (2,3) with steps (6,7). Since a ′ 1 only modifies trigTree1 and GSC1.action(a3) only modifies actTree1, the two GSC contracts result in the same state as in the honest execution (shown in the middle), thus passing the consistency check. come this challenge, the Two-Phase Comm… view at source ↗
Figure 3
Figure 3. CRATE Overview encodes her intended CRT by making the appropriate calls to GSC.trigger(·), and sends her transaction to the Executor (step 1). The Executor keeps executing received transactions off-chain (phase 1 below) and, at regular intervals, he submits transaction batches – along with the state digest they produce – to the VSM on L1 (phase 2 below). Phase 1. The Executor executes the transaction batch off￾chain… view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: L1 gas usage increase incurred by the MPT [PITH_FULL_IMAGE:figures/full_fig_p013_4.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

58 extracted references · 57 canonical work pages

  1. [1]

    https: //bitcointalk.org/index.php?topic= %20193281.msg2224949#msg2224949

    Alt chains and atomic transfers. https: //bitcointalk.org/index.php?topic= %20193281.msg2224949#msg2224949

    work page

  2. [2]

    https://axelar.network/

    Axelar | Secure cross-chain communication for Web3. https://axelar.network/

    work page

  3. [3]

    https://docs.circom.io/

    Circom 2 Documentation. https://docs.circom.io/

    work page

  4. [4]

    https://www.forbes.com/digital-assets/ crypto-prices/

    Cryptocurrency Prices, Market Cap and Charts. https://www.forbes.com/digital-assets/ crypto-prices/

    work page

  5. [5]

    https://defillama.com/bridges

    DefiLlama. https://defillama.com/bridges

    work page

  6. [6]

    https:// pages.near.org/bridge/

    ETH <> NEAR Rainbow Bridge. https:// pages.near.org/bridge/

    work page

  7. [7]

    https:// etherscan.io/

    The ethereum blockchain explorer. https:// etherscan.io/

    work page

  8. [8]

    https: //docs.equalizer.finance/equalizer-deep- dive/flash-loan-gas-cost-comparison

    Flash loan gas cost comparison. https: //docs.equalizer.finance/equalizer-deep- dive/flash-loan-gas-cost-comparison

    work page

Show all 58 references
  1. [9]

    https://en.bitcoin.it/wiki/ Hash_Time_Locked_Contracts

    Hash Time Locked Contracts - Bitcoin Wiki. https://en.bitcoin.it/wiki/ Hash_Time_Locked_Contracts

  2. [10]

    https://www.optimism.io/

    Optimism. https://www.optimism.io/

  3. [11]

    https:// explorer.zksync.io/

    Zksync era block explorer. https:// explorer.zksync.io/. 14

  4. [12]

    Typhon’s Chimera Chains | Blog - Anoma, 2023.https: //anoma.net/blog/chimera-chains

    2023

  5. [13]

    Andrew W. Appel. Compiling with Continuations. Cam- bridge University Press, USA, 2007

    2007

  6. [14]

    Astria documentation

    Astria. Astria documentation. https: //docs.astria.org/

  7. [15]

    Sok: Security and privacy of blockchain interoperability

    André Augusto, Rafael Belchior, Miguel Correia, André Vasconcelos, Luyao Zhang, and Thomas Hardjono. Sok: Security and privacy of blockchain interoperability. In 2024 IEEE Symposium on Security and Privacy (SP) , pages 3840–3865, 2024

    2024

  8. [16]

    Concurrency control and recovery in database systems

    Philip A Bernstein, Vassos Hadzilacos, and Nathan Goodman. Concurrency control and recovery in database systems. Addison-Wesley Longman Publish- ing Co., Inc., USA, June 1986

    1986

  9. [17]

    Vitalik Buterin, Diego Hernandez, Thor Kamphefner, Khiem Pham, Zhi Qiao, Danny Ryan, Juhyeok Sin, Ying Wang, and Yan X. Zhang. Combining GHOST and casper. CoRR, abs/2003.03052, 2020

    2003 arXiv

  10. [18]

    Cross-Chain Interoperability Protocol (CCIP) | Chainlink

    Chainlink. Cross-Chain Interoperability Protocol (CCIP) | Chainlink. https://chain.link/cross- chain

  11. [19]

    CIRC: Coordinated inter-rollup communica- tion

    Espresso. CIRC: Coordinated inter-rollup communica- tion. https://espresso.discourse.group/t/circ- coordinated-inter-rollup-communication/43

  12. [20]

    Transactional cross-chain smart contract invocations

    Ghareeb Falazi, Uwe Breitenbücher, Frank Leymann, Stefan Schulte, and Vladimir Yussupov. Transactional cross-chain smart contract invocations. Distrib. Ledger Technol., 8 2023

    2023

  13. [21]

    Introduction to smart contracts

    Etherem Foundation. Introduction to smart contracts. https://ethereum.org/en/smart-contracts

  14. [22]

    Ethereum virtual machine (evm)

    Ethereum Foundation. Ethereum virtual machine (evm). https://ethereum.org/en/developers/ docs/evm/

  15. [23]

    JSON-RPC API

    Ethereum Foundation. JSON-RPC API. https://ethereum.org/en/developers/docs/ apis/json-rpc/

  16. [24]

    Ethereum Foundation. Layer 2. https:// ethereum.org/en/layer-2/

  17. [25]

    Merkle Patricia Trie

    Ethereum Foundation. Merkle Patricia Trie. https://ethereum.org/en/developers/docs/ data-structures-and-encoding/patricia- merkle-trie/

  18. [26]

    Reorgs in proof of stake

    Ethereum Foundation. Reorgs in proof of stake. https://ethereum.org/en/developers/docs/ consensus-mechanisms/pos/attack-and- defense/#reorgs

  19. [27]

    Zero-Knowledge rollups

    Ethereum Foundation. Zero-Knowledge rollups. https://ethereum.org/en/developers/docs/ scaling/zk-rollups

  20. [28]

    Superchain explainer

    Optimism Foundation. Superchain explainer. https://docs.optimism.io/superchain/ superchain-explainer

  21. [29]

    A pub-sub ar- chitecture to promote blockchain interoperability.CoRR, abs/2101.12331, 2021

    Sara Ghaemi, Sara Rouhani, Rafael Belchior, Rui Santos Cruz, Hamzeh Khazaei, and Petr Musílek. A pub-sub ar- chitecture to promote blockchain interoperability.CoRR, abs/2101.12331, 2021

    2021 arXiv

  22. [30]

    On the size of pairing-based non-interactive arguments

    Jens Groth. On the size of pairing-based non-interactive arguments. In Marc Fischlin and Jean-Sébastien Coron, editors, Advances in Cryptology – EUROCRYPT 2016, pages 305–326, Berlin, Heidelberg, 2016. Springer Berlin Heidelberg

    2016

  23. [31]

    Atomic Cross-Chain Swaps

    Maurice Herlihy. Atomic Cross-Chain Swaps. In Pro- ceedings of the 2018 ACM Symposium on Principles of Distributed Computing, PODC ’18, pages 245–254, New York, NY , USA, July 2018. Association for Com- puting Machinery

    2018

  24. [32]

    Jansen and J

    G. Jansen and J. Saladas. Advantages of event- driven architecture. Developer IBM, 2020. https://developer.ibm.com/technologies/ messaging/articles/advantages-of-an-event- driven-architecture/

    2020

  25. [33]

    solidity-mpt

    Jun Kimura. solidity-mpt. https://github.com/ibc- solidity/solidity-mpt

  26. [34]

    Matter Labs. Zksync. https://zksync.io/ ecosystem

  27. [35]

    Instant confirmations, 2024

    Matter Labs. Instant confirmations, 2024. https://docs.zksync.io/zksync-protocol/ rollup/finality#instant-confirmations

    2024

  28. [36]

    zksync transaction work- flow

    Madigan Lebreton, Elouan Wauquier, and Victor Houal. zksync transaction work- flow. https://blog.quarkslab.com/zksync- transaction-workflow.html. Published: October 26, 2023

    2023

  29. [37]

    Namjoshi

    Huaixi Lu, Akshay Jajoo, and Kedar S. Namjoshi. Atom- icity and abstraction for cross-blockchain interactions, 2024

    2024

  30. [38]

    Ralph C. Merkle. A digital signature based on a conven- tional encryption function. In Carl Pomerance, editor, 15 Advances in Cryptology — CRYPTO ’87 , pages 369– 378, Berlin, Heidelberg, 1988. Springer Berlin Heidel- berg

    1988

  31. [39]

    Aggregation layer

    Polygon. Aggregation layer. https: //polygon.technology/agglayer

  32. [40]

    Attacking the DeFi Ecosystem with Flash Loans for Fun and Profit

    Kaihua Qin, Liyi Zhou, Benjamin Livshits, and Arthur Gervais. Attacking the DeFi Ecosystem with Flash Loans for Fun and Profit. In Nikita Borisov and Claudia Diaz, editors, Financial Cryptography and Data Secu- rity, Lecture Notes in Computer Science, pages 3–32, Berlin, Heide...

    2021

  33. [41]

    The radius documentation

    The Radius. The radius documentation. https:// docs.theradius.xyz/

  34. [42]

    Event-driven architecture to im- prove performance and scalability in microservices- based systems

    Alam Rahmatulloh, Fuji Nugraha, Rohmat Gunawan, and Irfan Darmawan. Event-driven architecture to im- prove performance and scalability in microservices- based systems. In 2022 International Conference Ad- vancement in Data Science, E-learning and Information Systems (ICADEIS),...

    2022

  35. [43]

    Isaac Sheff, Xinwen Wang, Robbert van Renesse, and Andrew C. Myers. Heterogeneous Paxos: Technical Report, November 2020

    2020

  36. [44]

    Foundations of Distributed Consensus and Blockchains

    Elaine Shi. Foundations of Distributed Consensus and Blockchains. 2020

    2020

  37. [45]

    Gerald Jay Sussman and Guy L. Steele. Scheme: A In- terpreter for Extended Lambda Calculus. Higher-Order and Symbolic Computation, 11(4):405–439, December 1998

    1998

  38. [46]

    Espresso network documentation

    Espresso Systems. Espresso network documentation. https://docs.espressosys.com/network

  39. [47]

    Foundry book

    Foundry Team. Foundry book. https:// book.getfoundry.sh/

  40. [48]

    Proofs, Arguments, and Zero-Knowledge

    Justin Thaler. Proofs, Arguments, and Zero-Knowledge. Georgetown University, 2022

    2022

  41. [49]

    MAD-HTLC: Because HTLC is Crazy-Cheap to Attack

    Itay Tsabary, Matan Yechieli, Alex Manuskin, and Ittay Eyal. MAD-HTLC: Because HTLC is Crazy-Cheap to Attack. In 2021 IEEE Symposium on Security and Privacy (SP), pages 1230–1248, May 2021. ISSN: 2375- 1207

    2021

  42. [50]

    Shared validity sequencing | umbra research

    John Guibas Uma Roy, 0xShitTrader. Shared validity sequencing | umbra research. https: //umbraresearch.xyz/writings/shared- validity-sequencing

  43. [51]

    He-HTLC: Revisiting Incentives in HTLC

    Sarisht Wadhwa, Jannis Stoeter, Fan Zhang, and Kartik Nayak. He-HTLC: Revisiting Incentives in HTLC. In Network and Distributed System Security (NDSS) Sym- posium 2023, San Diego, CA, USA, 2023

    2023

  44. [52]

    Ethereum: A secure decentralised generalised transaction ledger

    Dr Gavin Wood. Ethereum: A secure decentralised generalised transaction ledger. Ethereum project yellow paper, 151:1–32, 2014

    2014

  45. [53]

    Composability is Innovation, June

    Linda Xie. Composability is Innovation, June

  46. [54]

    zkBridge: Trustless Cross-chain Bridges Made Practical

    Tiancheng Xie, Jiaheng Zhang, Zerui Cheng, Fan Zhang, Yupeng Zhang, Yongzheng Jia, Dan Boneh, and Dawn Song. zkBridge: Trustless Cross-chain Bridges Made Practical. In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Secu- rity, CCS ’22, pages 3003–...

    2022

  47. [55]

    Cross-chain state machine replication, 2022

    Yingjie Xue and Maurice Herlihy. Cross-chain state machine replication, 2022. https://arxiv.org/abs/ 2206.07042

    2022 arXiv

  48. [56]

    only if” direction corresponds to the honest execution; its proof is simple and omitted. We focus on the “if

    Victor Zakhary, Divyakant Agrawal, and Amr El Abbadi. Atomic commitment across blockchains. Proceedings of the VLDB Endowment, 13(9):1319–1331, May 2020. 16 A General System Contract Algorithm 3 contains the pseudocode for the General System Contract supporting DAG-CRTs. Modif...

    2020

  49. [58]

    Token : only GSC

    This gives us directly that trigTree′ 1 ̸= actTree′ 2. 9This statement also captures the edge cases where either a is not triggering or is not action-wrapped; e.g. if |a.desc| = 0, then trivially a.desc = []⊆ actTree. 19 • Case 2: a′ i+1.desc ⊆ actTree′ 2 and ∃ j such that ai+...

  50. [2021]

    https://a16zcrypto.com/posts/article/ how-composability-unlocks-crypto-and- everything-else/

Pith tools

Reviewed August 8, 2026 · model on record in the stance chip above.