CIP-0068 | Add RFT Rich-fungible token support

[AndrewWestberg]

Rich-fungible tokens sit somewhere between FTs and NFTs. They need the richness of metadata provided by CIP-25, but require decimals like FTs.

One example is a fractionalized NFT. It could be represented by 100 tokens and setting decimals to 2 to show that there was only 1 NFT.

Alternatively, you could choose to mint 100m tokens and set decimals to 6. In this scenario, holding 1 token would represent holding 1% as there are 100 tokens in circulation.

A final example would be a card-style game where you have a number of the player cards as NFTs (222), but interchangeable mana/land/utility cards would be semi-fungible tokens (444)

---

(updated CIP-0068 rendered in branch)

[fallen-icarus]

This is very similar to what I described here. What you are calling a "reference NFT" is what I have been calling a "beacon token". #466 is a work-in-process CIP that is looking to explain how beacon tokens can be used for all kinds of applications, including being able to lookup specific datums as you describe. For consistency, I will use beacon tokens for the rest of this comment.

I do not believe it is necessary, nor a good idea, to have the asset and the beacon token share the same minting policy. What I have in mind is instead to have a separate beacon policy script that everyone uses for a given application. The token name of the beacon token would be the hash of the full asset name for the asset in question. This way there can still be a unique beacon token for every asset. I have not actually tried this yet but I have created a proof-of-concept that does something similar for storing the pre-image of a datum on chain with a beacon (effectively creating an on-chain map from datum hash to pre-image). You can find that here.

The main benefit to sharing the beacon policy is that the universal beacon policy can enforce the proper datum format. If we all agree to use beacon policy X, then if you see a beacon token (minted by that policy) at a UTxO, it is guaranteed to have a datum with the proper format for the standard. If minting policies had to both mint the asset and enforce the standard, you have no way of guaranteeing the standard is being followed without reading the code for every minting policy.

This is more a comment on CIP-0068 as a whole and not on the changes suggested for SFTs.

[Crypto2099]

This is very similar to what I described here. What you are calling a "reference NFT" is what I have been calling a "beacon token". #466 is a work-in-process CIP that is looking to explain how beacon tokens can be used for all kinds of applications, including being able to lookup specific datums as you describe. For consistency, I will use beacon tokens for the rest of this comment.

I do not believe it is necessary, nor a good idea, to have the asset and the beacon token share the same minting policy. What I have in mind is instead to have a separate beacon policy script that everyone uses for a given application. The token name of the beacon token would be the hash of the full asset name for the asset in question. This way there can still be a unique beacon token for every asset. I have not actually tried this yet but I have created a proof-of-concept that does something similar for storing the pre-image of a datum on chain with a beacon (effectively creating an on-chain map from datum hash to pre-image). You can find that here.

The main benefit to sharing the beacon policy is that the universal beacon policy can enforce the proper datum format. If we all agree to use beacon policy X, then if you see a beacon token (minted by that policy) at a UTxO, it is guaranteed to have a datum with the proper format for the standard. If minting policies had to both mint the asset and enforce the standard, you have no way of guaranteeing the standard is being followed without reading the code for every minting policy.

This is more a comment on CIP-0068 as a whole and not on the changes suggested for SFTs.

Just thinking about this in the larger context of beacon tokens in general... If there was some shared "Beacon Policy" how would you verify that I am the entity authorized to mint a "Beacon" for SpaceBudz1234 (for example)? Utilizing the same policy for both reference and beacon tokens at least provides a cryptographic proof link between the two tokens. Also, how would anyone know that they should look for a beacon token under "Random Other Policy X" in this scenario?

[fallen-icarus]

You can require that, in order to mint the beacon for asset A, asset A must be minted in the same transaction as the beacon is minted. The beacon policy would check that asset A is indeed minted in the transaction and would fail to mint the corresponding beacon if asset A was not minted. This is the same cryptographic proof as if they were minted by the same policy. You can make this more flexible by requiring that any asset be minted from the minting policy for asset A. This latter case can be useful if asset A was an NFT that can never be minted again.

As for as looking for the beacon token, that is what the standard is for. People are already looking to CIPs for the information regarding the standard. The CIPs would also mention the corresponding beacon token to check.

[alessandrokonrad]

@AndrewWestberg the 444 label needs to be added to the registry.json of CIP-0067 as well.

[AndrewWestberg]

@alessandrokonrad Updated CIP-67 registry.json

[rphair]

This didn't make it into our CIP editors' meeting a couple days ago even thought I think it would have been a good candidate for discussion. Will recommend it for next meeting's agenda (# 64, not scheduled yet, probably 12 days from now).

Once the stakeholders agree (e.g. #494 (comment) #494 (comment)) I think this is well presented & would be ready to merge.

CIP-0068 never got a format review & update as per #389 - although not recommending we update the header for the new CIP-0001 as part of this PR, I wanted to get @AndrewWestberg @alessandrokonrad attention to see if we could fix the header levels:

• I can understand why major headings like 333 and 444 were made H2's (##): for readability and to make sure their own subheadings aren't inconveniently small.

• Still the standard for a reference manual... and CIP-0068 is becoming a reference manual for these formats... is for strict header levels, like a thesis, rather than chosen cosmetically for type size.

So I am hoping the PR can appropriately demote the 222, 333, 444 sections so they're less significant than their container. Since Labels is an H3 (###) I guess that would make each of these an H4, with the Class / Pattern / Metadata subsections as H5's.

Apologies for this nitpicky treatment but I do believe this will have to be reconciled someday soon, especially given the importance of this document. If not handled in this PR I'll submit a separate PR myself for the header level correction allog with the preamble correction as per #389. cc @KtorZ

[AndrewWestberg]

@rphair I believe I updated the headers correctly. Please let me know if it's all good.

[rphair]

thanks @AndrewWestberg - looks good. I corrected one header indentation that wasn't part of the new material because there isn't a standard "Backward compatibility" section.

I would vote for adding an H3 (###) with an explicit title that introduces all the numbered metadata formats (222, 333, 444) because otherwise they look in the outline like sub-sections of "Constraints and conditions". But the added SFT material itself is clear enough now.

[AndrewWestberg]

@rphair Is this one ready for last check?

[rphair]

sure @AndrewWestberg - I will recommend that at our next meeting if not already marked Last Check here by consensus (cc @KtorZ @Ryun1 @SebastienGllmt).

#494 (review) is mostly addressed, except for the preamble format (outside the scope of this PR) which still obsolete so I'll either fix this in a PR after this one is merged or at least add it to the list in #389.

Mainly approving since I believe the 444 case is addressed at least as well as the previous cases, but will welcome further discussion if anyone feels otherwise.

[Ryun1]

This is not my area of expertise, but I see good discussion and positive reviews from the relevant actors so I will approve on that basis.

[papag00se]

I would like to chime and here and say that without being aware of this PR, our team felt the need for this same CIP-68 variant. We even guessed at the (444) label designation.

In our case, ADA Handles will be launching background images with our NFT partners where we and our partners would like to offer the same background artwork to multiple Handle owners in perpetuity. This resonates with the trading card game example of multiple land/mana cards that all share the same properties but need to be in constant print. Not quite an NFT, but also not a monetary coin-like FT needing to be registered in the token registry,

All of that is to say, we endorse this idea and could make immediate use of it.

[rphair]

Let's try to merge it at tomorrow's CIP meeting then. Given the round of approval, promoting to Last Check in case the agenda, or items to merge, end up being determined on the fly (or shortly before the meeting).

[AndrewWestberg]

@KtorZ @rphair SFT -> RFT update has been completed.

[KtorZ]

Approved. I did catch a tiny oversight but pushed directly on the branch 🙃.

[rphair]

The last of the items that came up at the last hour's CIP meeting have been addressed and document looks good in final check to me, so merging as planned without further ado 🤠