LNURL, Not PayString
The Travel Rule Protocol (TRP) working group, of which we are a leading contributor, designed an elegant solution for the address- and VASP- discovery problem, an important challenge in any Travel Rule solution. In short, the problem can be summarized to the question: How can an originating VASP discover to what address and what beneficiary VASP it needs to send coins? TRP solved this with the Travel Address, which is based on LNURL. Often there are questions about why LNURL was chosen as the solution and not one of the alternatives such as PayNym, BIP75, OpenAlias or PayString. Why indeed an existing standard at all?
The goal of the TRP working group is to provide a minimal, pragmatic solution for the FATF Travel Rule guidance. Off the shelf standards like InterVASP IVMS 101 fit the requirement. In a similar vein, the group set out to find an existing standard fitting the requirements instead of re-inventing the wheel.
Of all the existing alternatives, PayString and LNURL were close contenders. Both have existed for some time, and both do what we need them to do; they facilitate the exchange of a piece of text for a cryptocurrency address and a beneficiary VASP.
A PayString looks like this:
While a LNURL looks like this:
Both are very different from the looks of it, but the similarities are significant. A PayString looks like an URL and can be transformed into one. The LNURL does not look like an URL but can be transformed into one nonetheless. A LNURL is merely a bech32 encoded URL!
ADVANTAGES OF LNURL OVER PAYSTRING
While the human-readable format of PayString might seem like an advantage, it is not. Having a human-readable format lends itself to reuse, which is not always desirable. A beneficiary VASP might want to restrict the validity of a URL to one time due to their risk assessments. A human-readable format also opens up the possibility of nefarious substitutions like this one: bȯb$digitalwallet.com. Note the tiny dot on the letter ‘o’! This is a common attack when using URLs on the web, and although we think it is harder to pull off in this use case, we felt that the upside of a human-readable format did not outweigh the potential security risk.
INTERACTIVITY AND FALLBACKS
The conversion of a PayString into an URL involves an interactive protocol between the originator VASP and the beneficiary VASP. While simple and supporting a fallback mechanism in case the interactive protocol is unavailable or fails, it is undeniably an additional complexity. With LNURL, the originator simply decodes the LNURL from which it will arrive immediately on the final URL. No interactivity is required, nor secondary fallbacks.
Finally, the LNURL standard is widely used in the Lightning Network, Bitcoin’s layer 2 network. This ensures ongoing development of the standard, and security issues are monitored by many. PayString, on the other hand, seems to enjoy little popularity outside the Ripple network, thus lacking the features LNURL enjoys.
Hence, LNURL was the chosen technology to facilitate Travel Rule information transactions. That is not to say that individual VASP can't agree on something else. TRP facilitates this with its flexible extensions mechanism, which you can read more about here.