Simple Ledger Protocol (SLP) is one of the best token systems out there for Bitcoin Cash. It's simple, robust, easy-to-use, and works on lite wallets. I say this in a non-humble manner and loudly pat myself on the back because I'm one of the co-creators of the system.

All joking aside, it works pretty well. Give it a try sometime :-)

One of the next missions is to create non-fungible tokens (NFT)! Quick primer: "Fungible" tokens means they are all the same, like a tradeable coin. "Non-fungible" means they are all different, like baseball cards, or cryptokitties.

ERC-20 and ERC-721

Most Bitcoiners are familiar with the Ethereum platform which really popularized the use and issuance of tokens. One of the early promises of Ethereum was that anyone could issue their own smart-contract token. The standard protocol to do this is the famous "ERC-20". Later on came ERC-721 which is used in cryptokitties.

Investigation

I started looking into ERC-721 to see what the format is like, and how we adopt the SLP protocol to do something similar. I was slightly surprised when I did not see any data fields that would store properties of a cryptokitty.

It seems that the metadata for a token is stored off-chain.

Here is a link to the ERC-721 protocol spec. It's hard to glean too much from this as it builds on the Ethereum platform. So unless you've built stuff on Ethereum before you might find it hard to comprehend. At least, I did.

But here's a few articles that talk about how ERC-721 stores metadata (off chain)

Contemplating Storing Metadata On-Chain

My first thought was that storing everything off-chain is lame. SLP should be able to do better. If any chain can do it, BCH can with its low fees, right? But then I tried to conceptualize how we would do that. Each kind of token might want to have different data fields. A cryptokitty token would want to store different properties than a baseball bard token. So the data structures would have to be different. Then I started thinking about how we could implement some kind of universal data structure to accommodate all of these, perhaps with variable length fields. But who would validate all this to make sure token transfers and mutations were accurate? And keep in mind that each kind of token would have to follow the rules of its own ecosystem. You would have to have unique node validators for each kind of NFT token system doing this, and if you're going to do that, it kinda defeats the point of doing everything on chain anyway.

It would still be possible to put more stuff on-chain rather than off-chain, but I decided maybe the Ethereum model of having metadata hold a URL for the token isn't so dumb after all.

Using SLP Out of the Box

SLP already has an awesome framework for the issuance and transfer of tokens. Perhaps it already has everything that would be needed for NFT. If you created 100 kitty tokens, then they would all be the same type and SLP already has a URL in the metadata. What if that URL was now used for the NFT functionality? In other words, the traditional SLP wants to use the URL to give an official link or give some information about the project. For the NFT use case, it is basically the same thing, except perhaps it is an API link where you plug in the outpoint of the token. There could be some standard where there is a universal scheme so that the URL+outpoint gives you a JSON array of the token parameters according to the server. In Bitcoin, an outpoint (or "output point") is simply the transaction ID plus an index number, which uniquely identifies a coin or "UTXO" element.