CIP-0088? | Token Policy Registration

[Crypto2099]

A proposal to create a standardized format, similar to stake pool registration certificates and Catalyst voter registration certificates that will allow Native Asset policies and the projects/creators behind them to register the intent and top-level information pertaining to their project.

This is a very rough first draft of the proposal and some refinements and sub-specifications are already underway to formalize the payloads mentioned.

The proposal aims to be as forward and backwards compatible for all native script policies assuming project creators still have access to their keys. This standard should allow us to have dynamic, readily updateable metadata at a token policy level with minimal ledger bloat and maximum flexibility.

The 867 JSON metadata index is used in the examples here and would be acceptable as a CIP number for the sake of consistency. The goal would be to register, reserve, and utilize the JSON index that matches the CIP number for ease of reference.

---

(rendered proposal in branch)

[fallen-icarus]

The cardano-address-book program I created does something similar. It cryptographically links metadata to a specific user in an easily queryable manner. If you are looking to tie keys/scripts to a minting policy, I think it would be more secure to use beacon tokens like in the address-book program.

[Ryun1]

A couple small things.

[cent-development]

Hi Adam, I'm leaving my comment / suggested addition to the CIP as we discussed in the NFT Guild Roundtable 18 (Wed March 8th), so it can be discussed further. (Link to recording will shortly be available at https://www.nft-guild.io/the-nft-roundtable)

It is specified in the section "Token Registration Witness Array" to include public key hash "as included in the native script". I agree that this will (as you say) be "proper validation of an updated token registration" for native scripts. As commented in said meeting, this will not be the case for smart contract minting policies who do not have an owner in the same sense as native scripts.

Plutus smart contract scripts only contain a script cbor hex. I am adding a minimal example here for reference.

{
    "type": "PlutusScriptV2",
    "description": "",
    "cborHex": "49480100002221200101"
}

This is the simplest / shortest possible Plutus smart contract, but the structure is the same for all contracts.

The "ownership" of a smart contract or "verification that the owner of a certain pub key hash can mint tokens using this policy" can not be proved directly by examining the script file. If the owner pub key hash is hard coded into the Plutus code, you could verify by manual examination of the code, but then you would need to also build the code to verify it is in fact the correct policy id. This would of course be too cumbersome to be usable.

I think small additions can be made to this CIP to make it work also for smart contract policies. An example could be to support that the same 867 metadata can be part of the tx metadata of special "identity token" minted with the policy. This would prove that you are able to mint tokens with the policy, or at least that someone that can mint tokens with it has named you to be an owner, and the pub key hash would be in the metadata of the token. The identity token would then enable automatic proof and verification for the relationship between the Plutus minting policy and pub key hash.

Or...is there another solution than the "identity token"?

I might add that if the logic of the plutus minting policy is programmed to be locked after some time similar to locked native scripts, then this identity token would not be a possibility as no new minting of identity token can be done. So this approach is not backwards compatible with "locked" plutus policy scripts.

[Crypto2099]

Thank you for taking the time to write this up @cent-development! It is indeed tricky to apply this same logic to Plutus minting scripts, particular I believe impossible to do so via backwards compatibility as we cannot retroactively introduce the logic to mint a "beacon" or "identity" token. The other part of the problem (I suppose) would be having to introduce additional complexity/size to all Plutus minting scripts going forward for what may be minor benefit...

Just to spitball ideas... since most scripts should now take advantage of script references via UTXO that would be in the control of the deploying entity (or some sort of multisig DAO or something)… Maybe including this 867 metadata in the tx where the script is deployed would be sufficient?

Or, one could, optionally of course, somehow add a pub key when deploying a Plutus script reference (via inline datum perhaps?) that could then be used for signing and issuing updates?

[cent-development]

Yes, backward compatibility seems impossible to achieve for Plutus minting policies if we cannot figure out a mechanism that doesn't include the need for identity token minting.

I agree that the reference UTxOs may be nice feature to make use of in this solution. Throwing out a couple of ideas that also can be investigated (NFT guild is already looking into this and we can help of course as we are eager to participate in introducing token verification to the community:) ):

1 - Minting contract owner can mint token called ID (or something that can act as standard) that has the 867 metadata attached either as Datum or tx metadata. (This is perhaps the option you mentioned?)
2 - Mint token called ID-<ownerpubkeyhash> or some other prefix if owner wants another name <random-name>-<ownerpubkeyhash>.

Information added to the 867 metadata is the token name as a value in the Witness Method (element 3) and the owner pub key hash as usual in Witness Array (element 7).

Verification in both options can be done by simply verifying the token is minted using the correct minting policy and that it is named according to the 867 metadata.

[Ryun1]

Might be nice to include an explanation of the flow for discovery and validation for clients.

[Crypto2099]

Agreed, this discovery flow description is currently being worked on as I am working on getting some NFTs I control on preprod so I can use the various tools involved to highlight and show various process of discovery, indexing, and validation as part of the CIP.

[KtorZ]

I think this section needs to be expanded a bit indeed. Possibly settle on a few "well-known" methods and give concrete examples of using those authentication methods.

One big question is how does one link that back to the original token metadata? How do we prevent someone from claiming being someone else token's owner? Do we rely on client applications to then perform manual verification of the witnesses for tokens they support?

[nftguild]

See Adam Dean give a brief overview of his new CIP, what it's all about and the main issues the proposal is trying to address.
https://youtu.be/8V1zfu76hyw

[rphair]

thanks @nftguild but I would suggest the video title be corrected, and the featured image touched up (not expecting a re-recording of video), to show the actual CIP number 88. I understand the fondness for the number 867 but in the long run the community will be fonder of not using 2 different numbers for this CIP. 🙏 (cc @Crypto2099)

[Crypto2099]

@rphair hehe I was doing my best to keep emphasizing "working number, tbd" in all the context I've discussed the CIP. That video is property of @nftguild but I'm sure they'll be happy to correct the title at the very least. Updates to the repo to accommodate the newly assigned number coming soon. :)

[rphair]

@Crypto2099 it seems to me that this proposal supersedes 2 other proposals, designed to work together & from the same author, to handle on-chain references to NFT / FT common data:

• CIP-0048? | NFT metadata references and payloads #249
• NFT metadata extension tag #343

Perhaps you would give them a look & comment if you think there is anything this other framework could provide that is not handled (better in my opinion) by CIP-0088. Otherwise we will probably deprecate those pending proposals in favour of this one.

[nftguild]

thanks @nftguild but I would suggest the video title be corrected, and the featured image touched up (not expecting a re-recording of video), to show the actual CIP number 88. I understand the fondness for the number 867 but in the long run the community will be fonder of not using 2 different numbers for this CIP. 🙏 (cc @Crypto2099)

Thanks for the heads up @rphair . We've chaged the title and the video thumbnail to CIP 88.
At the time we published the videos (both the full recording of the call and the short presentation) the CIP didn't have an official designation assigned to it so we went with the working title given by @Crypto2099 . We were aware we would probably have to go back and change it later, but we weren't expecting it to be this soon :-). But it's all done now.

[rphair]

@Crypto2099 I've just done an editorial overhaul (#249 (review)) of @Jack-0's CIP-0048 to clear the way towards merging according to your suggestion #467 (comment). I can see your text currently has this item here:

TODO: Expand Support for CIP-48

so for the time being we'll check that these two CIPs are mutually compatible & please (both authors) let us know if that ever changes. cc @KtorZ

[thaddeusdiamond]

Well reasoned and well-written @Crypto2099. Thanks for putting this together. I only have two main thoughts:

1. Should the nonce be implied by the block slot height? While I hate "implicit" cache busting, I also worry about an accidental cache mis-deployment that causes a bunch of dependent dApps to break. Since presumably this entry into the decentralized token registry will take the form of a datum/UTxO combination, that will have an implicit livelihood based on the tx slot height it was locked at.
2. Any way to incorporate CIP-0071 here? I would love to register my votes as separate from my main collection, but have them linked. That way, JPG could natively pick up the NFT type of the policy without having to have me explain what each type is and put out a description.

[GeorgeFlerovsky]

@Crypto2099
I noticed that your CIP has implications/interactions for CIP-25.
Our CIP-86 extends CIP-25, so perhaps your CIP might also have corresponding effects on CIP-86.

I'll take a closer look at your CIP to see what those might be.

cc @nicolasayotte @nalane

[BrockCruess]

Small changes, widening the focus on CIP-25/68 from only tokens with a total mint count of 1 to include FTs/RFTs. Can await CIP editor meeting 74.

[rphair]

@BrockCruess @Crypto2099 since our agendas have not been full recently I've put this PR on the agenda for Review again at the next (03 October) meeting (since #467 (review) overlaps with #593 already on agenda): https://hackmd.io/@cip-editors/74

[Crypto2099]

@Crypto2099 I noticed that your CIP has implications/interactions for CIP-25. Our CIP-86 extends CIP-25, so perhaps your CIP might also have corresponding effects on CIP-86.

I'll take a closer look at your CIP to see what those might be.

cc @nicolasayotte @nalane

Hey George, thanks for reminding me on this one, I'm getting ready to publish some updates to hopefully get to a "nearly ready" for deployment and integration work standard so I'll make sure this one is also included. :)

[Crypto2099]

I believe, given these latest changes, that the standards contained herein are now at a point that I can begin some publication and verification testing on test net to confirm that everything works as advertised. Unless there is a glaring or obvious error or omission pointed out by community contributors, I will consider this an "official" v1 of the specification. Appreciate any review or feedback from @rphair @Ryun1 @SmaugPool @thaddeusdiamond @yHSJ and any others who may feel the desire. :)

[rphair]

thanks @Crypto2099; looking forward to a full re-read...

[rphair]

@Crypto2099 #467 (comment): the standards contained herein are now at a point that I can begin some publication

Before that happens, would you retitle this PR to the the same as the concise (but still complete I think) document title... to avoid difficulty & possible divergence when discussing in the community?

[rphair]

l did both a read-through review of the document and a bean-counting inventory of all the comments raised so far and it looks good in both. Everything is comprehensively addressed as far as I can tell.

I can see all the work that has gone into making this compliant with other CIPs but it's beyond my abilities to cross-check it against all the schema documents let alone check if their schemas are sensible, though:

• e.g. for CIP-60 though I think relevant subject matter experts have been given the opportunity (since March 2023) to dispute or adjust the schemas so they can be considered correct by default
• ... and I think we would rely on implementors to adjust these schemas over time anyway after this is merged.

Marking as resolved in this last review (not bulleting so GitHub doesn't expand them):
#467 (comment) addressed in #467 (comment).
#467 (comment) (question answered by author)
#467 (comment) (clarified by author)
#467 (comment) (fixed in rewrite)
#467 (comment) (fixed in rewrite)
#467 (comment) (fixed in much earlier rewrite)
#467 (comment) (answered)
#467 (comment) (new CIP component [spec] added that addresses the inconsistency)
#467 (comment) (no problems w/ CIP-60 reported & TODO item is removed)
#467 (comment) (ditto)
#467 (comment) (template: fixed in rewrite)
#467 (comment) (no longer an issue due to deprecation of CIP48)

request for rewrite of "Witness method" also has been addressed by distributing this explanation into various more detailed sections of the document, so also resolving now:
#467 (comment)
(duplicate) #467 (comment)
(similar) #467 (comment)

From memory it also looks like the RFC2119 language, in keeping with some of this year's newer CIPs, has been added: good job @Crypto2099 for that in the rewrite if I missed it the first time.

@Ryun1 (also inviting @KtorZ since you'd contributed valuably to this discussion) I would be in favour of adding this as Last Check for our next meeting if other editors also think it's good to go based on a latter review. 🚀

[rphair]

p.s. have added this to next CIP meeting https://hackmd.io/@cip-editors/77 if only to assign/confirm Last Check status (cc @Ryun1 @Crypto2099)

[Ryun1]

Excited to see this on-chain 🤠

[cent-development]

Yes, backward compatibility seems impossible to achieve for Plutus minting policies if we cannot figure out a mechanism that doesn't include the need for identity token minting.

I agree that the reference UTxOs may be nice feature to make use of in this solution. Throwing out a couple of ideas that also can be investigated (NFT guild is already looking into this and we can help of course as we are eager to participate in introducing token verification to the community:) ):

1 - Minting contract owner can mint token called ID (or something that can act as standard) that has the 867 metadata attached either as Datum or tx metadata. (This is perhaps the option you mentioned?) 2 - Mint token called ID-<ownerpubkeyhash> or some other prefix if owner wants another name <random-name>-<ownerpubkeyhash>.

Information added to the 867 metadata is the token name as a value in the Witness Method (element 3) and the owner pub key hash as usual in Witness Array (element 7).

Verification in both options can be done by simply verifying the token is minted using the correct minting policy and that it is named according to the 867 metadata.

Some further thoughts on the smart contract verification: To work around the 32 char limitation for token names, we have the possibility to mint ID-tokens named as the MD5 hash of each of the owners pub key hashes as MD5 is always 32 char length. Minting owner identity tokens in this way will give us the benefit of proving ownership of the smart contract as we are able to mint tokens from it, but this also has the nice feature that contract owners are able to add/remove valid owners of a policy by simply minting new owner tokens or burning old tokens for member addresses that leave the team(!).
This solution is also backward compatible for existing smart contracts as long as a contract doesn't enforce specific names for tokens minted by it.

[cent-development]

Please also consider the problem with scam tokens now seen in the community. I cannot see that this new standard will tackle this issue, or have I missed something? If a scam "project" decides to mint tokens, my hypotheses is that if they follow this standard in the current form, it will not be possible to directly flag a token as a scam as they can publish metadata containing the fake pub keys and fake policy ids on chain in a legal format.

One possible way to fight scam tokens is to add a requirement to the standard that a file containing the pub keys are placed on a web server on the same web domain as the project and that the NFT metadata contains a link to this file.
Scam projects will not be able to place their pub key hashes on legitimate project web sites, and this will then make it impossible (or at least very difficult) for scam tokens to appear legit. They will also not be able to reuse legit pub keys in their metadata as this will cause their metadata signatures to be noticeably fake.

Suggestion is to add a property for this path, or make use of the existing Oracle property for this (with some additions to the property description), that contains the link to this file with keys. It must reside on the project domain web site.

You might say that not all projects have a web domain, but most do. It is of course still OK to not have this, but then the project tokens should be verified to status "yellow - not completely verified" as we will not be able to 100% verify the legitimacy. Projects that have a web domain with a valid pub key hash file, will be verified to status "green - verified"