CHIP-0054: XCHandles & CHIP-0055: CATalog

[Yakuhito]

No description provided.

[Yakuhito]

Hey, all! Wanted to provide some more context along with these CHIPs. I've been working on these dApps since I've come up with a solution to the problem of uniqueness - which translates to the past 1.5 years. The 'alpha' version has been working for over a year, which is why you'll see that most documentation pages were created ~1 year ago. I've spent the remaining time on major redesigns that resulted from private feedback. I'm now happy with the current design, and I'm releasing these CHIPs as drafts to start discussion about them in the broader Chia community.

The latest version is written in Rue (Rue vs. Chialisp; cost/size comparison) and is currently undergoing another security-focused review. chia-wallet-sdk and the CLI are currently using the previous version, but will be updated after the review is finished.

I have put a lot of effort into getting these applications to be as good as possible. If you have any feedback but don't want to post it here, please feel free to DM me to discuss on Twitter, Discord (yakuhito) or Keybase (yakuhito_chia). There are some complex ideas behind these designs - for example, what does it mean for handles to be fairly distributed? I encourage everyone to discuss these on public forums, and tag me if you want my thoughts.

[danieljperry]

CHIP-54 is now a Draft. It proposes a decentralized application for storing unique handles.

[danieljperry]

CHIP-55 is now a Draft. It proposes a database for tracking CATs.

[danieljperry]

Please leave your reviews of CHIPs 54 and 55 here, and feel free to discuss them in the #chips channel of our Discord.

[danieljperry]

We are going to hold a Zoom discussion of these CHIPs on March 13 at

• 7 AM PDT
• 2 PM UTC
• 10 PM China
• 11 PM Japan

Visit the #chips channel of our Discord for more details.

[danieljperry]

The recording of Yak's presentation for these CHIPs is now available on Youtube.

[EvanWinget]

On XCHandles: curious how you think about XCHandles versus BIP353-style payment instructions. You mention in the FireAcademy announcement that XCHandles are DNS-inspired, and I'm wondering what you think about embracing DNS directly, paired with a human-readable encoding like name@domain? It's battle-tested at global scale (via email) and already familiar to every internet user.

On CATalog: do you see it as potentially complementary to a separate registration proposal like Titled CATs? (Disclosure: I drafted that CHIP, so I'm biased here.)

My view is that registration and curation are separable concerns. Asset identity is what users anchor trust to, so mutability there seems rarely desirable, whereas curation genuinely benefits from active stewardship. CATalog's unique value prop IMO is the curation layer. Folding registration into it conflates two things that could each be stronger as independent primitives.

Would love to hear your thoughts!

[Yakuhito]

I'm wondering what you think about embracing DNS directly, paired with a human-readable encoding like name@domain? It's battle-tested at global scale (via email) and already familiar to every internet user.

You could see handles as a blockchain-native DNS (esp. a potential DIG sub-registry). I think the goal here is to minimize (and eventually eliminate) trusted parties involved in the registration/resolution processes. The user would have full custody of their handle, which would coincide with that of their funds (hopefully much less likely to be compromised, which we see with DNS a bit too often). Another big advantage of doing things natively is convenience - asking the users registering the handles to pay, manage, and use an on-chain system is much easier than having them go to a registrar and navigating interfaces that were mainly designed for other purposes (websites/email/etc.). All in all, this is a chain-native option because Chia can support it - I see DNS as a work-around.

On CATalog: do you see it as potentially complementary to a separate registration proposal like Titled CATs? (Disclosure: I drafted that CHIP, so I'm biased here.)

My view is that registration and curation are separable concerns. Asset identity is what users anchor trust to, so mutability there seems rarely desirable, whereas curation genuinely benefits from active stewardship. CATalog's unique value prop IMO is the curation layer. Folding registration into it conflates two things that could each be stronger as independent primitives.

I've written about mutability in the discussions section of the linked CHIP. I think CATalog's strongest property is that the registration criteria is so flexible - it can become a repository of information for all TAILs. For special/non-ordinary cases where you need to register a lot of CATs (which I believe is why you started the new CHIP) or you can't predict the TAILs in advance (e.g., TibetSwap liquidity CATs), I think the curation layer can just be used with overrides (so you can have your own verifier containing all your CAT data - e.g., TibetSwap maintaining a verifier just for LP CATs that frontends would trust).

I agree these are two separable layer, but they only form a solution to the problem of figuring out CAT details when taken/used them together, which is why I've grouped the system inside a single CHIP. If another solution becomes popular in the future, the verification layer can be extended to refer to data from outside the CATalog registry with enough support (likely a CHIP + community adoption).