How to Create Tokens Using Hedera Consensus

Hedera Consensus Service (HCS) is a gossip-based ordering service. It does not execute smart contracts or manage accounts; instead, it orders and timestamps messages for any distributed ledger or private network. Custom token logic runs off-chain, with HCS providing a decentralized append-only log to enforce agreement on transaction order and finality.

When to Use HCS vs. HTS

• Hedera Token Service (HTS): You want tokens natively on Hedera. Transactions are immutable Hedera ledger entries. Best for enterprise tokens, stablecoins, or dApps on Hedera.
• Hedera Consensus Service (HCS): You run your own token logic off-chain (in your database or private ledger) and use HCS to order and timestamp transactions. Best for private blockchain networks, alternative token implementations, or cross-chain settlements.

HCS is more flexible but requires you to build and operate the token node infrastructure. HTS is simpler but locks you into Hedera's on-chain execution model.

Architecture: HCS-Based Token System

A token system using HCS has three layers:

1. Message layer (HCS topic)

All token transactions are submitted as messages to a Hedera topic (an immutable, ordered log). A message contains: sender, recipient, amount, signature, timestamp. HCS guarantees:

• Total order (all nodes see messages in the same sequence).
• Timestamping (consensus timestamp is cryptographically bound).
• Immutability (once ordered, cannot be altered or censored).

Cost: ~0.00001 USD per message on mainnet.

2. Mirror node (message observer)

A mirror node subscribes to the HCS topic and caches messages in a local database. It reconstructs the token state (account balances) by replaying messages in order. Mirror nodes are stateless: they can be rebuilt by replaying the topic from genesis.

Run your own mirror node for low latency, or use Hedera's public mirror node API for read-only queries.

3. Token contract (rules enforcement)

Off-chain code that validates messages (signatures, balance checks, authorization) and applies them to the token state. It's not a smart contract on-chain; it's application logic you control. Example rules:

• Only the owner can mint.
• Frozen accounts cannot transfer.
• Transfers must balance (no inflation).

If a message violates rules, you reject it (don't apply it to state). Because all nodes replay the same message sequence, all nodes converge to the same state (strong consistency).

Building a Token Node: Implementation

Message format

// Token transaction message (JSON) { "type": "transfer", "from": "0.0.123", "to": "0.0.456", "amount": 100, "nonce": 1, "signature": "..." } // Alternative: mint { "type": "mint", "amount": 1000, "owner": "0.0.789", "nonce": 2, "signature": "..." }

Each message is signed by the sender (to prevent spoofing). The signature is verified before applying the transaction.

Token node (state machine)

import { TopicMessageQuery } from "@hashgraph/sdk"; const state = { balances: {}, // account => balance nonces: {}, // account => next expected nonce }; const topicId = "0.0.xxxxx"; // Subscribe to HCS topic const query = new TopicMessageQuery() .setTopicId(topicId) .onNext(async (msg) => { const tx = JSON.parse(msg.contents); const isValid = await validateTransaction(tx, state); if (isValid) { applyTransaction(tx, state); console.log(`Balance of ${tx.from}: ${state.balances[tx.from]}`); } else { console.log(`Invalid transaction: ${tx}`); } }); query.subscribe(client);

Validation logic

function validateTransaction(tx, state) { // Check nonce (prevents replays) if (tx.nonce !== (state.nonces[tx.from] || 0)) { return false; // Out-of-order or duplicate } // Verify signature const publicKey = getPublicKey(tx.from); if (!verifySignature(tx, publicKey)) { return false; // Unauthorized } // For transfer: check balance and frozen status if (tx.type === "transfer") { const balance = state.balances[tx.from] || 0; if (balance < tx.amount) { return false; // Insufficient balance } if (isFrozen(tx.from)) { return false; // Account frozen } } // For mint: only owner can mint if (tx.type === "mint") { if (tx.owner !== ownerAddress) { return false; } } return true; }

State application

function applyTransaction(tx, state) { if (tx.type === "transfer") { state.balances[tx.from] = (state.balances[tx.from] || 0) - tx.amount; state.balances[tx.to] = (state.balances[tx.to] || 0) + tx.amount; } else if (tx.type === "mint") { state.balances[tx.to] = (state.balances[tx.to] || 0) + tx.amount; } else if (tx.type === "burn") { state.balances[tx.from] = (state.balances[tx.from] || 0) - tx.amount; } state.nonces[tx.from] = (state.nonces[tx.from] || 0) + 1; }

Data Integrity and Consistency

All token nodes independently reconstruct state by replaying the same HCS topic. This guarantees strong consistency: all nodes agree on account balances at any timestamp.

Example: Nodes A, B, and C all subscribe to the token topic. Messages are ordered by HCS:

1. Alice transfers 100 to Bob.
2. Bob mints 50 new tokens.
3. Alice transfers 75 to Charlie.

All three nodes will apply these in the same order and reach identical balances. Consensus is enforced by message order, not node voting.

Querying Token State

Users can query token state from any mirror node. The node serves the current balance from its local database.

// Query mirror node API GET https://mainnet-public.mirrornode.hedera.com/api/v1/accounts/0.0.123 // Returns account details, including associated tokens and balances { "account": "0.0.123", "tokens": { "0.0.777": 500 // 500 tokens of type 0.0.777 } }

For custom token logic, expose your own API that queries your mirror node's state database.

Cost Model

• HCS messages: ~0.00001 USD per message mainnet. Batching multiple transfers into one message reduces cost.
• Mirror node operation: If you run your own, cost is your infrastructure (CPU, storage, bandwidth). If using Hedera's public API, cost is free with rate limits.
• Signature verification: CPU cost, no network cost. Negligible if batched.

Total cost per transfer: ~0.00001 USD (message) + signature verification overhead. Far cheaper than smart contract tokens.

Trade-offs: HCS vs. Ethereum L2s

Aspect	HCS	Ethereum L2 (Arbitrum/Optimism)
Cost per transfer	~0.00001 USD	0.01-0.10 USD
Finality	3-5 seconds	Minutes (optimistic rollup)
Decentralization	Council-governed	Ethereum-secured
Smart contracts	Off-chain custom logic	Solidity, full turing-complete
Token logic complexity	You control, can be complex	On-chain, gas cost scales with complexity
Cross-chain atomicity	No	No (requires bridges)

When HCS Makes Sense

• Cost is critical (millions of transfers).
• You can write and operate token node infrastructure.
• Private ledger or alternative consensus is acceptable (not fully decentralized).
• You need custom token logic beyond standard ERC20 (e.g., complex royalties, DAOs).

If you need Ethereum compatibility, smart contracts on-chain, or maximal decentralization, use an Ethereum L2 instead.

Summary

HCS provides decentralized message ordering and timestamping for custom token implementations. You build token logic off-chain, use HCS as the source of truth for transaction order, and reconstruct state locally. This approach scales to millions of transactions cheaply but requires you to operate and maintain the token node infrastructure. It's a good fit for private or consortium blockchains where you control the ledger and value low cost and simplicity over on-chain smart contract flexibility.