Atomic Cross-Network Swaps

Trey Griffith
Sep 1, 2018 · 10 min read

The below is a deep dive into the technology powering instant settlement at sparkswap, a new way to trade cryptocurrencies without depositing assets on an exchange. It is a technical article, and it is recommended that readers be familiar with the Lightning Network and Atomic Cross-chain Swaps.

Trustless atomic cross-chain swaps have been hailed as a potential solution to the problem of custodial cryptocurrency exchanges, but have largely failed to deliver in terms of significant user adoption. I would argue that a significant reason for that failure is the unacceptably slow speed of finality for trading of ordinary amounts.

Atomic swaps using Layer 2 solutions like the Lightning Network (and Payment Channel Networks more generally) have the potential to increase the speed of these swaps significantly, but to date have been largely implementation-specific demonstrations.

Cross-Network Preimage Retrieval is a new mechanism for trustless atomic swaps over Payment Channel Networks that increases potential currency support and simplifies implementation while maintaining the atomic and trustless properties of an on-chain swap.

Custodial Exchanges re-introduce risk

Custodial exchanges, as a result, exhibit all of the problems of the traditional financial system, although in some cases exacerbated by the new and mostly unregulated nature of the industry. Billions have been stolen from exchanges over the past few years, assets are frequently frozen by local governments or users simply can’t move currency out due to operational backlogs.

Atomic swaps are too slow for trading

Decred has published an atomic swap contract in Script that is simple and easy to follow, and produced a sample implementation for swapping several currencies (that research was extended to include Ethereum).

However, using atomic swaps via on-chain transactions takes considerable time to remain trustless — in the case of trades using Bitcoin, by far the most liquid cryptocurrency, these swaps take over an hour to finalize. For trading currencies in which prices move in seconds and minutes, such slow finalization would result in one party or the other backing out of the trade for all but the largest of transactions. As a result, they do not lead to a slow settling exchange as might be expected, but rather to no exchange at all.

Some projects are using a combination of 0-confirmation transactions and dedicated arbiter nodes or similar systems to try to increase speed of the swaps, which diminishes the trustless nature of the swap. Others are taking advantage of the latency aspect of on-chain swaps to build them into transactions resembling option contracts — a promising area of research, but one that does not solve the problem of spot trading.

Lightning Network swaps are currently limited

But these Layer 2 swaps have remained largely demonstrations, and have only been demonstrated with two currencies that can support the same Layer 2 network specification, in the case of the Lightning Network, BOLT. While the BOLT specification is by far the most mature of the Payment Channel Networks, it was built for Bitcoin (rightfully so), and may not be able to support as many currencies as users would like to swap. The development of Raiden as a non-BOLT-compatible network is a clear step in that direction.

As a hybrid solution between on-chain and off-chain swaps, Alex Bosworth created Submarine Swaps, which allows users to use on-chain transations to pay Lightning Network invoices. That software has broadened interoperability with other currencies and provided a unique perspective on Lightning Network invoices. However, it is still limited in settlement speed due to on-chain transactions.

Cross-Network Preimage Retrieval

  • Increases the potential reach of swaps to additional blockchains and currencies
  • Simplifies the implementation of swaps
  • Maintains the trustless and atomic properties of swaps

We call this mechanism Cross-Network Preimage Retrieval.

Before I explain the specific construction for this mechanism, I’ll provide a brief background on Payment Channel Network Payments and Swaps, two critical components to understand Cross-Network Preimage Retrieval.

Payment Channel Network Payments

To redeem her payment, the destination node presents the preimage to the penultimate node, transferring the promised currency and finalizing the payment. The penultimate node then uses that preimage to redeem the payment he is due, and so on, triggering an entire settlement chain backward along the route to the origin, leaving the origin node with less currency, the destination node with more, and each intermediate node with no change in balance (except for fees extracted).

Multi-hop payment on the Lightning Network

The contract used to irrevocably promise payment upon receipt of the preimage in the Lightning Network is a Hashed Timelock Contract.

Payment Channel Network Swaps

Cross-chain Atomic Swap on the Lightning Network

As they have been demonstrated to date, Payment Channel Network swaps rely on User B operating his node on both Blockchain 1 and Blockchain 2 so that he can receive a promise for payment (HTLC) on Blockchain 1, and extend a promise for payment on Blockchain 2, and settle backwards across the route in the case of a successful swap.

This setup introduces significant difficulties for User B, namely:

  1. The software he runs must support every blockchain he wishes to trade between (or: that he must have software that supports every pair he wishes to trade)
  2. The payment forwarding mechanism must support swaps natively and have access to (or logic for) the user’s trading preferences

#1 significantly limits compatibility both in theory and in practice, and #2 significantly increases implementation complexity.

Cross-Network Preimage Retrieval Swap

  • A payment channel network node for each different network (two nodes total)
  • A node connecting the payment channel network nodes, which we call the Interchain Router

These components are all controlled and operated by the same user, so the interaction mode between them is semi-trusted.

Swap setup for Cross-Network Preimage Retrieval

Prepare Swap To setup the swap, User A, the initiating party, creates an invoice with a preimage known only to her on her Payment Channel Network node operating on blockchain 2. She sends the hash of this preimage to User B out-of-band.

User B, the translating party, creates a invoice on his Payment Channel Network node operating on blockchain 1 for the hash sent by User A. Since User B does not know the preimage for this invoice, he marks it as an External Preimage invoice, or an invoice for which the preimage is stored externally.

Initiate Swap User A then initiates the swap by extending an irrevocable promise of payment upon receipt of the preimage (HTLC) from her PCN node on blockchain 1 to User B’s PCN node on blockchain 1.

User B’s PCN node on blockchain 1, upon receiving this promise of payment, would normally reject it since it does not have the preimage to redeem it. In our case, User B has created a special External Preimage invoice indicating that the preimage for the payment is available on an external service. User B’s PCN node on blockchain 1 makes a request for the preimage from an external service, which in our case is the Interchain Router.

Translate Swap across blockchains The Interchain Router makes a determination about whether to proceed with the swap based on the price, the counterparty, and size. If the Interchain Router does decided to proceed with the swap, it translates the payment by using User B’s PCN node on blockchain 2 to extend an irrevocable promise of payment upon receipt of the preimage (HTLC) to User A’s PCN node on blockchain 2.

Settle final leg of swap User A’s PCN node on blockchain 2, upon being extended this payment for a preimage which it knows (see step 1), settles the payment, thus revealing the preimage to User B’s PCN node on blockchain 2.

Translate preimage across blockchains User B’s PCN node on blockchain 2 returns the preimage to the Interchain Router (which initiated the payment). Once the Interchain Router has the preimage, it can return the preimage to User B’s PCN node on blockchain 1.

Settle initial leg of swap Now in possession of the preimage for the payment extended to it, User B’s PCN node on blockchain 1 settles the initial payment, triggering settlement back to User B’s PCN node on blockchain 1.

Swap Result The result is User A reducing currency on blockchain 1 in exchange for currency on blockchain 2, and User B the inverse.

In normal operation, this swap would settle in about as much time as it takes to make two payments on the respective Payment Channel Networks, which in the case of the Lightning Network is typically in the hundreds of milliseconds.

Increased Interoperability

In addition to the increased interoperability on paper, Cross-Network Preimage Retrieval increases practical interoperability by removing the requirement for a single client to support two blockchains. For different enough currencies (e.g. Bitcoin and Zcash), even a client that follows the same specification (e.g. BOLT) may be different enough to require (or at least make advisable) a separate client.

Simplified Implementation

In addition, Cross-Network Preimage Retrieval uses, by and large, primitives that should be common to every Payment Channel Network. Specifically it uses:

  • Send payment
  • Settle payment
  • Invoice / preimage creation

In only one area does the Payment Channel Network node have to perform a non-standard action, which is to retrieve a preimage stored on an external service. Given the potential sensitivity of preimages and a desire to separate concerns, even that functionality may end up having utility outside of Cross-Network Swaps.


The swap demonstrated by Lightning Labs only required User A, the Initiating Party to know the identity of User B, the Translating Party. Cross-Network Preimage Retrieval requires that each party knows the other’s identity (on at least one of the Payment Channel Networks) since each party is responsible for constructing one leg of the route. This is, in my view, an acceptable tradeoff given that the identity of your counterparty may be a relevant detail when it comes to making a swap.

Additionally, because this is intended as a cross-network and cross-specification swap, the ability to pass network-specific messages back is limited. This is also likely an acceptable trade-off given that the need to pass such messages back across networks is also limited.

Fast, simple, & interoperable cross-chain swaps

This new mechanism allows swaps between multiple different types of networks built on different underlying blockchains, implemented in different network clients. It is a simpler approach that takes better advantage of the built-in functionality of these networks making it a more robust swap mechanism.

Cross-Network Preimage Retrieval in Practice

Take look at the developer documentation, GitHub repository, or join us on Discord for more details of how we implemented these types of swaps, and to help us make them more reliable.


The Lightning Exchange

Trey Griffith

Written by



The Lightning Exchange