Hedera Development: Building With the Token Service, Consensus Service and Smart Contracts

Building on Hedera means choosing between three native services: the Hedera Token Service for tokens, the Hedera Consensus Service for ordered, timestamped messages, and an EVM-compatible Smart Contract Service for custom logic. Good Hedera architecture usually uses the native services where they fit and writes Solidity only for what they cannot do.

This guide covers the practical side of shipping on the public network. If you want to understand the underlying consensus algorithm (gossip about gossip, virtual voting, aBFT finality), read the separate explainer on hashgraph development first.

The three services and when to use each

A common and sensible pattern: issue the token through HTS for low, predictable fees and built-in compliance controls, then let Solidity contracts interact with it through the HTS system contract when you need custom behavior.

Hedera Token Service in practice

HTS tokens are first-class ledger objects. When you create one you decide which keys exist and who holds them, and that decision is effectively your compliance model:

• KYC key to grant or revoke an account's permission to hold the token.
• Freeze key to freeze an account's balance of that token.
• Wipe key to remove tokens from an account (relevant for regulated assets and court orders).
• Supply key to mint and burn, and fee schedule key to change custom fees.
• Custom fees, including fixed, fractional and royalty fees on NFTs, enforced by the network rather than by marketplace goodwill.

Leaving a key unset makes that capability permanently impossible, which is how you signal decentralization. Setting every key and holding them in one hot wallet is how you create a single point of failure. Use threshold keys or a custody provider for anything valuable. For the broader design questions around asset tokens, see the guide to building a tokenization platform.

One Hedera-specific detail trips up almost every new team: accounts must associate with a token before receiving it, unless they have free auto-association slots. Build association into your onboarding flow and your error handling.

Hedera Consensus Service in practice

HCS is the most underused service, and for many enterprise projects it is the right one. You create a topic, optionally with a submit key so only your systems can post, and send messages. The network returns a consensus timestamp and a running hash, and mirror nodes let anyone verify the sequence later. Your application logic stays off-chain where it is cheaper and private, while the ordering and integrity are publicly verifiable. Hash or encrypt sensitive payloads before submitting; never post personal data in clear text. This pattern suits supply-chain traceability and audit logging particularly well.

Smart contracts on Hedera

Hedera runs an EVM, so Solidity, Hardhat, Foundry and ethers.js all work through the JSON-RPC relay, and wallets like MetaMask can connect. Differences to plan for:

• Accounts have native IDs in the form 0.0.12345 alongside EVM-style addresses; your UI and indexer need to handle both.
• Calling HTS from Solidity goes through a system contract interface rather than a standard ERC-20 implementation, although HTS tokens expose ERC-20 and ERC-721 facades.
• Gas pricing, per-transaction limits and throttles are set by the network and denominated with USD targets in mind, so test realistic workloads early.
• Deploy the same contracts and the same audit process you would use anywhere; EVM compatibility does not reduce the need for a review.

Accounts, fees and tooling

Hedera fees are set in US dollar terms and paid in HBAR, so the HBAR amount changes with its price but the dollar cost stays fairly stable. This predictability is a real advantage for budgeting high-volume use cases. Check the current schedule on the official Hedera documentation rather than relying on numbers quoted in blog posts.

The official SDKs (JavaScript, Java, Go and others) handle native transactions, while mirror nodes provide REST and gRPC access to history; you will query mirror nodes for nearly all reads. Testnet and previewnet accounts are free through the developer portal.

Scoping a Hedera build

1. Map each feature to HTS, HCS, contracts or off-chain. Default to native services.
2. Design the key structure and custody before writing code.
3. Decide how users get accounts: wallet connection, custodial creation, or alias-based auto-creation.
4. Prototype against testnet and load-test throttles and fees.
5. Build indexing on mirror nodes and plan for their rate limits or run your own.
6. Audit contracts, review key management, then launch.

As a rough estimate, a token plus a simple web dashboard using HTS and a hosted wallet connection is a few weeks of work for two developers. A product combining HTS, HCS, custom Solidity logic, custody integration and compliance workflows runs several months with a larger team. Integrations, not the ledger, usually dominate the schedule.

Frequently asked questions