1 Introduction

Blockchains enable users to send and receive money in a trust-less manner. They offer a mean for peer-to-peer (P2P) exchanges of crypto-assets such as cryptocurrencies over the Internet, which was not possible without intermediaries before.

Blockchains are a very young ecosystem, where good practices, controls, certifications and regulations still need to be defined. For instance trading the associated assets (located on different blockchains) usually takes place on centralized market places, called exchanges, which become trusted third parties. This exposes users to loss of their funds, through hacks of those platforms or straight-up scams when owners disappear with the funds. It emphasizes a common wisdom in this ecosystem: Not your keys, Not your funds. If we do not control the private key of the account with the assets, we do not actually own the funds.

Atomic cross-chain swaps solve this problem for exchanges of assets without intermediaries. Those swaps are atomic in the sense that either both parties receive the other crypto-assets, or they both keep their own. They are used in two ways. First, as explained earlier, they can serve as a basis for non custodial exchanges. Using these decentralized marketplaces, users keep control of their funds while being able to trade them.

Second, they enable Layer 2 scaling solutions, like [8, 20], to become a network of payment channels and not just P2P channels, thus increasing the scalability of blockchains. The principle of layered scalability for blockchains is to conduct some transactions off the blockchain (off-chain or Layer 2) and notarize the state on the Layer 1 (on-chain), the blockchain, when necessary. The payment channel works like a tab between two users, with many transactions happening off-chain and only two transactions happening on-chain, one to open the channel and another one to close it. The limitation is obviously that Alice has to open a channel first with Bob before they can exchange. Atomic swaps come into play for cross-channels payments. If Alice has a payment channel with Bob and Bob has one with Charlie, Alice can atomically send a payment to Charlie with a swap between the two channels, provided there are enough funds in both channels.

The first proposal for atomic cross-chain swaps came from an online forum, bitcointalk [22]. It was between Bitcoin [18] and forks of Bitcoin, called altcoins for alternative coins. It made use of the scripting capabilities of those protocols, particularly conditional release of the coins, hashed locked and time locked transactions. This restricts the use cases to blockchains with scripting or smart contract capabilities. There are various types of cryptocurrencies with different goals and features and not all of them support Hash Time Lock Contracts (HTLC for short). In this work, we propose an extension of atomic cross-chain swaps to blockchains that do not have such capabilities with the same assumptions as HTLC atomic swaps. We construct our protocol for a blockchain with smart contracts and one that only supports multi-signatures (multisig) transactions. Those transactions are controlled by multiple private keys and require, to be valid, a certain number of signatures. Each signature is generated by a different private key and all those signatures need to be explicitly attached to the transaction. Using multisig transactions, we provide greater capabilities for cross-chain communications without adding any extra trust hypothesis.

The rest of this paper is organized as follows: the properties of atomic cross-chain swaps and their construction using HTLCs are recalled in Sect. 2. We show how to extend them to blockchains with multisig in Sect. 3, then discuss the relative advantages and drawbacks of our proposal in Sect. 4. A comparison to related works is proposed in Sect. 5 before concluding.

2 Hash Time Locked Contracts

2.1 Properties

Atomic swaps have two properties:

  1. 1.

    If all parties behave, i.e follow the protocol, all swaps happen.

  2. 2.

    If any party misbehaves, everyone is refunded.

This gives the users the guarantee they will not lose their assets by participating in an exchange. As stated earlier, the first proposal for blockchains came from bitcointalk [22]. We note that most blockchains rely on digital signatures to track the ownership of the coins. Thus, the proposed protocols, so far, make use of some scripting or smart contracts capabilities.

  • Hash lock: to release the funds in the contract, one needs to provide the secret preimage s that gives H(s), the lock in the contract,

  • Time lock: if nothing happens before some time t on a chain, refund the user on that chain.

Those swaps are currently possible between Bitcoin and altcoins such as Litecoin [17] and on smart contract platforms like Ethereum [5] or EOS [15].

2.2 HTLC Based Atomic Swaps

We now present the atomic swap based on HTLCs. Let Alice be a user of the blockchain \(\mathcal {A}\) that wants to exchange X coins with Bob a user of \(\mathcal {B}\) for Y coins. We suppose that there is a common cryptographic hash function Hash available on both blockchains. We also suppose that Alice and Bob agree on the timelocks T for Bob and 2T for Alice that are function of the blockchains involved. Specifically those timelocks are function of the Block times and confirmation times. We omit the digital signatures in the description for clarity and brevity.

Setup

  1. 1.

    Alice generates a secret preimage s and computes \(h=Hash(s)\).

  2. 2.

    She also generates a HTLC on \(\mathcal {A}\) with the hash lock h and the time lock 2T.

  3. 3.

    Alice sends h and the HTLC address to Bob.

  4. 4.

    Bob can verify that the HTLC on \(\mathcal {A}\) is properly constructed.

  5. 5.

    If it is valid, then Bob can generate a HTLC on \(\mathcal {B}\) with the same hash lock h but the time lock T.

  6. 6.

    Alice can verify that the HTLC on \(\mathcal {B}\) is properly constructed.

  7. 7.

    If it is valid, then Alice funds the HTLC on \(\mathcal {A}\) and Bob does the same on \(\mathcal {B}\).

We stress that the time locks are different on \(\mathcal {A}\) and B and that Bob does not know s at this point.

Swap. The swap works as follows:

  1. 1.

    Alice presents the secret preimage s to the HTLC in \(\mathcal {B}\) and receives the Y coins. She does so sufficiently early, with respect to T and the block time and confirmation time of \(\mathcal {B}\).

  2. 2.

    Bob, who was monitoring the HTLC on \(\mathcal {B}\) learns s.

  3. 3.

    Bob can then present s to the HTLC on \(\mathcal {A}\) and receives the X coins. He does so sufficiently early, with respect to 2T and the block time and confirmation time of \(\mathcal {A}\).

Refunds. Each user can refund herself by waiting for her time lock to expire and call the relevant HTLC. Obviously this is only possible if the funds have not been spent, in which case the other user is able to spend hers also.

Discussions. Alice has the advantage of being able to initiate the swap. This means that she can wait as long as possible to see if the trade gets more or less interesting with prices fluctuations. She can also propose a swap just to lock Bob’s funds. We do not address these issues in this paper.

3 Extending Atomic Cross-Chain Swaps

The previous protocol is designed for blockchains that support Hashed Timelock Contract. But scripting or smart contract capabilities are not supported by all blockchains, including commonly used ones such as Steem [16]. We propose a protocol to conduct an atomic swap between a blockchain that supports scripting or smart contracts and one that supports multisig instead of HTLCs. Figure 1 presents a high level overview of the actors of the protocol. The basic idea is to transfer all the time locking part on the first blockchain, since the second does not support it. For example Steem supports multisig accounts and uses ECDSA signatures [13]. On Ethereum, the smart contract [19] can be used as an implementation basis. We leave the implementation of the full protocol for future work.

Fig. 1.
figure 1

Atomic Cross-Chain Swaps using multisig and smart contract

Full size image

3.1 Assumptions

Our protocol enables two users, Alice and Bob, of different blockchains to securely swap their coins. As such we rely on the security model of those blockchains. We assume that each of them has a majority \(({>}2/3)\) of consensus participants, miners for Proof-of-Work and validators for Proof-of-Stake, that are honest [4, 6, 9, 10, 14, 18].

We also assume that Alice and Bob have a secure communication channel to do price discovery and exchange the swap details. We suppose that they agree on the timelocks T for Bob and 2T for Alice that are function of the blockchains involved (see Discussion Sect. 4).

We further assume that one blockchain supports multi-signature(multisig) transactions and that the second blockchain supports smart contracts and can verify the signature of a transaction issued in the first blockchain.

3.2 Notations

Let \(\mathcal {A}\) be the blockchain with only multisig and \(\mathcal {B}\) be the smart chain. Let \(\textsf {sk}\mathcal {A}\) be the private key for the signature scheme on a blockchain \(\mathcal {A}\) and \(\textsf {pk}\mathcal {A}\) the corresponding public key. We note \(\textsf {sk}\mathcal {A}_{A}\) and \(\textsf {pk}\mathcal {A}_{A}\) if these are Alice’s private and public keys and \(\textsf {sk}\mathcal {A}_{B}\) and \(\textsf {pk}\mathcal {A}_{B}\) for Bob’s. We call \(\mathrm {SC}\) the smart contract for the atomic swap on \(\mathcal {B}\). We call \(\mathrm {M}\) the multisig account on \(\mathcal {A}\) that helps make the atomic swap. This can be understood as a shared account between Alice and Bob and we note \(\mathrm {M}=(\textsf {pk}\mathcal {A}_{A},\textsf {pk}\mathcal {A}_{B})\) to express that this account requires both signatures, meaning Alice and Bob need to cooperate to transact on the behalf of \(\mathrm {M}\).

Let the refund operations be \(\mathrm {R}(\mathcal {A},\textsf {pk}\mathcal {A}_{A})\) and \(\mathrm {R}(\mathcal {B},\textsf {pk}\mathcal {B}_{B})\), which means that Alice (resp. Bob) makes a transaction so that the public key \(\textsf {pk}\mathcal {A}_{A}\) (resp. \(\textsf {pk}\mathcal {B}_{B}\)) has sole control of the funds on the chain \(\mathcal {A}\) (resp. \(\mathcal {B}\)) and Alice (resp. Bob) is thus refunded. Let the swap operations be \(\mathrm {S}(\mathcal {B},\textsf {pk}\mathcal {B}_{A})\) and \(\mathrm {S}(\mathcal {A},\textsf {pk}\mathcal {A}_{B})\), which means that Alice (resp. Bob) makes a transaction so that the public key \(\textsf {pk}\mathcal {B}_{A}\) (resp. \(\textsf {pk}\mathcal {A}_{B}\)) has sole control of the funds on the chain \(\mathcal {B}\) (resp. \(\mathcal {A}\)) and Alice (resp. Bob) has completed the swap.

3.3 Setup, Transactions and Operations

Setup

  1. 1.

    Alice generates \(\textsf {sk}\mathcal {A}_{A}\), \(\textsf {pk}\mathcal {A}_{A}\), \(\textsf {sk}\mathcal {B}_{A}\), \(\textsf {pk}\mathcal {B}_{A}\) and sends \(\textsf {pk}\mathcal {A}_{A}\) and \(\textsf {pk}\mathcal {B}_{A}\) to Bob.

  2. 2.

    Bob generates \(\textsf {sk}\mathcal {A}_{B}\), \(\textsf {pk}\mathcal {A}_{B}\), \(\textsf {sk}\mathcal {B}_{B}\), \(\textsf {pk}\mathcal {B}_{B}\) and sends \(\textsf {pk}\mathcal {A}_{B}\) and \(\textsf {pk}\mathcal {B}_{B}\) to Alice.

  3. 3.

    Alice creates \(\mathrm {M}=(\textsf {pk}\mathcal {A}_{A},\textsf {pk}\mathcal {A}_{B})\) on \(\mathcal {A}\) and sends its address to Bob for verification. She also creates and sends \(tx_1= \mathrm {R}(\mathcal {A},\textsf {pk}\mathcal {A}_{A})\) and \(tx_2 = \mathrm {S}(\mathcal {A},\textsf {pk}\mathcal {A}_{B})\).

  4. 4.

    After verification, Bob computes \((\sigma _1,tx_1)\), where \(\sigma _1 = Sign_{\textsf {sk}\mathcal {A}_{B}}(tx_1)\). He can then create \(\mathrm {SC}\), fund this contract and send its address and \((\sigma _1,tx_1)\).

  5. 5.

    Alice verifies that everything is in order and funds the account \(\mathrm {M}\).

The Smart Contract \(\mathrm {SC}\). It consists of four procedures SC1, SC2, SC3 and SC4 respectively presented in Algorithm 1.

figure a

Operations. The list of possible operations is summarized in Table 1. We use OPX if the operation X succeeds and will mention explicit failure if it does not.

Table 1. List of operations.
Full size table

3.4 Protocol Flow and Guarantees

The protocol flow is described in Fig. 2. It starts with OP3, an off-chain communication (black arrow). Alice then calls \(\mathrm {SC}3\) (blue arrow) while Bob learns \(\sigma '_2\) (dashed blue arrow). The following action (*) can happen before or after \(t=T\) and Bob then controls the X coins (dashed purple arrow). The final step is OP6, where Alice waits for \(t \ge 2T\) and calls \(\mathrm {SC}4\) (blue arrow) to receive the Y coins (dashed blue arrow).

Fig. 2.
figure 2

Protocol flow resulting in a swap (Color figure online)

Full size image

The protocol needs to ensure that for every outcome, swap or refund, for one user, there exists a sequence of operations the second user can do or could have done to have the same outcome, complete the swap or get a refund. Additionally, each user should get refunded if the other user aborts the swap or does nothing.

Swaps. Assuming \(\mathrm {S}(\mathcal {A},\textsf {pk}\mathcal {A}_{B})\), i.e Bob received the X coins, we have:

$$\begin{aligned} \mathrm {S}(\mathcal {A},\textsf {pk}\mathcal {A}_{B})&\implies OP5\end{aligned}$$
(1)
$$\begin{aligned} OP5&\implies OP4\end{aligned}$$
(2)
$$\begin{aligned} OP4&\implies unlock == True\end{aligned}$$
(3)
$$\begin{aligned} \text {if } t\ge 2T \text { and } OP6&\implies \mathrm {S}(\mathcal {B},\textsf {pk}\mathcal {B}_{A})\end{aligned}$$
(4)

The step (3) relies on the fact that Bob can only learn \(\sigma '_2\) if Alice creates it, assuming \(\mathcal {A}\) uses a secure signature scheme. The only way for Bob to access the Y coins is to use \(\mathrm {SC}2\) since \(unlock == True\). He thus needs \(\sigma '_1\), which Alice has no reason to provide.

Assuming \(\mathrm {S}(\mathcal {B},\textsf {pk}\mathcal {B}_{A})\), we have:

$$\begin{aligned} \mathrm {S}(\mathcal {B},\textsf {pk}\mathcal {B}_{A})&\implies unlock == True \text { from } \mathrm {SC}4\end{aligned}$$
(5)
$$\begin{aligned} unlock == True&\implies OP4\end{aligned}$$
(6)
$$\begin{aligned} OP4&\implies OP5\end{aligned}$$
(7)
$$\begin{aligned} OP5&\implies \mathrm {S}(\mathcal {A},\textsf {pk}\mathcal {A}_{B})\end{aligned}$$
(8)

Thus Bob can complete the swap. There is however one setting in which his part of the swap can fail: Alice has already taken the funds out of \(\mathrm {M}\), which is described in Fig. 3. This is covered by the refund case.

Refunds. If Alice does no operation, Bob has to wait for \(t\ge T\) to be refunded using OP2.

Alice, on the other end, can be refunded any time by using OP1. The problem is that Alice can refund herself and then try to get the funds on \(\mathcal {B}\) using OP2 after OP1 while \(t\le T\), as described in Fig. 3. This means that:

$$\begin{aligned} \text {Since } unlock == True \implies OP2 \text { will fail when calling } \mathrm {SC}1 \end{aligned}$$
(9)

But Alice does not have yet the funds from \(\mathcal {B}\) and \(T< t < 2T\).

$$\begin{aligned} \text {if }T< t < 2T \text { and } OP7 \implies \mathrm {R}(\mathcal {B},\textsf {pk}\mathcal {B}_{B})\end{aligned}$$
(10)
Fig. 3.
figure 3

Alice attack scenario

Full size image

4 Discussion

Cross-chain exchanges inherit the adversarial environment of each blockchain. This introduces multiple points of failure that we need to take into account to make the swaps atomic.

For example, Alice or Bob may have the means to launch an Eclipse attack [11]. One user would then have control over the other’s network connections and decide which transactions reach the rest of the network. One user can also just have a better connectivity than the other and be sure his or her transactions would go through first, in the case of a race. We can not solve such problems in the protocol without further assumptions thus we rely on the time locks the users set. They represent the intervals of time necessary for the users, in comparison to the block times, the confirmation times, to create, broadcast the relevant transactions and have them confirmed. In practice, they should also consider what is the current state of both blockchains as to not use them when they are more vulnerable. This could be the case if the mining hashing rate in Proof-of-Work, or the price of the coin in Proof-of-Stake crashes dramatically.

Another question is the pre-generation of the transactions that are in the smart contract C. This is relevant for security. It is better to require the signature of a particular message under a private key than any message under that key. This is also relevant for the fees of the transactions. Some blockchains do not take fees (Steem) or have very low fees (Litecoin) while other have a volatile fee market (Bitcoin, Ethereum). Alice can take care of this on \(\mathcal {A}\) while Bob pays on \(\mathcal {B}\). Still, if the fees were too low at creation, there is the risk that the transactions would take too long to appear in the blockchain(s).

5 Related Works

The first atomic swap protocol emerged on a Bitcoin online forum and is based on HTLCs [22]. It has since been standardized on Bitcoin development resources [1, 2]. This protocol is briefly presented in Sect. 2.

To our knowledge, Herlihy [12] presented the first formal study of the underlying theory of atomic cross-chain swaps. It focuses on a swap of on-chain and off-chain assets between three parties. Using graph theory and the HTLCs, they explore the time locks constraints for the atomicity in that particular setting.

Many protocols focus on cross-chain communications and exchanges. Interledger [21] uses Hashed-Timelock Agreements (HTLAs) [7], which generalized the idea of HTLCs for payments systems with or without a private or public ledger. Those agreements are used to create secure multi-hop payments using conditional transfers. The parties involved decide where their trust lies, for example a HTLC between blockchains or a legal contract.

Cosmos [3, 4], Polkadot [23] and earlier versions of Interledger [21] rely on a set of validators to ensure cross-chain communication. Each round, a subset of those validators decides which cross-chain information to notarize on their chain, provided only a small protocol-defined portion of those validators is Byzantine. The problem is to guarantee that those systems are decentralized enough to be consider censorship resistant and secure while remaining scalable.

XClaim [24] is a framework for achieving trustless cross-chain exchanges using cryptocurrency-backed assets based on a smart contract blockchain and an existing link between the other blockchains like a relay. It requires vault providers to guarantee the liquidity and ownership on the original chain and to have collateral on the smart contract blockchain. Bad behaviour is discouraged using slashing or proof-of-punishment on the smart contract chain. With these assumptions, XClaim builds a trustless and non interactive protocol for issuance, redemption and swapping of tokenized assets.

Our construction does not require collateral (because there is no vault to provide) or an existing link between the blockchains. We argue that our protocol uses simpler assumptions to enable trustless exchange between users, in the same manner as HTLC based atomic cross-chain swaps.

6 Conclusion

In this work, we propose a new protocol for atomic cross-chain swaps. We extend the support of atomic swaps to blockchains without hash lock and time lock capabilities without additional trust requirements. Users can now trade in a P2P way between blockchains with smart contracts and blockchain with only mutli-signatures transactions. We leave the full implementation and live experimentation of this protocol for future work.