Hedera Token Service (HTS)
Give a token a complete lifecycle.
Design token issuance, distribution and operating controls around the asset or entitlement it represents. We connect Hedera Token Service integration to the records, permissions and reconciliation the business needs.
The opportunity
Start with a decision
worth improving.
An organization wants to issue and manage a digital entitlement. The token's supply, holders and lifecycle actions must stay aligned with the system that defines the underlying entitlement.
From possibility to a working system
Follow the flow.
Three connected decisions. One considered architecture.
Conceptual flow, not a live system or measured result.
Define the token contract
Specify the token's purpose, supply model and administrative roles. Decide how ownership, transfers and lifecycle actions relate to the underlying business records.
Connect issuance and movement
Integrate token operations with the application and signing process. Validate recipient details, permissions and transaction results before updating the business system's view.
Reconcile the lifecycle
Monitor network state against internal records and handle exceptions explicitly. Document key custody, administrative actions and the process for correcting operational mistakes.
The work, made concrete
What we can build
with your team.
We agree scope, dependencies and acceptance criteria before delivery. Your project can start with an assessment, a pilot or an integration into an existing system.
Token model and administration design
Clarify the system boundary, the responsible owners and the decisions the architecture needs to support.
HTS application integration
Turn the agreed design into reviewable work, evaluated against representative inputs and explicit success criteria.
Reconciliation and custody procedures
Make the next step operable: document responsibilities, known limitations and the path from pilot to ongoing use.
Explore the practice
Further capabilities
and implementation detail.
What HTS is
Hedera Token Service (HTS) is a native, protocol-level tokenisation primitive on Hedera. You issue, transfer, and govern fungible and non-fungible tokens by sending Hedera transactions — not by deploying a smart contract. That gives you predictable USD-denominated fees, sub-second finality, and aBFT settlement, while compliance controls (KYC, freeze, pause, supply, royalty, custom fees) live at the protocol layer rather than in bespoke contract code.
ColdAI's HTS service
Token design & issuance
Token economics, supply policy, fee schedules, royalty design, and on-chain governance — issued via HTS with the right key structure for your operating model.
Compliance configuration
KYC, freeze, pause, wipe, and supply keys configured to match your regulatory perimeter, plus integration with KYC providers and transfer agents.
Application integration
SDK integration (JavaScript, Java, Go) into wallets, treasury systems, exchanges, and core banking — including HSCS system-contract calls when programmability is required.
Operations & treasury
Multi-sig treasury, key rotation, HSM-backed signing, on-call procedures, and monitoring for production HTS deployments.
Where HTS is the right answer
- Branded stablecoins and tokenised deposits
- Loyalty points and closed-loop value
- Compliance-aware NFTs and digital product passports
- Real-world asset tokens issued via Asset Tokenization Studio
- High-volume in-game or in-app fungible economies
Deploy HTS in your stack
Talk to our Hedera practice about issuing a compliant token on HTS — from design through mainnet operations.
Contact our Hedera teamIn depth
Go deeper into HTS token design
Two design decisions every HTS issuer faces: which keys to set and who holds them, and whether to issue natively or through an ERC-20 contract.
- 01Deep diveHTS token keys explained: admin, KYC, freeze, wipe and moreWhat each Hedera Token Service key can do, what happens when you leave one out, and how to decide which team or key structure should hold each one.
- 02ComparisonNative HTS token or ERC-20 contract on Hedera?Compare issuing a fungible token natively on Hedera Token Service with deploying an ERC-20 contract on Hedera's EVM, with a decision guide by requirement.
Settings you choose once when an HTS token is created
Some token properties can be updated later by the admin key; others are fixed for the life of the token. The update transaction covers names, symbol, treasury, keys, expiry, renewal, memo and metadata, and nothing else3. The settings below deserve the most thought.
- Token type
- Fungible or non-fungible. Non-fungible collections start with zero supply and mint serials individually, and must use zero decimals2.
- Decimals
- How finely a fungible unit divides. It is not among the updatable properties, so a wrong choice means a new token3.
- Supply type and maximum
- Infinite by default, or finite with a maximum supply. A finite cap gives holders a guarantee no key can override2.
- Treasury account
- The account that receives the initial supply and every minted unit. It is exempt from the token's custom fees24.
- Freeze default
- When set, every new association starts frozen and needs an unfreeze. Without a freeze key, such accounts stay frozen permanently2.
- Custom fees
- Up to ten fixed, fractional or royalty fees paid to collector accounts on transfer, changeable later only if a fee schedule key exists4.
- Keys
- Optional powers such as supply, KYC, freeze, wipe and pause. Their design is covered in depth on the token keys page.
The operational path of a unit, from creation to reconciliation
- Create token
Set type, decimals, supply model, treasury, keys and fees, signed by the treasury and admin keys.
- Holder associates
The recipient opts in manually or through an automatic association slot.
- Grant KYC or unfreeze
Required only when the token has a KYC key or freeze default.
- Distribute from treasury
Units leave the treasury against an internal issuance record.
- Holders transfer
Custom fees are assessed automatically on each transfer.
- Mint or burn
Supply changes, signed by the supply key, follow redemptions or new issuance.
- Reconcile
Network balances and supply are compared with the entitlement system of record.
Fixed, fractional and royalty fees on HTS
Custom fees let a token pay collectors on every transfer without any contract code. Each type behaves differently4.
| Attribute | Fixed fee | Fractional fee | Royalty fee |
|---|---|---|---|
| Applies to | Fungible and non-fungible tokens | Fungible tokens only | Non-fungible tokens only |
| Charged as | A set amount per transfer | A share of the amount moved, with optional minimum and maximum | A share of the value exchanged for the NFT |
| Paid by | The sender | The receiver, unless set to be net of transfers | The party giving value; a fallback fee applies if none is given |
| Paid in | HBAR or another fungible token | The token being transferred | The fungible value exchanged, or the fallback denomination |
| Main caveat | Adds friction to small transfers | Changes the amount the receiver ends up with | Enforceable only when both sides of the trade are in one transfer |
The token's treasury is always exempt, and collectors can be exempted from every fee on the token when the fees are created.
Keeping network balances aligned with the entitlement records
An HTS token is a representation of something defined elsewhere: a customer's credit, a member's entitlement, units in a program. The system that defines the entitlement remains authoritative, so the token's supply, holders and lifecycle actions must stay aligned with it5. That alignment is a daily operating task, not a launch-day check.
We reconcile at three levels. Total supply on the network should equal outstanding entitlements in the internal record, plus whatever the treasury holds unissued. Each holder's balance, read from a mirror node, should match the internal account it maps to. And every administrative transaction, whether mint, burn, wipe, freeze or a fee change, should match an approval record. A mismatch at any level goes to an exceptions queue with the evidence attached, never to an automatic correction.
Two HTS behaviors create predictable exceptions. A transfer to an account that has not associated, or that lacks KYC, fails rather than waiting1, so the business system needs a pending state and a retry path. Fractional fees mean the amount a receiver gets can differ from the amount sent. The finance side of this work, including journal mapping, is covered in reconciling Hedera transactions with your ERP.
HTS configuration errors that are expensive to reverse
Decimals or supply type chosen in a hurry
Early signalProduct asks for fractional units, or for supply beyond a cap, after launch.
MitigationSettle divisibility and supply policy with finance before creation, because neither can be changed by an update.
Freeze default enabled without a freeze key
Early signalNew holders associate and find the token permanently unusable.
MitigationValidate the creation parameters against a checklist in code review, and create on testnet first with the exact production settings.
Royalties assumed to be guaranteed
Early signalNFT sales settle off-network or in two separate transfers, and no royalty is paid.
MitigationRoute sales through flows that put payment and NFT in one transfer, and document where royalties cannot be enforced.
Treasury used as a working wallet
Early signalDay-to-day distributions are signed by the key that controls the whole unissued supply.
MitigationMove units from the treasury to a separately keyed distribution account in controlled batches.
Where HTS work ends and other practices take over
This practice covers the token primitive itself: model, issuance and movement, controls and reconciliation. Several neighbors build on it. Regulated securities with transfer restrictions, partitions and corporate actions are better served by the Asset Tokenization Studio. Fiat-backed stablecoins, with reserve and treasury operations, belong with Stablecoin Studio.
Questions about what to tokenize and why sit with tokenisation program design, consumer programs such as loyalty and collectibles with digital assets, and tokens tied to physical property with real-world assets. A token is not automatically a legal claim, a compliant security or a liquid market5; those questions are settled separately from the HTS configuration.
Frequently asked questions
Which HTS token settings cannot be changed after creation?
The token update transaction can change the name, symbol, treasury, existing keys, expiry, auto-renewal settings, memo and metadata, and only when the admin key or the relevant key signs. Settings outside that list, such as token type, decimals, supply type and maximum supply, are fixed. Keys that were never set cannot be added later, so decide them with compliance before creation.
Why did a transfer of our HTS token fail for a new customer?
The most common causes are that the customer's account has not associated with the token and has no free automatic association slots, that the token has a KYC key and KYC has not been granted, or that the token uses freeze default and the account has not been unfrozen. Build each of these checks into onboarding so customers never see the failure.
Can a Hedera token charge a fee on every transfer?
Yes. HTS supports custom fixed, fractional and royalty fees paid to collector accounts automatically on transfer, up to ten per token. The ordinary network transaction fee is separate and paid in HBAR by the transaction's payer. If you may want to change fees later, the token needs a fee schedule key from the start.
Who should pay network fees for holders of an HTS token?
It depends on the audience. Consumer programs usually have the issuer or a wallet provider pay network fees on users' behalf, so holders never need HBAR. Programs for professional holders often let each participant pay its own fees. Either way, budget fees in USD, since they are defined in dollars and converted to HBAR at the network exchange rate.
Sources
- Hedera Token Service (HTS): native tokenization — Hedera documentation
- token_create.proto: TokenCreateTransactionBody field definitions — Hedera protobufs (GitHub)
- Update a token — Hedera documentation
- Custom token fees — Hedera documentation
- Hedera Token Service (HTS) — ColdAI
Connect the architecture
The next connection.
Explore the complementary capabilities that can turn an individual technology into a complete workflow.
Your next move
Bring us the
real problem.
A workflow that takes too long. A system that cannot connect. An idea that needs a technical path. Start there, and we can define what to investigate, build and measure.
- A defined asset or entitlement
- Account and administrative ownership
- Lifecycle and transfer requirements