Hedera delegated token burn operations

[anvabr]

Problem description

In the blockchain-based environmental markets, where emissions and offsets are modelled by different tokens, the final stage of these tokens' lifecycle and their very reason to exist is to be 'burned together' - under some (may be very complex) rules. In a way, each such environmental accounting transaction has a 'plus' and a 'minus' side, and when these are 'added' together they in effect 'cancel' each other and thus produce zero, which is recorded as a burn of the tokens representing both sides. Here is some further context:

• The sides can be NFTs and/or FTs, possibly different types on each side.
• The full transaction needs to be atomic.
• The rules (what can and can't be burned together) can be recorded and enforced through a smart contract language.
• Typically each side of such transaction would have been minted by different addresses, and may be owned by different or the same address at the burn time.
• Such operations will be happening on a massive scale.

Currently owing to the 'burn' design, performing such an operation requires complex coordination of parties, is awkward and not scalable.

Proposal

Add a capability for the owner of the token burn key to authorise another address, which can be smart contract or a user address, to execute token burn operation. Such authorisation should have parameters allowing it to be:

• limited by the total number of burned tokens
• limited by the number of tokens burned in one transaction
• limited by the number of burn transactions
• unlimited (i.e. until explicit withdrawal of authorisation)
• ???

There should be an opposite operation, i.e. the owner of the burn key should be able to withdraw the authorisation to burn specific tokens.

Option 1: smart contract rules

In this version an issuer of a token would be able authorise a specific smart contract (address) for burning the token instances. Since smart contracts are immutable and their execution is deterministic the issuer would have certainty that its tokens would be burned if and only if all rules expressed in the code of the smart contract have been followed.

Option 2: core platform implementation

There is value in enabling the actual end-users to execute the burn transaction for a pair of tokens, this way their action would be directly traceable as explicit 'burn'. The disadvantage of this option is that it lacks the flexibility of the smart contract version, and may require implementation of additional parameters/logic to enforce additional rules. The MVP subset of such rules is TBD.

[anvabr]

An update: currently the following high level design is under consideration (@sergmetelin for visibility):

1. The minter of the token creates a smart contract with the functionality to burn instances of this token
2. The minter of the token authorises the smart contract to perform burn operations on the token by listing the smart contract account public key (alias) described in https://hips.hedera.com/hip/hip-631 and https://hips.hedera.com/hip/hip-583 in the keylist for the burn operation. This would allow scalability of the system by allowing the smart contract to burn tokens automatically (a kind of pre-approval), without additional manual approval/action from the minter of the token.
3. The exchange creates the 'match-making' smart contract registering matching pairs of tokens
4. The minters of the token (or another entities they delegated this permission in the smart contract) authorise the exchange smart contract inside the corresponding 'burn' smart contracts (from p.2)

In this configuration the retirement operation would work as follows:

• The current owner of the instances of the tokens of type A and type B, which form both sides of the matching, would call the 'match-making' smart contract specifying the correct amount of both of this tokens as parameters for the call
• The match-making smart contract in turn would call the A token type burn smart contract, and B token type smart contracts
• The 'burn' contracts would verify that the 'match-making' smart contract has been authorised previously to use the retirement functionality of the 'burn' contract.
• The 'burn' smart contracts burn tokens.

The operation is atomic since it is executed from inside the single smart contract call. If any of the 'burn' contracts or the 'match-making' contract reject the submission the entire transaction is reverted.