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:
Note: To make sure you have everything you need to follow along, be sure to check out these getting started resources. There, you will see how to create a Hedera testnet account, and then you can configure your development environment. If you want the entire code used, skip to the Code Check section below.
When you create a token with HTS, you can optionally use the .setKycKey(<key>) method to enable this <key> to grant (or revoke) 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.
We will continue with the NFT example from Part 1. However, we have to 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.
// ENABLE TOKEN KYC FOR ALICE AND BOB let aliceKyc = await kycEnableFcn(aliceId); let bobKyc = await kycEnableFcn(bobId); console.log(`- Enabling token KYC for Alice's account: ${aliceKyc.status}`); console.log(`- Enabling token KYC for Bob's account: ${bobKyc.status}\n`);
// KYC ENABLE FUNCTION ========================================== async function kycEnableFcn(id) { let kycEnableTx = await new TokenGrantKycTransaction() .setAccountId(id) .setTokenId(tokenId) .freezeWith(client) .sign(kycKey); let kycSubmitTx = await kycEnableTx.execute(client); let kycRx = await kycSubmitTx.getReceipt(client); return kycRx; }
Console output:
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 longer receive or send that token. Here’s sample code for disabling token KYC on Alice’s account:
// DISABLE TOKEN KYC FOR ALICE let kycDisableTx = await new TokenRevokeKycTransaction() .setAccountId(aliceId) .setTokenId(tokenId) .freezeWith(client) .sign(kycKey); let kycDisableSubmitTx = await kycDisableTx.execute(client); let kycDisableRx = await kycDisableSubmitTx.getReceipt(client); console.log(`- Disabling token KYC for Alice's account: ${kycDisableRx.status} \n`);
Note: The following sections require that Alice has token KYC enabled.
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 of 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>), then 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.
// QUERY TO CHECK INITIAL KYC KEY var tokenInfo = await tQueryFcn(); console.log(`- KYC key for the NFT is: \n${tokenInfo.kycKey.toString()} \n`); // UPDATE TOKEN PROPERTIES: NEW KYC KEY let tokenUpdateTx = await new TokenUpdateTransaction() .setTokenId(tokenId) .setKycKey(newKycKey) .freezeWith(client) .sign(adminKey); let tokenUpdateSubmitTx = await tokenUpdateTx.execute(client); let tokenUpdateRx = await tokenUpdateSubmitTx.getReceipt(client); console.log(`- Token update transaction (new KYC key): ${tokenUpdateRx.status} \n`); // QUERY TO CHECK CHANGE IN KYC KEY var tokenInfo = await tQueryFcn(); console.log(`- KYC key for the NFT is: \n${tokenInfo.kycKey.toString()}`);
// TOKEN QUERY FUNCTION ========================================== async function tQueryFcn() { var tokenInfo = await new TokenInfoQuery().setTokenId(tokenId).execute(client); return tokenInfo; }
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 we don’t have Alice’s and Bob’s signatures 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.
// CREATE THE NFT TRANSFER FROM BOB->ALICE TO BE SCHEDULED // REQUIRES ALICE'S AND BOB'S SIGNATURES let txToSchedule = new TransferTransaction() .addNftTransfer(tokenId, 2, bobId, aliceId) .addHbarTransfer(aliceId, -200) .addHbarTransfer(bobId, 200); // SCHEDULE THE NFT TRANSFER TRANSACTION CREATED IN THE LAST STEP let scheduleTx = await new ScheduleCreateTransaction().setScheduledTransaction(txToSchedule).execute(client); let scheduleRx = await scheduleTx.getReceipt(client); let scheduleId = scheduleRx.scheduleId; let scheduledTxId = scheduleRx.scheduledTransactionId; console.log(`- The schedule ID is: ${scheduleId}`); console.log(`- The scheduled transaction ID is: ${scheduledTxId} \n`);
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 schedule 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 schedule 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.
// SUBMIT ALICE'S SIGNATURE FOR THE TRANSFER TRANSACTION let aliceSignTx = await new ScheduleSignTransaction().setScheduleId(scheduleId).freezeWith(client).sign(aliceKey); let aliceSignSubmit = await aliceSignTx.execute(client); let aliceSignRx = await aliceSignSubmit.getReceipt(client); console.log(`- Status of Alice's signature submission: ${aliceSignRx.status}`); // QUERY TO CONFIRM IF THE SCHEDULE WAS TRIGGERED (SIGNATURES HAVE BEEN ADDED) scheduleQuery = await new ScheduleInfoQuery().setScheduleId(scheduleId).execute(client); console.log(`- Schedule triggered (all required signatures received): ${scheduleQuery.executed !== null}`); // SUBMIT BOB'S SIGNATURE FOR THE TRANSFER TRANSACTION let bobSignTx = await new ScheduleSignTransaction().setScheduleId(scheduleId).freezeWith(client).sign(bobKey); let bobSignSubmit = await bobSignTx.execute(client); let bobSignRx = await bobSignSubmit.getReceipt(client); console.log(`- Status of Bob's signature submission: ${bobSignRx.status}`); // QUERY TO CONFIRM IF THE SCHEDULE WAS TRIGGERED (SIGNATURES HAVE BEEN ADDED) scheduleQuery = await new ScheduleInfoQuery().setScheduleId(scheduleId).execute(client); console.log(`- Schedule triggered (all required signatures received): ${scheduleQuery.executed !== null} \n`);
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.
// VERIFY THAT THE SCHEDULED TRANSACTION (TOKEN TRANSFER) EXECUTED oB = await bCheckerFcn(treasuryId); aB = await bCheckerFcn(aliceId); bB = await bCheckerFcn(bobId); console.log(`- Treasury balance: ${oB[0]} NFTs of ID: ${tokenId} and ${oB[1]}`); console.log(`- Alice balance: ${aB[0]} NFTs of ID: ${tokenId} and ${aB[1]}`); console.log(`- Bob balance: ${bB[0]} NFTs of ID: ${tokenId} and ${bB[1]}`);
// BALANCE CHECKER FUNCTION ========================================== async function bCheckerFcn(id) { balanceCheckTx = await new AccountBalanceQuery().setAccountId(id).execute(client); return [balanceCheckTx.tokens._map.get(tokenId.toString()), balanceCheckTx.hbars]; }
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!
https://github.com/ed-marquez/hedera-sdk-js/blob/main/examples/hts-nftP2-kyc-upate-schedule.js