Introducing Group Tokens for Bitcoin Cash - Part 4/N - Non-fungible Tokens (NFTs)

For a very short description of what Group tokens are, have a look here. I can't repeat the same text here due to read.cash rules.

The intro paragraph in that link describes what Group Tokenization is, but I imagined this series as a way to show what could be done with them. Today we'll look into non-fungible tokens (NFTs).

The notation is simple, stuff in [] describes a transaction output:

[BCH satoshi amount, Group ID, Group amount or authority flags]

Trivial way to create a NFT is to create a new Group for it and mint exactly 1 token without preserving the MINT authority.

TX01 Simple NFT Group Genesis
    In
        [10000]
    Out
        [  546, NFT ID = H(TX01), MINT] // One-time use mint authority
        [  546, NFT ID, MELT | BATON]   // Multi-use melt authority
        [ 7908]                         // BCH change
    Fee   1000

TX02 Simple NFT Token Mint
    In
        [ 7908]
        [  546, NFT ID, MINT]           // One-time use mint authority
    Out
        [  546, NFT ID,    1]           // One unit of token with NFT ID
        [ 6908]                         // BCH change
    Fee   1000

Recall Group genesis scheme -- the NFT ID is computationally guaranteed to be unique because the 32-byte ID is pseudo-random and generated from genesis TX inputs data. Supply is provably fixed because after minting the token no MINT authorities will exist because the only one will have been consumed in the TX02 above. Interested parties can check for that by simply scanning the UTXO set for particular group MINT authorities.

The creator doesn't need to create the MELT | BATON authority, but it is a good way to allow provable destruction of the NFT. With the BATON, the MELT authority can be transferred alongside the token.

NFT Metadata

The above example created a token, but no metadata was attached to it. We could attach metadata by embedding it into an OP_RETURN of the genesis transaction, but that wouldn't give us a good way to update it.

If updating is required then one way would be to first create a NFT metadata token, where every TX of that token would write updated data into the OP_RETURN. We'd then create the actual token and use the genesis OP_RETURN to link it to the metadata token. To fetch the latest metadata interested parties could then simply look up the metadata token UTXO, which there will only be one of. Metadata editing permission could be transferred simply by sending the metadata token to the new owner's address.

The above metadata scheme was just for example, and group token users could freely come up with something else as wallet standard. The metadata scheme is beyond scope of Group Tokenization consensus layer CHIP.

NFTs using Subgroups

Subgroups allow for more versatility and convenience in managing NFTs. First, we create new group with the full authority to operate on subgroups i.e. we create a genesis transaction that will create this authority output:

        [  546, PGID = H(TX),  MINT | MELT | BATON | SUBGROUP]

We can then use it to create any number of subgroup tokens or their authorities. Recall that subgroups are group tokens with extended Group ID, where the extended bytes can be freely set if the required authority is present. For example, we could create a series of trading cards with varying rarity. Note that the + operator in the example below indicates byte concatenation.

Minting Multiple Subgroup Token Supplies
    In
        [10000]
        [  546, PGID,  MINT | MELT | BATON | SUBGROUP]
    Out
        [  546, PGID + 0x01,   10]
        [  546, PGID + 0x02,   20]
        [  546, PGID + 0x03,   50]
        [  546, PGID + 0x04,  100]
        [  546, PGID + 0x05,  200]
        [ 6816]
    Fee   1000

and then burn all SUBGROUP | MINT authorities of the parent group, provably locking the supply of subgroups and their tokens. Because the group ID differs for that one extended byte they are distinct tokens and are not fungible

If the owner of parent group wants to delegate creation of distinct tokens to others, then instead of creating tokens themselves he can create subgroup authorities.

Minting Multiple Subgroup MINT Authorities
    In
        [10000]
        [  546, PGID,  MINT | MELT | BATON | SUBGROUP]
    Out
        [  546, PGID + 0x01, MINT] // one-time use subgroup mint authority
        [  546, PGID + 0x02, MINT]
        [  546, PGID + 0x03, MINT]
        [  546, PGID + 0x04, MINT]
        [  546, PGID + 0x05, MINT]
        [ 6816]
    Fee   1000

To lock the series, the owner of parent group can simply burn his SUBGROUP authority. This already happened in the transaction above because a "change" authority output wasn't included so all parent authorities got burned. Subgroup authorities can then be used to create actual tokens when convenient. Minting a subgroup token is done just like minting any other token:

Minting a Single Subgroup Token Supply
    In
        [ 6816]
        [  546, PGID + 0x01, MINT]
    Out
        [  546, PGID + 0x01,   10]
        [ 5816]
    Fee   1000

This will automatically lock the supply to whatever amount was chosen, because we set it up so that the one-time use subgroup MINT authority was the only one in existence.

Recall that a parent group MINT authority without a SUBGROUP authority CAN NOT create subgroup tokens. Burning the parent SUBGROUP authority makes the parent group just another group token, and it forever loses the capability to create subgroup tokens and authorities.

These tokens can then be freely used just like any other BCH and token outputs. Using the previous Atomic Swap example, a DEX for NFT tokens could be created.

Other posts in the series

Introducing Group Tokens for Bitcoin Cash - Part 1/N - Stablecoin Example

Introducing Group Tokens for Bitcoin Cash - Part 2/N - Atomic Swap Examples

Introducing Group Tokens for Bitcoin Cash - Part 3/N - CoinJoin

Introducing Group Tokens for Bitcoin Cash - Part 4/N - Non-fungible Tokens (NFTs) (this)