Announcing CATalog and XCHandles

Decentralized registries on Chia have been needed for a while

Note: This is the third post of a 3-part series. Part 1. Part 2.

In the previous blog posts, I explained the problem of uniqueness, as well as a great nice solution for it. This post’s main theme is: now that such a primitive exists, what dApps does the ecosystem need the most? Without further ado, let’s jump right in.

The needs

The first obvious need is names. I want to tell people to send me money at ‘yakuhito’ instead of an XCH address. I have tremendous respect for the services that have attempted to do that, some of which have also used the proceeds to support the ecosystem. That said, a decentralized option is better - it gives users confidence that the names will be available in 10 years and the service will continue to follow the same rules. After a lot of thinking, I have decided to name this service XCHandles.

Side-note: While it’s harder to build and launch, the maintenance of XCHandles is actually easier - there’s no registration key you have to be careful not to leak. Even if the main API/website goes down, wallets can have code that still allows them to resolve names and register them on-chain. XCHandles only goes down when Chia goes down. Worst-case scenario is that you lose control of the address where registration fees go - in which case, the name service continues to live on without any issue.

The second one - also suggested by Ken - is a CAT registry. If you’re a Chia user, you probably aren’t aware of any problems with CATs. But issuers and owners of sites displaying CATs have been battling with it for a long time. In essence, there is no ‘one place’/source of truth where you can go and put the details of your CATs so other sites - like Dexie or TibetSwap - pull them. A decentralized CAT registry - which I will refer to as CATalog from now on - is the best solution, as CAT issuers can own their entries and update them whenever they see fit.

There’s, of course, more to both XCHandles and CATalog than this. Let’s dive in!

Designing XCHandles

I like to think about XCHandles as a decentralized address book - but, in reality, it was designed taking a lot of inspiration from DNS. The Domain Name System (DNS, for short) is the collection of systems responsible for offering and managing domains - such as fireacademy[.]io. The reason XCHandles should be similar to them is that they’re fundamentally offering the same things: names that resolve to dynamic things (be it IP addresses or wallet addresses) and can be registered by anyone (add ‘mostly’ to the last part when talking about DNS).

The first major design decision was to let XCHandles expire. To understand why, let me take the example of my twitter handle - which is ‘yakuh1t0,’ not ‘yakuhito.’ In 2013 - years before I joined Twitter - someone registered as 'yakuhito’ and then left the site - no follows, posts or any activity since then. I would argue that the ‘yakuhito’ handle should come with a mechanism that ensures it’s being used - and the best way to get to that is to make people pay for the time they own handles. At a higher level, if you leave Chia for good or lose access to your handle, there should be a mechanism that eventually allows someone that really wants the handle to get it without having to get in touch with you. This is also, to a certain extent, a great way to prevent ‘squatters’ - people who would register a lot of handles only to offer them at much better prices when someone wants one - since they would have to pay to maintain their collection of handles. DNS has been doing this successfully since around 1983.

The other design decision was to make some handles more expensive. There’s a lot of factors that make some domains more valuable than others - the one I put into XCHandles is based on name length. A 3-letter handle (e.g., ‘yak’) will be more expensive than an 8-letter one (e.g., ‘yakuhito’) since less 3-letter handles are available overall. Since XCHandles are tradeable, a secondary market for handles with other properties (e.g., keywords) will probably establish itself.

That’s pretty much it - in all other major ways, XCHandles will work like most name services on other blockchains. Names are represented as NFTs that the users control - and are free to update and trade as they see fit.

Designing CATalog

CATalog is very interesting in a lot of ways. But, first, let’s talk about how you can build a decentralized CAT registry.

In essence, the goal is to have CAT issuers (‘owners’) control entries in a decentralized registry. This brings up the question: how do you check if someone is the issuer of a new CAT in a decentralized way? We have to keep in mind that CATs can have all kinds of issuance rules - from single issuance, where the owner is obvious, to liquidity CATs on TibetSwap, where the ‘owner’ is not necessarily the user that the funds came from.

The solution is to consider knowledge/information asymmetry. An issuer is a person who came up with the CAT - they’re the first ones to know about the CAT. CATalog can award the CAT entry to the first person that committed the CAT’s asset id on-chain (in most cases, before the CAT was actually issued).

This means that CATalog ensures the uniqueness of TAIL hashes to prevent double-registration - not CAT tickers. The problem with CAT details other than the asset id is that a Chialisp program can’t verify that their values - such as tickers, names, and images - are not misleading. Moreover, sites using CATs would want some vetting power over the CATs they display anyway. Site owners should be able to decide whether the CAT is appropriate for the site or not.

To fix this issue, we must see the registry as ‘PVP-enabled’ - scam attempts are a given. The singleton’s sole purpose is to give CAT creators the power to update the entries for their CATs on-chain - it’s a decentralized CAT database with no regards for the content of the entries. Content ‘filtering’ comes from a layer on top: site owners create on-chain verifications from their DIDs to actively flag CATs as not being misleading. These verifications can include other data (such as the CAT’s specific category on the site). Verifications can also be revoked at any point.

With this new ‘layer,’ CATalog becomes a collection of on-chain resources describing CATs. Issuers register entries and update values. Site owners - and any other DIDs - then create verifications for the values, saying that the content is ok from their perspective. Some dApps might choose to trust someone else - such as Dexie or SpaceScan - to curate CATs for them. This is, in my opinion, the best solution for a token registry that I’ve seen or thought about.

Lastly, CAT registrations last forever. A CAT owner can disappear while the CAT itself is still valid - if that is no longer the case, verifications can be revoked so CATs are no longer listed on websites that wish to hide them.

Wrapping up

If you’ve ever thought that launching a dApp is hard, try launching two! Jokes aside, while XCHandles and CATalog would be easy to launch on an EVM blockchain, a lot of work is needed to get them up and running on Chia.

Along with this post, I’ve also made this repository public. It contains Chialisp code that powers these new dApps, along with draft driver code and working tests. This series didn’t talk about a lot of other stuff - from a new, specialized layer for dApps to the drivers being implemented in Rust instead of Python. A bit more testing under real-world conditions is needed before I’m comfortable with releasing CHIPs and a plan for mainnet. Stay tuned for more news - coming next year!

Special thanks to stl and (or, maybe, a.k.a. 😉 ) Bob for reviewing this article.