How to create Hedera Hashgraph Tokens using Hedera Token Service?

In recording the value of tangible assets digitally, tokenization is a revolutionary invention for quick transactions and capturing of data. With the emergence of the first crypto-token Bitcoin, the development of Blockchain has traversed a long way in the field of tokenizing tangible and non-tangible assets digitally. The fundamental purpose of Blockchain and distributed ledger invention has served as the granting and exchange path of tokens.

The platform of Tokenization is constantly being analyzed beyond enterprises and decentralized protocols for safety, transparency, digital currency, and easy flow of virtual transactions. Tokenization has helped the market mechanisms and transactions initiated through its transparency. It allows every person from all industries to participate in the easy flow of digital transactions. This results in the enhanced liquidity of transactions and real-time assets.

It was estimated in research done by a firm that the growth of the tokenization market will expand from US$983 million in 2018 to US$2.6 billion by 2023, showcasing a compound yearly expansion rate of 22 percent. Recently one of the leading accessible online remittance platforms, PayU, initiated the mechanism of token-based payments for all the merchants, in association with Google Pay UPI. PayU also talked about the tokenized attribute that will help the payment platform of 4.5 lakh merchants engage debit cards, credit cards, or Google Pay UPI in case of recurring payments without providing any card credentials.

The online payment and banking industry is advancing to support and initiate new remittance form methods that involve excessive security against forgery, account hacking, account mishandling, and all sort of fraud activities. Hence protection is required for a card, noncard and hybrid exchange mechanism to help reduce unauthorized handling and access of cardholder account information and avoid cross-channel fraud activities. Tokenization as a fundamental concept has made a substantial promise to serve this need of the digital world.

In the year 2001, Trust Commerce had invented the concept of Tokenization to secure sensitive and confidential payment information of their client named Classmates.com. Afterward, the actual application of Tokenization was introduced to payment card information by Shift4 Corporation. It was then laid out to the general public during an industry Security Summit in Las Vegas, Nevada, in 2005. Card tokenization has also acquired positive affirmation throughout the world with Apple Pay, Samsung Pay and Google Pay initiating all sorts of retail payments through cellphone devices, with the collaboration of card web, namely the VISA, Mastercard, American Express, Discover, JCB and a lot more.

What is Tokenization?

Tokenization refers to the mechanism of issuing blockchain tokens in exchange for real-time assets. Tokenization also generates different tokens such as equity, utility and payment tokens, depending upon the nature of the industry involved.

It is the process of converting ownership rights and real assets into digital assets, recorded on a distributed ledger. It can transform how multiple trillion dollars operate. The increasing demand for tokenization relies on public networks that support compliance, cost and performance needed to achieve mainstream adoption. Hedera Hashgraph overcomes these limitations by introducing Hedera Token Service.

Types of Tokens and their use cases

1. Fungible Tokens
   Based on the attributes such as decentralized mechanism, safety, and invariability; Blockchain is understood as an efficient technology for managing various digital assets. Though with the advent of such interchangeable tokens, these attributes would not have been possible. Such types of tokens are acceptable for cryptocurrency, and the truth is that the attribute of fungibility is the base of any currency.Tokens with such a feature are created so that every part of them is equivalent to the part of the next token. For example, Bitcoin is an approved cryptocurrency with the attribute of fungibility, which explains that a Bitcoin is equivalent to another Bitcoin and hence is equal to all the subsequent Bitcoins. Such kind of tokens is the ones which possess the quality of being divisible and being interchangeable.In layman terms, these tokens are the ones identical in nature with similar base components. They can be interchanged with the other similar tokens without any technical barrier. Such tokens are similar to the objects we use in everyday life, and their application can also be made to the real world and digital assets.
2. Non-Fungible Tokens
   Non-fungible tokens are unique tokens that portray different items. They are different so that they cannot be divided or precisely changed for the other additional non-fungible tokens of a similar category. You can understand NFTs as tokens with absolutely no fungibility that serves you with various ways of using a blockchain network. Crypto Kitties is the most prominent example of non-fungible, acquirable tokens.Every CryptoKitty is different, and no two CryptoKitties can ever possess similar attributes; it is practically impossible to break a CryptoKitty into smaller parts, exchange them in the transaction, and rearrange them to make an equivalent and unique CryptoKitty, unlike fungible token Bitcoin.

Use Cases

CryptoKitties have been recorded as the first example of non-fungible tokens. The invention of crypto kitties has created a new level of standard and protocols for the Blockchain platform. Non-fungible tokens have multiple use cases across a variety of domains. Similar to crypto kitties, such tokens initiate the creation of a new and unique type of collectibles. Along with the above-mentioned use cases, these tokens also have their essential application use in KYC processes, voting & election mechanism, loyalty events, art creations, real-world assets, virtual assets, copyrights, supply chain assessment, medical information, and a lot more.

With the emergence of tokens, various use cases of the tokens are used as per the market needs. These include all the parts from decentralized governance tokens to regulated securities. This part will explain such tokens that initiate application drive for the mechanism of Hedera Token Service.

Utility Tokens serve the holder with access to a product or assistance. This can be some of the technical assistance, just like the cloud credits, or the actual world products and services like permission to a farm or estate for a holiday.

Security Tokens are those which explain the trading of the token as the trading of that same value. These tokens act for the shares held up in a company or authority/possession of an estate. Most importantly, these tokens must adhere to relevant safety and other financial protocols and fetch their value from the fundamental asset.

Concept of Hedera Token Service 

With the range of choices on the significant public cryptocurrency network, Tokenization pushes the issuers to cooperate with the unstable and rising cost, low speed of transaction and concern of forking. With the invention of the Hedera Token Service (HTS), Hedera gives a way to issue tokens on a network that is spread globally without taking a chance on the performance.

HTS, provided with a publicly available set of APIs, guarantees that anyone can access stablecoins, security tokens, governance, and other tokens issued on Hedera main net through a Hedera Account. Users can effortlessly transfer tokens between one another without the request of a massive spike in cost interfering with their commerce nor dependency on an intermediary.

Hedera Token Service was created based upon the existing and current needs of the token issuers, businesses and enterprises. The needs were settled with the Hedera Governing Council, token issuers, ecosystem members, and safety experts. The Hedera API (HAPI) is embedded with protocol buffers (protobufs) and explains how users can indulge with network services and features. These APIs are openly accessible for a series of use cases and enterprises. HTS initiates already present network primitives to define and indulge with tokens as a native network entity.

Why to Tokenize with Hedera Hashgraph? 

INDIVIDUAL TOKENS
There is no need for sluggish, costly, and perhaps incorrect smart contracts – Hedera Token Service-issued tokens are native to Hedera. They operate in the same manner as hbar in terms of performance, security, and efficiency.

REASONABLY LOW AND PREDICTABLE FEES
Hedera Token Service charges minimal and predictable transaction fees on the Hedera public network – it costs less than one dollar to transfer any amount of a tokenized asset.

COMPLIANCE CAN BE CONFIGURED
Configuring keys and tokens at the account level enables compliance requirements like as KYC verification and freezing, token supply management, and transfer to be met.

GOVERNMENT OF ENTREPRISES
Hedera’s decentralized governance structure of worldwide organizations provides network stability, decentralized decision-making, and a guarantee of no-fork.

AUDIT OF SECURITY
FP Complete conducted independent third-party audits of the Hedera Token Service and Hedera ledger software.

How to create Hedera Hashgraph Tokens using Hedera Consensus Service?

Step1: Token Definition

The journey of a user with HTS begins with the definition of the token. In a token definition transaction, the token issuer must specify the following fields. This definition will be publicly accessible to any user requesting information about a particular token entity. In exchange, the network will provide the transaction response, which will include the transaction’s unique identifier. This definition is inherited by a token-type entity.

Relevant fields are needed, while others are not mandatory to accommodate specific use cases. The following will be included in the token definition:

• NAME
  A required string consisting entirely of ASCII characters that represent the token’s name. This field is used to specify the uniqueness of a token. The name does not have to be unique concerning the other tokens on the network.
• SYMBOL
  A required string consisting entirely of uppercase letters representing the token’s symbol. This field is utilized to identify a token quickly and may facilitate integration with exchanges or wallets. The symbol does not have to be distinct from those of other tokens on the network.
• DECIMALS
  A mandatory specification of the maximum number of decimal points by which the token can be divided. This field cannot be modified via an update transaction once it has been set. The issuer of the token may specify zero decimals.
• ACCOUNT OF THE TREASURY
  A required field that specifies the token’s Treasury Account. The Treasury Account will receive the specified initial supply in the definition transaction and any tokens created via a mint transaction. The Treasury Account can be updated by signing an update transaction with the Admin key.
• TOKEN RENEWAL ACCOUNT
  If auto-renew is set to true, this field is required. The Token Renewal Account is responsible for token storage. At the auto-renew period interval, the account will be charged automatically to renew the token’s expiration.
• ADMIN KEY
  This is an optional field that specifies the public key or set of public keys that must be used to sign any admin transactions. The ability to update the token definition is included in the administrator rights. This includes the ability to update the admin, freeze, wipe, or KYC keys, but only if they existed at the time the token was created, as well as the ability to modify the Treasury Account and auto-renew properties. Additionally, this key or keys can be used to delete a token. If the admin key is left blank, its properties cannot be changed once a token is defined.
• FREEZE KEY
  An optional field that specifies the public key or set of public keys capable of freezing or unfreezing accounts associated with the defined token. A frozen account cannot interact with the specific token type, preventing it from being sent or received. Additionally, this key can unfreeze accounts, allowing them to resume sending and receiving tokens. The account will continue to send and receive hbar, but not the specific token type. This field may be used for AML enforcement or other token governance requirements. If this field is left blank, the specified token cannot be frozen or unfrozen within these accounts. If the key was left empty during definition, it could not be updated.
• DEFAULT FROZEN 
  A non-mandatory field that can be set to true or false. If true, then all accounts associated with the specified token type are marked as frozen. If false, then all accounts associated with the specified token type are marked as unfrozen.
• WIPE KEY 
  An optional field that specifies the key or keys that can be used to wipe a specified account’s token balances. A wipe deletes a specified number of tokens from a specified account. Clawback is a term that refers to the process of freezing an account followed by a wipe. The wipe transaction has no effect on the account’s hbar balance. This field may be used for AML enforcement or other token governance requirements. If this field is left blank, token balances cannot be wiped from accounts. If the key was left empty during definition, it could not be updated.
• KYC KEY
  An optional field specifies the key or keys that can be used to indicate that an account has completed Know Your Customer (KYC) for the specified token type. This key or set of keys can change an account’s flag from un-KYC’d to KYC’d and vice versa. If KYC is required, an un-KYC’d account behaves similarly to a frozen account in that it will be unable to send or receive transactions involving the specified token. Certain token types may require KYC/AML assurance. If this field is left blank, accounts cannot be KYC’d or un-KYC’d for the particular token type. If the key was left empty during definition, it could not be updated.
• SUPPLY MANAGER KEY
  A mandatory field specifies the public key or keys capable of minting or burning tokens. Tokens are deposited in the Treasury Account. Tokens may be destroyed only from the Treasury Account. If the Supply Manager key is left empty, the Initial supply is immutable. If the key was left empty during definition, it could not be updated.
• INITIAL SUPPLY
   A required field that specifies the initial supply of the token that will be minting in conjunction with the token definition. The initial allocation will be deposited in the Treasury Account. Initially, the supply can be set to zero.

Let’s understand this with the help of an example.

//Create a transaction and optionally freeze for manual signing
const transaction = await new TokenCreateTransaction()
.setTokenName(“Your Token Name”)
.setTokenSymbol(“HGC”)
.setTreasuryAccountId(treasuryAccountId)
.setInitialSupply(5000)
.setAdminKey(adminPublicKey)
.freezeWith(client);
//Sign the transaction with the token adminKey and the token treasury account private key
const signTx = await (await transaction.sign(adminKey)).sign(treasuryKey);
//Sign the transaction with the client operator private key and submit to a Hedera network
const txResponse = await signTx.execute(client);

Step2: Transaction

Once a token is created, transactions between accounts involving that token can be submitted to the network. These transactions enable the token definition’s defined behaviors to be implemented. The capacity of a user to submit a transaction against a specific token is conditional on the involved accounts meeting certain criteria, such as being associated with the token and not frozen. A Hedera account is required to pay any hbar-denominated transaction fees associated with each transaction and query for the transaction to succeed.

Each transaction specifies the smallest divisible unit, such as the number of tokens transferred in a transfer transaction, based on the number of decimal places specified in the definition transaction. The following section summarizes the transactions and queries that the Hedera Token Service supports.

• CREATE
  The creation transaction is the first transaction that any user on the network can submit to create a new token type. Each of the parameters discussed previously (admin key, supply manager key, etc.) will be specified in the transaction. The transaction results in the creation of a token-type entity that inherits the specified roles and behaviors. The result will contain the token’s entity ID.
• UPDATE
  An update transaction is used to modify the values of specified fields in the create transaction for a particular token type entity. The update transaction can be used to modify the name, symbol, and keys associated with each role, as well as the Treasury Account, auto-renew account, and renewal period. It is unable to modify the decimals of a token-type entity. A transaction containing an update must be signed with the admin key. If an admin key was not specified during the token’s initial creation of the transaction, updates are impossible to be done.
• MINT
  The mint transaction adds tokens to the network’s circulating supply. The transaction can be submitted only using the Supply Manager key and specifies the number of coins to be minted. The mint transaction funds the Treasury Account with the newly minted tokens.
• BURN
  The burn transaction depletes the network’s circulating supply of tokens. The transaction can be submitted only by the Supply Manager key and specifies the quantity to be burned that cannot reduce the supply to zero. Tokens may be destroyed only from the Treasury Account.
• WIPE
  A wipe transaction destroys a specified number of tokens from a specified account. The circulating supply is reduced as a result of the tokens being burned during the wipe. Only the wipe key can sign a wipe transaction. The token balance of any account can be wiped if the wipe key is included in the token’s initial defined transaction.
• FREEZE
  A freeze transaction can be used to mark an account as frozen, preventing it from interacting with a specified Hedera Account. This means that the account will be unable to send or receive tokens to or from other accounts. The freeze key must sign the freeze transfer. The frozen account is still capable of interacting with hbar and other types of tokens. Additionally, the freeze transaction can be used to unfreeze accounts, allowing them to resume interaction with the token type.
• KYC
  A KYC transaction is similar to a freeze transaction in that it modifies the account’s flag to indicate whether it has been KYC’d or not. If KYC is required, an account that has not been KYC’d will be unable to send or receive the token. The KYC transaction must be cryptographically signed using the KYC key.
• ASSOCIATE
  A token associate transaction certifies that the provided Hedera account can accept a particular token type. Before transferring a token to a Hedera account, the account must be associated with the token. The transaction must be signed by the Hedera account associated with the token. Additionally, accounts can be decoupled from token types.
• TRANSFER
  A transfer is a primary transaction used by a token holder to move tokens between accounts. A transfer transaction must be signed using the key associated with the account from which the token was sent. The transfer transaction will transfer the specified token(s) from the specified account(s) to the specified receiving account (s).

Let’s understand the above process with an example.

//Create a transfer transaction
const transaction = await new TransferTransaction()
.addTokenTransfer(tokenId, accountId1, -10)
.addTokenTransfer(tokenId, accountId2, 10)
.freezeWith(client);
//Sign with the sender account private key
const signTx = await transaction.sign(accountKey1);
//Sign with the client operator private key and submit to a Hedera network
const txResponse = await signTx.execute(client);

Step3: Queries

The Hedera Token Service provides new fields for the details of receipts and records, allowing applications to ask questions about a token created on the network. Receipts and records will have data on the token exchange between every account. Applications will get data on a token to understand which keys and inputs are attached to the token type.

Applications will get account info of balances of the new token types.

Step4: Pricing 

The pricing of the Hedera Token Service is decided to be in USD, like every other Hedera network service, and cost profile supportive identical to that of hbar transactions. It means that users can expect less cost for fundamental transfers and higher fees for the more expensive activities like generating a token.

Here is an example.

//Create the query
const query = new AccountBalanceQuery()
.setAccountId(accountId);
//Sign with the client operator private key and submit to a Hedera network
const token balance = await query.execute(client);
console.log(“The token balance(s) for this account: ” +tokenBalance.tokens);

Conclusion

Hedera Hashgraph platform offers multiple models for a variety of tokenization use cases. Hedera Token Service is one of the tokenization models that provide great benefits from ease of deployment to low cost, high performance, interoperability, decentralized trust and ease of integration.

If you are looking to create Hedera Hashgraph Tokens for your business use case, consult our Hedera Hashgraph Development Team who can provide you assistance from ideation to the launch of a token.