Non-fungible token (NFT) support

Overview & status

Abstract

It would be valuable to extend token support on qrl-mainnet to include non-fungible token (NFT) creation and transfer capabilities.

Motivation and implementation possibilities

A NFT is typically a token with a single transferrable owner address and a distribution of one. NFTs may be part of a class, but generally each NFT instance of the class has a single controlling owner address. The data payload of the contract address acts as a digital pointer to an URL, hash value for an IPFS lookup etc of which the NFT has some form of digital ownership rights.

NFT’s are now in common usage on smart contract platforms such as ethereum, linking decentralised blockchain ownership to digital collectibles such as art, app-based items, gaming artifacts or even real world physical objects. NFT’s are possibly entering the mainstream as a useful decentralised application for public blockchain networks.

Extending NFT support onto QRL would allow users and third parties to build functionality into QRL immediately. An example would be a digital game requiring a public blockchain with NFT support for in-game items and artifacts. Low or zero fees, minimal network congestion and ultra secure transactions with longevity guaranteed would potentially make QRL a popular network for such third party projects.

Consensus changes required

QRL mainnet currently supports quantum resistant token (QRT) native support. This is achieved through two transaction subtypes TOKEN_CREATE_TX and TOKEN_TRANSFER_TX. During token contract instantiation certain data fields are supplied including: owner address, token name (30 bytes), token symbol (10 bytes), decimals, number and a list of QRL addresses and initial token balances.

To enable NFT support it is suggested for TOKEN_CREATE_TX to be used with custom data supplied including encoding. The explorer and wallet layer would be modified to identify such custom tokens created as NFTs, presenting them differently to existing standard QRT functionality.

This can be achieved easily by forcing NFT creation to apply only to new token instantiations in which token supply is 1, parsing the token symbol for an encoding 4 byte sequence 0x00FF00FF, with the remaining 6 bytes concatenated with the 30 bytes in token name to create a 36 byte data field. This is sufficient for 4 further encoding bytes and a 32 byte cryptographic hash digest.

Projects building into the QRL may then register encoding byte sequences to enable qrl-explorer and wallet labelling / visibility.

Changes to enable support for this NFT may include: additional qrl-explorer logic and presentation of NFT versus current token transaction support, a new wallet function to allow a user to easily create an NFT within the GUI, modification of the qrl-cli or existing API to simplify NFT token creation, parsing and transfer, whilst adhering to the new NFT specification.

The above changes only occur in the data payload of existing token transaction subtypes and therefore are backwards compatible. They do not break existing consensus and are therefore soft fork changes requiring no base layer alteration at all.

Recommendation and attribution

It is recommended to implement the above changes as soon as is practical following team and community discussion. Precise encoding parameters require discussion. Attribution to JP Lomas for the initial idea.