What is An XRP, NFT, or Even XLS & How Do They Differ From One Another?

XRP is the native token on the XRP Ledger (XRPL). It is a fungible token, in that every individual XRP is identical. If I send 1 XRP to David Schwartz there is no way for him to differentiate that 1 XRP from the many others he holds in his wallet. In fact, the power of the XRPL is that it can be used to issue many different fungible tokens both cheaply and easily.

NFT stands for non-fungible token. What makes a token non-fungible is its individuality. However, the XRPL was not designed with NFTs in mind. This especially gets confusing when an XRPL NFT project issues a fungible token on the blockchain. Take XPUNK for example. They have issued 5,000 fungible $XPUNKs on the XRPL. Each of these is identical to the other and can be divided precisely up to 15 decimal places: 0.000000000000001

Unfortunately, such a tiny fraction of $XPUNK does not entitle you to a full XPUNK NFT in the future (you need to hold at least 0.5 $XPUNK). Now, you may be wondering, how will they issue and link their XPUNKs to an NFT on the XRPL? This is when the XLS comes into play. More specifically, the XLS-14d and XLS-20d.

XLS refers to ‘XRP ledger standards’. These are proposals about the XRPL put forward by various parties to be discussed, debated, and possibly implemented. There are many proposed ledger standards and as such, to keep track of them, there is a numbering system that starts sequentially from 1; XLS-1, XLS-2, XLS-3 … XLS-20, etc. The ‘d’ in XLS-14d and XLS-20d represents a protocol that has not yet been adopted.

*If you are interested in these protocols, you can review all the proposed XRP ledger standards over on Github.

How does the XLS-14d protocol work?

The XLS-14d was a proposed protocol (now labeled DEPRECATED) by XUMM founder and XRPL developer @WietseWind. The goal of this protocol was to enable the issuance of a token on the XRPL which had the properties of an NFT. Wietse proposed the concept of issuing a small amount of a fungible token, as this would yield a token that was indivisible, unique, and therefore had non-fungible properties. The fraction is as follows:

0.000000000000000000000000000000000000000000000000000000000000000000000000000000001

Although implementing this protocol worked, there were some consequences. As I mentioned before, the XRPL can divide issued tokens precisely up to 15 decimal places (I’ll save you the counting as there are more than 15 decimal places in the number above). Since the basic infrastructure of the XRPL was not designed to work with such small fractions of a token, one of the main consequences was that the XLS-14d tokens ended up being mishandled by the Decentralized Exchange (DEX) built into the XRPL due to rounding errors of the system. This is in part why @WietseWind has backed away from his protocol. It is also why it is destined to stay a ‘d’ (unadopted) protocol forever. 

The problem with unadopted protocols like the XLS-14d is that they will likely never be universally standardized. In other words, I could issue an XLS-14d ‘NFT’ linked to a SuperEagle, XPUNK, or Happy Cat but due to the lack of standardization, the style of metadata generated during the issuance would not be recognized by other users on the blockchain. The lack of such standards makes the semantics very difficult to interpret outside the confines of the issued NFT’s metadata and is therefore not scalable to the desired extent. Despite these drawbacks, some basic functions like sending and receiving XLS-14d tokens, are still available and in fact, will not compromise your XRP wallet when used. 

Why do we need the XLS-20d protocol?

The XLS-20d is another unadopted protocol proposed by cryptographer @nbougalis to implement NFTs on the XRPL. The main difference between the XLS-14d and the XLS-20d is that the latter introduces a new proposition in which, rather than issuing a tiny fraction of an XRPL token, a separate type of token is created altogether called ‘NFToken’.  

However, this new type of token also requires changes in supporting systems. For instance, you will be able to make offers to buy NFTokens and they will each have their own dedicated NFToken page where they will be stored. The downside of this new system is that it requires changes to the underlying code of the XRPL and therefore, the protocol needs to be voted upon by validators. This is primarily because we do not know for sure how it will affect the overall stability of the XRPL.

If the new proposal is passed, it will allow developers to access essential NFT functionalities such as:

• Minting, Trading, and Burning of Tokens
• Setting automatic royalties 
• Co-ownership

The XLS-20d protocol is now undergoing various tests and is publicly available to try out on the XRPL testnet. If all goes well, we will see it on the mainnet soon and the XLS-20d will hopefully become the fully adopted XLS-20.

Looking at the above, the future for XRPL and its users seems exciting and promising. Incorporating the XLS-20d protocol into the XRPL mainnet will generate abundant opportunities for those involved. More importantly, it will help create and develop a tight-knit relationship between artists, creators, developers, and investors who want what’s best for the community.

Is XLS-14d dangerous to the XRPL? No. Is it the future? Definitely not. Is XLS-20 the future? Maybe, just maybe.