Chia-Network
CHIP-0038: Revocable CATs
This CHIP is now a Draft. It proposes a new standard for CATs which can be revoked by the issuing entity. If it is accepted, it will exist along with the CAT2 standard, rather than replacing it. Note that this CHIP draws heavily from the CAT2 and VC standards.
Please leave your reviews here, and feel free to discuss it in the #chips channel of our Discord.
Glad we went with the name “revocation layer” instead of what it was before :)
I’m wondering if this CHIP considers whether this functionality also cover requirements from stablecoin issuers needed to issue them natively? For example, from Circle’s terms:
Blocked Addresses & Forfeited Funds Circle reserves the right to “block” certain USDC addresses and, if such addresses are Circle custodied addresses, freeze associated USDC (temporarily or permanently) that it determines, in its sole discretion, may be associated with illegal activity or activity that otherwise violates these Terms (“Blocked Addresses”). In the event that you send USDC to a Blocked Address, or receive USDC from a Blocked Address, Circle may freeze such USDC and take steps to terminate your USDC Account.
Blacklisting USDC is issued and redeemed in accordance with Circle's blacklisting policy. Circle reserves the right to block the transfer of USDC to and from an address on chain as permitted under the blacklisting policy.
My assumption is yes in that a melt + remint could mimic the functionality of pause or temporary blacklist.
The intent certainly is to give options to stable coin providers also. The key focus is to make equity CATs legal under US state law and to provide for an improved stockholder experience in that they will be able to use existing processes to get their stock re issued should all of the layers of self custody safety fail.
@SlowestTimelord In this proposal, the issuer has full power over all issued tokens. Which is perfect for equity, but might be a bit overreaching for stable coins or other types of tokens.
The hidden puzzle can be adjusted to limit the issuer permissions, or add things like timelocks.
I find the term "hidden puzzle" a bit confusing here because it's not the same thing as the hidden puzzle in the standard transaction. In this case the difference is that the hidden puzzle can do anything but the inner puzzle always gets wrapped to force the revocation layer to continue existing.
It will be even more confusing if we end up with driver code which has a hidden puzzle for the inner puzzle which then goes into this revocation layer which again has a hidden puzzle which is a completely different thing.
One thing to note is that, given an unrevocable (i.e., vanilla) CAT coin with the same TAIL hash, value can be transferred between the two (i.e., you can spend revocable and unrevocable coins together and change the amounts in each category - given they have the same TAIL id). Not a problem if the issuer creates all CATs with revocation layers.
Revocable secure the bag will be interesting. You could unwind part of the bag and then revoke other parts to create a new bag. Not sure if there is a use-case for it but we get that for free.
Alternatively we could purposefully not use the revocable layer in the bag but have it add the layer at the end to reduce the cost of unwinding the bag.
@freddiecoleman I don't think the hidden puzzle is a different thing.
It's a puzzle that is only revealed when it's being used. Until then it just sits there, as a puzzle hash.
That's the case for both the delegated_or_hidden puzzle and the revocation_layer.
The fact that only the inner puzzle is being wrapped is a property of the revocation layer, not the hidden puzzle.
@Yakuhito Yes, the TAIL is not the part that makes this revocable. So if the issuer wants the CAT to be revocable, they have to use the revocation_layer.
Do we need to clarify that in the CHIP?
Do we need to clarify that in the CHIP?
Yes we should clarify this. Feel free to do so, else I can also do it.
@freddiecoleman I don't think the
hidden puzzleis a different thing. It's a puzzle that is only revealed when it's being used. Until then it just sits there, as a puzzle hash.That's the case for both the
delegated_or_hiddenpuzzle and therevocation_layer.The fact that only the inner puzzle is being wrapped is a property of the revocation layer, not the hidden puzzle.
In the standard transaction even the hidden puzzle hash doesn't get revealed on a normal spend. In this case the hidden puzzle hash is curried in so if the issuer at any point revokes a CAT you will know what the hidden puzzle is. For our use-case it doesn't really matter since the hidden puzzle for a CAT is always the same so it's not really an issue but it's generic enough to support other use-cases and is different to the standard tx hidden puzzle.
I would recommend allowing the option when the CATs are issued, the issuer can choose to whether or not to enable time limited clawbacks by the holder. An issuer could be tricked in to revoking a CAT by a bad actor, so if the holder notices a revocation they weren't a party to they could clawback the CAT.
I would recommend allowing the option when the CATs are issued, the issuer can choose to whether or not to enable time limited clawbacks by the holder. An issuer could be tricked in to revoking a CAT by a bad actor, so if the holder notices a revocation they weren't a party to they could clawback the CAT.
Thanks for the suggestion. My initial thought is that this would be possible, but it require a bunch of extra work to implement. The reason for this is because the coins can circulate freely. For your idea to work, we would need to add a new layer with the clawback mechanism pointing to the current holder. This would need to be recalculated -- and the new layer would need to be updated -- every time the coin is spent.
It's an interesting concept, but I don't think it solves anything with our current use case. We only need the revocation layer. And this CHIP is nearly complete, so I don't think it makes sense to add the new complexity. It's always possible for someone (including you) to create a new CHIP with this idea at some point.
How is the burn address meant to interact with revocation? It seems I could potentially make a token appear as burned (as interpreted by a block explorer) and then undo that with a revocation. That seems to be a dangerous attack vector for various types of scams.
burn
Good point -- "burn" is incompatible with revocable CATs. They can, however, be melted, and that is permanent.
burn
Good point -- "burn" is incompatible with revocable CATs. They can, however, be melted, and that is permanent.
I'd like to see more clarification around the expected behavior, unless we're comfortable just saying it is "undefined." I sent some revocable CATs to the burn address in testnet yesterday and revoked them out. Maybe it's just an educational issue for users, wallet developers, and block explorers. I could definitely see a sketchy CAT issuer try to claim a huge percentage of their supply was burned, but then yanking it back after the market responded to the perceived small supply.
It is nice the issuer can melt them, but I do think further guard rails may be needed, even if only in education.
I mean, a sketchy multi issuance CAT issuer can also just burn half their supply and mint it back, so this doesn't change that. You have to trust Permuto (as an example of a Revocable CAT issuer). There's an S-1 and regulations for a reason. Anything short of a single issuance with a clearly distributed supply relies on trust IMO.
Put simply: With multi issuance CATs, the issuer has full control over the supply. With Revocable CATs they have full control over all coins. Anything else is a social or legal contract.
@Rigidity Everything you've said is correct, but it doesn't take away from the concern that most of this behavior is brand new and needs to be understood by the user base. There are very few multi-issue CATs in play at this time, and fewer that have heavy adoption.
Edit: I'm not looking for anything crazy here as a change. A one-liner in the CHIP saying burning is not a supported operation for revocable CATs, or that it no longer offers the finality it does with non-revocable CATs would address my concerns.
@Rigidity Everything you've said is correct, but it doesn't take away from the concern that most of this behavior is brand new and needs to be understood by the user base. There are very few multi-issue CATs in play at this time, and fewer that have heavy adoption.
Edit: I'm not looking for anything crazy here as a change. A one-liner in the CHIP saying burning is not a supported operation for revocable CATs, or that it no longer offers the finality it does with non-revocable CATs would address my concerns.
This is a good point. I'll update the CHIP with this info.
I added a note to the Security section of this CHIP making it clear that one should never assume that revocable CATs have been burned because the issuer can always revoke them, including from a burn address.
This CHIP is now in Last Call. If no changes are required in the next two weeks, then it will be moved to Final status and no further changes will be allowed.