Adding pause feature to Hedera Token Service

[chung-chao]

• hip: (TBD)
• title: Pause feature on Hedera Token Service
• author: chung@xfers.com, junhao@xfers.com, zhikai@xfers.com
• type: Standards Track
• category: Application
• status: Idea
• created: 2021-08-09
• discussions-to: (TBD)
• updated: 2021-08-16

Abstract

Stablecoin tokens issued on various protocols usually have a pause function included as part of their smart contract. This allows the token issuer to pause the whole smart contract for contract upgrading, emergencies and other scenarios. This function is currently not available in the Hedera Token Service. Therefore, we propose to establish a standard format for pause feature in HTS.

Motivation

There are several reasons that would justify the need for a pause feature;

1. Compliance with regulatory frameworks across jurisdictions in the case of regulated token issuance (e.g. stablecoins)
2. Compliance with law enforcement requests
3. Parity with functionalities offered by other blockchain protocols in the case of multichain asset issuance.

We propose to establish a standard for HTS where a pause feature can be included for tokens deployed via HTS. This will be opt-in and allows token issuers the flexibility of including or excluding the pause functionality based on the token issuers' requirements.

Specification

To be Completed.

• Add a pauseKey to create token spec. The key can do both pause and unpause a token

  message TokenCreateTransactionBody {
      string name = 1; // The publicly visible name of the token, limited to a UTF-8 encoding of length <tt>tokens.maxSymbolUtf8Bytes</tt>.
      string symbol = 2; // The publicly visible token symbol, limited to a UTF-8 encoding of length <tt>tokens.maxTokenNameUtf8Bytes</tt>.
      uint32 decimals = 3; // For tokens of type FUNGIBLE_COMMON - the number of decimal places a token is divisible by. For tokens of type NON_FUNGIBLE_UNIQUE - value must be 0
      uint64 initialSupply = 4; // Specifies the initial supply of tokens to be put in circulation. The initial supply is sent to the Treasury Account. The supply is in the lowest denomination possible. In the case for NON_FUNGIBLE_UNIQUE Type the value must be 0
      AccountID treasury = 5; // The account which will act as a treasury for the token. This account will receive the specified initial supply or the newly minted NFTs in the case for NON_FUNGIBLE_UNIQUE Type
      Key adminKey = 6; // The key which can perform update/delete operations on the token. If empty, the token can be perceived as immutable (not being able to be updated/deleted)
      ...
      ...
      ...
      Key fee_schedule_key = 20; // The key which can change the token's custom fee schedule; must sign a TokenFeeScheduleUpdate transaction
      repeated CustomFee custom_fees = 21; // The custom fees to be assessed during a CryptoTransfer that transfers units of this token
      Key pauseKey = 22; // [New] The key which can pause the token. If empty, pause is not possible
  
  }

Backwards Compatibility

This HIP idea is entirely opt-in, and does not break any existing functionality. It simply provides standard of pause for HTS and the issuer can follow in order to meet requirement and integrity.

Security Implications

No known security concerns. Community comment is welcome here.

How to Teach This

N/A

Reference Implementation

N/A

Rejected Ideas

N/A

Open Issues

N/A

References

[0] XSGD fiat token contract: https://etherscan.io/address/0x2e21613c4eed4a5af1e9223edcfc8640138da7fb

[1] Hedera Token Service SDK documentation:
https://docs.hedera.com/guides/docs/hedera-api/token-service/tokenservice

Copyright/license

This document is licensed under the Apache License, Version 2.0 -- see LICENSE or (https://www.apache.org/licenses/LICENSE-2.0)

[bugbytesinc]

Suggest adding a "pause" administrative key to the create token spec., not all tokens will want this feature.

[chung-chao]

@bugbytesinc Thanks for your suggestion. Just updated the idea 👍