Pith. sign in

REVIEW 3 major objections 6 minor 43 references

The Smart Contract Model

T0 review · 3 major / 6 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 The paper proposes a smart contract model for cross-chain protocols in which correctness is coalition Nash equilibrium plus liveness plus safety, and proves that a two-party hash-timed swap satisfies all three conditions.

desk verdict A useful synthesis of a cross-chain model with game-theoretic correctness, but the case-study proofs verify a stipulated outcome map rather than the automaton-defined protocol. read the letter →

arxiv 2502.05280 v1 pith:H65O7FVG submitted 2025-02-07 cs.DC

Yackolley Amoussou-Guenou , Maurice Herlihy , Sucharita Jayanti , Maria Potop-Butucaru , Sergio Rajsbaum This is my paper · ORCID
classification cs.DC
keywords smartcontractmodelcross-chainprotocolsByzantinepartiesgametheorycoalitionNashequilibriumatomicswapblockchaindistributedcomputing
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 a formal model of cross-chain protocols in which mutually distrusting parties interact only through trusted smart contracts on separate ledgers. It argues that correctness in this setting cannot be classical all-or-nothing atomicity, because a party can deviate in arbitrary ways, so tasks must be specified by a utility function over possible asset-transfer outcomes. A protocol is correct when it satisfies coalition Nash equilibrium, liveness, and safety: no coalition gains by deviating, full compliance achieves every party's preferred transfer, and no compliant party loses value. The paper demonstrates the model on a two-party hash-timed swap and proves the three correctness conditions for that protocol.

What carries the argument

The central object is the execution function $\Xi : I_P \times I_C \times 2^{\mathcal{P}} \to 2^{O_C}$, which assigns to each input party vector, input contract vector, and compliance set $Q$ the set of possible output contract-state vectors. It stands in for the protocol's behavior so that correctness can be checked directly on outcomes rather than on individual automaton traces. The formal substrate is the product composition of interface automata, and the evaluation metric is the utility function $U$ defined on transitions. The two-party swap proof then works by case analysis over which party, Alice, Bob, both, or neither, is compliant, using the stipulated $\Xi$ outcomes and the utility table.

What would settle it

Construct the composed interface automaton for the two-party swap and compute its reachable execution fragments; if any reachable outcome is missing from the paper's $\Xi$ table, or any listed outcome is unreachable, then Lemmas 1, 2, and 3 do not apply to the protocol as formally defined. A concrete trace to look for: Bob is compliant while Alice deviates after escrowing $a$ but before claiming $b$, and Bob ends up with neither asset, which would violate safety if it is reachable.

Watch

Extended reading notes

Core claim

The central claim is that the smart contract model, with correct protocols defined by three game-theoretic conditions, captures cross-chain tasks and separates the roles of parties and contracts: parties propose, contracts dispose. The paper defines a cross-chain system as interface automata for parties and contracts, a task by input party vectors, input contract vectors, output contract vectors, and a utility function, and a protocol by an execution function $\Xi$ mapping inputs and compliance sets to possible output contract states. Correctness is coalition Nash equilibrium plus liveness plus safety as formalized in Section 4.3. As evidence, the paper proves Lemmas 1, 2, and 3 for a two-party atomic swap, showing that when both comply the swap occurs and each party gains utility 1, and that no compliant party can be driven negative and no singleton coalition can profit by deviating.

Load-bearing premise

The load-bearing assumption is that the hand-written outcome table in Section 5.2 faithfully describes everything the composed contracts and parties can actually do; the paper does not derive that table from the formal automaton definitions.

Editorial extensions

If this is right

  • If the model is right, cross-chain protocols can be analyzed without assuming an honest majority; the working assumption is only that at least one party is compliant.
  • Correctness can be checked by finite case analysis over compliance sets for small protocols, making the three conditions a practical design template for new cross-chain tasks.
  • The formal swap proof gives a baseline for expressing other tasks in the model, such as auctions, loans, options, and multi-party swaps, as the paper itself notes.
  • Because contracts, not parties, decide executed transfers, Byzantine behavior of parties is contained at the contract boundary, which is the key structural difference from classical distributed computing models.

Reading between the lines

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

  • A natural extension the paper leaves implicit is to derive $\Xi$ algorithmically from the composed interface automata, for instance by reachable-state exploration, and then re-check the three conditions against that derived table rather than a hand-asserted one.
  • The coalition Nash condition is weaker than strong Nash equilibrium: it only requires that a coalition cannot increase its collective utility, so a deviating coalition member could individually lose while the coalition as a whole gains; this distinction matters for multi-party tasks but is not exercised by the two-party case study.
  • The model implicitly frames smart contracts as trusted third parties for fair exchange, so the well-known impossibility result for fair exchange without a trusted third party explains why contract-mediated protocols can solve tasks that purely peer-to-peer protocols cannot; the paper cites that result but does not develop the connection.
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

3 major / 6 minor

Summary. The paper introduces a formal model, called the smart contract model, for cross-chain protocols in which parties (some possibly Byzantine) interact through trusted smart contracts on distinct ledgers. Parties and contracts are modeled as interface automata; a task is defined by input party vectors, input contract state vectors, output contract state vectors, and a utility function; a protocol is defined by a tuple (IP, IC, OC, Ξ), where Ξ is an execution function mapping inputs and a compliance set to a set of possible output contract states. Correctness of a protocol is defined by coalition Nash equilibrium, liveness, and safety, all formulated in terms of Ξ. The paper then presents a two-party cross-chain swap protocol, specifies Ξ for it, and claims in Lemmas 1–3 that it satisfies liveness, safety, and coalition Nash equilibrium. The central claim is that this swap protocol is correct under the proposed model.

Significance. If the formal connection between the execution function Ξ and the automaton semantics were established, the model would provide a useful abstraction that adapts classical distributed-computing concepts (interface automata, tasks, protocols) to blockchain-based cross-chain settings while incorporating game-theoretic correctness conditions. The related work is broad and the two-party swap case study is well motivated. However, as it stands, the paper does not deliver a rigorous correctness proof of the swap protocol, because the proofs in Section 5.3 verify a stipulated outcome map rather than the automaton-defined protocol. This gap is internal and fixable, but it undermines the central claim; the paper therefore requires substantial revision before the stated results can be accepted.

major comments (3)
  1. [Section 4.3, 5.3] The correctness conditions (coalition Nash equilibrium, liveness, safety) are stated exclusively over the execution function Ξ, but the protocol is identified with the composed interface automaton. No formal rule is given that maps execution fragments of the automaton product to the output sets Ξ(IP, IC, Q); in particular, the paper never proves that the terminal states of the automaton product coincide with the enumerated Ξ sets. Lemmas 1–3 of Section 5.3 are direct case analyses over the hand-defined Ξ (Lemma 1 uses Ξ(P) = swapped outcome, Lemma 2 enumerates Ξ({A}) and Ξ({B}), and Lemma 3 compares utility values on those same sets). Consequently, the lemmas establish properties of an asserted outcome list, not of the protocol as an automaton. If the automaton's reachable outcomes differ from the listed Ξ values, safety or coalition equilibrium could fail even though the lemmas hold. This is the load-bearing gap in the correctness argument.
  2. [Section 4.1] The composition operation is defined only for two composable interface automata, IA_P ⊗ C, with composability conditions involving one party and one contract. The interface automaton of a cross-chain system is then asserted to be the composition 'as proposed by Alfaro and Henzinger' without specifying how the pairwise product extends to m parties and n contracts, how multiple parties sharing actions with the same contract are handled, or how the product state space and transitions are formed. Since the swap protocol of Section 5 involves two parties and two contracts, the existence and semantics of the claimed composed automaton are not formally established. The paper should either define the general composition operation or instantiate the pairwise products for the case study and prove the required properties for that specific automaton.
  3. [Section 5.2, 5.3] The execution function Ξ for the swap protocol is stipulated by fiat ('we can restrict the execution function to its compliance set argument alone'), and the informal protocol steps (escrow, claim, refund) are never translated into interface automata. The proofs of Lemmas 1–3 therefore verify the utility properties of the chosen Ξ (Equation 6 and the bullet lists in Section 5.2), not that the described protocol actually realizes those outcome sets. Because Ξ is a component of the protocol tuple, the correctness claim risks being tautological: one could choose Ξ to satisfy the three conditions for any desired outcome list regardless of what the automaton does. The revision must define the automaton for the swap protocol and prove that its reachable terminal outcomes are exactly the sets listed for Ξ, or alternatively restate the correctness conditions directly over automaton executions.
minor comments (6)
  1. [Section 4.4] In the first paragraph, 'The contacts receive messages' should be 'The contracts receive messages'.
  2. [Section 5.2] In Step 3, 'If Alice observs that Bob has not escrowed' should be 'observes'; and 'If, b the end of this round' should be 'by the end of this round'.
  3. [Section 5.1, Equation (5)] The output contract state vectors are typeset with symbols like '[֒→֒→A]' that are not legible in the provided PDF; readers cannot reliably match the four output vectors to the utility values in Equation (5), which complicates checking the case analysis in Section 5.3. Please use a clear ownership notation (e.g., listing for each asset which party owns it).
  4. [Section 5.3, Lemma 2] In the case 'If Bob alone is compliant' the set is written as Ξ({B}) = {[֒→֒→B], [֒→֒→B]}, where the two symbols appear identical; this should be corrected to the two distinct outcomes described in Section 5.2 (Alice fails to escrow a at Step 1, and Alice fails to claim b at Step 3).
  5. [References] Reference [38] spells 'equilbrium' for 'equilibrium' and cites a Wikipedia page for strong Nash equilibrium; a textbook or peer-reviewed survey reference would be more appropriate.
  6. [General] The figure '2swap.PNG' is listed in the arXiv metadata but is not cited or captioned in the text; it should be either integrated with a proper caption or removed.

Circularity Check

1 steps flagged · score 8.0 of 10

Correctness proofs verify the hand-stipulated execution function Ξ, not the interface-automaton protocol.

  1. self definitional [Section 4.3 (execution function and correctness), Section 5.2 (Ξ definition), Section 5.3 (Lemmas 1-3)]
    "we can restrict the execution function Ξ : IP × IC × 2P → OC to its compliance set argument alone Ξ : 2P → OC. • If both parties are compliant, the swap takes place: Ξ({A, B}) = [֒→֒→A]. (6) ... Proof. Recall that Ξ(P) = [֒→֒→A]), which has utility 1 for both Alice and Bob (Equation 5)."

    Correctness (Section 4.3) is defined as conditions on the execution function Ξ: liveness, safety, and coalition Nash equilibrium quantify over Ξ(IP,IC,Q). The protocol tuple contains Ξ, and no formal rule connects Ξ to the interface-automaton composition called 'the protocol itself'. Section 5.2 fixes Ξ by hand: Ξ({A,B}) is the swapped outcome; Ξ({A}) and Ξ({B}) are enumerated lists. Lemma 1 'proves' liveness by recalling the stipulated Ξ(P) and reading utility; Lemmas 2-3 case-analyze the same stipulated sets. The lemmas verify the chosen outcome table, not the operational protocol. The claimed correctness is forced by the definition of Ξ and would hold even if the automaton had different reachable outcomes.

full rationale

The paper's formal model is a definitional framework and is not itself circular: it introduces interface automata, tasks, utilities, and correctness criteria as explicit definitions. The circularity is localized to the case-study correctness claim. The swap protocol is declared to be both the automaton composition and the tuple (IP,IC,OC,Ξ), but all three lemmas reason exclusively from the manually supplied Ξ values. Since the correctness predicate is defined over Ξ, choosing Ξ to contain the swapped outcome immediately yields Lemma 1, and choosing the deviating-outcome lists as in Section 5.2 immediately yields Lemmas 2 and 3. There is no derivation of these outcome sets from the interface-automaton semantics, so the 'proof of correctness' is a restatement of the protocol specification. This is one central self-definitional step rather than a chain of many circular steps; the score reflects that the paper's main claimed result reduces by construction to its stipulated execution function. Self-citations to prior atomic-swap work are not load-bearing here, so no separate self-citation step is scored.

Assumptions & free parameters 1 free parameters · 6 assumptions · 0 invented entities

The central claim rests on standard interface-automaton definitions plus several domain assumptions about blockchains. The main unstated assumption is that the execution function Xi used in correctness proofs is a faithful summary of the automaton composition.

free parameters (1)
  • Utility values for the swap task (Equation 5) = Alice: 2, 1, 0, -1 for the four outcomes; Bob symmetric
    Chosen by hand in Section 5.1. The coalition Nash equilibrium proof requires these exact preference orderings; they are not derived from any observable protocol behavior.
assumptions (6)
  • domain assumption Every interaction includes at least one compliant party.
    Stated in Section 3: 'We assume only that every interaction includes at least one honest party.' The safety and CNE conditions quantify over nonempty compliance sets.
  • domain assumption Synchronous rounds with a known upper bound Delta on message delivery.
    Sections 3 and 4.4 assume a known duration Delta for message delivery; the escrow timeouts in the swap protocol rely on this bound.
  • domain assumption Smart contracts are trusted, deterministic automata executing their code correctly; their code and state are public.
    Sections 2 and 3; the model treats contracts as honest while parties are Byzantine. This is the central refactoring the paper highlights.
  • domain assumption Contracts cannot send messages to contracts on other ledgers; compliant parties communicate only through contracts.
    Section 3 and Section 4.4; this motivates the synchronous four-phase execution and is treated as without loss of generality.
  • ad hoc to paper The pairwise interface-automaton composition of Section 4.1 extends to the full collection of m parties and n contracts.
    Section 4.1 defines the product of only two automata, then asserts that the CCS automaton is the composition of all parties and contracts without defining multi-way composition or its synchronization semantics.
  • domain assumption Utility functions are exogenous inputs to a task and are only weakly constrained by condition (3).
    Section 4.2 takes U as part of the task definition; the swap proof's CNE result is relative to the specific utility values in Equation 5.

how reviews work

0 comments
Cite this review

Pith. "Pith review of The Smart Contract Model." pith.science (2026). https://pith.science/paper/H65O7FVG

@misc{pith2026250205280,
  author       = {Pith},
  title        = {Pith review of: The Smart Contract Model},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/H65O7FVG}},
  note         = {Machine review of arXiv:2502.05280}
}
read the original abstract

Many of the problems that arise in the context of blockchains and decentralized finance can be seen as variations on classical problems of distributed computing. The smart contract model proposed here is intended to capture both the similarities and the differences between classical and blockchain-based models of distributed computing. The focus is on cross-chain protocols in which a collection of parties, some honest and some perhaps not, interact through trusted smart contracts residing on multiple, independent ledgers. While cross-chain protocols are capable of general computations, they are primarily used to track ownership of assets such as cryptocurrencies or other valuable data. For this reason, the smart contract model differs in some essential ways from familiar models of distributed and concurrent computing. Because parties are potentially Byzantine, tasks to be solved are formulated using elementary game-theoretic notions, taking into account the utility to each party of each possible outcome. As in the classical model, the parties provide task inputs and agree on a desired sequence of proposed asset transfers. Unlike the classical model, the contracts, not the parties, determine task outputs in the form of executed asset transfers, since they alone have the power to control ownership.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

43 extracted references · 36 canonical work pages

  1. [1]

    In: T joa, A.M., Gruhn, V

    de Alfaro, L., Henzinger, T.A.: Interface automata. In: T joa, A.M., Gruhn, V. (eds.) Proceedings of the 8th European Software Engineering Confe rence held jointly with 9th ACM SIGSOFT International Symposium on Foundation s of Software Engineering 2001, Vienna, Austria, September 10-14, 2001. pp. 109–120. ACM (2001)

    work page 2001

  2. [2]

    In: Spirakis, P.G., Tsigas, P

    Anceaume, E., Ludinard, R., Potop-Butucaru, M., Tronel, F.: Bitcoin a distributed shared register. In: Spirakis, P.G., Tsigas, P. (eds.) Stab ilization, Safety, and Se- curity of Distributed Systems - 19th International Symposi um, SSS 2017, Boston, The Smart Contract Model 15 MA, USA, November 5-8, 2017, Proceedings. Lecture Notes in C omputer Science, v...

    work page 2017

  3. [3]

    In: Scheideler, C., Bere nbrink, P

    Anceaume, E., Pozzo, A.D., Ludinard, R., Potop-Butucaru , M., Tucci Piergiovanni, S.: Blockchain abstract data type. In: Scheideler, C., Bere nbrink, P. (eds.) The 31st ACM on Symposium on Parallelism in Algorithms and Architect ures, SPAA 2019, Phoenix, AZ, USA, June 22-24, 2019. pp. 349–358. ACM (2019)

    work page 2019

  4. [4]

    In: D anos, V., Herlihy, M., Potop-Butucaru, M., Prat, J., Piergiovanni, S.T

    Anta, A.F., Georgiou, C., Nicolaou, N.: Atomic appends: S elling cars and co- ordinating armies with multiple distributed ledgers. In: D anos, V., Herlihy, M., Potop-Butucaru, M., Prat, J., Piergiovanni, S.T. (eds.) In ternational Conference on Blockchain Economics, Security and Protocols, Tokenomics 2019, May 6-7, 2019, Paris, France. OASIcs, vol. 71, pp...

    work page 2019

  5. [5]

    SIGACT News 49(2), 58–76 (2018)

    Anta, A.F., Konwar, K.M., Georgiou, C., Nicolaou, N.C.: F ormalizing and imple- menting distributed ledger objects. SIGACT News 49(2), 58–76 (2018)

    work page 2018

  6. [6]

    In: Borisov, N., Diaz, C

    Bartoletti, M., Bracciali, A., Lepore, C., Scalas, A., Zu nino, R.: A formal model of algorand smart contracts. In: Borisov, N., Diaz, C. (eds. ) Financial Cryptogra- phy and Data Security. pp. 93–114. Springer Berlin Heidelbe rg, Berlin, Heidelberg (2021)

    work page 2021

  7. [7]

    In: 40th IEEE International Conferen ce on Distributed Com- puting Systems, ICDCS 2020, Singapore, November 29 - Decemb er 1, 2020

    Belotti, M., Moretti, S., Potop-Butucaru, M., Secci, S.: Game theoretical analysis of cross-chain swaps. In: 40th IEEE International Conferen ce on Distributed Com- puting Systems, ICDCS 2020, Singapore, November 29 - Decemb er 1, 2020. pp. 485–495. IEEE (2020)

    work page 2020

  8. [8]

    bitcoinwiki: Atomic cross-chain trading, https://en.bitcoin.it/wiki/Atomic_cross-chain_trading

    work page

Show all 43 references
  1. [9]

    Blog, E.: Optimistic rollups (Nov 2022), https://ethereum.org/en/developers/docs/scaling/optimistic-rollups/ as of 28 December 2022

    2022

  2. [10]

    Bowe, S., Hopwood, D.: Hashed time-locked contract tran sactions, https://github.com/bitcoin/bips/blob/master/bip-0199.mediawiki

  3. [11]

    In: 20th IEEE Computer Security Fo undations Symposium, CSF 2007, 6-8 July 2007, Venice, Italy

    Canetti, R., Cheung, L., Kaynar, D.K., Lynch, N.A., Pere ira, O.: Compositional security for task-pioas. In: 20th IEEE Computer Security Fo undations Symposium, CSF 2007, 6-8 July 2007, Venice, Italy. pp. 125–139. IEEE Com puter Society (2007)

    2007

  4. [12]

    }: Chainlink 2.0 and the future of Decentralized Oracle Netwo rks | Chainlink, https://chain.link/whitepaper

    {Chainlink, Inc. }: Chainlink 2.0 and the future of Decentralized Oracle Netwo rks | Chainlink, https://chain.link/whitepaper

  5. [13]

    CoRR abs/1902.07986 (2019), http://arxiv.org/abs/1902.07986

    Chatterjee, K., Goharshady, A.K., Pourdamghani, A.: Pr obabilistic smart con- tracts: Secure randomness on the blockchain. CoRR abs/1902.07986 (2019), http://arxiv.org/abs/1902.07986

    2019 arXiv

  6. [14]

    In: Scheideler, C

    Civit, P., Potop-Butucaru, M.: Dynamic probabilistic i nput output automata. In: Scheideler, C. (ed.) 36th International Symposium on Distr ibuted Computing, DISC 2022, October 25-27, 2022, Augusta, Georgia, USA. LIPI cs, vol. 246, pp. 15:1–15:18. Schloss Dagstuhl - Leibniz-Ze...

    2022

  7. [15]

    In: Pelc, A., Schwarzmann, A .A

    Decker, C., Wattenhofer, R.: A fast and scalable payment network with bitcoin duplex micropayment channels. In: Pelc, A., Schwarzmann, A .A. (eds.) Stabiliza- tion, safety, and security of distributed systems. pp. 3–18 . Springer International Publishing, Cham (2015)

    2015

  8. [16]

    DeCred: Decred cross-chain atomic swapping, https://github.com/decred/atomicswap

  9. [17]

    In: Malysh kin, V

    Frey, D., Guillou, L., Raynal, M., Ta ¨ ıani, F.: Consensu s-Free Ledgers When Op- erations of Distinct Processes are Commutative. In: Malysh kin, V. (ed.) Par- allel Computing Technologies, vol. 12942, pp. 359–370. Spr inger International Publishing, Cham (2021). https://doi....

    2021 doi

  10. [18]

    In: Oswald, E., Fischlin, M

    Garay, J., Kiayias, A., Leonardos, N.: The Bitcoin Backb one Protocol: Analy- sis and Applications. In: Oswald, E., Fischlin, M. (eds.) Ad vances in Cryptol- ogy - EUROCRYPT 2015, vol. 9057, pp. 281–310. Springer Berli n Heidelberg, Berlin, Heidelberg (2015). https://doi.org/1...

    2015 doi

  11. [19]

    Garay, J., Kiayias, A., Leonardos, N.: The bitcoin backb one protocol: Analysis and applications. J. ACM 71(4) (aug 2024). https://doi.org/10.1145/3653445, https://doi.org/10.1145/3653445

    2024 doi

  12. [20]

    In: Proceedings of the 2017 ACM SIG SAC Conference on Computer and Communications Security (Oct 20 17)

    Green, M., Miers, I.: Bolt: Anonymous payment channels f or de- centralized currencies. In: Proceedings of the 2017 ACM SIG SAC Conference on Computer and Communications Security (Oct 20 17). https://doi.org/https://doi.org/10.1145/3133956.3134093

    2017

  13. [21]

    ArXiv (2019)

    Guerraoui, R., Kuznetsov, P., Monti, M., Pavlovic, M., S eredinschi, D.A.: The Consensus Number of a Cryptocurrency (Extended Ve r- sion). ArXiv (2019). https://doi.org/10.48550/ARXIV.1906.05574, https://arxiv.org/abs/1906.05574, publisher: arXiv Version Number: 1

    2019 doi arXiv

  14. [22]

    Heilman, E., Lipmann, S., Goldberg, S.: The arwen tradin g protocols (Jan 2019), https://www.arwen.io/whitepaper.pdf

    2019

  15. [23]

    In: Proceedings of the 2018 ACM symposium on principles of distributed computing

    Herlihy, M.: Atomic cross-chain swaps. In: Proceedings of the 2018 ACM symposium on principles of distributed computing. pp. 245– 254. PODC ’18, ACM, New York, NY, USA (2018). https://doi.org/10.1145/3212734.3212736, http://doi.acm.org/10.1145/3212734.3212736, number of pages:...

    2018

  16. [24]

    Proceedings of the VLDB Endowment 13(2), 100–113 (Oct 2019)

    Herlihy, M., Liskov, B., Shrira, L.: Cross-chain Deals a nd Ad- versarial Commerce. Proceedings of the VLDB Endowment 13(2), 100–113 (Oct 2019). https://doi.org/10.14778/3364324.3364326, http://arxiv.org/abs/1905.09743, arXiv: 1905.09743

    2019

  17. [25]

    In: Proceedings of the 2 7th USENIX Conference on Security Symposium

    Kalodner, H., Goldfeder, S., Chen, X., Weinberg, S.M., F elten, E.W.: Arbitrum: scalable, private smart contracts. In: Proceedings of the 2 7th USENIX Conference on Security Symposium. pp. 1353–1370. SEC’18, USENIX Assoc iation, USA (Aug 2018)

    2018

  18. [26]

    In: D’Angelo, G., Michail, O

    Lys, L., Micoulet, A., Potop-Butucaru, M.: R-SW AP: rela y based atomic cross- chain swap protocol. In: D’Angelo, G., Michail, O. (eds.) Al gorithmic Aspects of Cloud Computing - 6th International Symposium, ALGOCLOUD 2 021, Lisbon, Portugal, September 6-7, 2021, Revised Selec...

    2021

  19. [27]

    Network, R.: What is the raiden network?, https://raiden.network/101.html

  20. [28]

    Nolan, T.: Atomic swaps using cut and choose (Feb 2016), https://bitcointalk.org/index.php?topic=1364951

    2016

  21. [29]

    Organization, T.K.: The BarterDEX whitepaper: A decent ralized, open- source cryptocurrency exchange, powered by atomic-swap te chnology, https://supernet.org/en/technology/whitepapers/BarterDEX-Whitepaper-v0.4.pdf

  22. [30]

    Pagnia, H., Darmstadt, F.C.G.: On the impossibility of fair exchange without a trusted third party (1999), https://api.semanticscholar.org/CorpusID:11671049

    1999

  23. [31]

    Poon, J., Dryja, T.: The bitcoin lightning network: Scal able off-chain instant pay- ments (Jan 2016), https://lightning.network/lightning-network-paper.pdf

    2016

  24. [32]

    Poon, J., Buterin, V.: Plasma: Scalable autonomous smar t contracts (2017), https://www.plasma.io/plasma.pdf The Smart Contract Model 17

    2017

  25. [33]

    Rajsbaum, S., Raynal, M.: Mastering concurrent computi ng through sequential thinking. Commun. ACM 63(1), 78?87 (dec 2019). https://doi.org/10.1145/3363823, https://doi.org/10.1145/3363823

    2019 doi

  26. [34]

    Research, A.: Axelar network: Connecting applications with blockchain ecosystems (2022), https://arxiv.org/pdf/2011.12783.pdf, as of 8 May 2023

    2022 arXiv

  27. [35]

    Sliwinski, J., Wattenhofer, R.: ABC: Proof-of-Stake wi thout Consensus (Jul 2020), http://arxiv.org/abs/1909.10926, arXiv:1909.10926 [cs]

    2020 arXiv

  28. [36]

    Cryptolog y ePrint Archive, Paper 2024/418 (2024), https://eprint.iacr.org/2024/418

    Tas, E.N., Seres, I.A., Zhang, Y., Melczer, M., Kelkar, M ., Bonneau, J., Nikolaenko, V.: Atomic and fair data exchange via blockchain. Cryptolog y ePrint Archive, Paper 2024/418 (2024), https://eprint.iacr.org/2024/418

    2024

  29. [37]

    TechTarget: Cryptocurrency platform Wormhole loses $320M after attack | TechTarget,https://www.techtarget.com/searchsecurity/news/252512957/Cryptocurrency-platform-Wormhole-

  30. [38]

    https://en.wikipedia.org/wiki/Strong_Nash_equilibrium, as of 12 January 2025

    Wikipedia: Nash equilbrium. https://en.wikipedia.org/wiki/Strong_Nash_equilibrium, as of 12 January 2025

    2025

  31. [39]

    In: ACM Symposium on Principles of Distribut ed Computing (2021)

    Yingjie Xue, Maurice Herlihy: Hedging Against Sore Lose r Attacks in Cross-Chain Transactions. In: ACM Symposium on Principles of Distribut ed Computing (2021)

    2021

  32. [40]

    Zakhary, V., Agrawal, D., El Abbadi, A.: Atomic commitme nt across blockchains. CoRR abs/1905.02847 (2019), http://arxiv.org/abs/1905.02847, arXiv: 1905.02847 tex.bibsource: dblp computer science bibliogr aphy, https://dblp.org tex.biburl: https://dblp.org/rec/bib/journals/cor...

    2019 arXiv

  33. [41]

    In: Gilbert, S

    Zappal` a, P., Belotti, M., Potop-Butucaru, M., Secci, S .: Game theoretical frame- work for analyzing blockchains robustness. In: Gilbert, S. (ed.) 35th International Symposium on Distributed Computing, DISC 2021, October 4-8 , 2021, Freiburg, Germany (Virtual Conference). LI...

    2021

  34. [42]

    Zarick, R., Pellegrino, B., Banister, C.: Layerzero: Trustless omnichain interoperability protocol (2022), https://layerzero.network/pdf/LayerZero_Whitepaper_Release.pdf, as of 8 May 2023

    2022

  35. [43]

    2swap.PNG

    Zyskind, G., Kisagun, C., FromKnecht, C.: Enigma Cataly st: a machine-based investing platform and infrastructure for c rypto-assets, https://www.enigma.co/enigma_catalyst.pdf This figure "2swap.PNG" is available in "PNG" format from: http://arxiv.org/ps/2502.05280v1 This figu...

    arXiv

Pith tools

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