Skip to main content
In Part 1 of the series, you saw how to mint and transfer an NFT using the Hedera Token Service (HTS). Now, in Part 2, you will see how to take advantage of the flexibility you get when you create and configure your tokens with HTS. More specifically, you will learn how to:
  • Enable and disable a KYC flag for a token (KYC stands for “know your customer”)
  • Update token properties (only possible if it’s a mutable token. Hint: AdminKey)
  • Schedule transactions (like a token transfer)

Prerequisites

We recommend you complete the following introduction to get a basic understanding of Hedera transactions. This example does not build upon the previous examples. If you want the entire code used for this tutorial, skip to the Code Check section below.

Understanding KYC and Hedera Tokens

KYC Key

When you create a token with HTS, you can optionally use the .setKycKey(<key>) method to enable this <key> to grant (or revoke) the KYC status of other accounts so they can transact with your token. You would consider using the KYC flag when you need your token to be used only within parties that have been “authorized” to use it. For instance, known registered users or those who have passed identity verification. Think of this as identity and compliance features like anti-money laundering (AML) requirements or any type of off-ledger authentication mechanism, like if a user has signed up for your application. The .setKycKey(<key>) method is not required when you create your token, so if you don’t use the method that means anyone who is associated with your token can transact without having to be “authorized”. No KYC key also means that KYC grant or revoke operations are not possible for the token in the future.

Enable Token KYC on an Account

We will continue with the NFT example from Part 1. However, we must create a new token using .setKycKey(<key>). Before users can transfer the newly created token, we must grant KYC to those users, namely Alice and Bob.
nft-part2.js
Console output:

Disable Token KYC on an Account

After the KYC flag has been set to true for a user, the administrator, identity provider, or compliance manager can revoke or disable the KYC flag. After KYC is disabled for a user, he or she can no longer receive or send that token. Here’s a sample code for disabling token KYC on Alice’s account:
nft-part2.js
Console output:
Note: The following sections require Alice to have token KYC enabled.

Updating tokens

If you create a token using the .setAdminKey(<key>) method, then you can “update” that token, meaning change its metadata and characteristics. For instance, you can change the token name, symbol, or the keys that are associated with its controlled mutability. You could create a token that initially has a 1-to-1 key for minting and burning and, over time, change this to a threshold or multi-signature key. You can rotate the keys associated with compliance and administration or even remove them entirely, offering a more decentralized approach over time. On the other hand, if you create a token without using .setAdminKey(<key>), that token is immutable, and its properties cannot be modified. In our example, we start by checking the initial KYC key for the token, then we update the KYC key from <kycKey> to <newKycKey>, and then we query the token again to make sure the key change took place.
nft-part2.js
Console output:

Schedule Transactions

Scheduled transactions enable you to collect the required signatures for a transaction in preparation for its execution. This can be useful if you don’t have all the required signatures for the network to immediately process the transaction. Currently, you can schedule: TransferTransaction() (for hbar and HTS tokens), TokenMintTransaction(), TokenBurnTransaction(), and TopicMessageSubmitTransaction(). More transactions are supported with new releases. Now, we will schedule a token transfer from Bob to Alice using scheduled transactions. This token transfer requires signatures from both parties. Given that Alice’s and Bob’s signatures are not immediately available (for the purposes of this example), we first create the NFT transfer without signatures. Then, we create the scheduled transaction using the constructor ScheduleCreateTransaction() and specify the NFT transfer as the transaction to schedule using the .setScheduledTransaction() method.
nft-part2.js
Console output:
The token transfer is now scheduled, and it will be executed as soon as all required signatures are submitted. Note that the scheduled transaction IDs (scheduledTxId in this case) have a “scheduled” flag that you can use to confirm the status of the transaction. As of the time of this writing, a scheduled transaction has 30 minutes to collect all the required signatures before it can be executed or it expires (deleted from the network). If you set an <AdminKey> for the scheduled transaction, then you can delete it before its execution or expiration. Now, we submit the required signatures and get schedule information to check the status of our transfer.
nft-part2.js
Console output:
The scheduled transaction was executed. It is still a good idea to verify that the transfer happened as we expected, so we check all the balances once more to confirm.
nft-part2.js
Console output:

Conclusion

In this article, you saw examples of the flexibility you get when you create and configure your tokens with HTS - in a transparent and cryptographically provable way. Take advantage of this flexibility to tackle entirely new opportunities in the tokenization industry!
nft-part2.js

Additional Resources

Project Repository

Writer: Ed, DevRel Engineer

Editor: Krystal, Senior DX Engineer