CHIP-0038: Revocable CATs

[danieljperry]

No description provided.

[danieljperry]

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.

[SlowestTimelord]

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.

[hoffmang9]

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.

[greimela]

@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.

[freddiecoleman]

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.

[Yakuhito]

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.

[freddiecoleman]

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.

[greimela]

@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.

[greimela]

@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?

[danieljperry]

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]

@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.

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.

[danieljperry]

This CHIP is now in Review. Please leave your reviews here.

[Dishwasha]

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.

[danieljperry]

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.