A Specification for Non-Fungible Tokens (NFTs) on the BitShares Blockchain

What follows is a DRAFT proposed specification for standardizing or regularizing non-fungible tokens (NFTs) on the BitShares blockchain and similar blockchains. It is a work in progress, and comments and suggestions are welcomed and encouraged.

What makes an NFT

• Singular or very small integral issuance:
  • Asset precision should be zero
  • Asset should have a max_supply of 1 or of a very small limited number
• Immutability
  • BitShares assets have a disavowable permission to increase max supply. This permission must be disavowed by the issuer, else there remains a mechanism to increase issuance.
  • Asset descriptions — important metadata that uniquely identifies the digital entity encapsulated by the NFT is stored in the Asset Description field. Since this field is mutable, the possibility exists for the asset issuer to alter, deface, spoil, or otherwise destroy the NFT. At present, there is no disavowable asset permission for editing the description. For obvious reasons, it would be useful if there was one, to safeguard the NFT data, however there is not. An alternative, however, once the NFT is created, is to transfer asset issuership of the NFT to null-account, whereby future asset update operations will become impossible.

Asset Description Langauge

The asset description field can accommodate arbitrary text. Current convention is to store a JSON blob allowing asset issuers to embed three distinct descriptive properties of the asset. This JSON blob has the following form: (whitespace added for visual clarity)

{
  "main": "A magical asset that you will surely want to HODL",
  "market": "BTS",
  "short_name": "Magical Asset"
}

Where the fields have the following meanings:

To create a NFT, this document proposes the addition of two new fields to this JSON blob. The keys are nft_object and nft_signature, so that the blob will now have the following form:

{
  "main": "A magical asset that you will surely want to HODL",
  "market": "BTS",
  "nft_object": { ... },
  "nft_signature": "20ff....ea",
  "short_name": "Magical Asset"
}

with the following meanings:

NFT Object

The NFT object shall be represented as a canonicalized JSON blob containing all the of required fields and some combination of the optional fields described below. A canonicalized JSON blob is an ascii JSON serialization in which keys appear in lexicographically sorted order, and in which all non-quoted whitespace is removed (no space between keys and values, no linebreaks, no indentation, etc.). Additionally, quoted text should escape control sequences and special characters (such as linebreaks, tabs, unicode characters, etc.).

Specification vs. convention:

This document is not meant to impose a rigorous standard that "must" be followed. Rather, it is intended to establish common conventions that people will want to abide by. What exactly is to be included in the nft_object may be situationally dependent, and NFT creators are entitled to the full freedom to experiment and alter or extend the suggested conventions here.

Core keys:

The following keys are the core attributes that are most strongly suggested for NFTs following this document. They declare what type of NFT is being constructed, establish a firm intentional linkage between the token and the embedded content, and identify the public key or address of the party that will digitally sign the NFT object. In the sections following this one, additional keys are suggested that vary based on the specific type of NFT being created.

Type spaces:

This document seeks only to build out a proposed convention for the "NFT/ART/VISUAL" type space. Other protocol spaces listed here are merely to suggest the possibility of other applications of NFTs. Whoever wishes to deploy NFTs using a protocol space other than "NFT/ART" or "NFT/ART/VISUAL" shall bear the responsibility of establishing and documenting sensible conventions.

Keys expected for type NFT/ART:

The following keys are conventional and expected for NFT's in the "ART" subspace. They are strongly suggested, however this spec does not specifically forbid omitting them.

Media item keys for type NFT/ART:

Typically ONE of the following keys must be included to embed the media item if the value of the type field is "NFT/ART". The particular key used indicates the file type. Note, the data contained in the value is serialized according to the value of the required encoding key, unless the media is referenced by an ipfs multihash, in which case the encoding key can be ignored. If MORE than one of the following keys are used, it SHOULD be a combination of one data type and a multihash of the same type. In this case, the embedded image is understood to be a preview or thumbnail of a full-resolution image referenced by multihash.

The following is not a comprehensive list, and additional media types may be defined.

Optional and Proposed Keys:

Discussion

Discussion can occur here: Issues.

Strategies for reducing resource utilization by NFTs

NFTs impose a RAM burden on witness and API nodes by virtue of the fact that asset objects, including description field are kept in RAM. Token creators should do their utmost to reduce the storage footprints of their artwork, however, a storage burden in some form is inescapable. Aside from storing links to content instead of actual content data, one option to reduce the RAM hit might be to publish the NFT with full artwork, but then in a subsequent block to replace the nft_object field contents and replace with an object that refers to the block number in which the original publication occurred. Further discussion of this possibility is here: (issues/1).