CHIP-0054: XCHandles & CHIP-0055: CATalog

CHIPs/chip-0054.md

@@ -0,0 +1,121 @@
+CHIP Number   | 0054
+:-------------|:----
+Title         | XCHandles - A decentralized on-chain address book
+Description   | A decentralized application that allows anyone to register, manage, and resolve unique strings (handles) to singleton launcher ids.
+Author        | [yakuhito](https://github.com/yakuhito)
+Editor        | [Dan Perry](https://github.com/danieljperry)
+Comments-URI  | [CHIPs repo, PR #192](https://github.com/Chia-Network/chips/pull/192)
+Status        | Draft
+Category      | Informational
+Sub-Category  | Rue
+Created       | 2026-02-23
+Requires      | [CHIP-0050: Action Layer and Slots](https://github.com/Chia-Network/chips/pull/165); [CHIP-0005: NFT1 Standard](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0005.md)
+
+## Abstract
+This CHIP proposes a complex decentralized application on the Chia blockchain that allows the registration, management, and resolution of handles - short strings such as ‘@yak’ - to relevant information, such as payment addresses. Importantly, the uniqueness of handles is enforced on-chain, ensuring owners truly control their handles after registration as it is impossible for the app to assign the same handle to someone else.
+
+## Motivation
+‘Name services’ exist on virtually all programmable blockchains. At a high level, they aim to solve the UX problems around identity. Namely, addresses, as long strings made up of seemingly-random characters, are hard to:
+ - **recognize** as belonging to a particular individual
+ - **visually compare** to determine if two addresses are the same
+ - **type**, forcing users to copy them from app to another app, which gets even more complicated when multiple devices are involved
+
+Handles are short, often easy to remember strings. By using one, which is resolved to an address by applications through query of on-chain data, it becomes much easier to send payments, as well as recognize individuals in places such as governance proposal discussions.
+
+## Backwards Compatibility
+This proposal includes a new set of puzzles that collectively make up a dApp. XCHandles is **not** compatible with previous naming services, as those have a very light-weight footprint on-chain, handling most of the logic (including uniqueness checks) off-chain.
+
+## Rationale
+Because XCHandles is essentially an on-chain address book, it is crucial that users and applications recognize entries quickly and can tell which service they belong to. Because of the history surrounding the ‘.xch’ suffix, XCHandle chose to employ an ‘@’ prefix instead. Valid handles such as ‘@yak’ are easily communicated and recognized while making it highly unlikely that they’re mistaken for an address.
+
+The current design heavily emphasizes decentralization. Registrations of available handles should be open to anyone, with handle uniqueness proved [on-chain](https://blog.fireacademy.io/p/solving-the-problem-of-uniqueness). Once a handle is registered, its owner should have full control over it. To preserve compatibility without requiring future updates, handles can be controlled by and resolved to arbitrary singletons (not just NFTs). At launch, the handle will both be controlled and resolved to special NFTs, as described under ‘Specifications.’
+
+Because registration is decentralized, the XCHandles pricing strategy balances two main concerns to achieve the goal of fair handle distribution. High prices create a barrier for some blockchain users, undermining XCHandle’s mission to improve UX by becoming the on-chain address book. Prices that are too low, however, allow some users to register many handles they think will be popular and attempt to resell them at a high premium, diminishing the protocol’s usefulness. Thus, a [factor pricing algorithm](https://docs.xchandles.com/techincal-manual/pricing-puzzles#factor-pricing) similar to the one employed by the Ethereum Name Service is used to price handles. Handles will be priced based on their length (excluding the ‘@’ prefix), with 3-character handles (e.g., ‘@yak’) costing 640 wUSDC.b/year while 6+ characters handles (e.g., ‘@yakuhito’) have a much lower price (10 wUSDC.b/year). This is based on a definition of ‘rarity’ (desiredness) that can easily be checked on-chain - namely, shorter handles are more desirable because they are rarer. Another factor in the pricing formula is the existence of numbers - as most users’ first handle choices would likely not contain numbers, all handles containing numbers are less desirable and thus cost half the normal price. For example, ‘@y4k’ would have a fee of 320 wUSDC.b/year, while ‘@y4kuh1t0’ would have one of 5 wUSDC.b/year. A full table of initial prices for handles can be found below - note that the pricing strategy may be changed later as detailed in this CHIP.
+
+| Attributes | Example | Price |
+| :--- | :--- | :--- |
+| 3 characters, no numbers | @abc | 640 wUSDC.b per year |
+| 3 characters, numbers | @4bc | 320 wUSDC.b per year |
+| 4 characters, no numbers | @abcd | 320 wUSDC.b per year |
+| 4 characters, numbers | @12ab | 160 wUSDC.b per year |
+| 5 characters, no numbers | @abcde | 80 wUSDC.b per year |
+| 5 characters, numbers | @a12345 | 40 wUSDC.b per year |
+| 6+ characters, no numbers | @yakuhito | 10 wUSDC.b per year |
+| 6+ characters, numbers | @yakuh1t0 | 5 wUSDC.b per year |
+
+Historic activity on other chains also suggests the handle expiration mechanism should be designed to deter snipers - users purchasing handles that just expired in order to try to sell them to the original owner at a high premium. XCHandles employs an [auction mechanism](https://docs.xchandles.com/techincal-manual/pricing-puzzles#exponential-premium) to achieve this goal. When a handle expires, a 28 day auction starts where an exponentially-decreasing premium is added to the normal handle price. The premium starts at almost 100.000.000 wUSDC.b and halves each day, reaching 0 at the end of the 28th auction day. This was inspired by Ethereum Name Service’s 3rd and latest expiry mechanism implementation, which is based on the protocol's extensive experience with sniper behavior.
+
+wUSDC.b has been chosen as the payment asset because the CAT currently functions as Chia’s go-to stablecoin. wUSDC.b can also be easily obtained by bridging USDC from Base, which some vendors offer directly in exchange for card/ACH payments. XCH is not a suitable pricing asset for handles, as its dollar-denominated price is too volatile in the long term, meaning that dynamic pricing would require a trusted oracle that is not currently available.
+
+Initial handle distribution is another topic that deserves special consideration. The initial launch should be fair - that is, available handles should be distributed to those who want them the most. Taking inspiration from the process used by newly launched TLDs for DNS domains, XCHandles will have an initial reverse auction for all handles. 
+
+As with any subregistry, the payment CAT, as well as the main and expiry pricing strategies are configurable for the XCHandles main registry. After the initial launch price schedule above is completed, the singleton controlling these parameters will be upgraded to a  7-of-11multisig controlled by warp.green’s validators. This choice was made to ensure XCHandles is ready in case a native USDC-like stablecoin is introduced while not adding more security assumptions to the setup (bridge trust is required to keep wUSDC.b peg). The logic for the factor schedule and 7-of-11 multisig transformation behavior is configured at launch and can be publicly verified.
+
+## Specification
+
+### General Structure
+The XCHandles registry uses the [action layer and slots](https://github.com/Chia-Network/chips/pull/165) framework introduced in CHIP-0050. The possible actions are defined in [this repository](https://github.com/Yakuhito/slot-machine/tree/master) and allow users interacting with the registry to:
+ - **Register** an available handle
+ - **Extend** a handle’s registration
+ - **Update** a handle’s owner and/or the data the handle resolves to
+ - **Refund** an invalid registration attempt
+ - Purchase an **expired** handle
+ - Assert handle data through an **oracle**
+
+More information about the problem of uniqueness can be found [here](https://blog.fireacademy.io/p/uniqueness-on-chain), [here](https://blog.fireacademy.io/p/solving-the-problem-of-uniqueness), and [here](https://blog.fireacademy.io/p/announcing-catalog-and-xchandles). Most of the XCHandles technical documentation can be found on [this site](https://docs.xchandles.com/), with the rest of the components and concepts being explained on [this site](https://docs.catalog.cat/).
+
+At launch, handles will be owned and resolved to NFTs with the [any_metadata](https://github.com/Yakuhito/slot-machine/blob/smol-optimizations/puzzles/nft/any_metadata.clsp) puzzle. This will allow the NFTs’ owners to update all fields of the metadata as desired. A resolver compatible with this specification will be able to resolve the following fields:
+ - **display_name (‘dn’)**: A string indicating the name that should be displayed when the user owning the handle is logged into an application. By default, this is the user’s handle.
+ - **image_uris (‘u’), image_hash (‘h’), metadata_uris (‘mu’), metadata_hash (‘mh’), license_uris (‘lu’), license_hash (‘lh’)**: A set of attributes describing the NFT (see CHIP-0005 for more details). The image may also be used as a profile picture.
+
+Under this specification, the address a handle is resolved to corresponds to the inner puzzle hash of the resolved singleton. If the singleton is an NFT, the NFT’s inner puzzle hash will be used. The resolved DID may be set by transferring the NFT the handle resolves to to a profile.
+
+### Sub-Registries
+
+The XCHandles specification allows anyone to create and operate sub-registries. A handle from a sub-registry can be referenced as ‘@registry:handle’, where ‘@registry’ is a registered handle in the main/root XCHandles registry that resolves to the launcher id of the singleton subregistry and ‘handle’ is a registered entry in the subregistry. Registry owners can choose the registration period (XCHandles root registry uses 1 year), as well as the payment CAT (XCHandles will use wUSDC.b after launch) and pricing strategies (with the root registry strategies outlined below). It is important for users (and wallets) to vet subregistries before using them - for example, a subregistry’s handle in the main registry may still be updateable by a singleton, which would allow a malicious owner to effectively ‘reset’ all registrations or point to another subregistry singleton. Moreover, a subregistry’s setup could allow pricing strategies to be updated without proper vetting or notice. As such, a subregistry whitelist approach is highly recommended.
+
+### Launch
+
+The first two weeks after mainnet deployment will be considered a special registration period. Handle prices will be multiplied by a global factor that goes down each day, eventually reaching one (when handles will reach their ‘normal’ price). The factor schedule can be found below:
+
+| Time | Pricing Factor |
+| :--- | :--- |
+| Day 1 | 1000x |
+| Day 2 | 750x |
+| Day 3 | 500x |
+| Day 4 | 250x |
+| Day 5 | 100x |
+| Day 6 | 75x |
+| Day 7 | 50x |
+| Day 8 | 33x |
+| Day 9 | 25x |
+| Day 10 | 15x |
+| Day 11 | 10x |
+| Day 12 | 5x |
+| Day 13 | 3x |
+| Day 14 | 2x |
+
+The premine - handles that have been pre-registered before launch - will be detailed before this CHIP is finalized.
+
+## Test Cases
+
+A series of tests verifying the behavior of the dApp and its components can be found in chia-wallet-sdk. Each action is tested at least once. Additional tests check the behavior of the pricing puzzles for normal registration and handle expiry.
+
+## Reference Implementation
+The Chialisp/Rue puzzles, along with a CLI that can be used to interact with XCHandles registries through Coinset and Sage, can be found [here](https://github.com/Yakuhito/slot-machine). Drivers and tests have already been integrated into chia-wallet-sdk under the ‘action-layer’ feature.
+
+## Security
+The main risk of this standard is the puzzle risk. Multiple members of the Chia community have reviewed the puzzles powering XCHandles. 
+
+Front-running is also a major concern that heavily influenced the design of XCHandles. An attacker observing the blockchain and public mempool should *not* be able to snipe handles (i.e., see handles that other users are registering and register them, invalidating the initial users’ registrations). XCHandles prevents these types of attacks by using a two-phase registration process. In the first transaction, the user creates a precommitment coin, which contains their payment, as well as data such as the handle they’re registering, their address, and a secret nonce. After 32 blocks, the user can spend the precommitment coin to register or buy an expired handle, revealing the information. The commit-reveal mechanism prevents frontrunning by malicious parties assuming the user does not leak their information during the process. [More details](https://docs.catalog.cat/technical-manual/commitments).
+
+The multisig represents the only centralized component of the system. The singleton may set new pricing puzzles, which control the cost of registering new and expired handles, as well as the price of extending existing registrations. The multisig does not have direct access to slots or the inner puzzle of the XCHandles registry, and is therefore unable to directly override existing handle registrations. The initial signers - warp.green [validators](https://docs.warp.green/#who-are-the-validators) - run highly secure operations and are also responsible for running Chia’s Base/Ethereum bridge.
+
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+
+
+## Acknowledgements
+
+Special thanks to Rigidity, stl, and Andreas for providing feedback on early designs of the dApp. Many thanks to BramV for reviewing the second to last, as well as the final version of the dApps in Chialisp or/and Rue.