From bb70255ee7c3eca58bdf34d6da59629a9a485936 Mon Sep 17 00:00:00 2001 From: Evan Date: Sun, 24 May 2026 09:32:47 -0700 Subject: [PATCH 1/8] Add Titled CAT Standard (draft CHIP) 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. --- CHIPs/chip-evanwinget-titled-cat.md | 379 ++++++++++++++++++++++++++++ 1 file changed, 379 insertions(+) create mode 100644 CHIPs/chip-evanwinget-titled-cat.md diff --git a/CHIPs/chip-evanwinget-titled-cat.md b/CHIPs/chip-evanwinget-titled-cat.md new file mode 100644 index 00000000..16c17632 --- /dev/null +++ b/CHIPs/chip-evanwinget-titled-cat.md @@ -0,0 +1,379 @@ +CHIP Number | TBD (to be assigned by Editor) +:-------------|:---- +Title | Titled CAT Standard +Description | A standard for CATs that carry immutable on-chain identity and provenance, spanning divisible tokens and indivisible editioned assets +Author | [Evan Winget](https://github.com/EvanWinget) +Editor | TBD +Comments-URI | TBD +Status | Draft +Category | Standards Track +Sub-Category | Primitive +Created | 2026-05-22 +Requires | [CAT2](https://chialisp.com/cats/), [CHIP-40 (`everything_with_singleton` TAIL)](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0040.md), Singleton Standard, Offer Standard. Optional layers: [DID1 (CHIP-4)](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0004.md) (creator provenance), [CHIP-56 (Fee CATs)](https://github.com/Chia-Network/chips/pull/194) (royalties), [CHIP-38 (Revocable CATs)](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0038.md) (revocability) +Replaces | None +Superseded-By | None + + +## Abstract + +A **Titled CAT** is a Chia Asset Token (CAT) that carries a verifiable, immutable, on-chain *title*: a name, a ticker, content hashes, a creator DID, and supply commitments, anchored in a single on-chain object and bound to the token by construction. Today an NFT carries its identity on-chain (name, creator DID, content hash) while a CAT carries none (a CAT's identity lives off-chain in indexers). Titled CAT closes this asymmetry: it gives any CAT (both divisible fungibles and indivisible editioned assets) the same on-chain, immutable, DID-rooted identity that NFTs already enjoy, without a registry. + +The standard is **additive and opt-in**. Titled CATs do not modify, deprecate, or compete with CAT2. An ordinary CAT remains the right choice for any token that wants mutable branding or no identity at all. Titled CAT introduces no new consensus rules, no new CLVM operators, and only one new puzzle: the **Title Singleton** inner puzzle which composes CAT2, the CHIP-40 `everything_with_singleton` TAIL, the CHIP-56 Fee Layer (for optional royalties), and the CHIP-38 revocation layer (for optional revocability). + +The Title Singleton is spent only when supply changes, and never on ordinary transfers. This means that a Titled CAT with no royalty layer costs exactly the same to transfer as a bare CAT2 while carrying full on-chain identity. + +A single `precision` field on the title spans the whole fungibility spectrum. **`precision = 1` is the indivisible case: one mojo is one whole token, displayed as an integer count.** This is the natural representation for trading cards, tickets, vouchers, and editioned collectibles. Larger powers of ten yield divisible, decimal-displayed tokens for stablecoins, fractional commodities, and other fungibles that want on-chain identity. One primitive, configured by a single field, replaces what would otherwise require CAT2 plus a registry plus a separate indivisible-token standard. + + +## Definitions + +Throughout this document: + +- **Title**: The immutable on-chain identity record of a Titled CAT: name, ticker, precision, content hashes, optional creator DID, optional royalty configuration, optional revocability, and supply commitments. By analogy to a property *title*, it names the asset and records its provenance. +- **Title Singleton**: The on-chain singleton whose inner puzzle holds the Title and controls minting and melting of the token's Units via its associated TAIL. Its launcher ID is the asset's permanent identifier. It is spent only at mint, melt, mint-close, URI-append, and ownership transfer. It is not spent on ordinary Unit transfers. +- **Title ID**: A bech32m encoding of the Title Singleton's launcher ID, with the human-readable prefix `tcat`. +- **TAIL Asset ID**: The SHA-256 tree hash of the CHIP-40 `everything_with_singleton` TAIL curried to the Title Singleton. This is the CAT asset ID that CAT-aware tooling (wallets, DEXs) uses to identify the token's Units. +- **Unit**: The base, indivisible unit of a Titled CAT: one mojo of a CAT whose TAIL is bound to the Title Singleton. Units of the same Titled CAT are interchangeable. Holdings, mint/melt counts, and the supply counters are all denominated in Units. A wallet shows a Unit balance divided by `precision` as a whole-token amount. +- **precision**: The number of Units (mojos) that make up one whole displayed token, committed immutably in the Title. `precision = 1` means one Unit is one whole token, shown as an **indivisible** integer count. This is the recommended representation for trading cards, tickets, vouchers, and editioned collectibles. `precision ≥ 10` means a whole token is many Units and is shown **divisible**, with `log10(precision)` decimal places (e.g. `precision = 1000` gives three decimals, matching the CAT2 convention). `precision` SHOULD be a power of ten. +- **Holder**: A wallet or coin that currently controls one or more Units. +- **Issuer**: The person or entity that creates a Titled CAT. The Issuer's DID (when present) is curried into the Title Singleton at creation and is immutable. +- **Title Owner**: The current controller of the Title Singleton, authorized to mint, melt, close the mint, prepend URIs, and transfer the title. Control may move via `transfer_title` (the immutable `creator_did` binding does not change). +- **Edition Cap**: An optional maximum on the total number of Units that may ever be minted. Immutable once set at creation. +- **Mint-Closed Flag**: A boolean on the Title Singleton. Once flipped to true, no further Units may ever be minted. May never be flipped back. +- **Total Minted**: A monotonically increasing counter tracking the cumulative number of Units ever minted. Never decreases, even on melt. Total Minted is a commitment about issuance, not circulating supply. +- **Circulating Supply**: The number of Units currently in existence, equal to the token's total CAT mojo supply and observable directly from the chain. Equals `total_minted` minus the number of Units melted. +- **Must, required, shall / Must not, shall not / Should, recommended / Should not, not recommended / May**: These follow the same meanings as in CHIP-0005. + + +## Motivation + +Chia supports two token primitives with an asymmetry between them. NFT1 (CHIP-5) carries identity *on-chain*: an NFT commits its name, its creator DID, and a hash of its artwork into its own coin, immutably and verifiably. CAT2 carries *none* of this. A CAT is identified solely by its TAIL hash. + +This asymmetry is the problem Titled CAT solves: **assets across the fungibility spectrum deserve the same on-chain, immutable, DID-rooted identity that non-fungible assets already have.** + +### The CAT identity gap + +Because a CAT has no native identity, that identity must be supplied from outside the coin, and every option has a cost: +- **Impersonation.** Anyone can mint a CAT and call it "wUSDC.b" or "Spacebucks." Nothing at the protocol level distinguishes the genuine issuer's token from a counterfeit with the same name and logo. Users are protected only by off-chain allowlists maintained by each wallet and exchange. +- **Dependence on third parties.** To show a name, ticker, or logo for a CAT, a wallet must consult an off-chain indexer or a registry and trust its answer. The token itself cannot vouch for its own identity. +- **Registration friction.** Decentralized registries such as [CATalog (CHIP-55)](https://github.com/Yakuhito/chips/blob/xchandles/CHIPs/chip-0055.md) improve on bare indexers by committing content hashes on-chain, but they require a registration step and a fee per asset (a legitimate anti-DoS measure). For an issuer with many assets (a trading-card game with 1,000 cards has 1,000 distinct TAILs) that is a real, repeated cost to establish basic identity. +- **No protocol provenance.** There is no immutable, on-chain binding from a CAT to the DID that issued it. Provenance, where it exists, is again an off-chain claim. + +NFTs face none of this, because their identity is intrinsic. Titled CAT brings that property to the rest of the asset spectrum. + +### Registries solve curation, not the primitive gap + +It is worth being precise about what a registry does and does not address, because Titled CAT does not eliminate the need for one entirely. + +A registry solves two distinct problems: it can *store* identity data, and it can *curate* which assets are considered "official." + +Titled CAT addresses the first by making identity intrinsic to the asset. With a Titled CAT there is no longer any need to *register* a token merely to establish what it is. + +Titled CATs do **not** solve curation. Anyone can mint a Titled CAT named "wUSDC.b" with their own DID. Deciding *which* DID is the legitimate issuer remains an off-chain, venue-specific judgment, exactly as it is for NFT1 collections today (wallets and marketplaces recognize the genuine Chia Network DID and ignore impostors). + +Titled CAT removes the need to *pay to register identity*. Titled CAT preserves the ecosystem's ability to curate trusted issuers. The two are complementary, and the Rationale below treats the relationship to CATalog in detail. + +### What a Titled CAT adds + +- **An immutable, intrinsic title.** Name, ticker, precision, content hashes, royalty configuration, and supply caps are committed at creation and bound to the token by construction. This data is not stored in a separate, mutable, lookup-able record. +- **DID-rooted provenance for any CAT.** A creator DID, curried immutably, gives a Titled CAT the same NFT1-grade provenance: any Unit can be traced cryptographically to the DID that issued it. +- **At no per-transfer cost.** The Title Singleton is spent only when supply changes. Ordinary transfers are ordinary CAT spends. A Titled CAT with no royalty layer is exactly as cheap to move as a bare CAT2. +- **Optional royalties and revocability.** The CHIP-56 Fee Layer (royalties on Offer settlement) and the CHIP-38 revocation layer (issuer revocation for regulated or entitlement use) compose cleanly when wanted, and are absent when not. +- **Ecosystem alignment.** Committing identity on-chain rather than to off-chain infrastructure routes value to farmers through transaction fees and keeps the data decentralized and permanent. + +### One primitive across the fungibility spectrum + +Because `precision` is only a display commitment and the identity machinery is opt-in and touched only at supply changes, a *single* standard serves the entire spectrum of assets that want on-chain identity: + +- **Fully fungible with identity**: stablecoins, wrapped assets, governance and utility tokens. The issuer wants a verifiable, immutable name/ticker and DID provenance, and typically no royalty. (Divisible, `precision ≥ 10`.) +- **Fractional claims**: tokenized commodities (gold by the gram), carbon credits, fractional real estate, streaming-royalty shares. The metadata describes the underlying asset. +- **Indivisible editioned assets**: trading cards, event tickets, coupons and loyalty rewards, music editions, proof-of-attendance tokens, in-game items at scale, redemption vouchers. The image and metadata are the asset's identity, the supply is finite, and royalties or revocability are often wanted. (Indivisible, `precision = 1`.) + +What otherwise requires CAT2 *plus* a registry *plus* a separate indivisible-token standard collapses into one primitive, configured by `precision` alone. The indivisible case is specified in full below and is the natural home for the large class of "fungible within a class, distinct across classes" assets that fit neither NFT1 (which would require one singleton per Unit and is wrong in principle since the Units are *meant* to be interchangeable) nor bare CAT2 (which has nowhere on-chain for the artwork hash, creator DID, or edition cap that give the asset its identity). + +### Use cases and precedent + +The fungible-identity case is motivated by the daily reality of CAT impersonation and the friction of registry-based identity described above. The indivisible-token case has strong cross-chain precedent: Ethereum's ERC-1155 (the Multi Token Standard), introduced by Enjin in 2017 and finalized in 2019, established the pattern of many interchangeable tokens per class with class-level identity, and has seen broad adoption in blockchain gaming, ticketing, and tokenized real-world assets. Solana's Metaplex and Flow's Cadence resources offer comparable primitives. The consistent lesson is that "fungible within a class, distinct across classes" is a genuinely useful shape that neither a pure NFT nor a pure fungible token serves well. Titled CAT brings that shape to Chia *and* generalizes it: the same machinery that makes a trading card's identity verifiable makes a stablecoin's identity verifiable. + +### 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. + + +## Backwards Compatibility + +Titled CAT introduces no breaking changes. It does not modify Chia's consensus, the CLVM, or any existing primitive. It is purely additive and fully opt-in, and it neither replaces nor deprecates CAT2. + +A wallet that does not implement Titled CAT recognition will see a Titled CAT's Units as ordinary CATs with a recognizable TAIL pattern (`everything_with_singleton` bound to a launcher ID). It will not display the title's name, ticker, precision, or artwork, and lacking the committed `precision` will fall back to its default CAT display. This is a strictly safe degradation: a non-Titled-aware wallet shows a generic CAT, never a misleading identity. + +**Alternatives considered.** The principal alternative is to assemble the same outcome from existing pieces: a plain CAT2, identity in a registry (CATalog), royalties via the CHIP-56 Fee Layer, and a wallet display flag. This composition is reasonable and is examined in detail in the Rationale. The short version is that it leaves identity *extrinsic* (a separate, registered, mutable-by-default record keyed to the asset) where Titled CAT makes it *intrinsic and immutable*. + +A second alternative is extending CAT2 itself to carry mandatory on-chain identity. This was rejected because it would force identity machinery onto every CAT, including the many that neither want nor need it, and would constitute a breaking change to the base fungible primitive. Making identity an opt-in standard layered atop an unmodified CAT2 avoids both problems. + + +## Rationale + +### On-chain Identity + +On-chain identity for CATs is important for the same reasons it is on-chain for NFTs. An on-chain, hash-committed identity lets any party verify, without trusting an indexer or registry, that the artwork and metadata they are shown are what the issuer committed to. An immutable creator-DID binding lets any party trace the asset to its issuer and detect impersonation. These guarantees are valuable for a trading card, and they are equally valuable for a stablecoin or a tokenized commodity (arguably more so, given the sums involved). + +### Title Singleton plus a CAT + +The design decomposes cleanly along Chia's coin-set model: + +- The **immutable identity and supply discipline**: name, ticker, precision, content hashes, creator DID, royalty configuration, edition cap, mint-closed flag, mint authorization lives once, in a single on-chain object. +- The **fungible holdings**: who holds how many Units, and how Units transfer, split, consolidate, and participate in Offers are what CAT2 already represents. +- The Title Singleton and the token's CAT are bound by the CHIP-40 `everything_with_singleton` TAIL, which commits the Title Singleton's launcher ID. This binding is the heart of the design: a Unit's TAIL Asset ID is derivable from the launcher ID, and the only object that can authorize a Unit's existence is its Title Singleton. Identity is therefore *intrinsic*, and there is no separate registry record and no "which object is the canonical identity holder?" question. + +The decisive efficiency consequence: the Title Singleton participates only in mint and melt. Ordinary Unit transfers never touch it. A Titled CAT with no royalty layer therefore has the *same per-transfer CLVM cost as a bare CAT2*. On-chain identity, at the level that matters for everyday use, comes at no extra cost. + +### Immutable identity + +Immutability is a key aspect of the value proposition and it is a large part of what distinguishes Titled CAT from a registry: + +- **Asymmetric failure modes.** A hostile or careless change to an asset's identity *after* holders have acquired it is a far worse failure than the inability to fix a typo. A holder cannot defend against a rename or a re-pointed artwork hash, but an issuer can avoid typos by being careful once, at creation. +- **Verify-once trust.** Immutability lets a wallet or buyer verify identity from the Title ID a single time and trust it permanently. Optional mutability would force every consumer to ask "has this changed, and who may change it?" which adds an attack surface. +- **The rebrand case does not require mutability.** An issuer who genuinely needs to change identity mints a new Titled CAT and offers a melt-and-mint migration. + +"Immutable" is precise here. The *commitments* freeze: name, ticker, precision, content hashes, creator DID, royalty configuration, revocability, and edition cap may never change. Two things still move, in tightly constrained ways: + +- **URI lists are prependable**: an owner may add new locations for the same hash-committed content (e.g., a fallback gateway), latest-first, but may never alter or remove existing entries. This is the NFT1 pattern. +- **Supply state is one-way**: `total_minted` only increases, and `mint_closed` only flips from false to true. + +Issuers who want mutable branding are well served by plain CAT2 plus a registry, and should use it. The principled split is: **immutable identity-bearing CAT (Titled CAT) versus mutable registry-backed CAT2.** + +### DID-rooted provenance + +A curried creator DID gives a Titled CAT the same provenance guarantee NFT1 provides: any Unit traces cryptographically to the issuer's DID. It does not make names unique, but it lets venues and wallets recognize the genuine issuer's DID and disregard impostors, which is exactly how NFT1 collections are authenticated today. This approach is expected to make curation of assets more straightforward, as one may choose to curate a list of verified DIDs rather than the assets themselves. + +### A single `precision` field instead of separate standards + +The base unit is always one mojo, and `precision` only states how many mojos constitute one displayed whole token, exactly as CAT2's 1000-mojo convention does. Because identity and divisibility are orthogonal, there is no reason to build two standards. A single `precision` commitment lets the same Title Singleton, TAIL, and layer stack serve an indivisible trading card (`precision = 1`) and a milligram-divisible gold token (`precision = 1000`) alike. + +`precision = 1` is used for the indivisible, integer-displayed case. It has distinct enough semantics to warrant a dedicated wallet display rule. Indivisibility is guaranteed mechanically (a coin cannot be smaller than one mojo), and wallets MUST display an integer count, never a fraction. This safety property is precisely why the indivisible case gets its own display rule rather than being treated as just another `precision` value. + +### Optional fee layer and revocation layer + +Royalties and revocability are wanted by some Titled CATs and not others, and forcing either onto all of them would impose cost and machinery on assets that do not need it. Making both optional, layered components keeps the common case (a Titled CAT with neither) as cheap as a bare CAT2, while letting the richer cases compose exactly the layers they need. The Titled CAT reuses these existing components unchanged. + +### Why not CAT2 + CATalog + Fee CAT + precision-1? + +This is the most important alternative, and it deserves a direct comparison. The composition of a plain CAT2 with `precision = 1`, identity registered in CATalog, royalties via the CHIP-56 Fee Layer, displayed as an identity asset via a CATalog flag is reasonable and can reproduce much of the outcome. The distinction is where identity lives and what establishing it costs: + +- **Intrinsic versus looked-up.** A Titled CAT's identity *is* its TAIL, bound to the Title Singleton by construction. There is no separate record to resolve and no canonical-holder ambiguity. The CATalog composition keeps identity in a separate registry entry keyed to the asset ID, which a wallet must look up and trust the registry to resolve. +- **No per-asset registration cost.** A 1,000-card game is 1,000 registrations and 1,000 fees under the registry approach. Under Titled CAT each title is simply a singleton with no third-party registration step. +- **Immutable by default, not by configuration.** CATalog's default metadata updater permits updating a CAT's name and ticker. Immutability requires deliberately selecting the immutable updater. A Titled CAT's identity is immutable by currying. + +To be clear about what Titled CAT does *not* do: it does not solve curation, and it is not a replacement for a fungible-CAT registry in cases where mutable display metadata is appropriate (a utility token that expects to rebrand). For those, CAT2 plus a registry remains the right tool. Titled CAT and such a registry address different asset populations and are complementary. + +### Why scope this to the primitive alone? + +This CHIP defines the primitive only. Two companions are anticipated and should be developed separately rather than folded in here: + +- **Titled CAT Off-Chain Metadata Format** (Process / Tooling): A JSON schema for the document referenced by `metadata_uri_list`, with fields spanning fungible tokens, fractional claims, and indivisible editioned assets. Analogous to CHIP-7 for NFT1. (The existing metadata draft generalizes directly into this companion.) +- **Titled CAT Collections** (Informational / Guideline): Conventions for grouping multiple titles into a collection (a trading-card set, a family of tokenized commodities, a season-ticket bundle). + + +## Specification + +### Title Singleton + +Each Titled CAT shall be anchored by a singleton conforming to the existing Chia Singleton Standard. The Title Singleton's launcher ID is the asset's permanent identifier. The **Title ID** shall be a bech32m encoding of the launcher ID with the human-readable prefix `tcat`. + +The Title Singleton's inner puzzle shall curry in the following values. All values marked immutable are committed at creation and may never change. The reference inner puzzle published with this CHIP is the canonical implementation. + +#### Identity (immutable) + +- **`name`**: UTF-8 string, maximum 256 bytes. The asset's full display name. Immutable. +- **`ticker`**: UTF-8 string, maximum 32 bytes. The asset's short symbol. Immutable. Tickers are not protocol-enforced as unique. Uniqueness is a curation concern. +- **`precision`**: Unsigned integer, the number of Units (mojos) per whole displayed token. Immutable. `precision = 1` selects the indivisible, integer-displayed case. Larger powers of ten (`precision ≥ 10`) make a whole token divisible into `precision` Units, displayed with decimals. Implementations SHOULD reject a `precision` that is not a power of ten. +- **`creator_did`** *(optional)*: 32-byte launcher ID of the issuer's DID singleton. Once set, immutable. If omitted, provenance is traceable only to the puzzle hash of the original Issuer. + +#### Content commitments (immutable hashes, prependable URI lists) + +Each URI list follows NFT1's pattern: the hash is a one-time commitment, while the URI list may be prepended to (latest-first) but never modified or removed. Wallets should verify fetched content against the hash before rendering. + +- **`data_hash`**: 32-byte SHA-256 hash of the asset's primary content (e.g., the card image or token logo). Immutable. +- **`data_uri_list`**: One or more URIs locating the primary content. +- **`metadata_hash`**: 32-byte SHA-256 hash of the off-chain metadata document at creation. Immutable. +- **`metadata_uri_list`**: One or more URIs locating the off-chain metadata document (richer fields per a companion metadata-format CHIP). +- **`license_hash`**: 32-byte SHA-256 hash of the licensing terms at creation. Immutable. +- **`license_uri_list`**: One or more URIs locating licensing and legal terms. + +#### Royalty configuration (present only if the fee layer is used) + +These values must match exactly the parameters curried into the CHIP-56 Fee Layer that wraps each Unit, so any wallet can reconstruct the expected Unit puzzle hash from the Title Singleton alone. + +- **`royalty_puzzle_hash`**: 32-byte puzzle hash to which royalties are directed. Immutable. +- **`royalty_basis_points`**: Unsigned integer in basis points (1 bps = 0.01%). Zero means no proportional royalty. No protocol cap. +- **`royalty_min_fee`**: Unsigned integer, the minimum royalty in mojos of the quote asset. Zero disables the floor. +- **`allow_zero_price`**: Boolean. When `false`, even direct-send transfers must declare a trade price and pay at least `royalty_min_fee`. When `true`, free transfers (gifting) are permitted. + +#### Revocability (present only if the revocation layer is used) + +- **`revocable`**: Boolean. When `true`, every Unit is wrapped in a CHIP-38 revocation layer between the Fee Layer (or the CAT layer, if no Fee Layer) and the holder's `p2` puzzle, and any Fee Layer present is curried with `has_hidden_revoke_layer: true` and `allow_revoke_fee_bypass: true`. +- **`hidden_puzzle_hash`** *(present only if `revocable`)*: The hidden puzzle hash used by the revocation layer. Immutable. + +#### Supply commitments + +- **`edition_cap`** *(optional)*: Unsigned integer maximum on `total_minted`. If set, immutable. If omitted, supply is uncapped (subject to `mint_closed`). +- **`total_minted`**: Unsigned integer, the cumulative count of Units ever minted. Strictly monotonically increasing. Melts reduce Circulating Supply but not `total_minted`. +- **`mint_closed`**: Boolean. When `true`, no further mints are permitted, ever. May be flipped from `false` to `true` by the Title Owner. + +Wallets and explorers can display supply state in plain language: + +| `edition_cap` | `mint_closed` | Display | +| ------------- | ------------- | --------------------------------------------- | +| Set | false | `Supply: N / cap C (mint open)` | +| Set | true | `Supply: N final (capped at C, mint closed)` | +| Not set | false | `Supply: N (uncapped, mint open)` | +| Not set | true | `Supply: N final (mint closed)` | + +where `N` is Circulating Supply and `C` is the `edition_cap`, both in Units and shown divided by the title's `precision`. + +#### Title Singleton inner puzzle actions + +The inner puzzle accepts the following spend actions, identified by a selector in the solution. + +- **`mint_units(count, target_puzzle_hash)`**: Authorizes the TAIL to mint `count` Units (i.e., `count` mojos) wrapped in the canonical Unit layer stack and sent to `target_puzzle_hash`. Requires `mint_closed == false` and, if `edition_cap` is set, `total_minted + count ≤ edition_cap`. Updates `total_minted` in the recreated singleton. +- **`melt_units(count)`**: Authorizes the TAIL to melt (burn) `count` Units presented for melting in the same spend bundle. Because the `everything_with_singleton` TAIL requires the Title Singleton to authorize every melt, *and* melting any CAT requires control of the Units being melted, neither the Holder alone nor the Issuer alone can destroy a Unit: melting requires both. This suits issuer-driven redemption (a ticket melted at venue scan) and retirement flows (a carbon credit retired on use), while preventing an Issuer from unilaterally burning a Holder's Units. Does not decrease `total_minted`. Circulating Supply decreases as the burned mojos leave the CAT supply. Titles that wish to forbid melting may omit this action. +- **`close_mint()`**: Sets `mint_closed` to `true`. Permanently disables further minting. +- **`add_uri(key, uri)`**: Prepends a URI to one of the three URI lists (`key` ∈ {`data`, `metadata`, `license`}). Does not modify any hash commitment. +- **`transfer_title(new_owner_p2_puzzle_hash, optional_new_did)`**: Transfers Title Singleton ownership. If the title has a `creator_did`, the spend follows the same DID-aware transfer pattern as NFT1. +- **`update_inner_puzzle(new_inner_puzzle_hash)`** *(optional)*: If included, allows swapping the inner puzzle for a published variant that preserves all immutable curried values, enforced by the inner puzzle itself. Titles that do not need upgradability should omit this action entirely. Wallets should treat any inner puzzle hash not on the canonical-variants list with caution. + +### Unit layer stack + +Each Unit is one mojo of a CAT2 coin whose TAIL is `everything_with_singleton` (CHIP-40), curried to the Title Singleton via the singleton module hash, the singleton struct (which commits the launcher ID `L`), and a nonce. The puzzle stack is built from the optional layers the title declares: + +Minimal (no royalties, no revocation): + +``` +├ CAT outer layer (cat_v2) +├── TAIL (everything_with_singleton, bound to Title Singleton L) +├──── p2 puzzle (holder's standard transaction puzzle) +``` + +With royalties: + +``` +├ CAT outer layer (cat_v2) +├── TAIL (everything_with_singleton, bound to Title Singleton L) +├──── Fee Layer (CHIP-56, curried with the title's royalty parameters) +├────── p2 puzzle +``` + +With royalties and revocation: + +``` +├ CAT outer layer (cat_v2) +├── TAIL (everything_with_singleton, bound to Title Singleton L) +├──── Fee Layer (CHIP-56, ... has_hidden_revoke_layer: true, allow_revoke_fee_bypass: true) +├────── Revocation Layer (CHIP-38, curried with the title's hidden_puzzle_hash) +├──────── p2 puzzle +``` + +Revocation without royalties places the revocation layer directly under the CAT layer. The layer parameters curried into every Unit must match exactly the values committed on the Title Singleton. The mint action constructs Units with the canonical stack and rejects any deviation. This gives wallets a complete verification path: from the Title ID, derive the expected stack and the expected Unit puzzle hash and given a coin claimed to be a Unit, verify the puzzle hash matches. + +### Precision and display + +- **Indivisible (`precision = 1`).** One Unit is one whole token. Wallets display an integer count, never decimals. +- **Divisible (`precision ≥ 10`).** A whole token is `precision` Units. Wallets display the Unit balance divided by `precision`, with `log10(precision)` decimal places. + +Both cases share the same Title Singleton, TAIL, and Unit-stack mechanics. They differ only in the committed `precision` and the resulting wallet display rule. + +### Wallet recognition and display + +A wallet implementing this standard shall recognize a CAT coin as a Titled CAT Unit when: +1. The outer layer is `cat_v2` +2. The TAIL is `everything_with_singleton` committing some launcher ID `L` +3. `L` resolves to a Title Singleton with a valid inner puzzle +4. The Unit's inner stack matches the stack derived from the title's curried parameters + +When recognized, the wallet shall display the holding using the title's `name` and `ticker`, sourced from the Title Singleton, formatted at the title's `precision`. Wallets should verify `data_hash` against fetched content before rendering imagery, should surface the `creator_did` when present, and should display royalty configuration and revocability before any Offer involving Units is accepted. + +### Offer integration + +Offers involving Titled CAT Units that carry a Fee Layer follow the CHIP-56 Offer integration pattern unchanged: the maker's wallet computes the royalty per trade price from the title's parameters, includes royalty settlement payments in the bundle, injects `SetCatTradeContext(trade_nonce, trade_prices)` into each Unit lock-leg spend, and the taker's wallet must include the royalty payments to complete the Offer. Units with no Fee Layer trade as ordinary CATs. Per-Offer royalty cost is bounded per title regardless of Unit quantity. + +### RPC calls + +Wallets may expose the following RPCs: + +- **`titled_cat_create`**: Create a Title Singleton and optionally mint an initial batch. Parameters include `name`, `ticker`, `precision`, the three URI/hash sets, optional `royalty_*`, optional `revocable`/`hidden_puzzle_hash`, optional `edition_cap`, optional `initial_mint_count`, optional `did_id`, `target_address`, and `fee`. Returns `title_id` (`tcat…`), `title_singleton_coin_id`, `tail_asset_id`, and transaction info. +- **`titled_cat_mint`**: Mint additional Units. Parameters: `title_id`, `count`, `target_address`, optional `fee`. +- **`titled_cat_melt`**: Melt Units. Parameters: `title_id`, `count`, optional `fee`. Requires both Title Singleton authorization and control of the Units. The title must expose `melt_units`. +- **`titled_cat_close_mint`**: Permanently disable minting. Parameters: `title_id`, optional `fee`. +- **`titled_cat_add_uri`**: Prepend a URI. Parameters: `title_id`, `key`, `uri`, optional `fee`. +- **`titled_cat_transfer`**: Transfer Units to an address. Parameters: `title_id`, `amount`, `target_address`, optional `trade_price`, optional `fee`. +- **`titled_cat_get_info`**: Return a title's on-chain state (all curried fields, `total_minted`, `mint_closed`, derived Circulating Supply). Parameters: `title_id`. +- **`titled_cat_get_balances`**: Return the wallet's holdings aggregated per title. Parameters: optional `wallet_id`. +- **`titled_cat_revoke`** *(revocable titles only)*: Revoke specified Units. Parameters: `title_id`, `coin_ids[]`, `destination_puzzle_hash`, optional `fee`. + + +## Test Cases + +Test cases will be added to `assets/chip-/tests/` and will cover, at minimum: + +- Title creation across the precision range and option combinations. Indivisible (`precision = 1`) and divisible (`precision ≥ 10`), with and without DID, royalties, edition cap, and revocability. +- Verification that Unit puzzle hashes derived from the title's curried fields match the actual on-chain Units, for each layer-stack variant. +- Initial mint and subsequent mints respecting and exceeding the edition cap (must fail when exceeding). Minting after `close_mint` (must fail). +- Melting via `melt_units`: Circulating Supply decreases while `total_minted` is unchanged. Melt without Title Singleton authorization (must fail). Melt without control of the Units (must fail). +- Ordinary transfers, splits, and consolidations of Units. +- Verification that a minimal (no-Fee-Layer) Titled CAT transfer has the same structure and per-transfer cost as a bare CAT2 transfer. +- Decimal display correctness across `precision` values. Assurance that the indivisible case (`precision = 1`) never produces a fractional display. +- Offer settlement with royalties correctly enforced (CHIP-56), underpaid royalty (must fail), CAT-denominated trades, multiple titles in one bundle, and a Titled CAT alongside an NFT1 royalty (all must settle). +- Title ownership transfer between DIDs. +- URI prepend on each list. Attempted modification or removal of existing URIs (must fail). +- Attempted modification of any immutable field: name, ticker, precision, hashes, royalty parameters, revocability, edition cap, creator DID (all must fail). +- Revocable titles: hidden-puzzle revocation succeeds. Normal transfers continue to work. Revocation by a non-controller fails. +- A non-Titled-aware wallet displays Units as ordinary CATs with the TAIL asset ID (no scam vector introduced by the standard's existence). + + +## Reference Implementation + +The reference implementation will be provided in: + +- `chia-wallet-sdk/crates/chia-sdk-puzzles/puzzles/titled_cat_inner_puzzle.rue` will contain the Title Singleton inner puzzle, written in [Rue](https://github.com/Rigidity/rue) and compiled to CLVM. Following the convention established by the CHIP-56 Fee Layer (`fee_layer_v1.rue`), the `chia-sdk-puzzles` crate owns the Rue source alongside the embedded compiled bytes and serialized tree hash. +- `chia-wallet-sdk` will contain the typed Rust bindings and the driver layer for Title Singleton construction/spending and Unit parsing/construction. +- `chia-blockchain/chia/wallet/titled_cat/` will contain the wallet integration, RPC handlers, and indexing. + +The Title Singleton inner puzzle composes with the existing Singleton, CAT2, CHIP-40 TAIL, and CHIP-38 revocation layer (Chialisp) and the CHIP-56 Fee Layer (Rue). Each layer curries the hash of the layer it wraps, meaning that the source language of each layer is immaterial: a Rue-authored inner puzzle interoperates with Chialisp-authored layers transparently. This mixed-language stack is the same one already used in production by Revocable Fee CATs. + + +## Security + +### Duplicate Titled CAT names + +Titled CAT does not make names unique, and it does not decide which issuer is legitimate. An attacker may mint a Titled CAT with a `name` and `ticker` identical to a genuine one. Mitigations are the same as for NFT1 collections: wallets should surface the `creator_did` prominently, and wallets and marketplaces should maintain reputation overlays (verified DIDs, allowlists, denylists). + +### Title Singleton key compromise + +An attacker controlling the Title Singleton key (or its DID) can mint additional Units up to `edition_cap` (or without bound if uncapped), prepend URIs, transfer title ownership, and close the mint. They cannot modify any immutable field, change royalty parameters, alter the creator DID, or revoke held Units. Issuers should set an explicit `edition_cap`, close the mint once the intended supply is reached, custody the controlling key in a vault/multisig/hardware wallet, and keep it separate from the revocation hidden-puzzle key for revocable titles. + +### Royalty bypass + +For titles using the Fee Layer, two cooperating parties can arrange an off-chain payment and use the transfer path to move Units without an Offer, bypassing royalties. The CHIP-56 mitigations apply unchanged: `allow_zero_price: false` forces every transfer to declare a trade price and pay the royalty floor, and `royalty_min_fee` deters nominal-price evasion. + +### Offer reliability for revocable titles + +For revocable titles, the CHIP-38 and CHIP-56 offer-reliability considerations apply: an attacker controlling the hidden puzzle could revoke Units mid-settlement, causing buyer-side Offer execution to fail. Wallets accepting Offers for revocable titles must display revocability prominently so users can judge the issuer's revocation risk. + +One ambiguity is *removed* with Titled CATs. CHIP-38's "revocability confusion scam" exists because a bare revocable CAT shares its asset ID with a non-revocable one, so a wallet must heuristically guess whether coins are revocable. A Titled CAT commits `revocable` on the title, and recognition requires a Unit's stack to match that commitment. A Titled-aware wallet knows definitively whether Units must carry the revocation layer and rejects any that disagree, rather than guessing. + +### Update path + +The optional `update_inner_puzzle` action lets future variants be adopted by existing titles, but a compromised key could swap to a malicious inner puzzle. The reference inner puzzle requires any replacement to preserve all immutable curried values, and wallets must verify a new inner puzzle hash against the canonical-variants list before treating the title as conformant. Titles that omit this action eliminate the attack surface entirely. + + +## Additional Assets + +The following additional assets are anticipated as the reference implementation progresses: + +- `assets/chip-/titled_cat_inner_puzzle.rue`: canonical inner puzzle source (Rue), to be added during Draft. +- `assets/chip-/titled_cat_inner_puzzle.clsp.hex` and its tree hash: compiled CLVM bytes mirroring the source, following the CHIP-56 Fee Layer convention. + + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 88b12801c699df9ef4229c80b6e1c39ab095b8b1 Mon Sep 17 00:00:00 2001 From: Evan Date: Sun, 24 May 2026 15:45:23 -0700 Subject: [PATCH 2/8] Add Relationship to NFT1 section to Titled CAT CHIP --- CHIPs/chip-evanwinget-titled-cat.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/CHIPs/chip-evanwinget-titled-cat.md b/CHIPs/chip-evanwinget-titled-cat.md index 16c17632..3bb27163 100644 --- a/CHIPs/chip-evanwinget-titled-cat.md +++ b/CHIPs/chip-evanwinget-titled-cat.md @@ -166,6 +166,20 @@ This is the most important alternative, and it deserves a direct comparison. The To be clear about what Titled CAT does *not* do: it does not solve curation, and it is not a replacement for a fungible-CAT registry in cases where mutable display metadata is appropriate (a utility token that expects to rebrand). For those, CAT2 plus a registry remains the right tool. Titled CAT and such a registry address different asset populations and are complementary. +### Relationship to NFT1 + +Titled CAT is singleton-anchored and DID-rooted, so a natural question is whether it subsumes NFT1: could an NFT simply be a Titled CAT minted with an edition cap of one? For a *single* unique asset (a one-of-one artwork, a deed) the answer is essentially yes, and a Titled CAT with `edition_cap = 1`, `mint_closed`, and a `creator_did` carries the same intrinsic, immutable, DID-rooted identity an NFT does. But NFT1 is not superseded, because the two standards anchor identity at different granularities, and that difference is architectural rather than incidental. + +A Titled CAT puts one singleton around a whole *class* (the title) and holds balances as fungible Units, spending the singleton only at supply changes. NFT1 puts a singleton around every *item*, spent on every transfer, which is what lets each item carry distinct metadata and a DID-bound owner. A CAT Unit has no individual identity by construction: any two Units of a title are interchangeable and merge into one coin, so there is no per-Unit slot for distinct artwork or a distinct owner. Identity lives on the title, shared by every Unit. + +This decides which standard fits. A 10,000-piece PFP collection of unique artworks needs a per-item identity anchor for each item, and the only anchor is the Title Singleton, so it requires 10,000 titles *plus* 10,000 single-Unit CATs. This is roughly twice the footprint of NFT1's 10,000 singletons, with the fungibility machinery serving no purpose. NFT1 is correct and cheaper. Storing the per-item metadata on the title does not help: the obstacle is not where metadata lives but that fungible Units cannot be individually addressed. The reasoning inverts for *interchangeable* items: a drop of one hundred numbered copies of a card is one hundred singletons under NFT1, but one title and one hundred fungible Units under Titled CAT. + +Titled CAT is NFT1 turned inside out: NFT1 is native when items are distinct, Titled CAT when items are interchangeable within a class, including the editioned middle NFT1 serves awkwardly. + +DID ownership follows the same line. Titled CAT supports DID ownership of the *title*, but deliberately not of each *holding*. Binding an owner DID to every Unit would have to be spent on every transfer, forfeiting the bare-CAT2 transfer cost, and would make Units non-fungible (a Unit owned by one DID could no longer merge with another's). Per-holding DID ownership therefore stays with NFT1, while Titled CAT provides clean collection-level and issuer-level provenance. + +The partition is clean and complementary: **NFT1 for assets whose items are individually distinct or individually DID-owned; Titled CAT for assets whose items share a class identity and are interchangeable within it**, across the spectrum from divisible fungibles to indivisible editioned collectibles. + ### Why scope this to the primitive alone? This CHIP defines the primitive only. Two companions are anticipated and should be developed separately rather than folded in here: From ac321392135d9456242e9ef73193e459a28ee2c9 Mon Sep 17 00:00:00 2001 From: Evan Date: Sun, 24 May 2026 16:40:21 -0700 Subject: [PATCH 3/8] Updates and conciseness pass --- CHIPs/chip-evanwinget-titled-cat.md | 56 ++++++++++++++--------------- 1 file changed, 27 insertions(+), 29 deletions(-) diff --git a/CHIPs/chip-evanwinget-titled-cat.md b/CHIPs/chip-evanwinget-titled-cat.md index 3bb27163..faa1d4e2 100644 --- a/CHIPs/chip-evanwinget-titled-cat.md +++ b/CHIPs/chip-evanwinget-titled-cat.md @@ -59,41 +59,25 @@ Because a CAT has no native identity, that identity must be supplied from outsid - **Registration friction.** Decentralized registries such as [CATalog (CHIP-55)](https://github.com/Yakuhito/chips/blob/xchandles/CHIPs/chip-0055.md) improve on bare indexers by committing content hashes on-chain, but they require a registration step and a fee per asset (a legitimate anti-DoS measure). For an issuer with many assets (a trading-card game with 1,000 cards has 1,000 distinct TAILs) that is a real, repeated cost to establish basic identity. - **No protocol provenance.** There is no immutable, on-chain binding from a CAT to the DID that issued it. Provenance, where it exists, is again an off-chain claim. -NFTs face none of this, because their identity is intrinsic. Titled CAT brings that property to the rest of the asset spectrum. +NFTs face none of this, because their identity is intrinsic. Titled CAT brings that property to the rest of the asset spectrum. Committing identity on-chain rather than to off-chain infrastructure also keeps the data permanent and decentralized while routing value to farmers through transaction fees. ### Registries solve curation, not the primitive gap -It is worth being precise about what a registry does and does not address, because Titled CAT does not eliminate the need for one entirely. - A registry solves two distinct problems: it can *store* identity data, and it can *curate* which assets are considered "official." -Titled CAT addresses the first by making identity intrinsic to the asset. With a Titled CAT there is no longer any need to *register* a token merely to establish what it is. - -Titled CATs do **not** solve curation. Anyone can mint a Titled CAT named "wUSDC.b" with their own DID. Deciding *which* DID is the legitimate issuer remains an off-chain, venue-specific judgment, exactly as it is for NFT1 collections today (wallets and marketplaces recognize the genuine Chia Network DID and ignore impostors). - -Titled CAT removes the need to *pay to register identity*. Titled CAT preserves the ecosystem's ability to curate trusted issuers. The two are complementary, and the Rationale below treats the relationship to CATalog in detail. - -### What a Titled CAT adds +Titled CAT addresses only the first, by making identity intrinsic, so a token no longer needs to be *registered* merely to establish what it is. -- **An immutable, intrinsic title.** Name, ticker, precision, content hashes, royalty configuration, and supply caps are committed at creation and bound to the token by construction. This data is not stored in a separate, mutable, lookup-able record. -- **DID-rooted provenance for any CAT.** A creator DID, curried immutably, gives a Titled CAT the same NFT1-grade provenance: any Unit can be traced cryptographically to the DID that issued it. -- **At no per-transfer cost.** The Title Singleton is spent only when supply changes. Ordinary transfers are ordinary CAT spends. A Titled CAT with no royalty layer is exactly as cheap to move as a bare CAT2. -- **Optional royalties and revocability.** The CHIP-56 Fee Layer (royalties on Offer settlement) and the CHIP-38 revocation layer (issuer revocation for regulated or entitlement use) compose cleanly when wanted, and are absent when not. -- **Ecosystem alignment.** Committing identity on-chain rather than to off-chain infrastructure routes value to farmers through transaction fees and keeps the data decentralized and permanent. +Titled CAT does **not** solve curation. Anyone can mint a Titled CAT named "wUSDC.b" with their own DID, and deciding *which* DID is the legitimate issuer remains an off-chain, venue-specific judgment, exactly as for NFT1 collections today. So Titled CAT removes the need to *pay to register identity* without removing the ecosystem's ability to curate trusted issuers. The two are complementary, and the Rationale treats the relationship to CATalog in detail. ### One primitive across the fungibility spectrum -Because `precision` is only a display commitment and the identity machinery is opt-in and touched only at supply changes, a *single* standard serves the entire spectrum of assets that want on-chain identity: +A *single* standard serves the entire spectrum of assets that want on-chain identity: - **Fully fungible with identity**: stablecoins, wrapped assets, governance and utility tokens. The issuer wants a verifiable, immutable name/ticker and DID provenance, and typically no royalty. (Divisible, `precision ≥ 10`.) - **Fractional claims**: tokenized commodities (gold by the gram), carbon credits, fractional real estate, streaming-royalty shares. The metadata describes the underlying asset. - **Indivisible editioned assets**: trading cards, event tickets, coupons and loyalty rewards, music editions, proof-of-attendance tokens, in-game items at scale, redemption vouchers. The image and metadata are the asset's identity, the supply is finite, and royalties or revocability are often wanted. (Indivisible, `precision = 1`.) -What otherwise requires CAT2 *plus* a registry *plus* a separate indivisible-token standard collapses into one primitive, configured by `precision` alone. The indivisible case is specified in full below and is the natural home for the large class of "fungible within a class, distinct across classes" assets that fit neither NFT1 (which would require one singleton per Unit and is wrong in principle since the Units are *meant* to be interchangeable) nor bare CAT2 (which has nowhere on-chain for the artwork hash, creator DID, or edition cap that give the asset its identity). - -### Use cases and precedent - -The fungible-identity case is motivated by the daily reality of CAT impersonation and the friction of registry-based identity described above. The indivisible-token case has strong cross-chain precedent: Ethereum's ERC-1155 (the Multi Token Standard), introduced by Enjin in 2017 and finalized in 2019, established the pattern of many interchangeable tokens per class with class-level identity, and has seen broad adoption in blockchain gaming, ticketing, and tokenized real-world assets. Solana's Metaplex and Flow's Cadence resources offer comparable primitives. The consistent lesson is that "fungible within a class, distinct across classes" is a genuinely useful shape that neither a pure NFT nor a pure fungible token serves well. Titled CAT brings that shape to Chia *and* generalizes it: the same machinery that makes a trading card's identity verifiable makes a stablecoin's identity verifiable. +The indivisible end of this range has strong cross-chain precedent. Ethereum's ERC-1155 (the Multi Token Standard), introduced by Enjin in 2017 and finalized in 2019, established the pattern of many interchangeable tokens per class with class-level identity, and saw broad adoption in blockchain gaming, ticketing, and tokenized real-world assets. Solana's Metaplex and Flow's Cadence resources offer comparable primitives. The consistent lesson is that "fungible within a class, distinct across classes" is a useful shape that neither a pure NFT nor a pure fungible token serves well. Titled CAT brings that shape to Chia *and* generalizes it: the same machinery that makes a trading card's identity verifiable makes a stablecoin's identity verifiable. ### Technical feasibility @@ -154,13 +138,13 @@ The base unit is always one mojo, and `precision` only states how many mojos con ### Optional fee layer and revocation layer -Royalties and revocability are wanted by some Titled CATs and not others, and forcing either onto all of them would impose cost and machinery on assets that do not need it. Making both optional, layered components keeps the common case (a Titled CAT with neither) as cheap as a bare CAT2, while letting the richer cases compose exactly the layers they need. The Titled CAT reuses these existing components unchanged. +Royalties and revocability are wanted by some Titled CATs and not others, and forcing either onto all of them would impose cost and machinery on assets that do not need it. Making both optional, layered components keeps the common case (a Titled CAT with neither) as cheap as a bare CAT2, while letting the richer cases compose exactly the layers they need. The Titled CAT reuses these existing components unchanged. Royalties in particular are oriented to the editioned, indivisible case. Divisible fungibles generally want identity without a per-trade fee, and the Specification accordingly recommends they omit the Fee Layer (see *Royalty configuration*). ### Why not CAT2 + CATalog + Fee CAT + precision-1? This is the most important alternative, and it deserves a direct comparison. The composition of a plain CAT2 with `precision = 1`, identity registered in CATalog, royalties via the CHIP-56 Fee Layer, displayed as an identity asset via a CATalog flag is reasonable and can reproduce much of the outcome. The distinction is where identity lives and what establishing it costs: -- **Intrinsic versus looked-up.** A Titled CAT's identity *is* its TAIL, bound to the Title Singleton by construction. There is no separate record to resolve and no canonical-holder ambiguity. The CATalog composition keeps identity in a separate registry entry keyed to the asset ID, which a wallet must look up and trust the registry to resolve. +- **Intrinsic versus looked-up.** A Titled CAT's identity *is* its TAIL, bound to the Title Singleton by construction, with no canonical-holder ambiguity. A wallet reads it by resolving the one object the TAIL already commits to: it walks the Title Singleton's lineage to the current coin and reads the curried fields. That lineage is short, because the Title Singleton is spent only at supply changes, and the walk is the same trustless, full-node operation that NFT and DID wallets already perform to resolve a singleton, with every field verifiable against the on-chain commitment. There is thus no registry to consult and no trusted third party. The CATalog composition instead keeps identity in a separate registry entry keyed to the asset ID, whose answer a wallet must trust the registry to resolve. - **No per-asset registration cost.** A 1,000-card game is 1,000 registrations and 1,000 fees under the registry approach. Under Titled CAT each title is simply a singleton with no third-party registration step. - **Immutable by default, not by configuration.** CATalog's default metadata updater permits updating a CAT's name and ticker. Immutability requires deliberately selecting the immutable updater. A Titled CAT's identity is immutable by currying. @@ -172,13 +156,13 @@ Titled CAT is singleton-anchored and DID-rooted, so a natural question is whethe A Titled CAT puts one singleton around a whole *class* (the title) and holds balances as fungible Units, spending the singleton only at supply changes. NFT1 puts a singleton around every *item*, spent on every transfer, which is what lets each item carry distinct metadata and a DID-bound owner. A CAT Unit has no individual identity by construction: any two Units of a title are interchangeable and merge into one coin, so there is no per-Unit slot for distinct artwork or a distinct owner. Identity lives on the title, shared by every Unit. -This decides which standard fits. A 10,000-piece PFP collection of unique artworks needs a per-item identity anchor for each item, and the only anchor is the Title Singleton, so it requires 10,000 titles *plus* 10,000 single-Unit CATs. This is roughly twice the footprint of NFT1's 10,000 singletons, with the fungibility machinery serving no purpose. NFT1 is correct and cheaper. Storing the per-item metadata on the title does not help: the obstacle is not where metadata lives but that fungible Units cannot be individually addressed. The reasoning inverts for *interchangeable* items: a drop of one hundred numbered copies of a card is one hundred singletons under NFT1, but one title and one hundred fungible Units under Titled CAT. +This decides which standard fits. A 10,000-piece PFP collection of unique artworks needs a per-item identity anchor for each item, and the only anchor is the Title Singleton, so it requires 10,000 titles *plus* 10,000 single-Unit CATs. This is roughly twice the footprint of NFT1's 10,000 singletons, with the fungibility machinery serving no purpose. NFT1 is correct and cheaper. Storing the per-item metadata on the title does not help: the obstacle is not where metadata lives but that fungible Units cannot be individually addressed. The reasoning inverts for *interchangeable* items: a drop of one hundred identical copies of a card is one hundred singletons under NFT1, but one title and one hundred fungible Units under Titled CAT. The boundary is precisely individuation. Because Units are fungible, a Titled CAT cannot assign a per-copy serial number, a distinguishing "#7 of 100" that travels with one specific copy: any two Units merge indiscriminately, so there is nowhere for a serial to live. An edition of one hundred is one hundred *interchangeable* copies, not copies #1 through #100. The moment individual copies must be distinguished, whether by serial number, distinct artwork, or a per-copy owner, the asset has crossed back into NFT1's domain. Titled CAT is NFT1 turned inside out: NFT1 is native when items are distinct, Titled CAT when items are interchangeable within a class, including the editioned middle NFT1 serves awkwardly. DID ownership follows the same line. Titled CAT supports DID ownership of the *title*, but deliberately not of each *holding*. Binding an owner DID to every Unit would have to be spent on every transfer, forfeiting the bare-CAT2 transfer cost, and would make Units non-fungible (a Unit owned by one DID could no longer merge with another's). Per-holding DID ownership therefore stays with NFT1, while Titled CAT provides clean collection-level and issuer-level provenance. -The partition is clean and complementary: **NFT1 for assets whose items are individually distinct or individually DID-owned; Titled CAT for assets whose items share a class identity and are interchangeable within it**, across the spectrum from divisible fungibles to indivisible editioned collectibles. +The partition is clean and complementary: **NFT1 for assets whose items are individually distinct or individually DID-owned, and Titled CAT for assets whose items share a class identity and are interchangeable within it**, across the spectrum from divisible fungibles to indivisible editioned collectibles. ### Why scope this to the primitive alone? @@ -223,6 +207,8 @@ These values must match exactly the parameters curried into the CHIP-56 Fee Laye - **`royalty_min_fee`**: Unsigned integer, the minimum royalty in mojos of the quote asset. Zero disables the floor. - **`allow_zero_price`**: Boolean. When `false`, even direct-send transfers must declare a trade price and pay at least `royalty_min_fee`. When `true`, free transfers (gifting) are permitted. +The Fee Layer is oriented to the indivisible, editioned case (`precision = 1`), where a royalty on resale is an established expectation. Divisible titles (`precision ≥ 10`) SHOULD set `royalty_basis_points = 0` and SHOULD NOT set `allow_zero_price: false`. A per-trade royalty interferes with the price discovery and arbitrage that fungible tokens depend on (notably automated market makers), and a floor charged on every transfer makes a circulating fungible impractical to use. A divisible Titled CAT therefore typically omits the Fee Layer entirely, carrying on-chain identity without royalties. + #### Revocability (present only if the revocation layer is used) - **`revocable`**: Boolean. When `true`, every Unit is wrapped in a CHIP-38 revocation layer between the Fee Layer (or the CAT layer, if no Fee Layer) and the holder's `p2` puzzle, and any Fee Layer present is curried with `has_hidden_revoke_layer: true` and `allow_revoke_fee_bypass: true`. @@ -249,7 +235,7 @@ where `N` is Circulating Supply and `C` is the `edition_cap`, both in Units and The inner puzzle accepts the following spend actions, identified by a selector in the solution. -- **`mint_units(count, target_puzzle_hash)`**: Authorizes the TAIL to mint `count` Units (i.e., `count` mojos) wrapped in the canonical Unit layer stack and sent to `target_puzzle_hash`. Requires `mint_closed == false` and, if `edition_cap` is set, `total_minted + count ≤ edition_cap`. Updates `total_minted` in the recreated singleton. +- **`mint_units(count, target_puzzle_hash)`**: Authorizes the TAIL to mint `count` Units (i.e., `count` mojos) and send them to `target_puzzle_hash` wrapped in the canonical Unit layer stack. The action derives the canonical Unit puzzle hash from the title's own immutable parameters (the TAIL Asset ID, the declared royalty and revocation layers, and `target_puzzle_hash`) and constrains issuance to coins bearing exactly that puzzle hash, so it cannot authorize a Unit assembled from a non-canonical stack (see *Mint-time stack binding* below). Requires `mint_closed == false` and, if `edition_cap` is set, `total_minted + count ≤ edition_cap`. Updates `total_minted` in the recreated singleton. - **`melt_units(count)`**: Authorizes the TAIL to melt (burn) `count` Units presented for melting in the same spend bundle. Because the `everything_with_singleton` TAIL requires the Title Singleton to authorize every melt, *and* melting any CAT requires control of the Units being melted, neither the Holder alone nor the Issuer alone can destroy a Unit: melting requires both. This suits issuer-driven redemption (a ticket melted at venue scan) and retirement flows (a carbon credit retired on use), while preventing an Issuer from unilaterally burning a Holder's Units. Does not decrease `total_minted`. Circulating Supply decreases as the burned mojos leave the CAT supply. Titles that wish to forbid melting may omit this action. - **`close_mint()`**: Sets `mint_closed` to `true`. Permanently disables further minting. - **`add_uri(key, uri)`**: Prepends a URI to one of the three URI lists (`key` ∈ {`data`, `metadata`, `license`}). Does not modify any hash commitment. @@ -287,7 +273,11 @@ With royalties and revocation: ├──────── p2 puzzle ``` -Revocation without royalties places the revocation layer directly under the CAT layer. The layer parameters curried into every Unit must match exactly the values committed on the Title Singleton. The mint action constructs Units with the canonical stack and rejects any deviation. This gives wallets a complete verification path: from the Title ID, derive the expected stack and the expected Unit puzzle hash and given a coin claimed to be a Unit, verify the puzzle hash matches. +Revocation without royalties places the revocation layer directly under the CAT layer. The layer parameters curried into every Unit must match exactly the values committed on the Title Singleton. This gives wallets a complete verification path: from the Title ID, derive the expected stack and the expected Unit puzzle hash, and given a coin claimed to be a Unit, verify the puzzle hash matches. + +**Mint-time stack binding.** A Unit's CAT Asset ID is the hash of the TAIL alone, so it is identical whether or not the optional Fee and revocation layers are present: those layers live in the inner puzzle, beneath the CAT layer. Nothing at the CAT layer can therefore distinguish a canonical Unit from one assembled with a missing or altered layer. The Title Singleton's `mint_units` action is the only thing that can, and it is the linchpin of the verifiable-stack guarantee. The action recomputes the canonical Unit puzzle hash `H` (the CAT layer curried with the TAIL Asset ID, wrapping the title's declared Fee and revocation layers and the holder's `p2` puzzle) from the title's immutable parameters, and authorizes issuance only for created coins whose puzzle hash equals `H`. Because the `everything_with_singleton` TAIL delegates all issuance authorization to the Title Singleton, a coin minted with any other stack is never authorized and is not a Unit. The exact condition wiring by which the singleton scopes its authorization to `H` (a committed announcement that each issued coin's spend must assert, or a direct assertion over the created coins) is fixed by the reference inner puzzle against the CHIP-40 authorization interface. This single derive-and-constrain step is the most security-critical code in the standard and the focus of reference-implementation review. + +**Persistence across transfers.** Mint-time binding establishes a Unit's stack. The Fee Layer, when present, must preserve it. Titled CAT relies on the CHIP-56 Fee Layer re-wrapping itself on every spend, including ordinary non-Offer transfers, and rejecting any spend that would drop it. A Fee Layer that permitted a plain transfer to settle to a bare `p2` puzzle would let a holder strip the layer and produce a royalty-free coin that shares the title's CAT Asset ID. The royalty-stripping consequences are treated under Security. ### Precision and display @@ -365,9 +355,17 @@ Titled CAT does not make names unique, and it does not decide which issuer is le An attacker controlling the Title Singleton key (or its DID) can mint additional Units up to `edition_cap` (or without bound if uncapped), prepend URIs, transfer title ownership, and close the mint. They cannot modify any immutable field, change royalty parameters, alter the creator DID, or revoke held Units. Issuers should set an explicit `edition_cap`, close the mint once the intended supply is reached, custody the controlling key in a vault/multisig/hardware wallet, and keep it separate from the revocation hidden-puzzle key for revocable titles. -### Royalty bypass +### Royalty integrity and bypass + +For titles using the Fee Layer, royalty integrity rests on a two-link chain, and each link has a distinct failure mode. + +*Mint-time binding.* A Unit's CAT Asset ID does not depend on the presence of the Fee Layer, so the guarantee that minted Units actually carry it comes entirely from the Title Singleton's `mint_units` action constraining the issued puzzle hash (see *Mint-time stack binding*). This makes the inner puzzle's derive-and-constrain step the most security-critical code in the standard: a flaw there would let the Title Owner issue royalty-free coins indistinguishable by Asset ID from royalty-bearing ones. + +*Transfer-time persistence.* Even a correctly minted Unit stays royalty-bearing only if the CHIP-56 Fee Layer re-wraps itself on every spend and rejects spends that drop it (see *Persistence across transfers*). If it does not, a holder can strip the layer in a single ordinary transfer. + +A stripped or non-canonically minted coin does not disappear: it carries the title's CAT Asset ID under a bare inner puzzle. A Titled-aware wallet rejects it, because its stack fails the recognition rule, and so will not trade it as a Unit. This is the backstop. But a CAT-only or non-Titled-aware wallet sees a generic CAT of that Asset ID and may accept it, so wallet recognition bounds the damage without eliminating it. Issuers for whom royalty integrity is critical should weigh this. It is inherent to placing royalties in a strippable inner layer beneath a shared Asset ID, and is not specific to Titled CAT. -For titles using the Fee Layer, two cooperating parties can arrange an off-chain payment and use the transfer path to move Units without an Offer, bypassing royalties. The CHIP-56 mitigations apply unchanged: `allow_zero_price: false` forces every transfer to declare a trade price and pay the royalty floor, and `royalty_min_fee` deters nominal-price evasion. +Finally, even with both links sound, two cooperating parties can arrange an off-chain payment and use the transfer path to move Units without an Offer, bypassing the royalty. The CHIP-56 mitigations apply unchanged: `allow_zero_price: false` forces every transfer to declare a trade price and pay the royalty floor, and `royalty_min_fee` deters nominal-price evasion. ### Offer reliability for revocable titles From 2e59cd25b9e0180dcdc4e20071647cb0eca5310d Mon Sep 17 00:00:00 2001 From: Evan Date: Sun, 24 May 2026 21:14:25 -0700 Subject: [PATCH 4/8] Language cleanups --- CHIPs/chip-evanwinget-titled-cat.md | 44 ++++++++++++++++++++--------- 1 file changed, 31 insertions(+), 13 deletions(-) diff --git a/CHIPs/chip-evanwinget-titled-cat.md b/CHIPs/chip-evanwinget-titled-cat.md index faa1d4e2..b7c3a132 100644 --- a/CHIPs/chip-evanwinget-titled-cat.md +++ b/CHIPs/chip-evanwinget-titled-cat.md @@ -16,7 +16,7 @@ Superseded-By | None ## Abstract -A **Titled CAT** is a Chia Asset Token (CAT) that carries a verifiable, immutable, on-chain *title*: a name, a ticker, content hashes, a creator DID, and supply commitments, anchored in a single on-chain object and bound to the token by construction. Today an NFT carries its identity on-chain (name, creator DID, content hash) while a CAT carries none (a CAT's identity lives off-chain in indexers). Titled CAT closes this asymmetry: it gives any CAT (both divisible fungibles and indivisible editioned assets) the same on-chain, immutable, DID-rooted identity that NFTs already enjoy, without a registry. +A **Titled CAT** is a Chia Asset Token (CAT) that carries a verifiable, immutable, on-chain *title*: a name, a ticker, content hashes, a creator DID, and supply commitments, bound to the token by construction. An NFT carries its identity on-chain (name, creator DID, content hash) while a CAT carries none, relying on off-chain indexers. Titled CAT closes this asymmetry, giving any CAT (divisible fungibles and indivisible editioned assets alike) the same immutable, DID-rooted on-chain identity an NFT has, without a registry. The standard is **additive and opt-in**. Titled CATs do not modify, deprecate, or compete with CAT2. An ordinary CAT remains the right choice for any token that wants mutable branding or no identity at all. Titled CAT introduces no new consensus rules, no new CLVM operators, and only one new puzzle: the **Title Singleton** inner puzzle which composes CAT2, the CHIP-40 `everything_with_singleton` TAIL, the CHIP-56 Fee Layer (for optional royalties), and the CHIP-38 revocation layer (for optional revocability). @@ -65,9 +65,7 @@ NFTs face none of this, because their identity is intrinsic. Titled CAT brings t A registry solves two distinct problems: it can *store* identity data, and it can *curate* which assets are considered "official." -Titled CAT addresses only the first, by making identity intrinsic, so a token no longer needs to be *registered* merely to establish what it is. - -Titled CAT does **not** solve curation. Anyone can mint a Titled CAT named "wUSDC.b" with their own DID, and deciding *which* DID is the legitimate issuer remains an off-chain, venue-specific judgment, exactly as for NFT1 collections today. So Titled CAT removes the need to *pay to register identity* without removing the ecosystem's ability to curate trusted issuers. The two are complementary, and the Rationale treats the relationship to CATalog in detail. +Titled CAT makes only the first intrinsic, so a token no longer needs to be *registered* to establish what it is. It does not attempt curation: which DID is the legitimate issuer of a "wUSDC.b" remains an off-chain, venue-specific judgment, exactly as for NFT1 collections. Titled CAT removes the need to *pay to register identity* without removing the ecosystem's ability to curate trusted issuers. ### One primitive across the fungibility spectrum @@ -86,7 +84,7 @@ Titled CAT is feasible today with no protocol changes. Everything the non-royalt ## Backwards Compatibility -Titled CAT introduces no breaking changes. It does not modify Chia's consensus, the CLVM, or any existing primitive. It is purely additive and fully opt-in, and it neither replaces nor deprecates CAT2. +Titled CAT introduces no breaking changes: it does not modify Chia's consensus, the CLVM, or any existing primitive. It is purely additive and opt-in, and neither replaces nor deprecates CAT2. A wallet that does not implement Titled CAT recognition will see a Titled CAT's Units as ordinary CATs with a recognizable TAIL pattern (`everything_with_singleton` bound to a launcher ID). It will not display the title's name, ticker, precision, or artwork, and lacking the committed `precision` will fall back to its default CAT display. This is a strictly safe degradation: a non-Titled-aware wallet shows a generic CAT, never a misleading identity. @@ -99,7 +97,7 @@ A second alternative is extending CAT2 itself to carry mandatory on-chain identi ### On-chain Identity -On-chain identity for CATs is important for the same reasons it is on-chain for NFTs. An on-chain, hash-committed identity lets any party verify, without trusting an indexer or registry, that the artwork and metadata they are shown are what the issuer committed to. An immutable creator-DID binding lets any party trace the asset to its issuer and detect impersonation. These guarantees are valuable for a trading card, and they are equally valuable for a stablecoin or a tokenized commodity (arguably more so, given the sums involved). +On-chain identity matters for a CAT for the same reasons it matters for an NFT. A hash-committed identity lets any party verify, without trusting an indexer or registry, that the artwork and metadata shown are what the issuer committed to, and an immutable creator-DID binding lets any party trace the asset to its issuer and detect impersonation. These guarantees are as valuable for a stablecoin or a tokenized commodity as for a trading card, arguably more so given the sums involved. ### Title Singleton plus a CAT @@ -109,11 +107,11 @@ The design decomposes cleanly along Chia's coin-set model: - The **fungible holdings**: who holds how many Units, and how Units transfer, split, consolidate, and participate in Offers are what CAT2 already represents. - The Title Singleton and the token's CAT are bound by the CHIP-40 `everything_with_singleton` TAIL, which commits the Title Singleton's launcher ID. This binding is the heart of the design: a Unit's TAIL Asset ID is derivable from the launcher ID, and the only object that can authorize a Unit's existence is its Title Singleton. Identity is therefore *intrinsic*, and there is no separate registry record and no "which object is the canonical identity holder?" question. -The decisive efficiency consequence: the Title Singleton participates only in mint and melt. Ordinary Unit transfers never touch it. A Titled CAT with no royalty layer therefore has the *same per-transfer CLVM cost as a bare CAT2*. On-chain identity, at the level that matters for everyday use, comes at no extra cost. +The efficiency consequence: the Title Singleton participates only in mint and melt. A Titled CAT with no royalty layer has the *same per-transfer CLVM cost as a bare CAT2*, so on-chain identity comes at no extra cost for everyday use. ### Immutable identity -Immutability is a key aspect of the value proposition and it is a large part of what distinguishes Titled CAT from a registry: +Immutability is central to the value proposition and is much of what distinguishes Titled CAT from a registry: - **Asymmetric failure modes.** A hostile or careless change to an asset's identity *after* holders have acquired it is a far worse failure than the inability to fix a typo. A holder cannot defend against a rename or a re-pointed artwork hash, but an issuer can avoid typos by being careful once, at creation. - **Verify-once trust.** Immutability lets a wallet or buyer verify identity from the Title ID a single time and trust it permanently. Optional mutability would force every consumer to ask "has this changed, and who may change it?" which adds an attack surface. @@ -126,6 +124,10 @@ Immutability is a key aspect of the value proposition and it is a large part of Issuers who want mutable branding are well served by plain CAT2 plus a registry, and should use it. The principled split is: **immutable identity-bearing CAT (Titled CAT) versus mutable registry-backed CAT2.** +### Mutability solutions + +Immutability needs an escape hatch for the case where identity genuinely must change, such as a real rebrand or a corrected content hash. That hatch is migration by melt-and-mint, and it is what makes immutability acceptable. The issuer mints a new Titled CAT carrying the corrected identity, closes the old title's mint, and offers holders a swap: a holder melts old Units with `melt_units` and receives an equal count of the new title's Units. + ### DID-rooted provenance A curried creator DID gives a Titled CAT the same provenance guarantee NFT1 provides: any Unit traces cryptographically to the issuer's DID. It does not make names unique, but it lets venues and wallets recognize the genuine issuer's DID and disregard impostors, which is exactly how NFT1 collections are authenticated today. This approach is expected to make curation of assets more straightforward, as one may choose to curate a list of verified DIDs rather than the assets themselves. @@ -138,17 +140,27 @@ The base unit is always one mojo, and `precision` only states how many mojos con ### Optional fee layer and revocation layer -Royalties and revocability are wanted by some Titled CATs and not others, and forcing either onto all of them would impose cost and machinery on assets that do not need it. Making both optional, layered components keeps the common case (a Titled CAT with neither) as cheap as a bare CAT2, while letting the richer cases compose exactly the layers they need. The Titled CAT reuses these existing components unchanged. Royalties in particular are oriented to the editioned, indivisible case. Divisible fungibles generally want identity without a per-trade fee, and the Specification accordingly recommends they omit the Fee Layer (see *Royalty configuration*). +Royalties and revocability are wanted by some Titled CATs and not others, and forcing either onto all would impose cost and complexity on assets that do not need it. Making both optional, reused-as-is layered components keeps the common case (a Titled CAT with neither) as cheap as a bare CAT2 while letting richer cases compose exactly the layers they need. Royalties in particular are oriented to the editioned, indivisible case. Divisible fungibles generally want identity without a per-trade fee, so the Specification recommends they omit the Fee Layer (see *Royalty configuration*). + +### Regulated and stablecoin issuers + +A regulated fungible token such as a fiat-backed stablecoin typically wants three properties at once: verifiable issuer identity, control over who may hold the asset, and the ability to freeze or claw back. Titled CAT supplies identity intrinsically and composes the other two from existing layers. Holding control reuses the deployed Credential Restricted CAT (CR-CAT) pattern, where a credential layer gates each transfer on the receiver proving an on-chain Verifiable Credential from an authorized provider, and claw-back reuses the CHIP-38 revocation layer. Both add to the inner stack as the Fee and revocation layers do (see *Unit layer stack*), with the revocation layer outside the credential layer by default so an issuer's claw-back path stays independent of the credential check while ordinary transfers satisfy both. ### Why not CAT2 + CATalog + Fee CAT + precision-1? -This is the most important alternative, and it deserves a direct comparison. The composition of a plain CAT2 with `precision = 1`, identity registered in CATalog, royalties via the CHIP-56 Fee Layer, displayed as an identity asset via a CATalog flag is reasonable and can reproduce much of the outcome. The distinction is where identity lives and what establishing it costs: +This is the most important alternative. A plain CAT2 with `precision = 1`, identity registered in CATalog, royalties via the CHIP-56 Fee Layer, and a CATalog display flag is reasonable and reproduces much of the outcome. The distinction is where identity lives and what establishing it costs: - **Intrinsic versus looked-up.** A Titled CAT's identity *is* its TAIL, bound to the Title Singleton by construction, with no canonical-holder ambiguity. A wallet reads it by resolving the one object the TAIL already commits to: it walks the Title Singleton's lineage to the current coin and reads the curried fields. That lineage is short, because the Title Singleton is spent only at supply changes, and the walk is the same trustless, full-node operation that NFT and DID wallets already perform to resolve a singleton, with every field verifiable against the on-chain commitment. There is thus no registry to consult and no trusted third party. The CATalog composition instead keeps identity in a separate registry entry keyed to the asset ID, whose answer a wallet must trust the registry to resolve. - **No per-asset registration cost.** A 1,000-card game is 1,000 registrations and 1,000 fees under the registry approach. Under Titled CAT each title is simply a singleton with no third-party registration step. - **Immutable by default, not by configuration.** CATalog's default metadata updater permits updating a CAT's name and ticker. Immutability requires deliberately selecting the immutable updater. A Titled CAT's identity is immutable by currying. -To be clear about what Titled CAT does *not* do: it does not solve curation, and it is not a replacement for a fungible-CAT registry in cases where mutable display metadata is appropriate (a utility token that expects to rebrand). For those, CAT2 plus a registry remains the right tool. Titled CAT and such a registry address different asset populations and are complementary. +Titled CAT does not solve curation, and it is not a replacement for a registry where mutable display metadata is appropriate (a utility token that expects to rebrand). For that, CAT2 plus a registry remains the right tool. + +### Curation via registries + +Making identity intrinsic does not make registries such as CATalog redundant. The proposed registry does two jobs: it stores identity data, and it curates and indexes assets. Titled CAT removes only the first need, because a wallet can read name, ticker, hashes, and creator DID straight from the chain. The second job remains valuable and is not something the primitive attempts. Verified-issuer lists, collection groupings, search, trending and discovery feeds, and human-curated "official" designations are real services, and they are better supplied by a registry or marketplace than baked into a coin. + +So Titled CAT and a registry compose rather than compete. Titled CAT provides a trustless identity substrate, and a registry like CATalog can index that substrate and add curation and discovery on top, annotating titles it has vetted without having to be the authoritative source of what a title is. This is consistent with the position taken throughout: paying to register basic identity should not be a precondition for an asset to state what it is, but curation and discovery are genuine services worth offering and worth paying for. ### Relationship to NFT1 @@ -156,7 +168,7 @@ Titled CAT is singleton-anchored and DID-rooted, so a natural question is whethe A Titled CAT puts one singleton around a whole *class* (the title) and holds balances as fungible Units, spending the singleton only at supply changes. NFT1 puts a singleton around every *item*, spent on every transfer, which is what lets each item carry distinct metadata and a DID-bound owner. A CAT Unit has no individual identity by construction: any two Units of a title are interchangeable and merge into one coin, so there is no per-Unit slot for distinct artwork or a distinct owner. Identity lives on the title, shared by every Unit. -This decides which standard fits. A 10,000-piece PFP collection of unique artworks needs a per-item identity anchor for each item, and the only anchor is the Title Singleton, so it requires 10,000 titles *plus* 10,000 single-Unit CATs. This is roughly twice the footprint of NFT1's 10,000 singletons, with the fungibility machinery serving no purpose. NFT1 is correct and cheaper. Storing the per-item metadata on the title does not help: the obstacle is not where metadata lives but that fungible Units cannot be individually addressed. The reasoning inverts for *interchangeable* items: a drop of one hundred identical copies of a card is one hundred singletons under NFT1, but one title and one hundred fungible Units under Titled CAT. The boundary is precisely individuation. Because Units are fungible, a Titled CAT cannot assign a per-copy serial number, a distinguishing "#7 of 100" that travels with one specific copy: any two Units merge indiscriminately, so there is nowhere for a serial to live. An edition of one hundred is one hundred *interchangeable* copies, not copies #1 through #100. The moment individual copies must be distinguished, whether by serial number, distinct artwork, or a per-copy owner, the asset has crossed back into NFT1's domain. +This decides which standard fits. A 10,000-piece PFP collection of unique artworks needs a per-item identity anchor, and the only anchor is the Title Singleton, so it requires 10,000 titles *plus* 10,000 single-Unit CATs, roughly twice the footprint of NFT1's 10,000 singletons with the fungibility machinery serving no purpose. NFT1 is correct and cheaper. Storing per-item metadata on the title does not help: the obstacle is not where metadata lives but that fungible Units cannot be individually addressed. The reasoning inverts for *interchangeable* items: one hundred identical copies of a card are one hundred singletons under NFT1, but one title and one hundred fungible Units under Titled CAT. The boundary is individuation. Because Units merge indiscriminately, a Titled CAT cannot assign a per-copy serial number, the "#7 of 100" that travels with one specific copy, so an edition of one hundred is one hundred *interchangeable* copies, not copies #1 through #100. The moment individual copies must be distinguished, by serial number, distinct artwork, or a per-copy owner, the asset has crossed back into NFT1's domain. Titled CAT is NFT1 turned inside out: NFT1 is native when items are distinct, Titled CAT when items are interchangeable within a class, including the editioned middle NFT1 serves awkwardly. @@ -351,10 +363,16 @@ The Title Singleton inner puzzle composes with the existing Singleton, CAT2, CHI Titled CAT does not make names unique, and it does not decide which issuer is legitimate. An attacker may mint a Titled CAT with a `name` and `ticker` identical to a genuine one. Mitigations are the same as for NFT1 collections: wallets should surface the `creator_did` prominently, and wallets and marketplaces should maintain reputation overlays (verified DIDs, allowlists, denylists). -### Title Singleton key compromise +### Title Singleton key compromise or loss An attacker controlling the Title Singleton key (or its DID) can mint additional Units up to `edition_cap` (or without bound if uncapped), prepend URIs, transfer title ownership, and close the mint. They cannot modify any immutable field, change royalty parameters, alter the creator DID, or revoke held Units. Issuers should set an explicit `edition_cap`, close the mint once the intended supply is reached, custody the controlling key in a vault/multisig/hardware wallet, and keep it separate from the revocation hidden-puzzle key for revocable titles. +Key *loss* is the opposite failure. With no controller, the title freezes in its current state (no mint, melt, mint-close, URI prepend, or transfer), while existing Units keep transferring normally because ordinary transfers never touch the singleton. For an already-closed mint this is benign and even makes the supply cap more credible, since not even the issuer can add to it. For an open or actively managed title it is a permanent loss of control, so issuers should custody the key durably and close the mint once issuance is complete. + +### Creator DID over time + +The curried `creator_did` is immutable, but the DID singleton it names is not frozen by it. That DID can be transferred, abandoned, or compromised over the asset's life. The binding therefore proves which DID issued the title at creation, not who controls that DID today, exactly as for an NFT1 collection's creator DID. Wallets and curators should treat the DID as a provenance anchor whose reputation is tracked over time, not as a permanent endorsement. + ### Royalty integrity and bypass For titles using the Fee Layer, royalty integrity rests on a two-link chain, and each link has a distinct failure mode. From 805790899438b02a3ff7d241bef7c1d9293d4f79 Mon Sep 17 00:00:00 2001 From: Evan Date: Mon, 25 May 2026 20:20:34 -0700 Subject: [PATCH 5/8] Address feedback and significantly reduce length --- CHIPs/chip-evanwinget-titled-cat.md | 277 ++++++++-------------------- 1 file changed, 79 insertions(+), 198 deletions(-) diff --git a/CHIPs/chip-evanwinget-titled-cat.md b/CHIPs/chip-evanwinget-titled-cat.md index b7c3a132..30c3f7b6 100644 --- a/CHIPs/chip-evanwinget-titled-cat.md +++ b/CHIPs/chip-evanwinget-titled-cat.md @@ -1,7 +1,7 @@ CHIP Number | TBD (to be assigned by Editor) :-------------|:---- Title | Titled CAT Standard -Description | A standard for CATs that carry immutable on-chain identity and provenance, spanning divisible tokens and indivisible editioned assets +Description | A standard attaching an immutable, on-chain metadata reference (name, ticker, content hashes, creator DID, and supply commitments) to a CAT. Author | [Evan Winget](https://github.com/EvanWinget) Editor | TBD Comments-URI | TBD @@ -16,172 +16,106 @@ Superseded-By | None ## Abstract -A **Titled CAT** is a Chia Asset Token (CAT) that carries a verifiable, immutable, on-chain *title*: a name, a ticker, content hashes, a creator DID, and supply commitments, bound to the token by construction. An NFT carries its identity on-chain (name, creator DID, content hash) while a CAT carries none, relying on off-chain indexers. Titled CAT closes this asymmetry, giving any CAT (divisible fungibles and indivisible editioned assets alike) the same immutable, DID-rooted on-chain identity an NFT has, without a registry. +A **Titled CAT** is a Chia Asset Token (CAT) with a **title**: an immutable, hash-committed, on-chain metadata reference (name, ticker, content hashes, an optional creator DID, and supply commitments) bound to the token by construction. -The standard is **additive and opt-in**. Titled CATs do not modify, deprecate, or compete with CAT2. An ordinary CAT remains the right choice for any token that wants mutable branding or no identity at all. Titled CAT introduces no new consensus rules, no new CLVM operators, and only one new puzzle: the **Title Singleton** inner puzzle which composes CAT2, the CHIP-40 `everything_with_singleton` TAIL, the CHIP-56 Fee Layer (for optional royalties), and the CHIP-38 revocation layer (for optional revocability). +A CAT already has an on-chain identity in its TAIL and the asset ID derived from it, but that identifier is opaque. The token's name, ticker, image, license, and creator DID all live off-chain, supplied by indexers and registries. Titled CAT closes this gap: it attaches a verifiable metadata reference to the CAT's existing on-chain identity with no registry. The standard is **additive and opt-in**, does not modify or deprecate CAT2, and introduces no new consensus rules or CLVM operators, only one new puzzle: the **Title Singleton** inner puzzle. -The Title Singleton is spent only when supply changes, and never on ordinary transfers. This means that a Titled CAT with no royalty layer costs exactly the same to transfer as a bare CAT2 while carrying full on-chain identity. - -A single `precision` field on the title spans the whole fungibility spectrum. **`precision = 1` is the indivisible case: one mojo is one whole token, displayed as an integer count.** This is the natural representation for trading cards, tickets, vouchers, and editioned collectibles. Larger powers of ten yield divisible, decimal-displayed tokens for stablecoins, fractional commodities, and other fungibles that want on-chain identity. One primitive, configured by a single field, replaces what would otherwise require CAT2 plus a registry plus a separate indivisible-token standard. +A single committed `precision` field fixes display across the fungibility spectrum. **`precision = 1` is the indivisible case: one mojo is one whole token, shown as an integer count**, suited to trading cards, tickets, and editioned collectibles, while larger powers of ten give divisible, decimal tokens for stablecoins and fractional commodities. ## Definitions Throughout this document: -- **Title**: The immutable on-chain identity record of a Titled CAT: name, ticker, precision, content hashes, optional creator DID, optional royalty configuration, optional revocability, and supply commitments. By analogy to a property *title*, it names the asset and records its provenance. -- **Title Singleton**: The on-chain singleton whose inner puzzle holds the Title and controls minting and melting of the token's Units via its associated TAIL. Its launcher ID is the asset's permanent identifier. It is spent only at mint, melt, mint-close, URI-append, and ownership transfer. It is not spent on ordinary Unit transfers. -- **Title ID**: A bech32m encoding of the Title Singleton's launcher ID, with the human-readable prefix `tcat`. -- **TAIL Asset ID**: The SHA-256 tree hash of the CHIP-40 `everything_with_singleton` TAIL curried to the Title Singleton. This is the CAT asset ID that CAT-aware tooling (wallets, DEXs) uses to identify the token's Units. -- **Unit**: The base, indivisible unit of a Titled CAT: one mojo of a CAT whose TAIL is bound to the Title Singleton. Units of the same Titled CAT are interchangeable. Holdings, mint/melt counts, and the supply counters are all denominated in Units. A wallet shows a Unit balance divided by `precision` as a whole-token amount. -- **precision**: The number of Units (mojos) that make up one whole displayed token, committed immutably in the Title. `precision = 1` means one Unit is one whole token, shown as an **indivisible** integer count. This is the recommended representation for trading cards, tickets, vouchers, and editioned collectibles. `precision ≥ 10` means a whole token is many Units and is shown **divisible**, with `log10(precision)` decimal places (e.g. `precision = 1000` gives three decimals, matching the CAT2 convention). `precision` SHOULD be a power of ten. -- **Holder**: A wallet or coin that currently controls one or more Units. -- **Issuer**: The person or entity that creates a Titled CAT. The Issuer's DID (when present) is curried into the Title Singleton at creation and is immutable. -- **Title Owner**: The current controller of the Title Singleton, authorized to mint, melt, close the mint, prepend URIs, and transfer the title. Control may move via `transfer_title` (the immutable `creator_did` binding does not change). -- **Edition Cap**: An optional maximum on the total number of Units that may ever be minted. Immutable once set at creation. -- **Mint-Closed Flag**: A boolean on the Title Singleton. Once flipped to true, no further Units may ever be minted. May never be flipped back. -- **Total Minted**: A monotonically increasing counter tracking the cumulative number of Units ever minted. Never decreases, even on melt. Total Minted is a commitment about issuance, not circulating supply. -- **Circulating Supply**: The number of Units currently in existence, equal to the token's total CAT mojo supply and observable directly from the chain. Equals `total_minted` minus the number of Units melted. -- **Must, required, shall / Must not, shall not / Should, recommended / Should not, not recommended / May**: These follow the same meanings as in CHIP-0005. +- **Title**: The immutable on-chain metadata reference of a Titled CAT (name, ticker, precision, content hashes, optional creator DID, optional royalty and revocation config, and supply commitments). By analogy to a property *title*, it names the asset and records its provenance. +- **Title Singleton**: The singleton whose inner puzzle holds the Title and authorizes minting and melting via the associated TAIL. Its launcher ID is the asset's permanent identifier. Spent only at mint, melt, mint-close, URI-append, and ownership transfer, never on ordinary Unit transfers. +- **Title ID**: A bech32m encoding of the launcher ID, prefix `tcat`. +- **TAIL Asset ID**: The tree hash of the CHIP-40 `everything_with_singleton` TAIL curried to the Title Singleton, the CAT asset ID by which tooling identifies the token's Units. +- **Unit**: The base indivisible unit, one mojo of the CAT. Units of a title are interchangeable, and all holdings and supply counters are denominated in Units. +- **precision**: Units per whole displayed token, committed immutably (defined under *Specification*). `precision = 1` is indivisible. +- **Holder**: A wallet or coin controlling one or more Units. +- **Issuer**: The creator of a Titled CAT. Its DID, when present, is curried at creation and immutable. +- **Title Owner**: The current controller of the Title Singleton (initially the Issuer), authorized to mint, melt, close the mint, prepend URIs, and transfer the title via `transfer_title`. +- **Total Minted / Circulating Supply**: `total_minted` is the monotonic cumulative count of Units ever minted (never falls, even on melt). Circulating Supply is the count currently in existence, equal to `total_minted` minus Units melted and observable on-chain. +- **Must, required, shall / Must not, shall not / Should, recommended / Should not, not recommended / May**: as in CHIP-0005. ## Motivation -Chia supports two token primitives with an asymmetry between them. NFT1 (CHIP-5) carries identity *on-chain*: an NFT commits its name, its creator DID, and a hash of its artwork into its own coin, immutably and verifiably. CAT2 carries *none* of this. A CAT is identified solely by its TAIL hash. - -This asymmetry is the problem Titled CAT solves: **assets across the fungibility spectrum deserve the same on-chain, immutable, DID-rooted identity that non-fungible assets already have.** - -### The CAT identity gap - -Because a CAT has no native identity, that identity must be supplied from outside the coin, and every option has a cost: -- **Impersonation.** Anyone can mint a CAT and call it "wUSDC.b" or "Spacebucks." Nothing at the protocol level distinguishes the genuine issuer's token from a counterfeit with the same name and logo. Users are protected only by off-chain allowlists maintained by each wallet and exchange. -- **Dependence on third parties.** To show a name, ticker, or logo for a CAT, a wallet must consult an off-chain indexer or a registry and trust its answer. The token itself cannot vouch for its own identity. -- **Registration friction.** Decentralized registries such as [CATalog (CHIP-55)](https://github.com/Yakuhito/chips/blob/xchandles/CHIPs/chip-0055.md) improve on bare indexers by committing content hashes on-chain, but they require a registration step and a fee per asset (a legitimate anti-DoS measure). For an issuer with many assets (a trading-card game with 1,000 cards has 1,000 distinct TAILs) that is a real, repeated cost to establish basic identity. -- **No protocol provenance.** There is no immutable, on-chain binding from a CAT to the DID that issued it. Provenance, where it exists, is again an off-chain claim. - -NFTs face none of this, because their identity is intrinsic. Titled CAT brings that property to the rest of the asset spectrum. Committing identity on-chain rather than to off-chain infrastructure also keeps the data permanent and decentralized while routing value to farmers through transaction fees. - -### Registries solve curation, not the primitive gap - -A registry solves two distinct problems: it can *store* identity data, and it can *curate* which assets are considered "official." - -Titled CAT makes only the first intrinsic, so a token no longer needs to be *registered* to establish what it is. It does not attempt curation: which DID is the legitimate issuer of a "wUSDC.b" remains an off-chain, venue-specific judgment, exactly as for NFT1 collections. Titled CAT removes the need to *pay to register identity* without removing the ecosystem's ability to curate trusted issuers. +A CAT is identified on-chain by its TAIL and the asset ID derived from it. That identifier is permanent and verifiable but opaque: it says nothing about what the token is called, what it represents, or who issued it. All of that lives off-chain. NFT1 (CHIP-5) shows the alternative, committing an NFT's name, creator DID, and content hash into its own coin. **The problem Titled CAT solves is that a CAT's metadata has no on-chain home bound to the asset.** -### One primitive across the fungibility spectrum +### The metadata gap -A *single* standard serves the entire spectrum of assets that want on-chain identity: +Because a CAT's metadata comes entirely from outside the coin, every option has a cost: -- **Fully fungible with identity**: stablecoins, wrapped assets, governance and utility tokens. The issuer wants a verifiable, immutable name/ticker and DID provenance, and typically no royalty. (Divisible, `precision ≥ 10`.) -- **Fractional claims**: tokenized commodities (gold by the gram), carbon credits, fractional real estate, streaming-royalty shares. The metadata describes the underlying asset. -- **Indivisible editioned assets**: trading cards, event tickets, coupons and loyalty rewards, music editions, proof-of-attendance tokens, in-game items at scale, redemption vouchers. The image and metadata are the asset's identity, the supply is finite, and royalties or revocability are often wanted. (Indivisible, `precision = 1`.) +- **Impersonation.** Anyone can mint a CAT and call it "wUSDC.b." Nothing at the protocol level separates the genuine issuer's token from a counterfeit, so users rely on off-chain allowlists. +- **Dependence on third parties.** To show a name or logo, a wallet must consult and trust an off-chain indexer or registry. The token cannot vouch for itself. +- **Registration friction.** Registries such as [CATalog (CHIP-55)](https://github.com/Yakuhito/chips/blob/xchandles/CHIPs/chip-0055.md) commit content hashes on-chain but require a registration step and a fee per asset. For an issuer with many assets (a 1,000-card game is 1,000 TAILs) that is a real, repeated cost. +- **No protocol provenance.** Nothing immutably binds a CAT to the DID that issued it. -The indivisible end of this range has strong cross-chain precedent. Ethereum's ERC-1155 (the Multi Token Standard), introduced by Enjin in 2017 and finalized in 2019, established the pattern of many interchangeable tokens per class with class-level identity, and saw broad adoption in blockchain gaming, ticketing, and tokenized real-world assets. Solana's Metaplex and Flow's Cadence resources offer comparable primitives. The consistent lesson is that "fungible within a class, distinct across classes" is a useful shape that neither a pure NFT nor a pure fungible token serves well. Titled CAT brings that shape to Chia *and* generalizes it: the same machinery that makes a trading card's identity verifiable makes a stablecoin's identity verifiable. +The same metadata reference serves the whole fungibility spectrum, from stablecoins and tokenized commodities to indivisible trading cards, tickets, and editioned collectibles, with a single `precision` field spanning the range. "Fungible within a class, distinct across classes" is well established elsewhere (notably Ethereum's ERC-1155), and Titled CAT brings it to Chia. ### 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. +Titled CAT needs no protocol changes. The non-royalty core uses only deployed pieces: CAT2, the CHIP-40 TAIL (Final, in production for Revocable CATs), the CHIP-38 revocation layer (Final), and the Singleton and Offer standards. The one new puzzle is the Title Singleton inner puzzle. The optional royalty path additionally relies on the CHIP-56 Fee Layer (open, PR #194). Composition is entirely at the puzzle-hash level, so no consensus or VM change is required. ## Backwards Compatibility Titled CAT introduces no breaking changes: it does not modify Chia's consensus, the CLVM, or any existing primitive. It is purely additive and opt-in, and neither replaces nor deprecates CAT2. -A wallet that does not implement Titled CAT recognition will see a Titled CAT's Units as ordinary CATs with a recognizable TAIL pattern (`everything_with_singleton` bound to a launcher ID). It will not display the title's name, ticker, precision, or artwork, and lacking the committed `precision` will fall back to its default CAT display. This is a strictly safe degradation: a non-Titled-aware wallet shows a generic CAT, never a misleading identity. +A wallet that does not implement Titled CAT recognition sees a Titled CAT's Units as ordinary CATs with a recognizable TAIL pattern. It will not show the title's name, ticker, or artwork, so it never displays a misleading name, only a generic CAT. It also will not read the committed `precision` and falls back to its own default, so for a title whose `precision` differs from that default a legacy wallet and a Titled-aware wallet can show different quantities for the same coins. That divergence is treated under Security (*Precision display divergence*). -**Alternatives considered.** The principal alternative is to assemble the same outcome from existing pieces: a plain CAT2, identity in a registry (CATalog), royalties via the CHIP-56 Fee Layer, and a wallet display flag. This composition is reasonable and is examined in detail in the Rationale. The short version is that it leaves identity *extrinsic* (a separate, registered, mutable-by-default record keyed to the asset) where Titled CAT makes it *intrinsic and immutable*. - -A second alternative is extending CAT2 itself to carry mandatory on-chain identity. This was rejected because it would force identity machinery onto every CAT, including the many that neither want nor need it, and would constitute a breaking change to the base fungible primitive. Making identity an opt-in standard layered atop an unmodified CAT2 avoids both problems. +Two alternatives are examined in the Rationale: assembling the same outcome from a plain CAT2 plus a registry (which leaves metadata extrinsic and mutable-by-default), and extending CAT2 itself to carry mandatory identity (rejected as a breaking change that would burden every CAT). ## Rationale -### On-chain Identity - -On-chain identity matters for a CAT for the same reasons it matters for an NFT. A hash-committed identity lets any party verify, without trusting an indexer or registry, that the artwork and metadata shown are what the issuer committed to, and an immutable creator-DID binding lets any party trace the asset to its issuer and detect impersonation. These guarantees are as valuable for a stablecoin or a tokenized commodity as for a trading card, arguably more so given the sums involved. - ### Title Singleton plus a CAT -The design decomposes cleanly along Chia's coin-set model: - -- The **immutable identity and supply discipline**: name, ticker, precision, content hashes, creator DID, royalty configuration, edition cap, mint-closed flag, mint authorization lives once, in a single on-chain object. -- The **fungible holdings**: who holds how many Units, and how Units transfer, split, consolidate, and participate in Offers are what CAT2 already represents. -- The Title Singleton and the token's CAT are bound by the CHIP-40 `everything_with_singleton` TAIL, which commits the Title Singleton's launcher ID. This binding is the heart of the design: a Unit's TAIL Asset ID is derivable from the launcher ID, and the only object that can authorize a Unit's existence is its Title Singleton. Identity is therefore *intrinsic*, and there is no separate registry record and no "which object is the canonical identity holder?" question. - -The efficiency consequence: the Title Singleton participates only in mint and melt. A Titled CAT with no royalty layer has the *same per-transfer CLVM cost as a bare CAT2*, so on-chain identity comes at no extra cost for everyday use. - -### Immutable identity - -Immutability is central to the value proposition and is much of what distinguishes Titled CAT from a registry: - -- **Asymmetric failure modes.** A hostile or careless change to an asset's identity *after* holders have acquired it is a far worse failure than the inability to fix a typo. A holder cannot defend against a rename or a re-pointed artwork hash, but an issuer can avoid typos by being careful once, at creation. -- **Verify-once trust.** Immutability lets a wallet or buyer verify identity from the Title ID a single time and trust it permanently. Optional mutability would force every consumer to ask "has this changed, and who may change it?" which adds an attack surface. -- **The rebrand case does not require mutability.** An issuer who genuinely needs to change identity mints a new Titled CAT and offers a melt-and-mint migration. +The design splits along Chia's coin-set model. Immutable metadata and supply discipline (name, ticker, precision, hashes, creator DID, royalty config, edition cap, mint state) live once, in the Title Singleton. Fungible holdings (who holds how many Units, and how they transfer and trade) are what CAT2 already represents. The CHIP-40 `everything_with_singleton` TAIL binds the two by committing the Title Singleton's launcher ID, so a Unit's Asset ID derives from that launcher ID and only the Title Singleton can authorize a Unit's existence. Metadata is therefore intrinsic, with no separate registry record and no canonical-holder ambiguity. Because the singleton participates only in mint and melt, a title with no royalty layer has the same per-transfer cost as a bare CAT2. -"Immutable" is precise here. The *commitments* freeze: name, ticker, precision, content hashes, creator DID, royalty configuration, revocability, and edition cap may never change. Two things still move, in tightly constrained ways: +### Argument for immutability -- **URI lists are prependable**: an owner may add new locations for the same hash-committed content (e.g., a fallback gateway), latest-first, but may never alter or remove existing entries. This is the NFT1 pattern. -- **Supply state is one-way**: `total_minted` only increases, and `mint_closed` only flips from false to true. +A title's commitments are frozen by currying: name, ticker, precision, hashes, creator DID, royalty config, revocability, and edition cap can never change. This is deliberate and is most of what distinguishes a title from a registry entry. -Issuers who want mutable branding are well served by plain CAT2 plus a registry, and should use it. The principled split is: **immutable identity-bearing CAT (Titled CAT) versus mutable registry-backed CAT2.** +A coherent alternative is to make immutability optional and verifiable, letting any field be mutable and letting consumers that care check whether a given field is frozen. This standard chooses against it for two reasons. First, the failure modes are asymmetric: a hostile change to metadata after holders acquire the asset is far worse than an uncorrectable typo. Second, mandatory immutability lets a wallet or buyer verify a title once and trust it permanently. Per-field optional immutability would instead force every consumer to ask, for every field it relies on, "is this frozen, and if not, who can change it and have they?" -### Mutability solutions - -Immutability needs an escape hatch for the case where identity genuinely must change, such as a real rebrand or a corrected content hash. That hatch is migration by melt-and-mint, and it is what makes immutability acceptable. The issuer mints a new Titled CAT carrying the corrected identity, closes the old title's mint, and offers holders a swap: a holder melts old Units with `melt_units` and receives an equal count of the new title's Units. +URI lists are prependable (an owner may add new locations for the same hash-committed content, latest-first, never altering or removing existing entries, the NFT1 pattern), and supply state moves one way (`total_minted` only rises, `mint_closed` only flips true). When metadata genuinely must change, such as a real rebrand, the escape hatch is melt-and-mint migration. ### DID-rooted provenance -A curried creator DID gives a Titled CAT the same provenance guarantee NFT1 provides: any Unit traces cryptographically to the issuer's DID. It does not make names unique, but it lets venues and wallets recognize the genuine issuer's DID and disregard impostors, which is exactly how NFT1 collections are authenticated today. This approach is expected to make curation of assets more straightforward, as one may choose to curate a list of verified DIDs rather than the assets themselves. +A curried creator DID gives a Titled CAT the provenance guarantee NFT1 provides: any Unit traces cryptographically to the issuer's DID. It does not make names unique, but it lets venues and wallets recognize the genuine issuer and disregard impostors, exactly as NFT1 collections are authenticated today. Curation can then target a list of verified DIDs rather than individual assets. ### A single `precision` field instead of separate standards -The base unit is always one mojo, and `precision` only states how many mojos constitute one displayed whole token, exactly as CAT2's 1000-mojo convention does. Because identity and divisibility are orthogonal, there is no reason to build two standards. A single `precision` commitment lets the same Title Singleton, TAIL, and layer stack serve an indivisible trading card (`precision = 1`) and a milligram-divisible gold token (`precision = 1000`) alike. - -`precision = 1` is used for the indivisible, integer-displayed case. It has distinct enough semantics to warrant a dedicated wallet display rule. Indivisibility is guaranteed mechanically (a coin cannot be smaller than one mojo), and wallets MUST display an integer count, never a fraction. This safety property is precisely why the indivisible case gets its own display rule rather than being treated as just another `precision` value. +The base unit is always one mojo, and `precision` states how many mojos make one displayed whole token, exactly as CAT2's 1000-mojo convention does. Because metadata and divisibility are orthogonal, one standard suffices: the same Title Singleton, TAIL, and layer stack serve an indivisible trading card (`precision = 1`) and a milligram-divisible gold token (`precision = 1000`). Committing the value on-chain also removes the wallet-default disagreement that has made CAT2 amounts ambiguous (see *Precision display divergence*). `precision = 1` is guaranteed indivisible mechanically, since a coin cannot be smaller than one mojo, and wallets MUST display it as an integer count. ### Optional fee layer and revocation layer -Royalties and revocability are wanted by some Titled CATs and not others, and forcing either onto all would impose cost and complexity on assets that do not need it. Making both optional, reused-as-is layered components keeps the common case (a Titled CAT with neither) as cheap as a bare CAT2 while letting richer cases compose exactly the layers they need. Royalties in particular are oriented to the editioned, indivisible case. Divisible fungibles generally want identity without a per-trade fee, so the Specification recommends they omit the Fee Layer (see *Royalty configuration*). - -### Regulated and stablecoin issuers - -A regulated fungible token such as a fiat-backed stablecoin typically wants three properties at once: verifiable issuer identity, control over who may hold the asset, and the ability to freeze or claw back. Titled CAT supplies identity intrinsically and composes the other two from existing layers. Holding control reuses the deployed Credential Restricted CAT (CR-CAT) pattern, where a credential layer gates each transfer on the receiver proving an on-chain Verifiable Credential from an authorized provider, and claw-back reuses the CHIP-38 revocation layer. Both add to the inner stack as the Fee and revocation layers do (see *Unit layer stack*), with the revocation layer outside the credential layer by default so an issuer's claw-back path stays independent of the credential check while ordinary transfers satisfy both. +Royalties and revocability are wanted by some titles and not others, so both are optional layered components rather than built in. This keeps the common case (neither) as cheap as a bare CAT2 while letting richer cases compose only what they need. Royalties are oriented to the editioned, indivisible case. Divisible fungibles generally want identity without a per-trade fee, so the Specification recommends they omit the Fee Layer (see *Royalty configuration*). -### Why not CAT2 + CATalog + Fee CAT + precision-1? +### Why not CAT2 plus a registry? -This is the most important alternative. A plain CAT2 with `precision = 1`, identity registered in CATalog, royalties via the CHIP-56 Fee Layer, and a CATalog display flag is reasonable and reproduces much of the outcome. The distinction is where identity lives and what establishing it costs: +The closest alternative is a plain CAT2 with metadata in a registry such as CATalog, royalties via the Fee Layer, and a display flag. It reproduces much of the outcome but differs in where metadata lives, what it costs, and whether it can change: -- **Intrinsic versus looked-up.** A Titled CAT's identity *is* its TAIL, bound to the Title Singleton by construction, with no canonical-holder ambiguity. A wallet reads it by resolving the one object the TAIL already commits to: it walks the Title Singleton's lineage to the current coin and reads the curried fields. That lineage is short, because the Title Singleton is spent only at supply changes, and the walk is the same trustless, full-node operation that NFT and DID wallets already perform to resolve a singleton, with every field verifiable against the on-chain commitment. There is thus no registry to consult and no trusted third party. The CATalog composition instead keeps identity in a separate registry entry keyed to the asset ID, whose answer a wallet must trust the registry to resolve. -- **No per-asset registration cost.** A 1,000-card game is 1,000 registrations and 1,000 fees under the registry approach. Under Titled CAT each title is simply a singleton with no third-party registration step. -- **Immutable by default, not by configuration.** CATalog's default metadata updater permits updating a CAT's name and ticker. Immutability requires deliberately selecting the immutable updater. A Titled CAT's identity is immutable by currying. +- **Intrinsic versus looked-up.** A title *is* the CAT's TAIL binding, read by walking the one Title Singleton the TAIL commits to, the same trustless full-node operation NFT and DID wallets already perform, with every field verifiable on-chain. The registry instead keeps metadata in a separate entry a wallet must trust the registry to resolve. +- **No per-asset registration cost.** A 1,000-card game is 1,000 registrations and fees under a registry. Under Titled CAT each title is a singleton the issuer creates to mint anyway. +- **Immutable by default.** CATalog's default updater permits changing name and ticker. A title's metadata is immutable by currying. -Titled CAT does not solve curation, and it is not a replacement for a registry where mutable display metadata is appropriate (a utility token that expects to rebrand). For that, CAT2 plus a registry remains the right tool. - -### Curation via registries - -Making identity intrinsic does not make registries such as CATalog redundant. The proposed registry does two jobs: it stores identity data, and it curates and indexes assets. Titled CAT removes only the first need, because a wallet can read name, ticker, hashes, and creator DID straight from the chain. The second job remains valuable and is not something the primitive attempts. Verified-issuer lists, collection groupings, search, trending and discovery feeds, and human-curated "official" designations are real services, and they are better supplied by a registry or marketplace than baked into a coin. - -So Titled CAT and a registry compose rather than compete. Titled CAT provides a trustless identity substrate, and a registry like CATalog can index that substrate and add curation and discovery on top, annotating titles it has vetted without having to be the authoritative source of what a title is. This is consistent with the position taken throughout: paying to register basic identity should not be a precondition for an asset to state what it is, but curation and discovery are genuine services worth offering and worth paying for. +This does not make registries redundant. Curation, verified-issuer lists, search, and discovery remain valuable and are better supplied by a registry than baked into a coin. The two compose: Titled CAT is a trustless metadata substrate a registry like CATalog can index and curate on top of. For a token that expects to rebrand, CAT2 plus a registry remains the right tool. ### Relationship to NFT1 -Titled CAT is singleton-anchored and DID-rooted, so a natural question is whether it subsumes NFT1: could an NFT simply be a Titled CAT minted with an edition cap of one? For a *single* unique asset (a one-of-one artwork, a deed) the answer is essentially yes, and a Titled CAT with `edition_cap = 1`, `mint_closed`, and a `creator_did` carries the same intrinsic, immutable, DID-rooted identity an NFT does. But NFT1 is not superseded, because the two standards anchor identity at different granularities, and that difference is architectural rather than incidental. - -A Titled CAT puts one singleton around a whole *class* (the title) and holds balances as fungible Units, spending the singleton only at supply changes. NFT1 puts a singleton around every *item*, spent on every transfer, which is what lets each item carry distinct metadata and a DID-bound owner. A CAT Unit has no individual identity by construction: any two Units of a title are interchangeable and merge into one coin, so there is no per-Unit slot for distinct artwork or a distinct owner. Identity lives on the title, shared by every Unit. +Titled CAT is singleton-anchored and DID-rooted, so it is fair to ask whether it subsumes NFT1. **It does not.** It is tempting to call an NFT a Titled CAT with `edition_cap = 1`, but even the 1-of-1 case is not a drop-in NFT: making a fungible Unit behave like a single item takes extra machinery (a `p2_singleton`-style check that the coin carries the right TAIL, supplied with the launcher ID, that the edition cap is one, and that the amount is exactly one). Such a title is a metadata equivalent, not a behavioral replacement. -This decides which standard fits. A 10,000-piece PFP collection of unique artworks needs a per-item identity anchor, and the only anchor is the Title Singleton, so it requires 10,000 titles *plus* 10,000 single-Unit CATs, roughly twice the footprint of NFT1's 10,000 singletons with the fungibility machinery serving no purpose. NFT1 is correct and cheaper. Storing per-item metadata on the title does not help: the obstacle is not where metadata lives but that fungible Units cannot be individually addressed. The reasoning inverts for *interchangeable* items: one hundred identical copies of a card are one hundred singletons under NFT1, but one title and one hundred fungible Units under Titled CAT. The boundary is individuation. Because Units merge indiscriminately, a Titled CAT cannot assign a per-copy serial number, the "#7 of 100" that travels with one specific copy, so an edition of one hundred is one hundred *interchangeable* copies, not copies #1 through #100. The moment individual copies must be distinguished, by serial number, distinct artwork, or a per-copy owner, the asset has crossed back into NFT1's domain. +The deeper difference is granularity. A title puts one singleton around a whole *class* and holds balances as fungible Units, spent only at supply changes. NFT1 puts a singleton around every *item*, spent on every transfer, which is what lets each item carry distinct metadata and a DID-bound owner. Because any two Units merge into one coin, there is no per-Unit slot for distinct artwork, a serial number, or an owner. So a collection of unique artworks belongs in NFT1, while 100 identical copies of a card are one title and 100 interchangeable Units rather than 100 singletons. The boundary is individuation: once copies must be distinguished, the asset is in NFT1's domain. DID ownership follows the same line, supported for the *title* but not each *holding*, since a per-Unit owner DID would spend on every transfer and break fungibility. -Titled CAT is NFT1 turned inside out: NFT1 is native when items are distinct, Titled CAT when items are interchangeable within a class, including the editioned middle NFT1 serves awkwardly. - -DID ownership follows the same line. Titled CAT supports DID ownership of the *title*, but deliberately not of each *holding*. Binding an owner DID to every Unit would have to be spent on every transfer, forfeiting the bare-CAT2 transfer cost, and would make Units non-fungible (a Unit owned by one DID could no longer merge with another's). Per-holding DID ownership therefore stays with NFT1, while Titled CAT provides clean collection-level and issuer-level provenance. - -The partition is clean and complementary: **NFT1 for assets whose items are individually distinct or individually DID-owned, and Titled CAT for assets whose items share a class identity and are interchangeable within it**, across the spectrum from divisible fungibles to indivisible editioned collectibles. +Part of this asymmetry is an NFT-side artifact, not a CAT deficiency: singletons were built for pooling and so allow only one of a thing, and a future where one mints N items under a single asset ID that must remain N coins would suit interchangeable cards and would itself want a class-level metadata reference like a title. ### Why scope this to the primitive alone? -This CHIP defines the primitive only. Two companions are anticipated and should be developed separately rather than folded in here: - -- **Titled CAT Off-Chain Metadata Format** (Process / Tooling): A JSON schema for the document referenced by `metadata_uri_list`, with fields spanning fungible tokens, fractional claims, and indivisible editioned assets. Analogous to CHIP-7 for NFT1. (The existing metadata draft generalizes directly into this companion.) -- **Titled CAT Collections** (Informational / Guideline): Conventions for grouping multiple titles into a collection (a trading-card set, a family of tokenized commodities, a season-ticket bundle). +This CHIP defines the primitive only. Two companions should be developed separately: a **Titled CAT Off-Chain Metadata Format** (a JSON schema for the `metadata_uri_list` document, analogous to CHIP-7), and **Titled CAT Collections** (conventions for grouping titles into a set or family). ## Specification @@ -232,71 +166,42 @@ The Fee Layer is oriented to the indivisible, editioned case (`precision = 1`), - **`total_minted`**: Unsigned integer, the cumulative count of Units ever minted. Strictly monotonically increasing. Melts reduce Circulating Supply but not `total_minted`. - **`mint_closed`**: Boolean. When `true`, no further mints are permitted, ever. May be flipped from `false` to `true` by the Title Owner. -Wallets and explorers can display supply state in plain language: - -| `edition_cap` | `mint_closed` | Display | -| ------------- | ------------- | --------------------------------------------- | -| Set | false | `Supply: N / cap C (mint open)` | -| Set | true | `Supply: N final (capped at C, mint closed)` | -| Not set | false | `Supply: N (uncapped, mint open)` | -| Not set | true | `Supply: N final (mint closed)` | - -where `N` is Circulating Supply and `C` is the `edition_cap`, both in Units and shown divided by the title's `precision`. +Wallets and explorers derive a plain-language supply state from `edition_cap` and `mint_closed` (open versus final, capped versus uncapped), with counts shown in Units divided by the title's `precision`. #### Title Singleton inner puzzle actions The inner puzzle accepts the following spend actions, identified by a selector in the solution. - **`mint_units(count, target_puzzle_hash)`**: Authorizes the TAIL to mint `count` Units (i.e., `count` mojos) and send them to `target_puzzle_hash` wrapped in the canonical Unit layer stack. The action derives the canonical Unit puzzle hash from the title's own immutable parameters (the TAIL Asset ID, the declared royalty and revocation layers, and `target_puzzle_hash`) and constrains issuance to coins bearing exactly that puzzle hash, so it cannot authorize a Unit assembled from a non-canonical stack (see *Mint-time stack binding* below). Requires `mint_closed == false` and, if `edition_cap` is set, `total_minted + count ≤ edition_cap`. Updates `total_minted` in the recreated singleton. -- **`melt_units(count)`**: Authorizes the TAIL to melt (burn) `count` Units presented for melting in the same spend bundle. Because the `everything_with_singleton` TAIL requires the Title Singleton to authorize every melt, *and* melting any CAT requires control of the Units being melted, neither the Holder alone nor the Issuer alone can destroy a Unit: melting requires both. This suits issuer-driven redemption (a ticket melted at venue scan) and retirement flows (a carbon credit retired on use), while preventing an Issuer from unilaterally burning a Holder's Units. Does not decrease `total_minted`. Circulating Supply decreases as the burned mojos leave the CAT supply. Titles that wish to forbid melting may omit this action. +- **`melt_units(count)`**: Authorizes the TAIL to melt `count` Units presented in the same spend bundle. Melting requires both Title Singleton authorization and control of the Units, so neither Holder nor Issuer alone can destroy a Unit. This suits issuer-driven redemption (a ticket melted at venue scan, a carbon credit retired on use) while preventing an Issuer from unilaterally burning a Holder's Units. Does not decrease `total_minted`. Circulating Supply falls as the burned mojos leave the CAT supply. Titles that forbid melting omit this action. - **`close_mint()`**: Sets `mint_closed` to `true`. Permanently disables further minting. - **`add_uri(key, uri)`**: Prepends a URI to one of the three URI lists (`key` ∈ {`data`, `metadata`, `license`}). Does not modify any hash commitment. - **`transfer_title(new_owner_p2_puzzle_hash, optional_new_did)`**: Transfers Title Singleton ownership. If the title has a `creator_did`, the spend follows the same DID-aware transfer pattern as NFT1. -- **`update_inner_puzzle(new_inner_puzzle_hash)`** *(optional)*: If included, allows swapping the inner puzzle for a published variant that preserves all immutable curried values, enforced by the inner puzzle itself. Titles that do not need upgradability should omit this action entirely. Wallets should treat any inner puzzle hash not on the canonical-variants list with caution. ### Unit layer stack -Each Unit is one mojo of a CAT2 coin whose TAIL is `everything_with_singleton` (CHIP-40), curried to the Title Singleton via the singleton module hash, the singleton struct (which commits the launcher ID `L`), and a nonce. The puzzle stack is built from the optional layers the title declares: - -Minimal (no royalties, no revocation): +Each Unit is one mojo of a CAT2 coin whose TAIL is `everything_with_singleton` (CHIP-40), curried to the Title Singleton via the singleton module hash and the singleton struct (committing launcher ID `L`). CHIP-40's `NONCE` is fixed to zero, since each title has its own dedicated singleton and does not need the one-singleton-many-CATs case the nonce exists for. The Unit's Asset ID is therefore a deterministic function of `L` alone. The optional Fee and revocation layers, when the title declares them, nest inside: ``` ├ CAT outer layer (cat_v2) ├── TAIL (everything_with_singleton, bound to Title Singleton L) -├──── p2 puzzle (holder's standard transaction puzzle) +├──── Fee Layer (CHIP-56, present only if royalties) +├────── Revocation Layer (CHIP-38, present only if revocable) +├──────── p2 puzzle (holder's standard transaction puzzle) ``` -With royalties: +Layers a title does not declare are omitted, so a minimal title is CAT/TAIL/p2 and a revocable royalty-free title places the revocation layer directly under the TAIL. The parameters curried into every Unit must match the values committed on the Title Singleton, giving wallets a complete verification path: from the Title ID, derive the expected stack and Unit puzzle hash, then check a candidate coin against it. -``` -├ CAT outer layer (cat_v2) -├── TAIL (everything_with_singleton, bound to Title Singleton L) -├──── Fee Layer (CHIP-56, curried with the title's royalty parameters) -├────── p2 puzzle -``` - -With royalties and revocation: +**Mint-time stack binding.** A Unit's Asset ID is the hash of the TAIL alone, identical whether or not the optional layers are present, since those layers live beneath the CAT layer. Nothing at the CAT layer can distinguish a canonical Unit from one assembled with a missing or altered layer. Only the Title Singleton's `mint_units` action can: it recomputes the canonical Unit puzzle hash `H` from the title's immutable parameters and authorizes issuance only for created coins whose puzzle hash equals `H`. Because the `everything_with_singleton` TAIL delegates all issuance authorization to the Title Singleton, a coin minted with any other stack is never authorized and is not a Unit. The exact wiring (a committed announcement each issued coin asserts, or a direct assertion over created coins) is fixed by the reference inner puzzle. This derive-and-constrain step is the most security-critical code in the standard. -``` -├ CAT outer layer (cat_v2) -├── TAIL (everything_with_singleton, bound to Title Singleton L) -├──── Fee Layer (CHIP-56, ... has_hidden_revoke_layer: true, allow_revoke_fee_bypass: true) -├────── Revocation Layer (CHIP-38, curried with the title's hidden_puzzle_hash) -├──────── p2 puzzle -``` - -Revocation without royalties places the revocation layer directly under the CAT layer. The layer parameters curried into every Unit must match exactly the values committed on the Title Singleton. This gives wallets a complete verification path: from the Title ID, derive the expected stack and the expected Unit puzzle hash, and given a coin claimed to be a Unit, verify the puzzle hash matches. - -**Mint-time stack binding.** A Unit's CAT Asset ID is the hash of the TAIL alone, so it is identical whether or not the optional Fee and revocation layers are present: those layers live in the inner puzzle, beneath the CAT layer. Nothing at the CAT layer can therefore distinguish a canonical Unit from one assembled with a missing or altered layer. The Title Singleton's `mint_units` action is the only thing that can, and it is the linchpin of the verifiable-stack guarantee. The action recomputes the canonical Unit puzzle hash `H` (the CAT layer curried with the TAIL Asset ID, wrapping the title's declared Fee and revocation layers and the holder's `p2` puzzle) from the title's immutable parameters, and authorizes issuance only for created coins whose puzzle hash equals `H`. Because the `everything_with_singleton` TAIL delegates all issuance authorization to the Title Singleton, a coin minted with any other stack is never authorized and is not a Unit. The exact condition wiring by which the singleton scopes its authorization to `H` (a committed announcement that each issued coin's spend must assert, or a direct assertion over the created coins) is fixed by the reference inner puzzle against the CHIP-40 authorization interface. This single derive-and-constrain step is the most security-critical code in the standard and the focus of reference-implementation review. - -**Persistence across transfers.** Mint-time binding establishes a Unit's stack. The Fee Layer, when present, must preserve it. Titled CAT relies on the CHIP-56 Fee Layer re-wrapping itself on every spend, including ordinary non-Offer transfers, and rejecting any spend that would drop it. A Fee Layer that permitted a plain transfer to settle to a bare `p2` puzzle would let a holder strip the layer and produce a royalty-free coin that shares the title's CAT Asset ID. The royalty-stripping consequences are treated under Security. +**Persistence across transfers.** Mint-time binding establishes a Unit's stack. The Fee Layer, when present, must preserve it: Titled CAT relies on the CHIP-56 Fee Layer re-wrapping itself on every spend, including ordinary transfers, and rejecting any spend that drops it. A Fee Layer that let a plain transfer settle to a bare `p2` puzzle would let a holder strip the layer and produce a royalty-free coin sharing the title's Asset ID (see Security). ### Precision and display - **Indivisible (`precision = 1`).** One Unit is one whole token. Wallets display an integer count, never decimals. - **Divisible (`precision ≥ 10`).** A whole token is `precision` Units. Wallets display the Unit balance divided by `precision`, with `log10(precision)` decimal places. -Both cases share the same Title Singleton, TAIL, and Unit-stack mechanics. They differ only in the committed `precision` and the resulting wallet display rule. +Both share the same Title Singleton, TAIL, and Unit-stack mechanics, differing only in the committed `precision` and the display rule. ### Wallet recognition and display @@ -308,6 +213,18 @@ A wallet implementing this standard shall recognize a CAT coin as a Titled CAT U When recognized, the wallet shall display the holding using the title's `name` and `ticker`, sourced from the Title Singleton, formatted at the title's `precision`. Wallets should verify `data_hash` against fetched content before rendering imagery, should surface the `creator_did` when present, and should display royalty configuration and revocability before any Offer involving Units is accepted. +### Discovering a title from a Unit + +A wallet reads a coin's Asset ID cheaply from its parent's puzzle reveal, but not the launcher ID `L`. The Asset ID is the hash of the TAIL curried with `L`, and the TAIL reveal appears on-chain only at mint and melt, so recovering `L` from a transferred coin (the Alice-sends-Bob case) can otherwise require walking the lineage back to a mint. + +This is a performance problem, not a trust one. Because the Asset ID is a deterministic hash of `L`, any candidate `L` is self-verifying: a wallet recomputes the hash and checks it against the coin, so a memo, an index, or a peer can all supply `L` untrusted. Accordingly: + +- **Hint on mint and on transfer.** `mint_units` SHOULD hint each created coin with `L` (a memo), and a Titled-aware wallet SHOULD carry that hint forward when it sends Units, so an ordinary transfer to a Titled-aware recipient stays a direct lookup. This is a convention, not puzzle-enforced, since enforcing it would add a per-transfer layer and cost. +- **Resolve once, cache.** A wallet needs `L` for a given Asset ID only once and may cache it permanently, since the cached value re-verifies against the Asset ID. The cost is one-time per title, not per transfer. +- **Fallback.** Receiving Units with no hint (for example from a non-aware sender), a wallet recovers `L` by the lineage walk or from an index, both trustless, then caches. If `L` cannot be resolved at all, the Unit degrades safely to a generic CAT. + +A wallet MAY also subscribe to the Title Singleton's launcher coin for live metadata and supply updates, but a Titled CAT does not require subscription by default. + ### Offer integration Offers involving Titled CAT Units that carry a Fee Layer follow the CHIP-56 Offer integration pattern unchanged: the maker's wallet computes the royalty per trade price from the title's parameters, includes royalty settlement payments in the bundle, injects `SetCatTradeContext(trade_nonce, trade_prices)` into each Unit lock-leg spend, and the taker's wallet must include the royalty payments to complete the Offer. Units with no Fee Layer trade as ordinary CATs. Per-Offer royalty cost is bounded per title regardless of Unit quantity. @@ -316,34 +233,16 @@ Offers involving Titled CAT Units that carry a Fee Layer follow the CHIP-56 Offe Wallets may expose the following RPCs: -- **`titled_cat_create`**: Create a Title Singleton and optionally mint an initial batch. Parameters include `name`, `ticker`, `precision`, the three URI/hash sets, optional `royalty_*`, optional `revocable`/`hidden_puzzle_hash`, optional `edition_cap`, optional `initial_mint_count`, optional `did_id`, `target_address`, and `fee`. Returns `title_id` (`tcat…`), `title_singleton_coin_id`, `tail_asset_id`, and transaction info. -- **`titled_cat_mint`**: Mint additional Units. Parameters: `title_id`, `count`, `target_address`, optional `fee`. -- **`titled_cat_melt`**: Melt Units. Parameters: `title_id`, `count`, optional `fee`. Requires both Title Singleton authorization and control of the Units. The title must expose `melt_units`. -- **`titled_cat_close_mint`**: Permanently disable minting. Parameters: `title_id`, optional `fee`. -- **`titled_cat_add_uri`**: Prepend a URI. Parameters: `title_id`, `key`, `uri`, optional `fee`. -- **`titled_cat_transfer`**: Transfer Units to an address. Parameters: `title_id`, `amount`, `target_address`, optional `trade_price`, optional `fee`. -- **`titled_cat_get_info`**: Return a title's on-chain state (all curried fields, `total_minted`, `mint_closed`, derived Circulating Supply). Parameters: `title_id`. -- **`titled_cat_get_balances`**: Return the wallet's holdings aggregated per title. Parameters: optional `wallet_id`. -- **`titled_cat_revoke`** *(revocable titles only)*: Revoke specified Units. Parameters: `title_id`, `coin_ids[]`, `destination_puzzle_hash`, optional `fee`. +- **`titled_cat_create`**: Create a title and optionally mint an initial batch (`name`, `ticker`, `precision`, the three URI/hash sets, optional `royalty_*`, `revocable`/`hidden_puzzle_hash`, `edition_cap`, `initial_mint_count`, `did_id`, `target_address`, `fee`). Returns `title_id`, `title_singleton_coin_id`, `tail_asset_id`. +- **`titled_cat_mint`** / **`_melt`** / **`_transfer`**: Mint, melt, or transfer Units (`title_id`, `count` or `amount`, `target_address`, optional `trade_price`/`fee`). Melt requires both Title Singleton authorization and control of the Units. +- **`titled_cat_close_mint`** / **`_add_uri`**: Close the mint, or prepend a URI (`title_id`, `key`, `uri`). +- **`titled_cat_get_info`** / **`_get_balances`**: Read a title's on-chain state, or the wallet's holdings aggregated per title. +- **`titled_cat_revoke`** *(revocable titles only)*: Revoke specified Units (`title_id`, `coin_ids[]`, `destination_puzzle_hash`). ## Test Cases -Test cases will be added to `assets/chip-/tests/` and will cover, at minimum: - -- Title creation across the precision range and option combinations. Indivisible (`precision = 1`) and divisible (`precision ≥ 10`), with and without DID, royalties, edition cap, and revocability. -- Verification that Unit puzzle hashes derived from the title's curried fields match the actual on-chain Units, for each layer-stack variant. -- Initial mint and subsequent mints respecting and exceeding the edition cap (must fail when exceeding). Minting after `close_mint` (must fail). -- Melting via `melt_units`: Circulating Supply decreases while `total_minted` is unchanged. Melt without Title Singleton authorization (must fail). Melt without control of the Units (must fail). -- Ordinary transfers, splits, and consolidations of Units. -- Verification that a minimal (no-Fee-Layer) Titled CAT transfer has the same structure and per-transfer cost as a bare CAT2 transfer. -- Decimal display correctness across `precision` values. Assurance that the indivisible case (`precision = 1`) never produces a fractional display. -- Offer settlement with royalties correctly enforced (CHIP-56), underpaid royalty (must fail), CAT-denominated trades, multiple titles in one bundle, and a Titled CAT alongside an NFT1 royalty (all must settle). -- Title ownership transfer between DIDs. -- URI prepend on each list. Attempted modification or removal of existing URIs (must fail). -- Attempted modification of any immutable field: name, ticker, precision, hashes, royalty parameters, revocability, edition cap, creator DID (all must fail). -- Revocable titles: hidden-puzzle revocation succeeds. Normal transfers continue to work. Revocation by a non-controller fails. -- A non-Titled-aware wallet displays Units as ordinary CATs with the TAIL asset ID (no scam vector introduced by the standard's existence). +Detailed test cases will ship with the reference implementation in `assets/chip-/tests/`. At minimum they will cover title creation across the precision range and option combinations, derived Unit puzzle hashes matching on-chain Units for each layer-stack variant, mint and melt rules (edition cap, `close_mint`, and the dual-authorization melt), ordinary transfers matching a bare CAT2 in cost, display correctness across `precision`, royalty-enforced Offer settlement, title ownership transfer and URI prepend, attempted mutation of any immutable field failing, revocable-title behavior, and safe degradation in a non-Titled-aware wallet. ## Reference Implementation @@ -354,7 +253,7 @@ The reference implementation will be provided in: - `chia-wallet-sdk` will contain the typed Rust bindings and the driver layer for Title Singleton construction/spending and Unit parsing/construction. - `chia-blockchain/chia/wallet/titled_cat/` will contain the wallet integration, RPC handlers, and indexing. -The Title Singleton inner puzzle composes with the existing Singleton, CAT2, CHIP-40 TAIL, and CHIP-38 revocation layer (Chialisp) and the CHIP-56 Fee Layer (Rue). Each layer curries the hash of the layer it wraps, meaning that the source language of each layer is immaterial: a Rue-authored inner puzzle interoperates with Chialisp-authored layers transparently. This mixed-language stack is the same one already used in production by Revocable Fee CATs. +The inner puzzle composes with the existing Singleton, CAT2, CHIP-40 TAIL, and CHIP-38 layer (Chialisp) and the CHIP-56 Fee Layer (Rue). Because each layer curries the hash of the layer it wraps, the source language is immaterial, the same mixed-language stack already in production for Revocable Fee CATs. ## Security @@ -363,38 +262,20 @@ The Title Singleton inner puzzle composes with the existing Singleton, CAT2, CHI Titled CAT does not make names unique, and it does not decide which issuer is legitimate. An attacker may mint a Titled CAT with a `name` and `ticker` identical to a genuine one. Mitigations are the same as for NFT1 collections: wallets should surface the `creator_did` prominently, and wallets and marketplaces should maintain reputation overlays (verified DIDs, allowlists, denylists). +### Precision display divergence + +A title commits `precision` on-chain, which is the correct fix for the display ambiguity that has dogged CAT2, where the 1000-mojo convention lives in wallet software as a default rather than on the coin. Every wallet that reads the title agrees on what a balance means. The residual risk is confined to the adoption window. A legacy or non-Titled-aware wallet does not read the committed `precision` and falls back to its own default, so for a title whose `precision` differs from that default it can display a different amount for the same Units than a Titled-aware wallet or explorer shows. This is dangerous in exactly the way the original CAT default was: a buyer could see an Offer priced against what looks like a far smaller or larger quantity than the maker intended and approve a trade they have misread. Safety depends on everyone agreeing on what they are looking at. Wallets and explorers SHOULD treat a recognized title's committed `precision` as authoritative and never override it with a local default, SHOULD warn when displaying Units of a title they cannot resolve, and Offer tooling SHOULD refuse to render an amount for a title whose `precision` it has not read from the chain. + ### Title Singleton key compromise or loss -An attacker controlling the Title Singleton key (or its DID) can mint additional Units up to `edition_cap` (or without bound if uncapped), prepend URIs, transfer title ownership, and close the mint. They cannot modify any immutable field, change royalty parameters, alter the creator DID, or revoke held Units. Issuers should set an explicit `edition_cap`, close the mint once the intended supply is reached, custody the controlling key in a vault/multisig/hardware wallet, and keep it separate from the revocation hidden-puzzle key for revocable titles. +An attacker controlling the Title Singleton key (or its DID) can mint additional Units up to `edition_cap` (or without bound if uncapped), prepend URIs, transfer ownership, and close the mint. They cannot modify any immutable field or revoke held Units. Issuers should set an explicit `edition_cap`, close the mint once supply is reached, and custody the key in a vault, multisig, or hardware wallet, separate from the revocation hidden-puzzle key. -Key *loss* is the opposite failure. With no controller, the title freezes in its current state (no mint, melt, mint-close, URI prepend, or transfer), while existing Units keep transferring normally because ordinary transfers never touch the singleton. For an already-closed mint this is benign and even makes the supply cap more credible, since not even the issuer can add to it. For an open or actively managed title it is a permanent loss of control, so issuers should custody the key durably and close the mint once issuance is complete. +Key *loss* is the opposite failure: with no controller the title freezes (no mint, melt, mint-close, URI prepend, or transfer), while existing Units keep transferring normally since ordinary transfers never touch the singleton. For a closed mint this is benign and even makes the cap more credible. For an open title it is a permanent loss of control, one more reason to close the mint once issuance is complete. ### Creator DID over time The curried `creator_did` is immutable, but the DID singleton it names is not frozen by it. That DID can be transferred, abandoned, or compromised over the asset's life. The binding therefore proves which DID issued the title at creation, not who controls that DID today, exactly as for an NFT1 collection's creator DID. Wallets and curators should treat the DID as a provenance anchor whose reputation is tracked over time, not as a permanent endorsement. -### Royalty integrity and bypass - -For titles using the Fee Layer, royalty integrity rests on a two-link chain, and each link has a distinct failure mode. - -*Mint-time binding.* A Unit's CAT Asset ID does not depend on the presence of the Fee Layer, so the guarantee that minted Units actually carry it comes entirely from the Title Singleton's `mint_units` action constraining the issued puzzle hash (see *Mint-time stack binding*). This makes the inner puzzle's derive-and-constrain step the most security-critical code in the standard: a flaw there would let the Title Owner issue royalty-free coins indistinguishable by Asset ID from royalty-bearing ones. - -*Transfer-time persistence.* Even a correctly minted Unit stays royalty-bearing only if the CHIP-56 Fee Layer re-wraps itself on every spend and rejects spends that drop it (see *Persistence across transfers*). If it does not, a holder can strip the layer in a single ordinary transfer. - -A stripped or non-canonically minted coin does not disappear: it carries the title's CAT Asset ID under a bare inner puzzle. A Titled-aware wallet rejects it, because its stack fails the recognition rule, and so will not trade it as a Unit. This is the backstop. But a CAT-only or non-Titled-aware wallet sees a generic CAT of that Asset ID and may accept it, so wallet recognition bounds the damage without eliminating it. Issuers for whom royalty integrity is critical should weigh this. It is inherent to placing royalties in a strippable inner layer beneath a shared Asset ID, and is not specific to Titled CAT. - -Finally, even with both links sound, two cooperating parties can arrange an off-chain payment and use the transfer path to move Units without an Offer, bypassing the royalty. The CHIP-56 mitigations apply unchanged: `allow_zero_price: false` forces every transfer to declare a trade price and pay the royalty floor, and `royalty_min_fee` deters nominal-price evasion. - -### Offer reliability for revocable titles - -For revocable titles, the CHIP-38 and CHIP-56 offer-reliability considerations apply: an attacker controlling the hidden puzzle could revoke Units mid-settlement, causing buyer-side Offer execution to fail. Wallets accepting Offers for revocable titles must display revocability prominently so users can judge the issuer's revocation risk. - -One ambiguity is *removed* with Titled CATs. CHIP-38's "revocability confusion scam" exists because a bare revocable CAT shares its asset ID with a non-revocable one, so a wallet must heuristically guess whether coins are revocable. A Titled CAT commits `revocable` on the title, and recognition requires a Unit's stack to match that commitment. A Titled-aware wallet knows definitively whether Units must carry the revocation layer and rejects any that disagree, rather than guessing. - -### Update path - -The optional `update_inner_puzzle` action lets future variants be adopted by existing titles, but a compromised key could swap to a malicious inner puzzle. The reference inner puzzle requires any replacement to preserve all immutable curried values, and wallets must verify a new inner puzzle hash against the canonical-variants list before treating the title as conformant. Titles that omit this action eliminate the attack surface entirely. - ## Additional Assets From ca4d4e9061fe9b3bf60a2e9de0db4efefb56e50b Mon Sep 17 00:00:00 2001 From: danieljperry Date: Tue, 26 May 2026 11:34:47 +0800 Subject: [PATCH 6/8] Assign CHIP-60 as a Draft --- CHIPs/{chip-evanwinget-titled-cat.md => chip-0060.md} | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) rename CHIPs/{chip-evanwinget-titled-cat.md => chip-0060.md} (99%) diff --git a/CHIPs/chip-evanwinget-titled-cat.md b/CHIPs/chip-0060.md similarity index 99% rename from CHIPs/chip-evanwinget-titled-cat.md rename to CHIPs/chip-0060.md index 30c3f7b6..b74b45f3 100644 --- a/CHIPs/chip-evanwinget-titled-cat.md +++ b/CHIPs/chip-0060.md @@ -1,10 +1,10 @@ -CHIP Number | TBD (to be assigned by Editor) +CHIP Number | 0060 :-------------|:---- Title | Titled CAT Standard Description | A standard attaching an immutable, on-chain metadata reference (name, ticker, content hashes, creator DID, and supply commitments) to a CAT. Author | [Evan Winget](https://github.com/EvanWinget) -Editor | TBD -Comments-URI | TBD +Editor | [Dan Perry](https://github.com/danieljperry) +Comments-URI | [CHIPs repo, PR #205](https://github.com/Chia-Network/chips/pull/205) Status | Draft Category | Standards Track Sub-Category | Primitive From b40ddc50fb6f888175b4c854c5b3cbc582d5c880 Mon Sep 17 00:00:00 2001 From: Evan Date: Sun, 7 Jun 2026 18:19:49 -0700 Subject: [PATCH 7/8] Mutability updates based on feedback --- CHIPs/chip-0060.md | 207 ++++++++++++++++++++++----------------------- 1 file changed, 100 insertions(+), 107 deletions(-) diff --git a/CHIPs/chip-0060.md b/CHIPs/chip-0060.md index b74b45f3..f3fd3be7 100644 --- a/CHIPs/chip-0060.md +++ b/CHIPs/chip-0060.md @@ -1,7 +1,7 @@ CHIP Number | 0060 :-------------|:---- Title | Titled CAT Standard -Description | A standard attaching an immutable, on-chain metadata reference (name, ticker, content hashes, creator DID, and supply commitments) to a CAT. +Description | A standard binding a CAT at issuance to a singleton-anchored title that carries on-chain metadata, enforced supply commitments, an optional creator DID, and optional royalties. Author | [Evan Winget](https://github.com/EvanWinget) Editor | [Dan Perry](https://github.com/danieljperry) Comments-URI | [CHIPs repo, PR #205](https://github.com/Chia-Network/chips/pull/205) @@ -16,44 +16,44 @@ Superseded-By | None ## Abstract -A **Titled CAT** is a Chia Asset Token (CAT) with a **title**: an immutable, hash-committed, on-chain metadata reference (name, ticker, content hashes, an optional creator DID, and supply commitments) bound to the token by construction. +A **Titled CAT** is a Chia Asset Token (CAT) bound at issuance to a **title**: a singleton-anchored, on-chain record carrying the asset's metadata (name, ticker, content references), supply commitments, an optional creator DID, and optional royalty and revocation configuration. The binding is intrinsic, since a Unit's asset ID derives from the Title Singleton's launcher ID by construction, so identity and supply live in the coin with no registry. A CAT already has an opaque on-chain identity in its TAIL, but its name, ticker, image, and provenance live off-chain in indexers and registries. Titled CAT attaches that record to the CAT's own identity. -A CAT already has an on-chain identity in its TAIL and the asset ID derived from it, but that identifier is opaque. The token's name, ticker, image, license, and creator DID all live off-chain, supplied by indexers and registries. Titled CAT closes this gap: it attaches a verifiable metadata reference to the CAT's existing on-chain identity with no registry. The standard is **additive and opt-in**, does not modify or deprecate CAT2, and introduces no new consensus rules or CLVM operators, only one new puzzle: the **Title Singleton** inner puzzle. +Metadata is **mutable by default**, updated by the title owner through an on-chain, auditable action, with no field forced permanent by the standard. An issuer who wants a field frozen locks it explicitly (a locking inner puzzle, or retiring the Title Singleton). -A single committed `precision` field fixes display across the fungibility spectrum. **`precision = 1` is the indivisible case: one mojo is one whole token, shown as an integer count**, suited to trading cards, tickets, and editioned collectibles, while larger powers of ten give divisible, decimal tokens for stablecoins and fractional commodities. +The standard is **additive and opt-in**, applies only to CATs newly minted under the CHIP-40 `everything_with_singleton` TAIL, and introduces no consensus or CLVM changes, only the **Title Singleton** inner puzzle. It is complementary to a registry such as CATalog, which indexes arbitrary existing CATs. A single **`precision`** field, the number of decimal places (`0` indivisible, `3` the current default), fixes display across the fungibility spectrum, from indivisible trading cards and tickets to divisible stablecoins and commodities. ## Definitions Throughout this document: -- **Title**: The immutable on-chain metadata reference of a Titled CAT (name, ticker, precision, content hashes, optional creator DID, optional royalty and revocation config, and supply commitments). By analogy to a property *title*, it names the asset and records its provenance. -- **Title Singleton**: The singleton whose inner puzzle holds the Title and authorizes minting and melting via the associated TAIL. Its launcher ID is the asset's permanent identifier. Spent only at mint, melt, mint-close, URI-append, and ownership transfer, never on ordinary Unit transfers. +- **Title**: The on-chain record carried by a Titled CAT's Title Singleton (name, ticker, precision, content references, optional creator DID, optional royalty and revocation configuration, and supply commitments). Metadata is mutable by default. The Unit-to-title binding, the Unit layer configuration, and the supply mechanism are fixed and are not metadata (see *Mutability and issuer-optional locking*). +- **Title Singleton**: The singleton whose inner puzzle holds the title and authorizes minting and melting via the associated TAIL. Its launcher ID is the asset's permanent identifier. Spent only at mint, melt, mint-close, metadata update, and ownership transfer, never on ordinary Unit transfers. - **Title ID**: A bech32m encoding of the launcher ID, prefix `tcat`. -- **TAIL Asset ID**: The tree hash of the CHIP-40 `everything_with_singleton` TAIL curried to the Title Singleton, the CAT asset ID by which tooling identifies the token's Units. +- **TAIL Asset ID**: The tree hash of the CHIP-40 `everything_with_singleton` TAIL curried to the Title Singleton, the CAT asset ID identifying the token's Units. - **Unit**: The base indivisible unit, one mojo of the CAT. Units of a title are interchangeable, and all holdings and supply counters are denominated in Units. -- **precision**: Units per whole displayed token, committed immutably (defined under *Specification*). `precision = 1` is indivisible. +- **precision**: The number of decimal places used to display the asset. `precision = 0` is indivisible, one Unit shown as one whole token. `precision = 3` is the current ecosystem default. Mutable by default. - **Holder**: A wallet or coin controlling one or more Units. -- **Issuer**: The creator of a Titled CAT. Its DID, when present, is curried at creation and immutable. -- **Title Owner**: The current controller of the Title Singleton (initially the Issuer), authorized to mint, melt, close the mint, prepend URIs, and transfer the title via `transfer_title`. +- **Issuer**: The creator of a Titled CAT. Its DID, when set, is recorded on the title. +- **Title Owner**: The current controller of the Title Singleton (initially the Issuer), authorized to mint, melt, close the mint, update metadata, prepend URIs, and transfer the title. - **Total Minted / Circulating Supply**: `total_minted` is the monotonic cumulative count of Units ever minted (never falls, even on melt). Circulating Supply is the count currently in existence, equal to `total_minted` minus Units melted and observable on-chain. - **Must, required, shall / Must not, shall not / Should, recommended / Should not, not recommended / May**: as in CHIP-0005. ## Motivation -A CAT is identified on-chain by its TAIL and the asset ID derived from it. That identifier is permanent and verifiable but opaque: it says nothing about what the token is called, what it represents, or who issued it. All of that lives off-chain. NFT1 (CHIP-5) shows the alternative, committing an NFT's name, creator DID, and content hash into its own coin. **The problem Titled CAT solves is that a CAT's metadata has no on-chain home bound to the asset.** +A CAT is identified on-chain by its TAIL and the asset ID derived from it: permanent and verifiable, but opaque about what the token is called, what it represents, or who issued it. All of that lives off-chain. NFT1 (CHIP-5) shows the alternative, committing an NFT's name, creator DID, and content reference into its own coin. **The problem Titled CAT solves is that, for an issuer minting a new asset, a CAT has no on-chain home for its metadata, supply discipline, or royalties bound to the asset itself.** ### The metadata gap Because a CAT's metadata comes entirely from outside the coin, every option has a cost: -- **Impersonation.** Anyone can mint a CAT and call it "wUSDC.b." Nothing at the protocol level separates the genuine issuer's token from a counterfeit, so users rely on off-chain allowlists. -- **Dependence on third parties.** To show a name or logo, a wallet must consult and trust an off-chain indexer or registry. The token cannot vouch for itself. -- **Registration friction.** Registries such as [CATalog (CHIP-55)](https://github.com/Yakuhito/chips/blob/xchandles/CHIPs/chip-0055.md) commit content hashes on-chain but require a registration step and a fee per asset. For an issuer with many assets (a 1,000-card game is 1,000 TAILs) that is a real, repeated cost. -- **No protocol provenance.** Nothing immutably binds a CAT to the DID that issued it. +- **Impersonation.** Anyone can mint a CAT reusing a known name and ticker, so users rely on off-chain allowlists to tell genuine from counterfeit. +- **Dependence on third parties.** To show a name or logo, a wallet must consult and trust an off-chain indexer or registry. The token cannot point to its own record. +- **Registration friction.** Registries such as [CATalog (CHIP-55)](https://github.com/Yakuhito/chips/blob/xchandles/CHIPs/chip-0055.md) record metadata on-chain but require a registration step and a fee per asset. For an issuer with many distinct assets this is a real, repeated cost. +- **No bound supply or royalties.** A registry describes a token but does not enforce a supply cap, a mint lifecycle, or a resale royalty. -The same metadata reference serves the whole fungibility spectrum, from stablecoins and tokenized commodities to indivisible trading cards, tickets, and editioned collectibles, with a single `precision` field spanning the range. "Fungible within a class, distinct across classes" is well established elsewhere (notably Ethereum's ERC-1155), and Titled CAT brings it to Chia. +The same record serves the whole fungibility spectrum, from stablecoins and tokenized commodities to indivisible trading cards, tickets, and editioned collectibles, with a single `precision` field. "Fungible within a class, distinct across classes" is well established elsewhere (notably Ethereum's ERC-1155), and Titled CAT brings it to Chia. It is an issuance shape for new assets that opt in at mint, complementary to a registry such as CATalog, which indexes arbitrary existing CATs and which a title can be indexed and curated on top of. ### Technical feasibility @@ -62,125 +62,119 @@ Titled CAT needs no protocol changes. The non-royalty core uses only deployed pi ## Backwards Compatibility -Titled CAT introduces no breaking changes: it does not modify Chia's consensus, the CLVM, or any existing primitive. It is purely additive and opt-in, and neither replaces nor deprecates CAT2. +Titled CAT introduces no breaking changes. It does not modify Chia's consensus, the CLVM, or any existing primitive, and neither replaces nor deprecates CAT2. A wallet that does not implement Titled CAT recognition sees a Unit as an ordinary CAT with a recognizable TAIL pattern, showing a generic CAT and never a misleading name, but it does not read `precision` and falls back to its own default, so a title whose `precision` differs can display a different quantity than an aware wallet. That divergence and its mitigation are covered under *Precision and display* and Security. -A wallet that does not implement Titled CAT recognition sees a Titled CAT's Units as ordinary CATs with a recognizable TAIL pattern. It will not show the title's name, ticker, or artwork, so it never displays a misleading name, only a generic CAT. It also will not read the committed `precision` and falls back to its own default, so for a title whose `precision` differs from that default a legacy wallet and a Titled-aware wallet can show different quantities for the same coins. That divergence is treated under Security (*Precision display divergence*). +### Applicability -Two alternatives are examined in the Rationale: assembling the same outcome from a plain CAT2 plus a registry (which leaves metadata extrinsic and mutable-by-default), and extending CAT2 itself to carry mandatory identity (rejected as a breaking change that would burden every CAT). +A Unit's asset ID is the tree hash of the `everything_with_singleton` TAIL curried to the Title Singleton's launcher ID, so the standard applies **only to CATs newly minted under that TAIL**. It cannot be applied retroactively: the common single-issuance TAIL (`genesis_by_coin_id`, currently the default) derives its asset ID from a one-time genesis coin with no standing on-chain object, and an issued CAT's TAIL is fixed for life. Single-issuance, `genesis_by_puzzle_hash`, `everything_with_signature`, and `delegated_tail` CATs are out of scope and remain best served by a registry such as CATalog, which maps any asset ID to metadata regardless of TAIL. This also shapes the supply guarantee: `everything_with_singleton` lets the Title Singleton mint up to the current `edition_cap`, so supply is permanently bounded only once `mint_closed` is set, enforced by the inner puzzle rather than by the TAIL. ## Rationale ### Title Singleton plus a CAT -The design splits along Chia's coin-set model. Immutable metadata and supply discipline (name, ticker, precision, hashes, creator DID, royalty config, edition cap, mint state) live once, in the Title Singleton. Fungible holdings (who holds how many Units, and how they transfer and trade) are what CAT2 already represents. The CHIP-40 `everything_with_singleton` TAIL binds the two by committing the Title Singleton's launcher ID, so a Unit's Asset ID derives from that launcher ID and only the Title Singleton can authorize a Unit's existence. Metadata is therefore intrinsic, with no separate registry record and no canonical-holder ambiguity. Because the singleton participates only in mint and melt, a title with no royalty layer has the same per-transfer cost as a bare CAT2. +The design splits along Chia's coin-set model. Metadata and supply discipline live once, in the Title Singleton. Fungible holdings (who holds how many Units, and how they transfer) are what CAT2 already represents. The CHIP-40 `everything_with_singleton` TAIL binds the two by committing the launcher ID, so a Unit's Asset ID derives from it and only the Title Singleton can authorize a Unit's existence. The record is intrinsic, with no registry entry and no canonical-holder ambiguity. Because the singleton participates only in mint and melt, a title with no royalty layer has the same per-transfer cost as a bare CAT2. -### Argument for immutability +### Mutability and issuer-optional locking -A title's commitments are frozen by currying: name, ticker, precision, hashes, creator DID, royalty config, revocability, and edition cap can never change. This is deliberate and is most of what distinguishes a title from a registry entry. +Metadata is mutable by default, allowing the title owner to update `name`, `ticker`, `precision`, `creator_did`, `edition_cap`, and content references through an `update_metadata` action recorded on-chain, so a field's history is auditable and a consumer can pin to a state and detect later change. Authenticity is a curation concern (verified-issuer lists, verifier attestations such as CATalog's overlay), as it already is for NFT1 collections and registry entries, rather than a property of a self-declared field. An issuer who needs a field permanent locks it: a locking inner puzzle that rejects `update_metadata` for chosen fields, or retiring the Title Singleton to a burn address once setup is complete. -A coherent alternative is to make immutability optional and verifiable, letting any field be mutable and letting consumers that care check whether a given field is frozen. This standard chooses against it for two reasons. First, the failure modes are asymmetric: a hostile change to metadata after holders acquire the asset is far worse than an uncorrectable typo. Second, mandatory immutability lets a wallet or buyer verify a title once and trust it permanently. Per-field optional immutability would instead force every consumer to ask, for every field it relies on, "is this frozen, and if not, who can change it and have they?" +Three values are fixed mechanism: -URI lists are prependable (an owner may add new locations for the same hash-committed content, latest-first, never altering or removing existing entries, the NFT1 pattern), and supply state moves one way (`total_minted` only rises, `mint_closed` only flips true). When metadata genuinely must change, such as a real rebrand, the escape hatch is melt-and-mint migration. +- **The Unit-to-title binding.** The launcher ID, and so the Asset ID, is fixed by construction. +- **The Unit layer configuration** (royalty and revocation parameters), because every Unit's stack is bound to it at mint and must stay uniform across the title, or the title would hold Units with different stacks under one Asset ID, reintroducing the layer-stripping and confusion attacks of CHIP-38. +- **The supply mechanism.** `total_minted` only rises and `mint_closed` only flips to true. ### DID-rooted provenance -A curried creator DID gives a Titled CAT the provenance guarantee NFT1 provides: any Unit traces cryptographically to the issuer's DID. It does not make names unique, but it lets venues and wallets recognize the genuine issuer and disregard impostors, exactly as NFT1 collections are authenticated today. Curation can then target a list of verified DIDs rather than individual assets. +A creator DID recorded on the title names its issuer, so curation can target verified DIDs rather than individual assets, as NFT1 collections are authenticated today. Because the field is mutable, the claim is curation-backed rather than self-proving, and an issuer who wants it permanent will need to lock it. ### A single `precision` field instead of separate standards -The base unit is always one mojo, and `precision` states how many mojos make one displayed whole token, exactly as CAT2's 1000-mojo convention does. Because metadata and divisibility are orthogonal, one standard suffices: the same Title Singleton, TAIL, and layer stack serve an indivisible trading card (`precision = 1`) and a milligram-divisible gold token (`precision = 1000`). Committing the value on-chain also removes the wallet-default disagreement that has made CAT2 amounts ambiguous (see *Precision display divergence*). `precision = 1` is guaranteed indivisible mechanically, since a coin cannot be smaller than one mojo, and wallets MUST display it as an integer count. +`precision` is the number of decimal places, the quantity CAT2's 1000-mojo convention encodes implicitly as three. Because metadata and divisibility are orthogonal, one standard serves an indivisible card (`precision = 0`) and a milligram-divisible gold token (`precision = 3`). A decimal count rather than a units-per-token value is fewer bytes, makes the power-of-ten relationship structural, and matches CATalog's `precision`, so a wallet has one notion of precision across both. `precision = 0` is mechanically indivisible, since a coin cannot be smaller than one mojo. Because it is mutable, a residual temporal risk remains, addressed under Security and *Offer integration*. ### Optional fee layer and revocation layer -Royalties and revocability are wanted by some titles and not others, so both are optional layered components rather than built in. This keeps the common case (neither) as cheap as a bare CAT2 while letting richer cases compose only what they need. Royalties are oriented to the editioned, indivisible case. Divisible fungibles generally want identity without a per-trade fee, so the Specification recommends they omit the Fee Layer (see *Royalty configuration*). +Royalties and revocability are wanted by some titles and not others, so both are optional layers rather than built in, keeping the common case as cheap as a bare CAT2. Royalties are oriented to the editioned, indivisible case. Divisible fungibles generally want identity without a per-trade fee, so the Specification recommends they omit the Fee Layer (see *Royalty configuration*). -### Why not CAT2 plus a registry? +### Relationship to registries (CATalog) -The closest alternative is a plain CAT2 with metadata in a registry such as CATalog, royalties via the Fee Layer, and a display flag. It reproduces much of the outcome but differs in where metadata lives, what it costs, and whether it can change: +A title and a plain CAT2 registered in a registry such as CATalog reproduce much of the same outcome but differ in where the record lives, what it costs, and what it enforces: -- **Intrinsic versus looked-up.** A title *is* the CAT's TAIL binding, read by walking the one Title Singleton the TAIL commits to, the same trustless full-node operation NFT and DID wallets already perform, with every field verifiable on-chain. The registry instead keeps metadata in a separate entry a wallet must trust the registry to resolve. -- **No per-asset registration cost.** A 1,000-card game is 1,000 registrations and fees under a registry. Under Titled CAT each title is a singleton the issuer creates to mint anyway. -- **Immutable by default.** CATalog's default updater permits changing name and ticker. A title's metadata is immutable by currying. +- **Intrinsic versus looked-up.** A title is the CAT's TAIL binding, read by walking the one Title Singleton it commits to, the trustless full-node operation NFT and DID wallets already perform. The registry keeps metadata in a separate entry a wallet trusts the registry to serve. +- **Per-asset cost.** A 1,000-card game is 1,000 registrations and fees under a registry. Under Titled CAT each title is a singleton the issuer launches to control issuance, a saving only for issuers who want singleton-governed issuance anyway. An issuer who would otherwise mint a fixed-supply single-issuance CAT takes on a singleton launch they would not otherwise need. +- **Bound supply and royalties.** A title enforces a supply cap and mint lifecycle and binds royalty enforcement into every Unit. A registry describes but does not enforce these. -This does not make registries redundant. Curation, verified-issuer lists, search, and discovery remain valuable and are better supplied by a registry than baked into a coin. The two compose: Titled CAT is a trustless metadata substrate a registry like CATalog can index and curate on top of. For a token that expects to rebrand, CAT2 plus a registry remains the right tool. +The two are complementary. A registry indexes arbitrary existing CATs, curates, and powers search and verified-issuer lists, none of which a title attempts. A title is a trustless issuance substrate a registry can index on top of. For a token that needs none of singleton-governed issuance, supply discipline, or royalties, a plain CAT2 plus a registry remains the right tool. ### Relationship to NFT1 -Titled CAT is singleton-anchored and DID-rooted, so it is fair to ask whether it subsumes NFT1. **It does not.** It is tempting to call an NFT a Titled CAT with `edition_cap = 1`, but even the 1-of-1 case is not a drop-in NFT: making a fungible Unit behave like a single item takes extra machinery (a `p2_singleton`-style check that the coin carries the right TAIL, supplied with the launcher ID, that the edition cap is one, and that the amount is exactly one). Such a title is a metadata equivalent, not a behavioral replacement. - -The deeper difference is granularity. A title puts one singleton around a whole *class* and holds balances as fungible Units, spent only at supply changes. NFT1 puts a singleton around every *item*, spent on every transfer, which is what lets each item carry distinct metadata and a DID-bound owner. Because any two Units merge into one coin, there is no per-Unit slot for distinct artwork, a serial number, or an owner. So a collection of unique artworks belongs in NFT1, while 100 identical copies of a card are one title and 100 interchangeable Units rather than 100 singletons. The boundary is individuation: once copies must be distinguished, the asset is in NFT1's domain. DID ownership follows the same line, supported for the *title* but not each *holding*, since a per-Unit owner DID would spend on every transfer and break fungibility. - -Part of this asymmetry is an NFT-side artifact, not a CAT deficiency: singletons were built for pooling and so allow only one of a thing, and a future where one mints N items under a single asset ID that must remain N coins would suit interchangeable cards and would itself want a class-level metadata reference like a title. +Titled CAT is singleton-anchored and DID-rooted, so it is fair to ask whether it subsumes NFT1. **It does not.** Even the 1-of-1 case is not a drop-in NFT, since making a fungible Unit behave like a single item takes extra machinery (a `p2_singleton`-style check that the coin carries the right TAIL, that the edition cap is one, and that the amount is exactly one). The deeper difference is granularity. A title puts one singleton around a whole *class* and holds balances as fungible Units, spent only at supply changes. NFT1 puts a singleton around every *item*, spent on every transfer, which is what lets each item carry distinct metadata and a DID-bound owner. Because any two Units merge into one coin, there is no per-Unit slot for distinct artwork, a serial number, or an owner, so a collection of unique artworks belongs in NFT1, while 100 identical copies of a card are one title and 100 interchangeable Units. The boundary is individuation: once copies must be distinguished, the asset is in NFT1's domain. ### Why scope this to the primitive alone? -This CHIP defines the primitive only. Two companions should be developed separately: a **Titled CAT Off-Chain Metadata Format** (a JSON schema for the `metadata_uri_list` document, analogous to CHIP-7), and **Titled CAT Collections** (conventions for grouping titles into a set or family). +This CHIP defines the primitive only. Two companions should be developed separately: a **Titled CAT Off-Chain Metadata Format** (a JSON schema for the `metadata_uri_list` document, analogous to CHIP-7), and **Titled CAT Collections** (conventions for grouping titles into a family). ## Specification ### Title Singleton -Each Titled CAT shall be anchored by a singleton conforming to the existing Chia Singleton Standard. The Title Singleton's launcher ID is the asset's permanent identifier. The **Title ID** shall be a bech32m encoding of the launcher ID with the human-readable prefix `tcat`. +Each Titled CAT shall be anchored by a singleton conforming to the Chia Singleton Standard. Its launcher ID is the asset's permanent identifier, and the **Title ID** is a bech32m encoding of that launcher ID with prefix `tcat`. The inner puzzle holds the title's metadata, enforces the supply mechanism, and is curried with the Unit layer configuration. Metadata fields are mutable through `update_metadata` unless the issuer has locked them. The layer configuration and supply-mechanism rules are fixed for the life of the title. The reference inner puzzle published with this CHIP is the canonical implementation. -The Title Singleton's inner puzzle shall curry in the following values. All values marked immutable are committed at creation and may never change. The reference inner puzzle published with this CHIP is the canonical implementation. +#### Identity (mutable metadata) -#### Identity (immutable) +- **`name`**: UTF-8 string, max 256 bytes. The asset's full display name. +- **`ticker`**: UTF-8 string, max 32 bytes. The asset's short symbol, not protocol-enforced as unique (a curation concern). +- **`precision`**: Unsigned integer, the number of decimal places. `precision = 0` is the indivisible, integer-displayed case. `precision = 3` is the current default. A divisible title MAY carry the legacy-safe variants under *Precision and display*. +- **`creator_did`** *(optional)*: 32-byte launcher ID of the issuer's DID singleton. If omitted, provenance traces only to the original Issuer's puzzle hash. -- **`name`**: UTF-8 string, maximum 256 bytes. The asset's full display name. Immutable. -- **`ticker`**: UTF-8 string, maximum 32 bytes. The asset's short symbol. Immutable. Tickers are not protocol-enforced as unique. Uniqueness is a curation concern. -- **`precision`**: Unsigned integer, the number of Units (mojos) per whole displayed token. Immutable. `precision = 1` selects the indivisible, integer-displayed case. Larger powers of ten (`precision ≥ 10`) make a whole token divisible into `precision` Units, displayed with decimals. Implementations SHOULD reject a `precision` that is not a power of ten. -- **`creator_did`** *(optional)*: 32-byte launcher ID of the issuer's DID singleton. Once set, immutable. If omitted, provenance is traceable only to the puzzle hash of the original Issuer. +#### Content references (mutable hash plus URI list pairs) -#### Content commitments (immutable hashes, prependable URI lists) +Each reference is a hash paired with a URI list, the hash committing the current bytes and the list locating them. A URI list may be prepended via `add_uri` without touching the hash, and the hash and list may be replaced together via `update_metadata` when content genuinely changes. Every change is on-chain, so a consumer needing permanence pins to a state or requires the field locked. Wallets should verify fetched content against the current hash before rendering. -Each URI list follows NFT1's pattern: the hash is a one-time commitment, while the URI list may be prepended to (latest-first) but never modified or removed. Wallets should verify fetched content against the hash before rendering. +- **`data_hash`** / **`data_uri_list`**: the asset's primary content (card image or token logo). +- **`metadata_hash`** / **`metadata_uri_list`**: the off-chain metadata document (richer fields per a companion CHIP, and the home for extensible attributes such as a future Colored CAT `color`, needing no puzzle change). +- **`license_hash`** / **`license_uri_list`**: licensing and legal terms. -- **`data_hash`**: 32-byte SHA-256 hash of the asset's primary content (e.g., the card image or token logo). Immutable. -- **`data_uri_list`**: One or more URIs locating the primary content. -- **`metadata_hash`**: 32-byte SHA-256 hash of the off-chain metadata document at creation. Immutable. -- **`metadata_uri_list`**: One or more URIs locating the off-chain metadata document (richer fields per a companion metadata-format CHIP). -- **`license_hash`**: 32-byte SHA-256 hash of the licensing terms at creation. Immutable. -- **`license_uri_list`**: One or more URIs locating licensing and legal terms. +#### Royalty configuration (fixed at creation, present only with the fee layer) -#### Royalty configuration (present only if the fee layer is used) +Curried into the CHIP-56 Fee Layer that wraps each Unit, so they are set at creation and fixed for life, not mutable metadata (see *Mint-time stack binding*). Any wallet can reconstruct the expected Unit puzzle hash from the Title Singleton alone. -These values must match exactly the parameters curried into the CHIP-56 Fee Layer that wraps each Unit, so any wallet can reconstruct the expected Unit puzzle hash from the Title Singleton alone. +- **`royalty_puzzle_hash`**: 32-byte puzzle hash royalties are directed to. +- **`royalty_basis_points`**: Unsigned integer, basis points (1 bps = 0.01%). Zero means no proportional royalty. No protocol cap. +- **`royalty_min_fee`**: Unsigned integer, minimum royalty in mojos of the quote asset. Zero disables the floor. +- **`allow_zero_price`**: Boolean. When `false`, even direct sends must declare a trade price and pay at least `royalty_min_fee`. When `true`, free transfers (gifting) are permitted. -- **`royalty_puzzle_hash`**: 32-byte puzzle hash to which royalties are directed. Immutable. -- **`royalty_basis_points`**: Unsigned integer in basis points (1 bps = 0.01%). Zero means no proportional royalty. No protocol cap. -- **`royalty_min_fee`**: Unsigned integer, the minimum royalty in mojos of the quote asset. Zero disables the floor. -- **`allow_zero_price`**: Boolean. When `false`, even direct-send transfers must declare a trade price and pay at least `royalty_min_fee`. When `true`, free transfers (gifting) are permitted. +The Fee Layer suits the indivisible, editioned case (`precision = 0`), where a resale royalty is expected. Divisible titles SHOULD set `royalty_basis_points = 0` and SHOULD NOT set `allow_zero_price: false`, since a per-trade royalty interferes with the price discovery and arbitrage fungibles depend on (notably AMMs) and a per-transfer floor makes a circulating fungible impractical. A divisible Titled CAT therefore typically omits the Fee Layer. -The Fee Layer is oriented to the indivisible, editioned case (`precision = 1`), where a royalty on resale is an established expectation. Divisible titles (`precision ≥ 10`) SHOULD set `royalty_basis_points = 0` and SHOULD NOT set `allow_zero_price: false`. A per-trade royalty interferes with the price discovery and arbitrage that fungible tokens depend on (notably automated market makers), and a floor charged on every transfer makes a circulating fungible impractical to use. A divisible Titled CAT therefore typically omits the Fee Layer entirely, carrying on-chain identity without royalties. +#### Revocability (fixed at creation, present only with the revocation layer) -#### Revocability (present only if the revocation layer is used) +Like the royalty configuration, curried into each Unit at mint and fixed for life, not mutable metadata. -- **`revocable`**: Boolean. When `true`, every Unit is wrapped in a CHIP-38 revocation layer between the Fee Layer (or the CAT layer, if no Fee Layer) and the holder's `p2` puzzle, and any Fee Layer present is curried with `has_hidden_revoke_layer: true` and `allow_revoke_fee_bypass: true`. -- **`hidden_puzzle_hash`** *(present only if `revocable`)*: The hidden puzzle hash used by the revocation layer. Immutable. +- **`revocable`**: Boolean. When `true`, every Unit is wrapped in a CHIP-38 revocation layer between the Fee Layer (or the CAT layer, if none) and the holder's `p2`, and any Fee Layer is curried with `has_hidden_revoke_layer: true` and `allow_revoke_fee_bypass: true`. +- **`hidden_puzzle_hash`** *(present only if `revocable`)*: the hidden puzzle hash used by the revocation layer. #### Supply commitments -- **`edition_cap`** *(optional)*: Unsigned integer maximum on `total_minted`. If set, immutable. If omitted, supply is uncapped (subject to `mint_closed`). -- **`total_minted`**: Unsigned integer, the cumulative count of Units ever minted. Strictly monotonically increasing. Melts reduce Circulating Supply but not `total_minted`. -- **`mint_closed`**: Boolean. When `true`, no further mints are permitted, ever. May be flipped from `false` to `true` by the Title Owner. +- **`edition_cap`** *(optional)*: maximum on `total_minted` checked by `mint_units`. A mutable declared target, so a holder needing a credible permanent cap relies on `mint_closed` (or on the issuer having locked `edition_cap`), not the value alone. If omitted, supply is uncapped subject to `mint_closed`. +- **`total_minted`**: cumulative count of Units ever minted, strictly monotonic, enforced by the inner puzzle. Melts reduce Circulating Supply but not `total_minted`. +- **`mint_closed`**: Boolean, flipped `false` to `true` by the Title Owner and never back. This one-way transition, not the surrounding metadata, is the binding supply guarantee. -Wallets and explorers derive a plain-language supply state from `edition_cap` and `mint_closed` (open versus final, capped versus uncapped), with counts shown in Units divided by the title's `precision`. +Wallets and explorers derive a plain-language supply state from `edition_cap` and `mint_closed`, with counts shown in Units scaled by `precision`. #### Title Singleton inner puzzle actions -The inner puzzle accepts the following spend actions, identified by a selector in the solution. - -- **`mint_units(count, target_puzzle_hash)`**: Authorizes the TAIL to mint `count` Units (i.e., `count` mojos) and send them to `target_puzzle_hash` wrapped in the canonical Unit layer stack. The action derives the canonical Unit puzzle hash from the title's own immutable parameters (the TAIL Asset ID, the declared royalty and revocation layers, and `target_puzzle_hash`) and constrains issuance to coins bearing exactly that puzzle hash, so it cannot authorize a Unit assembled from a non-canonical stack (see *Mint-time stack binding* below). Requires `mint_closed == false` and, if `edition_cap` is set, `total_minted + count ≤ edition_cap`. Updates `total_minted` in the recreated singleton. -- **`melt_units(count)`**: Authorizes the TAIL to melt `count` Units presented in the same spend bundle. Melting requires both Title Singleton authorization and control of the Units, so neither Holder nor Issuer alone can destroy a Unit. This suits issuer-driven redemption (a ticket melted at venue scan, a carbon credit retired on use) while preventing an Issuer from unilaterally burning a Holder's Units. Does not decrease `total_minted`. Circulating Supply falls as the burned mojos leave the CAT supply. Titles that forbid melting omit this action. -- **`close_mint()`**: Sets `mint_closed` to `true`. Permanently disables further minting. -- **`add_uri(key, uri)`**: Prepends a URI to one of the three URI lists (`key` ∈ {`data`, `metadata`, `license`}). Does not modify any hash commitment. -- **`transfer_title(new_owner_p2_puzzle_hash, optional_new_did)`**: Transfers Title Singleton ownership. If the title has a `creator_did`, the spend follows the same DID-aware transfer pattern as NFT1. +- **`mint_units(count, target_puzzle_hash)`**: Authorizes the TAIL to mint `count` Units to `target_puzzle_hash` in the canonical Unit stack. It derives the canonical Unit puzzle hash from the title's fixed layer configuration and constrains issuance to coins bearing exactly that hash, so it cannot authorize a non-canonical stack (see *Mint-time stack binding*). Requires `mint_closed == false` and, if set, `total_minted + count <= edition_cap`. Updates `total_minted`. +- **`melt_units(count)`**: Authorizes the TAIL to melt `count` Units presented in the same bundle. Melting requires both Title Singleton authorization and control of the Units, so neither Holder nor Issuer alone can destroy a Unit (suiting issuer-driven redemption, a ticket melted at scan, while preventing unilateral burning). Does not decrease `total_minted`. Titles forbidding melt omit this action. +- **`close_mint()`**: Sets `mint_closed` true, permanently disabling minting. +- **`update_metadata(fields)`**: Sets one or more mutable fields (`name`, `ticker`, `precision`, `creator_did`, `edition_cap`, content hash/URI pairs) in the recreated singleton. A locking inner puzzle MAY reject it for specific fields. Does not touch the layer configuration or supply mechanism. +- **`add_uri(key, uri)`**: Prepends a URI to a list (`key` in {`data`, `metadata`, `license`}) without modifying the paired hash. +- **`transfer_title(new_owner_p2_puzzle_hash, optional_new_did)`**: Transfers ownership. With a `creator_did`, follows NFT1's DID-aware transfer pattern. ### Unit layer stack -Each Unit is one mojo of a CAT2 coin whose TAIL is `everything_with_singleton` (CHIP-40), curried to the Title Singleton via the singleton module hash and the singleton struct (committing launcher ID `L`). CHIP-40's `NONCE` is fixed to zero, since each title has its own dedicated singleton and does not need the one-singleton-many-CATs case the nonce exists for. The Unit's Asset ID is therefore a deterministic function of `L` alone. The optional Fee and revocation layers, when the title declares them, nest inside: +Each Unit is one mojo of a CAT2 coin whose TAIL is `everything_with_singleton` (CHIP-40), curried to the Title Singleton via the singleton module hash and struct (committing launcher ID `L`). CHIP-40's `NONCE` is fixed to zero, since each title has its own singleton and does not need the one-singleton-many-CATs case, so the Unit's Asset ID is a deterministic function of `L` alone. Optional Fee and revocation layers, when declared, nest inside: ``` ├ CAT outer layer (cat_v2) @@ -190,66 +184,65 @@ Each Unit is one mojo of a CAT2 coin whose TAIL is `everything_with_singleton` ( ├──────── p2 puzzle (holder's standard transaction puzzle) ``` -Layers a title does not declare are omitted, so a minimal title is CAT/TAIL/p2 and a revocable royalty-free title places the revocation layer directly under the TAIL. The parameters curried into every Unit must match the values committed on the Title Singleton, giving wallets a complete verification path: from the Title ID, derive the expected stack and Unit puzzle hash, then check a candidate coin against it. +Undeclared layers are omitted, so a minimal title is CAT/TAIL/p2. The layer configuration is fixed at creation, so the expected stack is uniform across every Unit, and from the Title ID a wallet derives the expected stack and Unit puzzle hash to check a candidate coin. -**Mint-time stack binding.** A Unit's Asset ID is the hash of the TAIL alone, identical whether or not the optional layers are present, since those layers live beneath the CAT layer. Nothing at the CAT layer can distinguish a canonical Unit from one assembled with a missing or altered layer. Only the Title Singleton's `mint_units` action can: it recomputes the canonical Unit puzzle hash `H` from the title's immutable parameters and authorizes issuance only for created coins whose puzzle hash equals `H`. Because the `everything_with_singleton` TAIL delegates all issuance authorization to the Title Singleton, a coin minted with any other stack is never authorized and is not a Unit. The exact wiring (a committed announcement each issued coin asserts, or a direct assertion over created coins) is fixed by the reference inner puzzle. This derive-and-constrain step is the most security-critical code in the standard. +**Mint-time stack binding.** A Unit's Asset ID is the hash of the TAIL alone, identical whether or not the optional layers are present, since they live beneath the CAT layer. Nothing at the CAT layer distinguishes a canonical Unit from one with a missing or altered layer. Only `mint_units` can, by recomputing the canonical puzzle hash `H` from the fixed layer configuration and authorizing only created coins whose puzzle hash equals `H`. Because the TAIL delegates all issuance to the Title Singleton, a coin minted with any other stack is never authorized. This is why the layer configuration is fixed: if it could change, a title could hold Units with different stacks under one Asset ID, the exact condition CHIP-38 identifies as enabling layer stripping (combining a layered and unlayered coin of the same Asset ID) and the associated confusion scam. Keeping every Unit on one canonical stack makes royalties and revocation unstrippable. This derive-and-constrain step is the most security-critical code in the standard. -**Persistence across transfers.** Mint-time binding establishes a Unit's stack. The Fee Layer, when present, must preserve it: Titled CAT relies on the CHIP-56 Fee Layer re-wrapping itself on every spend, including ordinary transfers, and rejecting any spend that drops it. A Fee Layer that let a plain transfer settle to a bare `p2` puzzle would let a holder strip the layer and produce a royalty-free coin sharing the title's Asset ID (see Security). +**Persistence across transfers.** The Fee Layer, when present, must re-wrap itself on every spend, including ordinary transfers, and reject any spend that drops it. A Fee Layer that let a transfer settle to a bare `p2` would let a holder strip it and produce a royalty-free coin sharing the title's Asset ID (see Security). ### Precision and display -- **Indivisible (`precision = 1`).** One Unit is one whole token. Wallets display an integer count, never decimals. -- **Divisible (`precision ≥ 10`).** A whole token is `precision` Units. Wallets display the Unit balance divided by `precision`, with `log10(precision)` decimal places. +- **Indivisible (`precision = 0`).** One Unit is one whole token, displayed as an integer count. +- **Divisible (`precision = d`, `d >= 1`).** The Unit balance is displayed divided by `10^d`, with `d` decimal places. -Both share the same Title Singleton, TAIL, and Unit-stack mechanics, differing only in the committed `precision` and the display rule. +**Legacy-safe display for divisible titles.** A non-aware wallet applies its own default (3) instead of reading `precision`. For a divisible title this is made safe by a dual-name convention from CATalog: `name`/`ticker` are chosen to read correctly at precision 3, and the title MAY carry precision-aware variants `name_p`/`ticker_p` an aware wallet prefers. For example, `name`/`ticker` = "Base warped milliETH" / "wmilliETH.b" (the legacy view, in the smaller unit) and `name_p`/`ticker_p` = "Base warped ETH" / "wETH.b" with `precision = 6` (the aware view). The legacy wallet then shows the correct value in a smaller denomination, not a wrong number. This does not help the indivisible case, where five tokens show as `0.005` in a precision-3 wallet. That is the cost of mechanical indivisibility, so indivisible titles are safe only in aware tooling that refuses to render an unresolved amount. ### Wallet recognition and display -A wallet implementing this standard shall recognize a CAT coin as a Titled CAT Unit when: +A wallet recognizes a CAT coin as a Titled CAT Unit when: 1. The outer layer is `cat_v2` 2. The TAIL is `everything_with_singleton` committing some launcher ID `L` 3. `L` resolves to a Title Singleton with a valid inner puzzle -4. The Unit's inner stack matches the stack derived from the title's curried parameters +4. The Unit's inner stack matches the stack derived from the title's fixed layer configuration -When recognized, the wallet shall display the holding using the title's `name` and `ticker`, sourced from the Title Singleton, formatted at the title's `precision`. Wallets should verify `data_hash` against fetched content before rendering imagery, should surface the `creator_did` when present, and should display royalty configuration and revocability before any Offer involving Units is accepted. +When recognized, the wallet shall display the holding using the title's current `name`, `ticker`, and `precision`, verify `data_hash` against fetched content before rendering imagery, surface `creator_did` when present, flag recent metadata changes, and show royalty and revocation configuration before any Offer is accepted. ### Discovering a title from a Unit -A wallet reads a coin's Asset ID cheaply from its parent's puzzle reveal, but not the launcher ID `L`. The Asset ID is the hash of the TAIL curried with `L`, and the TAIL reveal appears on-chain only at mint and melt, so recovering `L` from a transferred coin (the Alice-sends-Bob case) can otherwise require walking the lineage back to a mint. - -This is a performance problem, not a trust one. Because the Asset ID is a deterministic hash of `L`, any candidate `L` is self-verifying: a wallet recomputes the hash and checks it against the coin, so a memo, an index, or a peer can all supply `L` untrusted. Accordingly: +A wallet reads a coin's Asset ID cheaply from its parent's puzzle reveal, but not `L`. The TAIL reveal appears on-chain only at mint and melt, so recovering `L` from a transferred coin can otherwise require walking the lineage back to a mint. This is a performance problem, not a trust one: because the Asset ID is a deterministic hash of `L`, any candidate `L` is self-verifying (recompute and check), so a memo, index, or peer can supply it untrusted. Recognition is therefore **pull-based**, resolved from data on coins a wallet already holds, never from a standing subscription: -- **Hint on mint and on transfer.** `mint_units` SHOULD hint each created coin with `L` (a memo), and a Titled-aware wallet SHOULD carry that hint forward when it sends Units, so an ordinary transfer to a Titled-aware recipient stays a direct lookup. This is a convention, not puzzle-enforced, since enforcing it would add a per-transfer layer and cost. -- **Resolve once, cache.** A wallet needs `L` for a given Asset ID only once and may cache it permanently, since the cached value re-verifies against the Asset ID. The cost is one-time per title, not per transfer. -- **Fallback.** Receiving Units with no hint (for example from a non-aware sender), a wallet recovers `L` by the lineage walk or from an index, both trustless, then caches. If `L` cannot be resolved at all, the Unit degrades safely to a generic CAT. +- **Hint on mint and transfer.** `mint_units` SHOULD hint each created coin with `L`, and an aware wallet SHOULD carry the hint forward on sends, keeping aware-to-aware transfers a direct lookup. This is convention, not puzzle-enforced. +- **Resolve once, cache.** A wallet needs `L` for an Asset ID only once and caches it permanently, since the cached value re-verifies. One-time per title, not per transfer. +- **Fallback.** With no hint (a non-aware sender), a wallet recovers `L` by lineage walk or index, both trustless, then caches. If `L` is unresolvable, the Unit degrades to a generic CAT. -A wallet MAY also subscribe to the Title Singleton's launcher coin for live metadata and supply updates, but a Titled CAT does not require subscription by default. +A wallet MAY subscribe to a Title Singleton it already holds for live updates. Wallets SHOULD NOT blanket-subscribe to a shared TAIL or hint hash to detect titledness across unknown CATs, since a widely-subscribed hash is an attractive dusting target and the pull-based path makes it unnecessary. ### Offer integration -Offers involving Titled CAT Units that carry a Fee Layer follow the CHIP-56 Offer integration pattern unchanged: the maker's wallet computes the royalty per trade price from the title's parameters, includes royalty settlement payments in the bundle, injects `SetCatTradeContext(trade_nonce, trade_prices)` into each Unit lock-leg spend, and the taker's wallet must include the royalty payments to complete the Offer. Units with no Fee Layer trade as ordinary CATs. Per-Offer royalty cost is bounded per title regardless of Unit quantity. +Offers involving Units with a Fee Layer follow the CHIP-56 pattern unchanged: the maker's wallet computes the per-price royalty, includes settlement payments, injects `SetCatTradeContext(trade_nonce, trade_prices)` into each lock-leg spend, and the taker must include the royalty payments to complete the Offer. Units without a Fee Layer trade as ordinary CATs, and per-Offer royalty cost is bounded per title regardless of Unit quantity. Because `precision` is mutable, offer tooling SHOULD record it at offer creation and warn or refuse to settle on a change, so a redenomination cannot silently alter how an in-flight offer's amounts display. ### RPC calls -Wallets may expose the following RPCs: +Wallets may expose: -- **`titled_cat_create`**: Create a title and optionally mint an initial batch (`name`, `ticker`, `precision`, the three URI/hash sets, optional `royalty_*`, `revocable`/`hidden_puzzle_hash`, `edition_cap`, `initial_mint_count`, `did_id`, `target_address`, `fee`). Returns `title_id`, `title_singleton_coin_id`, `tail_asset_id`. -- **`titled_cat_mint`** / **`_melt`** / **`_transfer`**: Mint, melt, or transfer Units (`title_id`, `count` or `amount`, `target_address`, optional `trade_price`/`fee`). Melt requires both Title Singleton authorization and control of the Units. -- **`titled_cat_close_mint`** / **`_add_uri`**: Close the mint, or prepend a URI (`title_id`, `key`, `uri`). -- **`titled_cat_get_info`** / **`_get_balances`**: Read a title's on-chain state, or the wallet's holdings aggregated per title. -- **`titled_cat_revoke`** *(revocable titles only)*: Revoke specified Units (`title_id`, `coin_ids[]`, `destination_puzzle_hash`). +- **`titled_cat_create`**: Create a title and optionally mint an initial batch. Returns `title_id`, `title_singleton_coin_id`, `tail_asset_id`. +- **`titled_cat_mint` / `_melt` / `_transfer`**: Mint, melt, or transfer Units. Melt requires both Title Singleton authorization and control of the Units. +- **`titled_cat_update_metadata`**: Update mutable fields, failing for any the issuer has locked. +- **`titled_cat_close_mint` / `_add_uri`**: Close the mint, or prepend a URI. +- **`titled_cat_get_info` / `_get_balances`**: Read a title's on-chain state (including update history), or holdings aggregated per title. +- **`titled_cat_revoke`** *(revocable titles only)*: Revoke specified Units. ## Test Cases -Detailed test cases will ship with the reference implementation in `assets/chip-/tests/`. At minimum they will cover title creation across the precision range and option combinations, derived Unit puzzle hashes matching on-chain Units for each layer-stack variant, mint and melt rules (edition cap, `close_mint`, and the dual-authorization melt), ordinary transfers matching a bare CAT2 in cost, display correctness across `precision`, royalty-enforced Offer settlement, title ownership transfer and URI prepend, attempted mutation of any immutable field failing, revocable-title behavior, and safe degradation in a non-Titled-aware wallet. +Detailed test cases ship with the reference implementation in `assets/chip-/tests/`. At minimum they cover title creation across the precision range and option combinations, derived Unit puzzle hashes matching on-chain Units per stack variant, mint and melt rules (edition cap, `close_mint`, dual-authorization melt), the supply invariants (monotonic `total_minted`, one-way `mint_closed`), ordinary transfers matching bare CAT2 cost, display across `precision` including the legacy-safe convention, `update_metadata` succeeding for the owner and being rejected for non-owners and locked fields, royalty-enforced Offer settlement, title transfer and URI prepend, a non-canonical-stack mint failing, revocable behavior, and safe degradation in a non-aware wallet. ## Reference Implementation The reference implementation will be provided in: -- `chia-wallet-sdk/crates/chia-sdk-puzzles/puzzles/titled_cat_inner_puzzle.rue` will contain the Title Singleton inner puzzle, written in [Rue](https://github.com/Rigidity/rue) and compiled to CLVM. Following the convention established by the CHIP-56 Fee Layer (`fee_layer_v1.rue`), the `chia-sdk-puzzles` crate owns the Rue source alongside the embedded compiled bytes and serialized tree hash. +- `chia-wallet-sdk/crates/chia-sdk-puzzles/puzzles/titled_cat_inner_puzzle.rue` will contain the Title Singleton inner puzzle, written in [Rue](https://github.com/Rigidity/rue) and compiled to CLVM. Following the CHIP-56 Fee Layer convention (`fee_layer_v1.rue`), the `chia-sdk-puzzles` crate owns the Rue source alongside the embedded compiled bytes and serialized tree hash. - `chia-wallet-sdk` will contain the typed Rust bindings and the driver layer for Title Singleton construction/spending and Unit parsing/construction. - `chia-blockchain/chia/wallet/titled_cat/` will contain the wallet integration, RPC handlers, and indexing. @@ -258,23 +251,23 @@ The inner puzzle composes with the existing Singleton, CAT2, CHIP-40 TAIL, and C ## Security -### Duplicate Titled CAT names +### Duplicate names and mutable metadata -Titled CAT does not make names unique, and it does not decide which issuer is legitimate. An attacker may mint a Titled CAT with a `name` and `ticker` identical to a genuine one. Mitigations are the same as for NFT1 collections: wallets should surface the `creator_did` prominently, and wallets and marketplaces should maintain reputation overlays (verified DIDs, allowlists, denylists). +Titled CAT does not make names unique or decide which issuer is legitimate, and because metadata is mutable, `name`, `ticker`, image, and `creator_did` can change after holders acquire Units. Neither is a protocol guarantee. Authenticity is a curation concern, as for NFT1 collections and registry entries: wallets should surface `creator_did`, make recent changes visible, and rely on reputation overlays (verified DIDs, verifier attestations, allow and deny lists). A consumer needing a field never to change should require it locked (or the singleton retired), and may pin to a state to detect change. ### Precision display divergence -A title commits `precision` on-chain, which is the correct fix for the display ambiguity that has dogged CAT2, where the 1000-mojo convention lives in wallet software as a default rather than on the coin. Every wallet that reads the title agrees on what a balance means. The residual risk is confined to the adoption window. A legacy or non-Titled-aware wallet does not read the committed `precision` and falls back to its own default, so for a title whose `precision` differs from that default it can display a different amount for the same Units than a Titled-aware wallet or explorer shows. This is dangerous in exactly the way the original CAT default was: a buyer could see an Offer priced against what looks like a far smaller or larger quantity than the maker intended and approve a trade they have misread. Safety depends on everyone agreeing on what they are looking at. Wallets and explorers SHOULD treat a recognized title's committed `precision` as authoritative and never override it with a local default, SHOULD warn when displaying Units of a title they cannot resolve, and Offer tooling SHOULD refuse to render an amount for a title whose `precision` it has not read from the chain. +Putting `precision` on the title removes the cross-wallet ambiguity of CAT2's wallet-default convention, since every aware wallet agrees on a balance's meaning. Two residual risks remain. First, a non-aware wallet falls back to its default, so a differing `precision` displays a different amount. The divisible legacy-safe convention (see *Precision and display*) makes this a smaller denomination rather than a wrong number, and the indivisible case is safe only in aware tooling. Second, because `precision` is mutable, an owner could change it between a taker reading an Offer and accepting it. Offers settle in Units, so the value is never wrong, but the displayed reading could be manipulated. Offer tooling SHOULD pin `precision` at offer creation and warn or refuse on a change, and an issuer of a token that should never be redenominated SHOULD lock `precision`. ### Title Singleton key compromise or loss -An attacker controlling the Title Singleton key (or its DID) can mint additional Units up to `edition_cap` (or without bound if uncapped), prepend URIs, transfer ownership, and close the mint. They cannot modify any immutable field or revoke held Units. Issuers should set an explicit `edition_cap`, close the mint once supply is reached, and custody the key in a vault, multisig, or hardware wallet, separate from the revocation hidden-puzzle key. +An attacker controlling the Title Singleton key (or its DID) can mint up to `edition_cap` (or without bound if uncapped), update mutable metadata, prepend URIs, transfer ownership, and close the mint. They cannot alter the layer configuration, change the supply invariants, or revoke a non-revocable title's Units. The primary exposure is minting, bounded by `edition_cap`, `close_mint`, and key custody (a vault, multisig, or hardware wallet separate from the revocation key). For a closed mint, supply is safe even under compromise, while metadata could still change, which is why authenticity rests on curation and an issuer needing permanence locks the field. -Key *loss* is the opposite failure: with no controller the title freezes (no mint, melt, mint-close, URI prepend, or transfer), while existing Units keep transferring normally since ordinary transfers never touch the singleton. For a closed mint this is benign and even makes the cap more credible. For an open title it is a permanent loss of control, one more reason to close the mint once issuance is complete. +Key loss freezes the title (no mint, melt, close, update, or transfer) while existing Units keep transferring, since ordinary transfers never touch the singleton. For a closed mint this is benign and equivalent to deliberately retiring the singleton. For an open title it is a permanent loss of control, a further reason to close the mint once issuance is complete. ### Creator DID over time -The curried `creator_did` is immutable, but the DID singleton it names is not frozen by it. That DID can be transferred, abandoned, or compromised over the asset's life. The binding therefore proves which DID issued the title at creation, not who controls that DID today, exactly as for an NFT1 collection's creator DID. Wallets and curators should treat the DID as a provenance anchor whose reputation is tracked over time, not as a permanent endorsement. +A `creator_did`, even when locked, names a DID singleton that is not itself frozen and can be transferred, abandoned, or compromised. The binding proves which DID the title names, not who controls it today, as for an NFT1 collection. A wallet should treat a change to `creator_did` as significant and the DID as a provenance anchor whose reputation is tracked over time, not a permanent endorsement. ## Additional Assets From 9b4b94625a33899ad014f8d7d030a28e99fa58e8 Mon Sep 17 00:00:00 2001 From: Evan Date: Sun, 7 Jun 2026 19:00:17 -0700 Subject: [PATCH 8/8] Field updates based on feedback --- CHIPs/chip-0060.md | 30 +++++++++++++++++++++++++++--- 1 file changed, 27 insertions(+), 3 deletions(-) diff --git a/CHIPs/chip-0060.md b/CHIPs/chip-0060.md index f3fd3be7..c00882f0 100644 --- a/CHIPs/chip-0060.md +++ b/CHIPs/chip-0060.md @@ -126,7 +126,10 @@ Each Titled CAT shall be anchored by a singleton conforming to the Chia Singleto - **`name`**: UTF-8 string, max 256 bytes. The asset's full display name. - **`ticker`**: UTF-8 string, max 32 bytes. The asset's short symbol, not protocol-enforced as unique (a curation concern). -- **`precision`**: Unsigned integer, the number of decimal places. `precision = 0` is the indivisible, integer-displayed case. `precision = 3` is the current default. A divisible title MAY carry the legacy-safe variants under *Precision and display*. +- **`description`** *(optional)*: UTF-8 string, max 1024 bytes. A short human-readable description. Longer prose belongs in the off-chain metadata document. +- **`precision`**: Unsigned integer, the number of decimal places. `precision = 0` is the indivisible, integer-displayed case. `precision = 3` is the current default. A divisible title MAY carry precision-aware `name_p`/`ticker_p` variants (see *Precision and display*). +- **`name_p`** *(optional, divisible titles)*: UTF-8 string, max 256 bytes. The precision-aware display name an aware wallet prefers, read together with `precision`. Falls back to `name` if absent. +- **`ticker_p`** *(optional, divisible titles)*: UTF-8 string, max 32 bytes. The precision-aware ticker an aware wallet prefers, read together with `precision`. Falls back to `ticker` if absent. - **`creator_did`** *(optional)*: 32-byte launcher ID of the issuer's DID singleton. If omitted, provenance traces only to the original Issuer's puzzle hash. #### Content references (mutable hash plus URI list pairs) @@ -168,7 +171,7 @@ Wallets and explorers derive a plain-language supply state from `edition_cap` an - **`mint_units(count, target_puzzle_hash)`**: Authorizes the TAIL to mint `count` Units to `target_puzzle_hash` in the canonical Unit stack. It derives the canonical Unit puzzle hash from the title's fixed layer configuration and constrains issuance to coins bearing exactly that hash, so it cannot authorize a non-canonical stack (see *Mint-time stack binding*). Requires `mint_closed == false` and, if set, `total_minted + count <= edition_cap`. Updates `total_minted`. - **`melt_units(count)`**: Authorizes the TAIL to melt `count` Units presented in the same bundle. Melting requires both Title Singleton authorization and control of the Units, so neither Holder nor Issuer alone can destroy a Unit (suiting issuer-driven redemption, a ticket melted at scan, while preventing unilateral burning). Does not decrease `total_minted`. Titles forbidding melt omit this action. - **`close_mint()`**: Sets `mint_closed` true, permanently disabling minting. -- **`update_metadata(fields)`**: Sets one or more mutable fields (`name`, `ticker`, `precision`, `creator_did`, `edition_cap`, content hash/URI pairs) in the recreated singleton. A locking inner puzzle MAY reject it for specific fields. Does not touch the layer configuration or supply mechanism. +- **`update_metadata(fields)`**: Sets one or more mutable fields (`name`, `ticker`, `description`, `name_p`, `ticker_p`, `precision`, `creator_did`, `edition_cap`, content hash/URI pairs) in the recreated singleton. A locking inner puzzle MAY reject it for specific fields. Does not touch the layer configuration or supply mechanism. - **`add_uri(key, uri)`**: Prepends a URI to a list (`key` in {`data`, `metadata`, `license`}) without modifying the paired hash. - **`transfer_title(new_owner_p2_puzzle_hash, optional_new_did)`**: Transfers ownership. With a `creator_did`, follows NFT1's DID-aware transfer pattern. @@ -195,7 +198,7 @@ Undeclared layers are omitted, so a minimal title is CAT/TAIL/p2. The layer conf - **Indivisible (`precision = 0`).** One Unit is one whole token, displayed as an integer count. - **Divisible (`precision = d`, `d >= 1`).** The Unit balance is displayed divided by `10^d`, with `d` decimal places. -**Legacy-safe display for divisible titles.** A non-aware wallet applies its own default (3) instead of reading `precision`. For a divisible title this is made safe by a dual-name convention from CATalog: `name`/`ticker` are chosen to read correctly at precision 3, and the title MAY carry precision-aware variants `name_p`/`ticker_p` an aware wallet prefers. For example, `name`/`ticker` = "Base warped milliETH" / "wmilliETH.b" (the legacy view, in the smaller unit) and `name_p`/`ticker_p` = "Base warped ETH" / "wETH.b" with `precision = 6` (the aware view). The legacy wallet then shows the correct value in a smaller denomination, not a wrong number. This does not help the indivisible case, where five tokens show as `0.005` in a precision-3 wallet. That is the cost of mechanical indivisibility, so indivisible titles are safe only in aware tooling that refuses to render an unresolved amount. +**Legacy-safe display for divisible titles.** A non-aware wallet applies its own default (3) instead of reading `precision`, and since it does not read the title at all, it sources `name`/`ticker` from an indexer keyed by asset ID, the same way it names any CAT today. For a divisible title this is made safe by a dual-name convention from CATalog: `name`/`ticker` are chosen to read correctly at precision 3, and the title MAY carry precision-aware variants `name_p`/`ticker_p` an aware wallet prefers. The benefit therefore reaches a legacy wallet through an indexer mirroring the title's legacy-safe `name`, as CATalog's own convention does, not through the coin directly. For example, `name`/`ticker` = "Base warped milliETH" / "wmilliETH.b" (the legacy view, in the smaller unit) and `name_p`/`ticker_p` = "Base warped ETH" / "wETH.b" with `precision = 6` (the aware view). The legacy wallet then shows the correct value in a smaller denomination, not a wrong number. This does not help the indivisible case, where five tokens show as `0.005` in a precision-3 wallet. That is the cost of mechanical indivisibility, so indivisible titles are safe only in aware tooling that refuses to render an unresolved amount. ### Wallet recognition and display @@ -278,6 +281,27 @@ The following additional assets are anticipated as the reference implementation - `assets/chip-/titled_cat_inner_puzzle.clsp.hex` and its tree hash: compiled CLVM bytes mirroring the source, following the CHIP-56 Fee Layer convention. +## Appendix: CATalog field mapping + +A title maps onto a [CATalog (CHIP-55)](https://github.com/Yakuhito/chips/blob/xchandles/CHIPs/chip-0055.md) entry with no translation beyond the notes below, so a registry can index a title directly. Title fields with no CATalog equivalent are title-only and are carried as extensions or dropped by an indexer. + +| Title field | CATalog key | +|:--|:--| +| `name` | `n` | +| `ticker` | `t` | +| `description` | `d` | +| `precision` | `p` | +| `name_p` | `pn` | +| `ticker_p` | `pt` | +| `data_hash` / `data_uri_list` | `h` / `u` | +| `metadata_hash` / `metadata_uri_list` | `mh` / `mu` | +| `license_hash` / `license_uri_list` | `lh` / `lu` | +| `hidden_puzzle_hash` | `hph` | +| `creator_did`, royalty config, supply commitments | (no equivalent, title-only) | + +Titled CAT keeps NFT1's `data_hash`/`data_uri_list` for the primary image, which map to CATalog's `image_hash` (`h`) and `image_uris` (`u`). The precision-aware `name_p`/`ticker_p` follow CATalog's `p`-prefixed convention (`pn`/`pt`). Keys reflect the CHIP-55 draft and should be reconciled against it at finalization. + + ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).