| CHIP Number | 0038 |
|---|---|
| Title | Revocable CATs |
| Description | A standard for a Chia Asset Token (CAT) that can be revoked by the issuing party |
| Author | Andreas Greimel |
| Editor | Dan Perry |
| Comments-URI | CHIPs repo, PR #136 |
| Status | Final |
| Category | Standards Track |
| Sub-Category | Primitive |
| Created | 2024-12-06 |
| Requires | CAT2, CHIP-40 |
Tokens that conform to the CAT2 standard use an ownership layer to set up the rules of how they may be spent. This CHIP builds upon the CAT2 standard to create a new type of CAT that allows the issuing entity to take back custody of the tokens they have issued. In addition, revocable CATs can be minted and melted from a vault. Beyond these special properties, revocable CATs can be spent just like CATs that follow the CAT2 standard.
In general, tokens can represent real world assets (RWAs) on blockchains. The most common token standard on Chia's blockchain is CAT2, which allows issuers to mint tokens from mojos. While the CAT2 standard could be used to represent certain RWAs, it is often the case that the issuer needs to be able to revoke issued tokens.
The primary situation where revocation is needed is when the owner loses all of their keys that are able to spend their CATs, and also loses the keys that are able to recover the vault that custodies them. In this scenario, the owner could contact the issuer and prove their identity, after which the issuer would revoke the CATs and issue new ones to the owner in a new wallet or vault.
A secondary (and much less reliable) reason for revocation is after keys have been stolen. In this case, the issuer could also attempt to revoke the CATs from the thief and reissue them to their rightful owner. However, the thief would most likely either sell the stolen CATs immediately, or attempt to obfuscate their origin by sending them to a mixer, AMM, or bridge. For these reasons, owners of revocable CATs should never consider these assets to be safe from theft.
In order to fulfill the revocability requirement for the issuers of RWAs, this CHIP sets a new standard for revocable CATs on Chia's blockchain. It would benefit Chia's ecosystem by allowing the issuance of RWAs that would not have been possible using existing standards.
Note: Wallets that implement revocable CATs should follow the recommendations provided in the Security section, particularly those concerning how to display the CATs and how the revocation layer could be removed in certain cases.
This proposal is for a new CAT standard that will exist in tandem with the CAT2 standard. It does not replace any existing standards, nor does it modify Chia's consensus. This CHIP therefore does not introduce any breaking changes to Chia.
The design for revocable CATs draws from the existing (albeit stagnant) CHIP-16 (Verifiable Credentials). That CHIP created a type of singleton with two primary properties:
- The issuing entity needed to verify a factual claim about a prospective holder prior to issuing a Verifiable Credential
- The issuing entity could revoke the proofs contained within a Verifiable Credential at any point
For the revocable CAT standard, we wanted to create a new type of CAT that maintained the revocation property of Verifiable Credentials. However, we did not want to restrict ownership of the CATs to only certain people or other entities. In addition, we wanted the CATs to be able to be minted and melted from a specified singleton such as a vault.
We therefore took the existing CAT2 standard, added the revocation aspect of Verifiable Credentials, and used the TAIL from CHIP-40 to allow minting and melting from a singleton.
Note that the revocable CAT standard from this CHIP uses the same 1000 mojo-per-CAT convention as the CAT2 standard.
The puzzle structure looks like this:
├ Outer layer (cat_v2)
├── TAIL (everything_with_singleton)
├── Revocation layer (revocation_layer.clsp)
├──── Inner puzzle -- the p2 puzzle that would usually go into cat_v2 (note that while an inner puzzle is required, this CHIP is agnostic to the specific inner puzzle that is used)
├──── hidden_puzzle
A few notes about this structure:
- The outer layer is the same puzzle used by CATs that follow the CAT2 standard
- Other TAILs may be used to mint and melt revocable CATs, but the only TAIL used in the initial reference implementation is
everything_with_singleton - The revocation layer is the same puzzle that was originally developed for use with Verifiable Credentials. It has two spend paths:
- Inner puzzle -- for normal spends; may not remove the revocation layer
- Hidden puzzle -- for revocation; must remain in place every time this coin is spent
Both the hidden puzzle and the TAIL function similarly. But by separating them, revocable CATs are able to use different rules for minting/melting and revocation.
Hidden puzzle
A hidden puzzle is required, but it is up to the issuer to specify the exact hidden puzzle used for a given revocable CAT. For example, issuers might opt to use p2_delegated_puzzle_or_hidden_puzzle.clsp, which is the standard transaction puzzle.
Revocable CATs are comprised of the following Chialisp puzzles:
- A TAIL, for example everything_with_singleton.clsp
- Revocation layer
- A hidden puzzle, for example p2_delegated_puzzle_or_hidden_puzzle.clsp
Chia Network, Inc. has conducted an internal review of the code involved with this CHIP, which has surfaced some minor issues, as detailed below.
Revocation transactions are not guaranteed to make it onto the blockchain. For example, at a given time, the mempool might be completely full. This could occur due to natural demand or from a Denial of Service attack (perhaps a revocable CAT holder launches the attack to prevent their CATs from being revoked). In both cases, the outcome is the same: the issuer might find it difficult to revoke the CATs in a timely manner.
To mitigate this issue, the issuer could include a large fee in order for their transaction to be included. They could also use Replace by Fee (RBF) to increase the fee of an existing transaction. Another option for a large issuer might be to farm their own block, in which case they would be free to include their own transactions.
However, while a full mempool might make it difficult for an issuer to revoke their tokens, this is a facet of the blockchain's limited block space, and not a specific issue with revocable CATs (other than perhaps a higher CLVM cost than standard CATs).
Issuers also might experience difficulty if they want to revoke many tokens at once. This is exacerbated by the fact that holders can split each of their whole CATs into up to 1000 tokens, thereby requiring the issuer to initiate 1000 times as many transactions as would have been required if the CATs had not been split.
In this scenario, the issuer could still revoke the tokens, but it might take lots of time and effort.
As mentioned previously, revocable CATs should not be considered secure against theft. For example, if an adversary steals all of the keys to a vault, they could immediately send the stolen revocable CATS to a mixer, which would mask their origin. The issuer likely would be unable to revoke the stolen tokens, and the owner would then not be able to recover their funds.
The intent of the puzzles laid out in this CHIP is to provide a token issuer with a method of issuing a CAT that is always revocable. As long as every issuance/minting of the CAT was done with a revocable layer, this will hold true. However, it is also possible for someone who controls a non-revocable CAT coin to turn it into a revocable CAT by adding a revocation layer. This means that someone who did not originally issue the CAT can later revoke some tokens of that CAT if they add a revocation layer when they are in control of those coins. This is discussed further below, along with methods for wallets to handle coins that have had a revocation layer added to them.
Because revocable CATs have two possible spend paths, Offers that involve them are not completely trustless. In theory, when Alice accepts an offer to buy a revocable CAT from Bob, then whoever added the revocation layer (typically the issuer, see above) could invoke the revocation spend path, and the CAT would be sent to the revocation layer creator instead of to Alice. This places additional importance on the trustworthiness of the issuer, or in certain cases, another entity that has created the revocation layer.
Users can "burn" certain Chia assets by sending them to an address controlled by a wallet for which nobody has a private key. Because of this lack of a private key, nobody can ever move these assets. This is true for NFTs that conform to the NFT1 standard, as well as for CATs that conform to the CAT2 standard. However, this is not true for revocable CATs because the owner can revoke them at any time, including when they are held at a burn address.
Users of these revocable CATs should therefore never assume that their tokens have actually been burned (can never be accessed again). Instead, the issuer can melt the tokens, which will remove the CAT layers and return them to their original mojos.
If a wallet chooses to support revocable CATs, then it must decide how to display them. This CHIP's recommendations are as follows:
- If the wallet has ever detected a non-revocable coin with a given TAIL ID, then that wallet should forever ignore all revocable coins with that TAIL ID.
- If the wallet has never detected a non-revocable coin with a given TAIL ID, then that wallet should assume for the time being that all coins with that TAIL ID are revocable.
- If the wallet is currently assuming that all coins with a given TAIL ID are revocable, then that wallet should prominently display the fact that these coins are revocable, for example by adding the word
Revocablewherever the coins are listed in the wallet.
The reason for this recommendation is that a revocable layer can be added to a non-revocable CAT coin. In this case, the TAIL ID of the revocable and non-revocable coins would be the same.
If the wallet were to go against this CHIP's recommendation, and instead display all revocable and non-revocable CAT coins as belonging to the same CAT type, and as non-revocable, then a scam would become possible. The scammer would create an Offer to trade some revocable CATs of a known CAT type in exchange for something of value (for example, XCH). The victim's wallet would display the revocable CATs as if they were not revocable. If the victim were to accept this offer, then they would send the scammer a valuable asset, and they would receive a revocable CAT, which the scammer would then revoke.
As long as the revocable coins belonging to that particular CAT are ignored as recommended in this CHIP, the wallet will not be susceptible to this scam.
The CAT2 standard disallows minting and melting of a CAT unless the TAIL puzzle of the CAT is successfully run. The accounting works via announcements that include the asset_id (hash of the TAIL puzzle). Because revocable and non-revocable versions of the same CAT have the same asset_id, they also make the same announcements.
As a result, it is possible to spend a non-revocable CAT together with a revocable CAT as inputs, and to output a non-revocable CAT whose value is the sum of the value of the two inputs. This is allowed by the accounting, and it effectively strips out the revocation layer. The result is the creation of a non-revocable version of the CAT. (In order for a given wallet to do this, it must implement the ability to mix inputs in this way.)
Because of the possibility of the revocation layer being stripped, holders of non-revocable CATs should never add a revocation layer to those assets because they cannot assume that the revocation layer will remain in place.
It is important to note that if every coin belonging to a particular CAT is revocable, then the above technique cannot be employed, so the revocation layer cannot be stripped. Therefore, this CHIP's recommendation for issuers who want to create revocable CATs is that they include the revocation layer with the initial minting, as well as with all subsequent mintings where applicable. This will then guarantee that the revocation layer can never be removed via coin-combining.
None
Copyright and related rights waived via CC0.