Mercury Layer's Lightning Latch Swap Protocol

by

Commerceblock has released a new atomic swap protocol for use with statechains on their Mercury Layer protocol. The HSM server has introduced functionality to support atomically swapping two statechains, as well as enforcing an atomic exchange of a statechain for a Lightning payment. This is the first example of concretely defined and built interactions between statechains and the Lightning Network. Synergy between both protocols has been postulated since the concept of a statechain was originally proposed by Ruben Somsen, specifically as a way to solve the limitation of having to transfer a whole statechain UTXO at once.

Basic Statechain Swaps

In order to support the new swap protocols, the HSM server needs to add some new fields to its database entries tracking each statechain it is facilitating. To facilitate the statechain to statechain swap, the server needs to track:

  • Batch_id: a value to associate statechains being swapped in a group.
  • Batch-time: a time that starts a counter after which the statechains can be “reclaimed” if the swap fails.
  • Locked: a value indicating whether or not the statechain is locked and restricted from regular transfers.

This allows the HSM server to track and enforce all the variables necessary to ensure a safe atomic swap. When initiating a swap, users have to communicate with each other directly in order to establish a shared batch_id between them. From this point they trade all the necessary information required to facilitate a normal statechain transfer, and send that information plus the batch_id and batch-time to the server. They essentially start the regular transfer process, but also attach the variables to connect the individual statechains as participating in a swap together and how long the timeout period is for that.

The server at this point will apply a lock to every statechain using the same batch_id in the transfer process. Until the timeout expires, or all of the statechains in its database using the same batch_id have been unlocked by the current owners, the server will not approve any transfers. A neat thing about the way the HSM enforces the swap logic is that it doesn’t matter who contacts the server first. When the server gets a message using a batch_id, it checks every statechain in its database and if there is a pre-existing batch-time for that batch_id it sets it as the same. This ensures that no matter who registers the swap first they all use the same time value for the timeout function.

Each client involved in the swap at this point checks for and downloads the messages that initiated the transfer protocol, and upon verifying they’re correct sends a message to the server to unlock their statechain, removing the transfer restrictions. Whenever anyone attempts to finalize a transfer on the receiver side of any of the statechains involved in the swap, the server checks to make sure all of the statechains with the same batch_id are unlocked. If even a single one with the related batch_id is still locked the server will finalize a transfer for none of them. If a swap doesn’t succeed before the timeout, the server will continue restricting the finalization of the swap transfer, but will let the current owners initialize a new transfer to themselves to effectively cancel the swap.

Lightning Latch

The Lightning Latch functionality, swapping a statechain for a Lightning payment, works very similarly to the statechain to statechain swap. Here are the new fields the server must track for the Lightning swap:

  • Batch_id: a value to associate statechains being swapped in a group.
  • Batch-time: a time that starts a counter after which the statechains can be “reclaimed” if the swap fails.
  • Pre-image: the preimage of the Lightning payment, which is generated by the HSM server.
  • Locked_1 and locked_2: there are two lock fields for the Lightning swap, one authorized by each user involved.

Just like with the statechain to statechain swap, the users establish and share a random batch_id. The current statechain owner then messages the server with the batch_id and statechain involved and requests it generates a hashlock preimage for a Lightning payment. This user then generates a Lightning invoice using this preimage, and the second user contacts the server to confirm it generated the preimage. The current statechain owner then begins the statechain transfer process and uploads the transfer message to the server.

After confirmation of that, the second user trying to swap for the statechain initiates the Lightning payment. At this time the server is the only one with the preimage, so the statechain owner cannot finalize the payment yet. The current owner after verifying the pending Lighting payment sends the server an unlock message to remove the first lock on the statechain. The receiver finally verifies the transfer message, and if valid messages the server to remove their lock as well.

Now with both locks removed, the HSM server will release the preimage to the current statechain owner to finalize the Lightning payment, and will finalize the statechain transfer to the receiver.

This scheme does require trusting the statechain operator to function honestly, but that is fundamentally not a change to the pre-existing trust model of using a statechain in general. At no time does the operator have control over users’ funds, nor do they learn anything about the Lightning payment details.

What Is This Good For?

This scheme is a far cry from the originally posited interaction between statechains and Lightning channels, stacking one on top of the other, but even as a simple starting point this presents functional utility for existing Lightning users. Rebalancing channels is a necessary thing for many nodes, if the capacity is entirely pushed to one side or the other the utility of that channel is limited for routing payments. Many businesses and users have started experimenting with using Liquid as a mechanism for this due to on-chain fees rising and making swaps into and out of the Lightning Network more expensive.

Statechains offer an alternative mechanism to a federated sidechain to alleviate some of the fee expenses associated with channel balance management. Instead of having to swap out to the mainchain directly, or use a sidechain, funds can be swapped to a statechain and held there until they are needed for swapping funds back into a channel. Similar savings in fees can be had while still maintaining the ability to unilaterally claim your funds on the mainchain.

Another potential use case (TRIGGER WARNING) would be the possibility of more efficient marketplaces for trading ordinals. Since ordinals are simply an index scheme tracking paths backwards in the transaction history to specific satoshis, they can easily be lifted off-chain onto a statechain. That dynamic in combination with Lightning Latch could allow cheaper and faster off-chain purchases of ordinals. Someone could build a marketplace where they can be sold instantly off-chain over the Lightning Network.

It’s even possible one day if Lightning clients could become aware somehow of which statechain operators specific Lightning nodes trust that Latch could be used to help route payments by passing statechains around between different nodes instead of using conventional Lightning channels.

On the front of pure statechain to statechain transfers, this offers the potential for a message passing layer to recreate coinjoin like system mixing coins off-chain, similar to the original mixing functionality in Commerceblock’s first statechain implementation.

While it is a very simple starting point, Lightning Latch and the statechain swap functionality crack open the first door of statechains integrating into the existing Lightning Network – and other similar layers to come in the future – in a way that lets them all integrate seamlessly and function as a singular network in terms of payment routing and liquidity management. Even while we debate the need for and usefulness of covenants, there is still quite a lot of room to continue building with what we already have. 

You can listen to the Commerceblock team explain the logic beyond the protocol here: 

And for a more technical explanation, here: 

Leave a Comment