CHIP-0060: Titled CATs#205
Conversation
An additive, opt-in standard giving CATs immutable, DID-rooted on-chain identity via a Title Singleton, spanning divisible fungibles and indivisible (precision=1) editioned assets. Introduces no consensus or CLVM changes and composes CAT2, the CHIP-40 everything_with_singleton TAIL, and the optional CHIP-56 Fee Layer and CHIP-38 revocation layer.
(broad comments)
|
|
Thank you for the review and feedback, @Quexington!
This is correct and I was imprecise here. A CAT does have on-chain identity via its asset ID. What I meant is that a CAT lacks human-meaningful metadata and provenance bound to that identifier. I have modified the CHIP to be more precise here.
My take is that for an identity-bearing standard the downsides of mutability outweigh the benefits. A malicious change to an asset's metadata after holders acquire it is a worse failure than an uncorrectable typo, and if immutability is per-field and optional, every consumer has to track "is this field frozen, who may change it, and have they?". A holder of Spacebucks should not be in a position where the issuer can change the asset out from under them IMO. I'll also note the Titled CAT proposal is additive and opt-in, so it does not force immutability on every CAT. An issuer who wants mutable branding still has plain CAT2 plus a registry. Also if the metadata genuinely must change there could be an escape hatch via melt-and-mint migration + offer files. If you can share reasons that mutability is valuable and what the UX might be, I'd be happy to learn more about the benefits and use cases.
Agreed and I have walked this back now. NFT1 remains the right option for non-fungible tokens.
You're right, thanks for pointing this out. tcat-aware wallets SHOULD carry the launcher-ID hint forward on transfers too, which keeps the common aware-to-aware case free. A wallet needs to resolve asset_id to launcher_id once per title and can cache it permanently, since the cached value re-verifies against the asset ID, so it's one-time per title rather than per transfer. An index could also serve this mapping and stay trustless for the same reason. If a wallet meets a title with no hint and no index entry, it walks the lineage back to a mint to recover the reveal and then caches, or degrades to showing a generic CAT. I rewrote the discovery section along these lines. This relies on the asset ID being a deterministic function of the launcher ID, so I checked CHIP-40: the everything_with_singleton NONCE is curried in only to let a single singleton issue multiple different CATs, and it never appears in the puzzle body, only the curry. Since each title has its own dedicated singleton, I think it's OK to pin the nonce to a constant. That keeps the asset ID deterministic from the launcher ID at no runtime cost and reuses the deployed puzzle unchanged. Please let me know if I am missing a reason it needs to vary.
I agree and this is the reasoning behind committing precision on-chain. Because precision is a mandatory immutable field on the title (as currently proposed), every wallet can read the title to agree on what a balance means. Disagreement can still arise in a legacy or non-Titled-aware wallet that does not read the field and falls back to its own default, and this requires some additional thought/discussion.
Fair point, thanks. I wrote this across multiple sessions and it sprawled. I just did another pass for focus and conciseness (with Claude giving some advice on cutting redundancy), and addressed your feedback as best I could.
This is a great point, and I added a note in the NFT1 section. On the N-of-N NFT shape: because it must remain N coins, holding or transferring multiple copies of the same card would be N-in / N-out, where fungible Units consolidate into one coin and transfer in roughly one. So I think the two still partition along individuation. The N-of-N shape fits cards that are individually distinct, and the fungible title fits interchangeable copies you hold and trade in bulk. |
|
This CHIP has been assigned as CHIP-60. It is currently a |
It can be the recommendation for wallets to only pay attention to provably immutable stuff at the beginning. The problem is that baking it into the standard is unnecessarily restrictive and having the response "someone can go use another standard" kind of undermines the necessity of a proposed standard. URIs are a common example of metadata that may need to change just because links break sometimes and need to be updated.
That's a good change, but I don't think I explained my point properly. My point is that when you receive any generic CAT, you can't know if it has a title or not. In order to check, you'll have to register interest in the TAIL hash and see if there's the appropriate title singleton returned to you. This is potentially a lot of unnecessary wallet subscriptions and also, I didn't mention before, but it's a very juice target for dusting since many wallets will all try to subscribe to this same hint.
Still not super relevant to the CHIP but trading cards are indeed a gray area of fungibility. Like you mention in the CHIP, once you start wanting like edition or serial numbers, then moving back to NFTs seems to be the move but using CATs otherwise might make sense. The only thing I was trying to bring to mind is that right now the different editioned/serialed cards would have necessarily different asset IDs according to the current standard whereas in the future you might be able to have a game of some sort check for "a Pikachu NFT" where all of the Pikachu NFTs have the same asset ID just like how CATs work and without having to solve for what edition, etc. they are. And your title standard would be helpful for centralizing the image of a Pikachu among the 1000 or whatever that you minted. |
|
A few points from my first pass:
|
|
Thanks for the additional feedback, @Quexington Despite having some concerns and preferences on convention for Titled CAT mutability: I've moved the CHIP to mutable-by-default. Immutability is opt-in by the issuer rather than imposed by the standard, and your broken-URI case is handled directly since a hash and its URI list can be updated together when the content genuinely changes. On the discovery and the dusting concern: my understanding is that given a generic CAT, you can't tell from the coin whether it's titled because the asset ID is an opaque hash of the TAIL and the TAIL reveal only appears at mint and melt. The naive way to check is to register interest in a TAIL or hint hash and watch for the title singleton, which is a lot of subscriptions and, worse, a shared hash many wallets watch is a juicy dusting target. Please correct me if this is off. The solutions I'm thinking about are:
Neither path subscribes to a shared hash, so neither creates the dusting target you flagged. A wallet reads The absence of a hint doesn't prove a CAT is untitled, so the cold case still costs a one-time lineage walk. I did consider a puzzle-enforced hint for a hard on-coin guarantee, but a layer below the TAIL would stop legacy wallets from spending the coin, which breaks the "looks like an ordinary CAT" property for a minimal title, so I'm inclined to keep it convention plus index and only consider enforcement for titles that are already aware-only such as revocable ones. If you have any feedback here I'm very open to suggestions. |
|
Thanks for the review and feedback, @Yakuhito. I've updated the CHIP based on feedback from both you and Quex:
Thank you - this was very useful! |
|
Following up on solutions for other TAILs after a chat with Claude: I think the title binding generalizes to single-issuance ( Construction (using the standard launcher):
Binding and discovery:
|
|
This special-casing reminds me of @Rigidity 's idea I mentioned in the CATalog CHIP call - in short, you could change the CATalog registration logic and have a custom approver puzzle per TAIL kind. So, for singleton-issued CATs, the singleton could just send a message to register the TAIL it controls, and, for single-issuance CATs, the puzzle of the coin that issued the CAT can be used to identify the issuer. This has the downside of needing someone to maintain and update the list of approver puzzles (which is my main reason for opting out of it), but I think it can get rid of registration fees. |
|
|
||
| ### Technical feasibility | ||
|
|
||
| Titled CAT is feasible today with no protocol changes. Everything the non-royalty core needs already exists and is deployed: CAT2, the CHIP-40 `everything_with_singleton` TAIL (Final, in production for Revocable CATs), the CHIP-38 revocation layer (Final), and the Singleton and Offer standards. The only new puzzle is the Title Singleton inner puzzle for which audited reference patterns exist. The optional royalty path additionally relies on the CHIP-56 Fee Layer, which is still an open proposal (PR #194). The composition occurs entirely at the CLVM / puzzle-hash level, so no consensus or VM change is required. |
5 participants
This CHIP adds the Titled CAT Standard as a Draft CHIP. Titled CATs are an additive and opt-in standard to give any CAT the same immutable, DID-rooted on-chain identity an NFT has without relying on a registry.
This CHIP introduces no new consensus rules and only one new puzzle, the Title Singleton. The
precisionfield allows Titled CATs to support the full range of options from divisible fungibles like stablecoins to indivisible assets like trading cards or tickets.