CPS-???? | Properly burning NFTs / tokens

[matiwinnetou]

(rendered version in branch)

[rphair]

Thanks for posting this @matiwinnetou - marked officially as in Draft stage according to the document title & the rudimentary stage of development. When ready for review it can be marked as such.

[rphair]

@matiwinnetou since today's CIP meeting acknowledged that this proposal is still a bit "thin" - a bit like a feature request for wallets - could you include some use cases for what NFT / token burns would look like, as a way of filling out the proposal and identifying components that might exist beyond the wallets themselves?

[nielstron]

I am willing to take this up and have a solution suggestion:

Instead of native scripts, I suggest users normally use Smart Contract tokens. I will try to compile a set of sample codes to emulate native script behaviour (most importantly the signature stuff) or maybe even an automatic tool that converts a native script into a Smart Contract.

This smart contract would then enforce the native script conditions for minting, but always allow burning.

Tutorials for minting/burning NFTs should be rewritten to use this smart contract instead of native tokens to make sure that at least all future tokens (that have no particular reason not to) are compatible

Extended reasoning: there are tokens that DO NOT want to be burned under any circumstances i.e. pool tokens certifying the correctness of a pool. Users should be able to opt-in into having their token burned at any time and it should be as simple as possible for them.

There can be an optional tag within the UPLC script of such a minting policy or added with some specific metadata tx so that wallets can distinguish between tokens that DO support this behaviour and tokens that DO NOT.

[nielstron]

The referenced PR shows a sample script that would compile to only 750 bytes of Smart Contract and cost 0.05 ada to execute, IMO feasible (and much more powerful) as a new default for Cardano Native Tokens

[nielstron]

I wrote up a small sample smart contract that fully emulates simple scripts. This can be used as a basis for supercharged native scripts... such as ones that skip condition checking if they're invoked only to burn tokens.

OpShin/opshin#67

[matiwinnetou]

@nielstron - isn't your solution kind of like full smart contract based ERC-721 tokens, what about existing native tokens that have ADA locked behind them? I must confess I don't know ERC-721 spec but I assume it is possible for owners to burn those tokens?

[nielstron]

@matiwinnetou I also don't know about ERC-721.

I know about the proposal to implement ERC-20 tokens by @michele-harmonic in #444 . This is different in a sense that it would still make use of Cardano Native Tokens and not simulate them within contract datums.

Further I would suggest that we should not retrospectively change the guarantees made towards token creators (which only increases the potential for insecurity and problems with finite gain, only affecting tokens minted so far). Rather I suggest establishing a new standard that applies to all new tokens with no additional risk and infinite gain (affecting all future tokens).

[rphair]

Nice to see that #479 has finally been presented as a solution for this.

[michaelpj]

In the past we have discussed a much simpler solution: simply don't require the minting policy script to be run when burning tokens. That is: you can always do it. We considered this right from the beginning in Mary.

The argument for why this is okay is quite simple: if you can send some tokens to an output, you can effectively send those tokens to the bin by sending them to an unspendable output. An unspendable output is more-or-less equivalent to burning tokens as far as the rest of the system is concerned, since they can never interact with anything else ever again. The only difference is they still show up in the UTXO set (and eat the min-ada deposit!).

I have always been a bit uncertain about this proposal but I think it a) achieves the goal very directly, b) is very simple, c) is very easy to implement, and d) seems pretty safe.

[JaredCorduan]

In the past we have discussed a much simpler solution: simply don't require the minting policy script to be run when burning tokens. That is: you can always do it. We considered this right from the beginning in Mary.

I'd just like to chime in to say that I've always been a strong supporter of this idea.

The other idea that I really like (which perhaps I should write as a CIP) is @redxaxder's "claim check" idea. Think of a hash function as a way to compress data. If I have a large token bundle in a single UTxO, imagine a transaction that exchanges the bundle for the hash of the bundle, thus allowing the min utxo value to decrease. In this form, the tokens are unusable, but if ever you want them back, we would allow for the inverse action, namely exchanging data for the matching hash. And you could have hashes within hashes, an infinite bag of holding.

[michaelpj]

And elaborating on a variant of the "claim check" idea that Jared and I discussed: just allow the elision of the "value" part of an output in favour of a hash, in exactly the same way that we do for the script and datum (script are always hashes, datums can be either). The preimage must be provided whenever needed, which means both when creating the output (to check balancing), and when spending the output (same). But crucially the size of the output in the UTXO would then be smaller and constant, so could have a smaller min-utxo requirement.

[nielstron]

I found out that there is a problem with this specification in combination with CIP 25:
NFT and FT metadata is tagged by the latest minting transaction of the token. However if every user can burn a token, this is technically a minting transaction, hence allowing every holder to arbitrarily change the metadata of their FT (for NFTs this is an obvious non-issue). However I would propose to adjust CIP 25 instead of changing any of the approaches here.

[rphair]

thanks @nielstron - Even with #527 submitted I think it would also be a good idea to add this reservation to the CPS here (as you say, without changing any of the recommended approaches)... since we don't know whether or how that requested modification to CIP-0025 will proceed and should have this issue documented in any case.

[rphair]

p.s. I would be happy to approve #527 right away, but let's try to check first with everybody in the community (as per #527 (review)) who might be affected by removing metadata update privileges from burn transactions 😅

[rphair]

@matiwinnetou this looks Abandoned so we'll close this soon unless you (or another advocate of this proposal) can post some updates & being carrying this forward.