Travelling at Lightning Speed

Complying with the Financial Action Task Force’s (FATF’s)  Travel Rule (also known as Recommendation 16) creates a multitude of challenges for virtual asset service providers (VASPs), which readers of this blog will be intimately familiar with. 

In this article, we want to highlight two ways in which those challenges are, somewhat surprisingly, considerably less of a concern for payments on the Lightning Network (or similar layer 2 networks, although we will focus on Lightning here). 

Currently, this will most likely be of theoretical interest only, as most parties will only be interested in a solution which works across all assets, including base-layer ones.

Pull and Push Payments

Base-layer payments and transactions on the Lightning Network differ in many characteristics, such as latency or fee levels. The most fundamental, though, is that payments on the Lightning Network follow a pull pattern instead of a push pattern: Receivers generate an invoice submitted out-of-band to the sender, who then initiates the payment. The invoice is linked to a specific amount and expires after a timeout.

For layer 2 payments, it is thus possible to avoid unwanted incoming payments, something which is fundamentally impossible on the base layer once a recipient address is known. This is of interest because the FATF Travel Rule implies some requirements on the conditions under which incoming payments should be accepted. For example, it is much easier for a VASP to avoid incoming payments from unverified self-hosted wallets (unhosted wallets) or from other VASPs if Travel Rule information cannot be exchanged.

Attaching Data to Payments

Lightning payments can contain a data payload that is attached to the payment. This becomes possible because the payment is only transmitted across a route through the network but never published to the base ledger for eternity. 

Thus, even full chat clients have been implemented on the Lightning Network, where chat messages are transmitted as payloads on vanishingly small payments. 

This transmission mode closely resembles the initial intention of the Travel Rule, where the associated information "travels" together with the payment, something which has quickly turned out to be infeasible and undesirable on base layer networks. 

This is of more than symbolic significance, as the simultaneous mode avoids a host of problems frequently encountered in the context of the Travel Rule, such as correlating Travel Rule payloads with payments, or gaining assurance of reception.

Future Directions

As alluded to in the beginning, few parties nowadays will want to constrain their solution in a way that works only for layer two assets. However, two current trends may alleviate this shortcoming in the future: 

First, layer two networks are constantly gaining relative popularity as base layer fee levels rise. 

Secondly, and somewhat more strikingly, a few different schemes have been proposed where assets other than Lighting-Bitcoin can be exchanged on the Lightning Network (for example, Taro or RGB). This development would make the above improvements open for other assets as well.