How to create tokens using Hedera Consensus Service?

A common entry point for developers to enter into blockchain and distributed ledger is tokenized assets. With the increasing popularity of tokens, the demand is also rising for these tokens to be faster and cheaper to operate.

Hedera Consensus Service (HCS) is the token service that provides its users the benefit of low cost, privacy, and development flexibility. Moreover, HCS acts as a layer of trust for any permissioned network and creates an immutable and verifiable log of messages. It allows individuals and organizations to issue and trade tokens between private ledgers using the fair global ordering of transactions for any application.

The following sections outline the details about Hedera Consensus Service and how it helps to create tokens.

What is tokenization?

Tokenization transforms tangible assets and ownership rights into digital assets, particularly known as tokens. The tokenization process is being readily explored across various decentralized protocols for securities, digital art, stablecoins, etc.

Hedera token service allows configuring, mint, and managing fungible and non-fungible tokens conveniently without deploying smart contracts. Hedera offers highly configurable tokens with low costs and strong and stable governance.

What is Hedera Consensus Service?

Hedera Consensus Service is a tokenization service that enables developers to define specific network participants, deployment models, use cases and data privacy. HCS combines Hedera Mirror nodes and State Proofs that unifies private and public DLT markets by providing advantages of both. It enables developers to use the public distributed networks for low-cost, fast and fair transaction sequencing that is immutable. Moreover, it provides distributed trust in code execution without deploying smart contracts. More essentially, it enables developers to add their native services to the public Hedera ledger.

Hedera Consensus Service as a model for issuing tokens is particularly powerful from the performance and cost perspective.

How does tokenization work in Hedera Consensus Service?

Hedera is a public network; it has a mainnet that is currently permissioned, meaning the council members run it. When a transaction is sent to a node or multiple nodes, the transaction is processed at once. Assuming the transaction is syntactically and semantically correct and the user has enough balance, the node will forward that transaction through a gossip mechanism.

The key point with the Hedera node is the difference that it does not keep transaction history on mainnet nodes. So, when the transaction is sent to Hedera, the transaction is processed by the nodes and it updates the state on the node.

The consensus mechanism supports the hashgraph algorithm that is final. It means the algorithm is not probabilistic; it does not wait for the increasing number of block confirmations once the network has reached a consensus on a transaction. This complete consensus process happens in just three or four seconds on the network. Thus, the finality within 3-4 seconds is staggering compared to other blockchain systems.

Create new tokens

Before creating tokens, you need an account on testnet to provide your account number, operator ID, and private key. Once you’ve got the file setup, time is to move to token creation.

Start constructing a new token using the following command:

$ java -jar hcs-token-example-2.0-run.jar construct Token-2 MT2 2
→ construct Token-2 MT2 2
New topic created: 0.0.56414
$ java -jar hcs-token-example-1.0-run.jar refresh
→ refresh
Processing mirror notification construct Token-2 MT2 2

The token is now created with Hedera consensus TopicID. Anybody who wants to use this token will have to connect with this TopicID.

Token Message Standard

During tokenization, the message transferred to HCS consists of instructions for transmitting tokens between a ledger of accounts. Token Message Standard is implemented for building a token using HCS. The core components of an HCS token includes:

• Application logic defining the token contract to codify the roles and behavior of the token.
• Permissioned nodes that run the logic present the token to the users on their accounts store the ledger of accounts, and HCS transaction ordering ensures nodes remain in sync in a fast and secure manner.

Token Contract

The application logic, also referred to as Token Contract, receives messages from HCS and is streamed through mirror nodes. The nodes are enabled to listen to only specific TopicID against which all messages relevant for the token are submitted. The token contract then validates the message coming from HCS to ensure that it is compliant with the roles and behavior of the token definition.

After validation, it changes the state of the permissioned network node based on the details of the transaction. It can also introduce more complex logic based on the use case requirement such as atomic swaps, reference to external oracles or automated event triggering. The state mutation then triggers a notification for completing the transaction and caching transaction details.

Token Node

The components required to deploy token nodes include:

• Token Contract
  As discussed earlier, the token contract includes code that defines the roles and behavior of tokens in specific use cases. It automates the execution of logic consistently on each node so that every ordered message on HCS results in a consistent update to each node’s state.
• API
  Token nodes deploy an API server that provides a standard interface to obtain information about an account in the token network. The API server is enabled to confirm the transaction record, get the balance of an account or even get the information on keys associated with every role in the token contract.
• Database
  HCS allows token nodes to store data on their local databases. It allows nodes to use logic in token contracts to ensure their local state is updated based on the latest message ordered by HCS.
• On-boarding
  On-boarding depends on the requirements of the decentralized token network, such as KYC of token node operator, token node location and key sharing for data encryption. The essential requirement for the token node is to deploy a copy of the latest token contract. Moreover, it is also necessary to subscribe to the TopicID of the token network created HCS.

Transaction Ordering

Transaction ordering ensures to update instructions related to transfer tokens or any other activity on the network. Token nodes’ consistency and the ability to support decentralized exchange depend on ordering transactions on the network.

Message

Every transaction on the permissioned network is packaged into a message which consists of the signature of the party transferring the tokens. Each message needs to sign through specific keys depending on the action being carried out.

The message coming from any participant in the token network is submitted to the Hedera mainnet with a TopicID. After the message is received at the mainnet consensus node, it is gossiped among mainnet nodes to achieve a consensus.

Mirror node

Mirror nodes are used by many applications and reference implementation on HCS to receive messages as they arrive at consensus automatically. A token node will need to subscribe to the TopicID specifically configured for the token network to receive HCS messages from the mirror node. The token node can ask any mirror node operator for the same information and verify that results are the same as the mainnet.

Moreover, a token node can operate its mirror node to receive records from the Hedera mainnet directly.

Fees

Hedera Consensus Service requires the users to pay the transaction fees associated with the services. A different fee is charged for every action.

The token network provides flexibility to who can pay the Hedera fees. A single account can be configured to pay all the transaction fees. Moreover, token nodes are also allowed to have their Hedera account to pay the fees necessary to support their end-users. Both the models enable the underlying crypto to remain obscure from the end-users.

Conclusion

Hedera hashgraph implements various models to support different tokenization use cases. These models benefit the distributed Hedera network with high throughput and low latency.

The token services provide a transparent, trusted solution with tokens directly residing on Hedera public ledger. Hedera Consensus Service is a token service that is best for use cases that require a greater degree of control and privacy over token node operation and token contract logic. For such use cases that require higher customization and control, HCS provides a means to establish a permissioned tokenized asset network with public trust.

If you’re intrigued with the Hedera Consensus Service and want to implement it into your project, we’re ready to help you. Schedule a meeting and discuss your technical requirements with us.