Blockchain Interoperability Series: Atomic Swaps

Introduction

Thank you for joining us for the second post in our Blockchain Interoperability & Cross-Chain Communication Series. Today, we’ll dive into the first of the five primary cross-chain communication mechanisms, atomic swaps.

If you happened to miss the first post in the series, be sure to check it out.

What Are Atomic Swaps?

In 2013, TierNolan devised the atomic swap, where Hashed TimeLock Contracts (HTLCs) on two chains could allow users to trade one digital asset for another directly in a peer-to-peer transaction.

For the majority of cryptocurrency holders today, accomplishing this is done in one of three problematic ways:

• Using a centralized exchange to first sell into fiat and then buy using the proceeds
• Trading on an exchange that supports your desired trading pair
• Trusting an individual enough to send them your crypto, with faith that they will send you the agreed-upon new currency.

Atomic swaps promised to reduce unnecessary fees, eliminate the need for a trusted third party, and minimize the volatility risk associated with using an intermediate currency. So, it’s no surprise that they’ve seen a rise in chatter over the past few years.

How Atomic Swaps Work

Unfortunately, atomic swaps are not as simple, efficient, or secure as they first appear. When used alone, atomic swaps are incredibly slow and expose both parties significant risk. Even in the best-case scenario, both parties are required to take several actions and stay online for hours.

It’s important to note that the actions necessary to complete an atomic swap are both synchronous and unenforceable. If at any time one of the parties goes offline or fails to complete a step, the swap will be delayed, the users will be exposed to risk, or the swap will fail.

Let’s dive into the steps involved in an atomic swap:

Step 1: Finding a Counterparty and Negotiating Terms

To set-up an atomic swap, a user must first find a willing counterparty, negotiate terms, and exchange information. This process includes determining the exchange rate, the size of the trade, and the duration of the HTLCs (generally based on the number of confirmations on each chain needed to provide sufficient economic security and account for delays). Once both parties have agreed on terms, pubkeys are exchanged.

I can’t emphasize enough how cumbersome and time consuming this step is.

Steps 2 & 3: Users Submit Collateral

Once terms are negotiated, one of the users (User 1) must be the first to time-lock their funds into an HTLC as collateral. These funds remain locked and illiquid until either the swap is completed or the HTLC expires.

Under ideal conditions, User 2 would then wait one confirmation cycle (~1 hour for BTC & ETH, but theoretically up to days on an inefficient chain like Vertcoin or Verge) to gain sufficient confidence that User 1 has indeed collateralized and then immediately time-lock their funds into the corresponding HTLC on the other chain — completing their side of the collateral.

User 1 would similarly wait for at least one confirmation cycle (a minimum of another hour) to gain confidence that User 2 is collateralized before proceeding.

Steps 4 & 5: Swapping Funds

After sufficient confidence that User 2 is collateralized, User 1 may (and should immediately) withdraw User 2’s collateral, thus completing their side of the swap. Only once they have done so, may User 2 similarly withdraw User 1’s collateral. After withdrawal, both users must again wait for at least one confirmation cycle on each chain to confirm that the withdrawal was not reorged out.

As you can see, even under ideal conditions (both with the individuals involved and with the chain) both parties must take several steps and remain illiquid for hours before an atomic swap can be considered complete.

Limitations & Tradeoffs

The main limitations of atomic swaps, as you may have guessed, are related to time and counterparty trust. Additionally, there are a few major manipulation tactics and vulnerabilities that are worth discussing. These arise primarily from the fact that the actions required to complete an atomic swap are both unenforceable and synchronous.

Let’s take a look at what can happen when you’re in an atomic swap with a bad-actor:

The Free Option Problem

The free option problem allows User 1 to delay or back out of an atomic swap after both users have collateralized, based on whether the exchange rate has moved for or against their favor since the time that the terms were set.

Because atomic swaps are synchronous, User 1 must be the first to withdraw funds and complete their side of the swap (Step 4) before User 2 is allowed to do the same. This stepwise process gives User 1 the unique ability to delay the swap while monitoring the prevailing exchange rate. If the rate has moved in their favor since the time that the terms were set (prevailing rate is now worse than the agreed-upon rate), then we should expect them to complete the swap. Conversely, if it has moved against them, it is in their best interest to let the swap expire, take their refund, and begin the process again.

As there are no ramifications for doing so, we should expect User 1 to delay the swap as long as possible (up until the expiration of the HTLCs) and only complete it if the market moves in their favor.

The Liquidity DoS (Liquidity Trolling)

The liquidity DoS (or liquidity troll), on the other hand, gives the unfair advantage to User 2. After the terms are agreed upon, and User 1 collateralizes, User 2 is free to back out of the trade. This right exposes User 1 to liquidity risk, locking up their funds for the duration of the HTLC (hours or days depending on the chains involved in the swap).

While highly unlikely, at scale, this could be used to manipulate the market by significantly lowering the short-term liquidity of an entire chain.

The Sleeping Vulnerability

Since atomic swaps are synchronous, both parties must remain online for the duration of the trade. The final vulnerability allows User 1 to steal User 2’s funds if they go offline for long enough after collateralizing.

Once User 2 has collateralized its funds, User 1 is free to withdraw them. If User 2 goes offline for long enough, User 1 can wait for the HTLC on their collateral to expire and withdraw those funds as well. There are no ramifications for User 1 and no recourse for User 2 if this occurs.

Applications of Atomic Swaps

As you can see, when used alone, atomic swaps are long, labor-intensive, and require a great deal of counterparty trust. It should also be clear that atomic swaps are not a true form of cross-chain communication, but rather a coordination mechanism between two parties.

But there’s still hope. We’ve included atomic swaps as a form of cross-chain communication due to the immense value they can bring both on Layer 2, and when used in conjunction with other cross-chain communication mechanisms (discussed at length later in the series.)

Atomic Constructions on Layer 2

The most prominent example of atomic constructions on Layer 2 is undoubtedly the Lightning Network. The lightning network is a second layer technology for Bitcoin, built to enable off-chain payment channels; increasing transaction speed and throughput.

When a payment is sent, the lightning network first determines the ideal route of payment channels in the mesh network and then passes the payment atomically through all parties in the route.

Arwen is another noteworthy company using layer 2 atomic constructions. They work to minimize counterparty risk by allowing individuals to swap cryptocurrencies with centralized exchanges without ever moving funds into an exchange wallet.

These are just two of many great applications for atomic constructions on Layer 2.

Conclusion

Atomic swaps are a coordination mechanism that allows parties to trade digital assets between chains without trusted third parties. While they have limitations and vulnerabilities associated with them, when used properly, they can be a valuable tool. Later in this series, we’ll look at the ways that atomic swaps can be combined with other mechanisms to overcome many of these limitations.

Stay tuned for our next post in the series, where we’ll discuss the Stateless SPV.

Summa is a provider of cross-chain architecture and interoperability as a service solutions. We have provided cross-chain development for Ethereum (EIP-152), Keep, The Electric Coin Company (ZIP-221), and the Zcash Foundation. Our investors include Polychain Capital, INBlockchain, and Kilowatt Capital.

Stay up to date with Summa on Twitter