Extend Mint and Burn Functionality for HTS Tokens

[mshakeg]

Summary

This proposal aims to extend the mint and burn functionality of Hedera Token Service (HTS) tokens to allow specifying the recipient account to which tokens are minted and the account whose tokens are to be burnt directly without having to first mint tokens to the treasury account and then transfer to the recipient or transfer tokens that are to be burnt to the treasury account before burning those tokens newly held by the treasury. This will make the minting and burning process more flexible and efficient, similar to the ERC20/721 token standards.

Motivation

Currently, the mint and burn functionality in HTS tokens involves the treasury account. The treasury account receives the initial token supply and any additional tokens that are minted. When tokens are burned, the supply is decreased from the treasury account. The ERC20 and ERC721 token standards typically have the following internal mint and burn functions that allow the ERC20/721 token contract to mint a fungible or non-fungible token directly to a specified account or burn a token from a specified account[1][2]:

// ERC20
function _mint(address account, uint256 amount) internal;
function _burn(address account, uint256 amount) internal;

// ERC721
function _mint(address to, uint256 tokenId) internal;
function _burn(uint256 tokenId) internal;

By allowing direct minting to the recipient account and direct burning from a specified account, the overall number of transactions required is reduced. This results in lower transaction fees as it avoids having to first transfer tokens to the treasury.

Specification

1. Extend the mint function:

   Add an optional "recipient" parameter to the TokenMintTransaction. When specified, the newly minted tokens will be credited directly to the recipient's account instead of the treasury account. If the "recipient" parameter is not provided, the minted tokens will be credited to the treasury account, as per the current functionality.

2. Extend the burn function:

   Add an optional "burnFrom" parameter to the TokenBurnTransaction. This parameter will specify the account from which the tokens will be burnt. If the "burnFrom" parameter is not provided, the tokens will be burnt from the treasury account, as per the current functionality.

The IHederaTokenService interface can be extended as follows to enable this functionality via the HTS precompile contract provided the calling account(i.e. msg.sender) has the required "supplyKey" authorization to perform the mint or burn operation.

/// Mints an amount of the token to the specified account
/// @param recipient The account to which tokens are minted to.
/// @param token The token for which to mint tokens. If token does not exist, transaction results in
///              INVALID_TOKEN_ID
/// @param amount Applicable to tokens of type FUNGIBLE_COMMON.
///               Amount must be a positive non-zero number represented in the lowest denomination of the
///               token. The new supply must be lower than 2^63.
/// @param metadata Applicable to tokens of type NON_FUNGIBLE_UNIQUE. A list of metadata that are being created.
///                 Maximum allowed size of each metadata is 100 bytes
/// @return responseCode The response code for the status of the request. SUCCESS is 22.
/// @return newTotalSupply The new supply of tokens. For NFTs it is the total count of NFTs
/// @return serialNumbers If the token is an NFT the newly generate serial numbers, othersise empty.
function mintToken(
  address recipient,
  address token,
  uint64 amount,
  bytes[] memory metadata
)
  external
  returns (
      int256 responseCode,
      uint64 newTotalSupply,
      int64[] memory serialNumbers
  );

/// Burns an amount of the token from the specified account
/// @param from Applicable to tokens of type FUNGIBLE_COMMON. The account that "amount" will be burnt from
///              INVALID_TOKEN_ID
/// @param token The token for which to burn tokens. If token does not exist, transaction results in
///              INVALID_TOKEN_ID
/// @param amount  Applicable to tokens of type FUNGIBLE_COMMON.
///                Amount must be a positive non-zero number, not bigger than the token balance of `from`
///                account (0; balance], represented in the lowest denomination.
/// @param serialNumbers Applicable to tokens of type NON_FUNGIBLE_UNIQUE. The list of serial numbers to be burned.
/// @return responseCode The response code for the status of the request. SUCCESS is 22.
/// @return newTotalSupply The new supply of tokens. For NFTs it is the total count of NFTs
function burnToken(
  address burnFrom,
  address token,
  uint64 amount,
  int64[] memory serialNumbers
) external returns (int256 responseCode, uint64 newTotalSupply);

Backwards Compatibility

This proposal introduces new optional recipient and burnFrom parameters to the "mint" and "burn" functions respectively. Existing implementations using the current mint and burn functions will continue to work as expected. If these optional parameters are omitted it can be assumed that the recipient and burnFrom is effectively the treasury account as is the existing behaviour.

Considerations

One of the concerns with extending the burn functionality to allow burning tokens from any account is the potential abuse of privileges associated with the supplyKey. Currently, the supplyKey has the authorization to burn tokens only from the treasury account, and granting it the ability to burn tokens from other accounts may lead to security risks.

To address this concern and maintain a balance between the extended functionality and security, I propose two possibilities while preferring the latter:

Approach 1: Constraint on the supplyKey privileges

The supplyKey should only be allowed to specify the burnFrom account if it is the same as the key associated with the treasury account. This ensures that the extended burn functionality doesn't unintentionally grant excessive privileges to the supplyKey while still offering more flexibility in burning tokens. In this approach, developers are expected to limit this constraint within a smart contract where both the supplyKey and the treasury account belong to the contract that created the token. This allows arbitrary validation internal to the contract and, if implemented correctly, ensures that the contract does not burn tokens from an account other than the intended one.

Approach 2: Require signatures from both burnFrom account and supplyKey

Alternatively, to not increase any security risks on existing HTS tokens, a transaction that specifies the burnFrom parameter should be signed by both the burnFrom account and the supplyKey. This approach ensures that the owner of the burnFrom account consents to burning tokens from their account, adding an extra layer of security. In the case of a contract transaction, the burnFrom parameter to the burnToken precompile call should either be tx.origin or msg.sender(or tx.origin/msg.sender should at least have a sufficient token allowance for burnFrom), maintaining consistency and ensuring that the transaction originator or the current contract (in case of nested calls) is the one providing consent for the burn operation.

By adopting either of these approaches, the proposal maintains a balance between providing extended functionality and ensuring the security of token holders.

References

1. OpenZeppelin ERC20 Contract
2. OpenZeppelin ERC721 Contract

[Ashe-Oro]

you can use the WIPE key on an HTS token to "burn" it from a non-treasury account while being able to specify the exact NFT serial numbers to wipe/burn. Does that cover your burnFrom case?

https://docs.hedera.com/hedera/sdks-and-apis/hedera-api/token-service/tokenwipeaccount

[mshakeg]

Thanks for the feedback, the wipe functionality seems to correspond with the burn functionality proposed here, so I guess it's only the mint functionality that remains.

[Ashe-Oro]

ok perfect and thank you for the feedback on mint/transfer. I've had other teams request the ability to transfer directly within the mint function...so you are not alone :)

[HGraphPunks]

I agree with @Ashe-Oro, wipe key exists and provides same functionality so much easier to transition to teach engineers to use it than completely change SupplyKey to satisfy that need.

[Ashe-Oro]

one potential issue with recipient param is that the receiving account will probably not have associated with the newly minted token and I expect the transfer to fail. The mint-then-transfer action will require all users to associate with the tokenId (ie NFT Collection) after it has been created, but before the NFT has been minted.

Fungible tokens will encounter a similar token association issue which again I expect to see a high degree of transfer failure due to TOKEN_NOT_ASSOCIATED_TO_ACCOUNT

[Ashe-Oro]

Hi again, ok a few things.

1. For associate-then-mint-then-transfer the receiving user will need to sign a tx to associate with the token and the account minting the token will not have the rights to associate on behalf of the receiver. Perhaps I don't understand the flow, but it seems that your example is expecting the account minting/transferring to sign on behalf of the receiver?

2. It doesn't look like an EVM precompile query exists to test if a token has been associated with an account. I believe your best bet would be to use balanceOf( ) and test if the balance is >=0 (since tokens associated, but not owned will have a balance of 0, whereas a token not associated will not be represented in the key-value pair of the token-amount.

[mshakeg]

@Ashe-Oro I'll try to address both points below.

1. Would it not be possible to aggregate the signatures from both the supplyKey and recipient off-chain? Within the context of a contract, there's no need to do this off-chain signature aggregation as if tx.origin is the recipient and the contract calling the precompile issueToken function(i.e. msg.sender) is the supplyKey then you've got both signatures.

2. What does IERC20(token).balanceOf(account) return when the account is not associated with the token? My assumption was that it returned 0, which isn't really helpful as you can be associated but not own the token(i.e. balance is also 0).

[Ashe-Oro]

thanks for such a quick turn around time on the replies 💪

1. Yep, i believe you are exactly right. If using native Hedera, you'd need to aggregate off-chain, but within a contract you could do it as you describe. For now, the issue is that intermediate hop to the Treasury account and the settlement/finality time before being able to transfer out of the treasury. For now the NFTs would need to be in the control of the contract (so pre-minted).

2. I will need to test this, but I believe it will return either null or undefined. When querying the mirror node, a balance of 0 means that the token has been associated. Any tokens that don't return a balance (even of 0) means that the token has not been associated. For example: https://mainnet-public.mirrornode.hedera.com/api/v1/accounts/0.0.604193/

[mshakeg]

@Ashe-Oro sure, it's getting a bit late here, so just want to answer any questions before I go AFK.

For now, the issue is that intermediate hop to the Treasury account and the settlement/finality time before being able to transfer out of the treasury.

That is indeed the issue that this proposal attempts to solve.

The evm has no concept of null or undefined, and so I would expect IERC20(token).balanceOf(account) to return the default value for a uint256 which is 0 or possibly though unlikely revert if account is not associated with token. I'm not sure how the Hedera JSON RPC Relay handles ERC20#balanceOf eth_calls but it's possible it manages it like any other eth_call and submit a ContractCallQuery(and not a mirror node /api/v1/accounts/accountId request) to a consensus node which likely returns the default uint256 value(i.e. 0).

[mshakeg]

@Ashe-Oro just confirmed that IERC20(token).balanceOf(account) returns 0 if the account is not associated with token, so it won't help in determining token association.

[Ashe-Oro]

ok, i will create an issue to add isAssociated the the precompile. Thanks for calling this out.

[mshakeg]

Hi @Ashe-Oro I just wanted to follow up on the progress of adding an isAssociated view function to the hts precompile.

[se7enarianelabs]

@mshakeg @Ashe-Oro
Here you have an example smart contract snippet, where the smart contract is the supply key and also the treasury account of an HTS NFT collection.

• The contract is initialized by calling the initialize() function which create a new NFT collection in which the contract is the treasury account and also the supply key.

• When a user calls the mint function, the contract executes the following steps:

  1. Mints a new NFT by calling mintToken function
  2. Associates the caller with the NFT. It's important to note that there is currently no precompile available for checking if an account is already associated. Therefore, we call the associate function every time. If the user is already associated, we receive the response code HederaResponseCodes.TOKEN_ALREADY_ASSOCIATED_TO_ACCOUNT, which creates a failed child transaction. However, we continue to proceed with our contract flow.
  3. We call the transferNFTDelegate function, to transfer the NFT to the receiver (who is also the caller).

It's important to note that we check the response code after every step, and if an error occurs, we revert.

You can find the hts-precompile imports here

pragma solidity ^0.8.0;
import "../hts-precompile/HederaTokenService.sol";
import "../hts-precompile/ExpiryHelper.sol";
import "../hts-precompile/KeyHelper.sol";
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";


contract ExampleContract is HederaTokenService, ExpiryHelper, KeyHelper {
    address private nftTokenAddress;
    bytes[] private metadata = new bytes[](1); 


    event ResponseCode(int responseCode);


    function initialize() public payable {
        createNonFungibleToken();
    }

    constructor () public {
        metadata[0] = "ipfs://bafkreigf4jlrunzkwhiqcd6jev4ho2xaae7nbrzintppswyqbxuighngau";
    }


    function mintToken() internal
        returns (int responseCode, uint64 newTotalSupply, int64[] memory serialNumbers) {
        (bool success, bytes memory result) = precompileAddress.call(
            abi.encodeWithSelector(IHederaTokenService.mintToken.selector,
            nftTokenAddress, 0, metadata));
        (responseCode, newTotalSupply, serialNumbers) =
            success
                ? abi.decode(result, (int32, uint64, int64[]))
                : (HederaResponseCodes.UNKNOWN, 0, new int64[](0));
    }

    function transferNFTDelegate(address token, address sender, address receiver, int64 serialNumber) internal
    returns (int responseCode)
    {
        (bool success, bytes memory result) = precompileAddress.delegatecall(
            abi.encodeWithSelector(IHederaTokenService.transferNFT.selector,
            token, sender, receiver, serialNumber));
        responseCode = success ? abi.decode(result, (int32)) : HederaResponseCodes.UNKNOWN;
    }

    function createNonFungibleToken() internal {
        // Instantiate the list of keys we'll use for token create
        IHederaTokenService.TokenKey[] memory keys = new IHederaTokenService.TokenKey[](1);
        // use the helper methods in KeyHelper to create basic key
        keys[0] = getSingleKey(KeyType.SUPPLY, KeyValueType.CONTRACT_ID, address(this));

        IHederaTokenService.Expiry memory expiry = IHederaTokenService.Expiry(
            0, address(this), 8000000
        );

        IHederaTokenService.HederaToken memory token = IHederaTokenService.HederaToken(
            "NFT", "NFT", address(this), "", true, 1000, false, keys, expiry
        );

        (int responseCode, address tokenAddress) = createNonFungibleTokenDelegate(token);

        if (responseCode != HederaResponseCodes.SUCCESS) {
            revert ((string)(abi.encodePacked(responseCode)));
        }

        nftTokenAddress = tokenAddress;
    }

    function mint() public returns (int responseCode) {
        (int responseMinting, uint64 newTotalSupply, int64[] memory serialNumbers) = mintToken();
        emit ResponseCode(responseMinting);
        if (responseMinting != HederaResponseCodes.SUCCESS) {
            revert((string)(abi.encodePacked(responseMinting)));
        }

        responseCode = HederaTokenService.associateToken(msg.sender, nftTokenAddress);
        emit ResponseCode(responseCode);
        if (responseCode != HederaResponseCodes.SUCCESS && 
            responseCode != HederaResponseCodes.TOKEN_ALREADY_ASSOCIATED_TO_ACCOUNT) {
            revert((string)(abi.encodePacked(responseCode)));
        }

        responseCode = transferNFTDelegate(nftTokenAddress, address(this), msg.sender, serialNumbers[0]);
        emit ResponseCode(responseCode);
        if (responseCode != HederaResponseCodes.SUCCESS) {
            revert((string)(abi.encodePacked(responseCode)));
        }

    }
}

[mshakeg]

Hi @se7enarianelabs thanks for the feedback.

I've actually already considered this and would opt to not do this and it seems very wasteful at least from a gas perspective as if I'm not mistaken a failed associateToken HTS precompile call costs the same amount of gas as a successful call. Hence, I suggested adding an isAssociated view function to the HTS precompile which should be much cheaper and similar in gas cost to an IERC20(token).balanceOf(account) call.

In any case, auto-association is peripheral functionality to the core of what is being proposed here.