huub

Intern at XRPL Labs researching NFT's on XRP Ledger

The past few weeks have been filled with searching for art dealers. There are now 3 art dealers that want to collaborate on my project to put certificates of existing art on the XRPL as an NFT. I had some fun meetings and learned a lot about art and the purchase and selling of exclusive pieces.

Also, there has been a lot of trying out ways to create NFTs on the XRPL. I recently created my first NFT on the XRPL.

The NFT in my first blog was just an NFT currency code. Richard from XRPL Labs found a way to add all the metadata that is needed for an NFT.

This is done by creating a transaction of 1 drop from the issuing address to the hot wallet address with the Memo fields containing all the data you want to add to your NFT, such as a description, URI (for example an IPFS URI containing an image) and a back-up URI. But everyone can adjust it to their own needs if wanted. This transaction's txn hash, txn_index, ledger_hash, and ledger_index can be converted to what Richard calls a Concise Transaction Indicator or short CTI. This is a unique identifier, a detailed explanation can be found in his proposal XLS-15d. The CTI combined with a prefix indicating an NFT and a 12 character name will be the currency code for the token.

This way you can add all the data you need for the NFT still on the XRPL.

I wrote a proposal myself combining the two previous proposals, which can be found here: XLS-16d

Before creating the first NFTs I had set up my own IPFS node on a VPS to make storage easier.

I will show the 2 NFTs I have created and how.

The first one I created is an image of the main character from a serious game some students and I created for a school project. It's called Plasticats. Its purpose was to make children aware of plastic soup in the ocean. A demo can be found on my website.

After uploading the selected image to the IPFS node, an XRPL transaction from the issuing address to the hot wallet containing the IPFS URI in the memo's field had to be sent. We have to make sure the NFT is valid later on so it's important to send it from the same address that issues the NFT.

The memo fields are converted to hex which is the format the XRPL uses for its data. The human-readable output would look like this.

However, this is not the complete format we will be using in future NFTs but was just for testing purposes.

Using this transaction's CTI which is generated by the transaction's txn hash, txn_index, ledger_hash, and ledger_index, the currency code will be created. How to generate it can be found in Richard's proposal XLS-15d.

The CTI for this transaction would be : 56013670751388626

The currency code for an NFT consist of 3 parts:

  • 02 Prefix that indicates an NFT on the XRPL
  • CTI converted to HEX
  • Short name converted to HEX for the NFT to a maximum of 12 characters or less (filled up with 0's if it's less)

As mentioned before the NFT is about Plasticats so the short name will be Plasticats.

The complete currency for this NFT would be: 02C7002303B3C3D2506C61737469636174730000

As described in my first blog post, a trust line has to be set up between the hot wallet and the issuing wallet.

In total 100 Plasticats NFTs are being created.

After this, the tokens can be sent from the issuer to the hot wallet.

At this link you can view the NFTs on the address, the address selected will show the Plasticats NFT and the first one Richard made. This one is not with IPFS but a very reduced image that is converted to a data URI. That is the first XLS-14 NFT on the XRPL ever.

As mentioned above the next NFTs will be somewhat different since we want to have more metadata in the NFT than just the URI.

In my proposal I explain a bit about the memo's and how the metadata could be stored in them:

The Memos Field in an XRPL transaction is presented as an array of objects which contains one memo field per object. This field consists of the following fields:

  • MemoData
  • MemoFormat
  • MemoType

The MemoData field can be used for the metadata itself and the MemoFormat indicates the nature of the given data inside the MemoData field (MIME type). To create a certain hierarchy for covering failure of the URI specified, the MemoType field contains the numbering of the data named as shown below followed by the MIME type:

  • NFT/0 – Description – text/plain

  • NFT/1 – Author – text/plain

  • NFT/2 – Primary URI – text/uri

  • NFT/3 – Back-up URI – text/uri

  • NFT/4 – Reduced image Data URI as last back-up – text/uri

The usage of a back-up URI and Data URI can be seen as optional and can be replaced with other kinds of data that have the preference of the issuer of the NFT for example contact information.

The limit of storage is 1kb of data in the memo's field in total. Multiple memos can be used to give as much information as fits to the 1kb of data.”

Here is the example from the NFT mentioned in the proposal.

In the coming weeks I will be starting with the creation of a Xapp inside of XUMM to make it easy for art dealers to put certificates of their physical art on the XRPL.

Welcome all to my blog where I will be posting my findings and research about the concept of NFTs on the XRPL. For my thesis I will also research how to apply this to real artworks. Wietse showed me how you can give the tokens (formerly called IOUs) the properties of a NFT.

Tokens can be issued by anyone with access to a account on the ledger. The cost of this (of an XRPL transaction) is 12 drops. In today's use the tokens are used to represent any currency that is owed by the counterparty, for example exchanges to there users and the other way around.

To issue (mint) a token, a trust line has to be created between two accounts. A limit will be set a limit for the amount of tokens to be sent.

The smallest amount of units for an issued token is as little as 80 zero's after the decimal and then a 1.

The scientific notation, as used “under the hood” by the XRPL (when requesting transaction / Trust Line information from a node) is 1000000000000000e-96.

The proposal of XRPL Labs is that numbers smaller than 70 zero's after the decimal will be considered as NFTs. and the last 11 digits will be seen as whole numbers.

For example:

0.0000000000000000000000000000000000000000000000000000000000000000000000 | 00000000001 Would be 1 NFT.

0.0000000000000000000000000000000000000000000000000000000000000000000000 | 00000000010 Would be 10 NFTs.

There are considerably 3 possible ways of creating NFTs on the XRPL:

  • One account can issue (mint) one token, after that the account will be blackholed, which means it would be impossible to create new tokens after.
  • One account can issue (mint) multiple tokens as a batch, after that the account will be blackholed

  • One account continuously issues (mint) new tokens because it can be trusted. (Set a domain and emailhash). Also doesn’t get blackholed.

For a more detailed overview of technical aspects of the methodology check out the proposal from XRPL Labs regarding NFT on the XRP Ledger.

Let's say we go for the last one and see how this works out on the testnet.

We use two accounts for this which the first one is the issuer (minter) and the other one the hot wallet for the NFT to be sent to a buyer.

  • Issuer (minter)rawSnhbdjsxrRqMupArYZAiSwVNyWgtM4M

  • Hot walletr3uZPZJsEjy4CV59EQZZcLzjAwVPc2fLZR

First we set a default flag which enables rippling. That is because we want the token to be moved between future recievers of the token with that trust line later on.

After that we set a trustline for the token between the two accounts with the smallest amount possible. For now I will call this one “De Nachtwacht”, since I will also be researching the registration of real artworks on the XRPL. The name is converted to hexadecimal code, this is the way the XRPL handles token names.

Next up we will send the token from the issuer to the hot wallet.

Now we have our token in the hot wallet. and can be seen on the balance sheet.

From here we could send it to a buyer. Any new account has to set a trust line with the initial issuer (minter) first.

This is because the XRPL has an 'opt in' (explicit trust) model, where to be able to receive a token, one has to trust the token issuer (minter) first After that the token can be sent to that account.

XUMM support for the the described methodology will be added on version 1.1 late Q1 2021.