ComparisonHedera Token Service (HTS)

HTS vs ERC-20: choosing how to issue a fungible token on Hedera

For most fungible tokens on Hedera, issuing natively through Hedera Token Service is the better default: the lifecycle controls are built into the protocol, there is no token contract to audit, and EVM contracts and wallets can still use the token through an ERC-20-style interface. A custom ERC-20 contract earns its place when the token needs transfer logic HTS cannot express, or when identical bytecode must run on other EVM chains.

Reviewed 6 min read

On this page
  1. Two ways to put a fungible token on Hedera
  2. Native HTS token and ERC-20 contract, requirement by requirement
  3. How contracts and EVM wallets reach an HTS token
  4. Audit surface and the cost of being wrong
  5. Fee comparisons that mislead
  6. Deciding by the token's real requirements
  7. If you need to switch routes after launch
  8. Questions and answers
  9. Sources

Two ways to put a fungible token on Hedera

Hedera offers two issuance routes that look similar from a wallet but differ underneath. With Hedera Token Service, you create the token with a native transaction; supply, decimals, treasury, keys and custom fees are properties the network itself tracks and enforces1. With Hedera's EVM, you deploy a Solidity contract that implements ERC-20, and balances live in that contract's storage under rules your code defines.

The choice is hard to reverse. Holders, integrations and exchange listings attach to a specific token identity, so moving from one route to the other later means a migration. It deserves a decision at design time, made against the token's actual requirements rather than the team's habits.

Native HTS token and ERC-20 contract, requirement by requirement

RequirementNative HTS tokenERC-20 contract on Hedera's EVM
Compliance controlsKYC, freeze, wipe, pause and supply keys built into the protocolWhatever your contract implements and tests
Code to auditNo token contract; review covers key design and integrationFull contract, any proxy and every upgrade
Fee modelFees set per transaction type in USD, charged in HBARGas for the work the contract does, also paid in HBAR
Custom transfer logicLimited to built-in options such as custom fees and KYCAny rule you can write in Solidity
Holder onboardingAccount must associate, unless it has automatic association slotsNo association; any address can receive
EVM tooling and walletsReachable through system contracts and the token facadeNative: standard ERC-20 behavior throughout
UpgradeabilityProperties changed by keys; logic fixed by the protocolPossible through proxy patterns, at the cost of upgrade governance
Portability to other chainsHedera-specific; other chains need a bridge or a new tokenSame source can deploy to other EVM chains

Highlighted is the usual default. The right-hand column wins on custom logic and portability, which some tokens genuinely need.

How contracts and EVM wallets reach an HTS token

The strongest argument against HTS used to be that Solidity developers could not treat it like an ordinary token. That gap has narrowed. Contracts can call the Hedera Token Service system contract at address 0x167 to create, mint, burn, transfer, freeze and query tokens, and tokens created that way remain manageable through the native APIs2.

HIP-218 went further: each HTS token address responds to the common ERC-20 calls, such as balanceOf, transfer and decimals, by redirecting them to the token service, so contracts and EVM tools can address the token as if it were a deployed contract3. HIP-376 added the approve, allowance and transferFrom calls4, and HIP-719 added associate, dissociate and isAssociated on the same facade, callable by ordinary accounts as well as contracts5. That last change matters for wallets: a user with an EVM wallet can opt in to an HTS token without a Hedera-specific client.

Gaps remain at the edges. HIP-218 lists some calls that return a failure on the facade, notably safeTransferFrom for NFTs and the enumeration functions3. Test any contract or integration that assumes the full standard against the facade, not against a reference ERC-20.

Audit surface and the cost of being wrong

A custom ERC-20 contract puts the token's rules in code that someone has to get right. Access control, rounding, reentrancy around hooks and the upgrade path are all yours. A proxy makes bugs fixable, but it also creates an upgrade key that can change the rules for every holder, which needs its own governance.

With a native token, the protocol implements transfers and balances, so the review moves to configuration: which keys exist, who holds them, how the treasury is protected and how the application handles receipts and failures. That review is smaller, but it is not optional; a badly held supply key does as much damage as a buggy mint function. See the HTS key design guide for that half of the work.

Fee comparisons that mislead

Deciding by the token's real requirements

  • If

    The token needs issuer controls such as KYC gating, freezing or supply management, and standard transfers otherwise.

    Then

    Issue natively on HTS and spend the design effort on key ownership and onboarding.

    The controls are already implemented and enforced by the network, so there is no contract logic to get wrong.

  • If

    Transfers must enforce rules HTS cannot express, such as per-holder limits computed from on-chain state.

    Then

    Use a contract. Consider letting the contract administer an HTS token through the system contract before writing a full ERC-20.

    The hybrid keeps native balances and controls while adding the custom logic you need.

  • If

    The same token code must deploy on several EVM chains under one design.

    Then

    Write an ERC-20 contract and test it on Hedera's EVM as one target among several.

    An HTS token is a Hedera object; elsewhere it needs a bridge or a separate representation.

  • If

    The token is a regulated security or a fiat-backed stablecoin.

    Then

    Start from the purpose-built tooling: Asset Tokenization Studio or Stablecoin Studio.

    Both already encode the lifecycle and role model those instruments need, and they settle the issuance route for you.

If you need to switch routes after launch

Migration is possible but visible to every holder. Plan it like a corporate action.

  1. Freeze the old design

    Announce a cut-off, pause or restrict the old token if its keys allow it, and snapshot balances from a mirror node at a defined consensus timestamp.

    Output
    Signed balance snapshot

  2. Create the new token

    Issue the replacement with the corrected design, then test association, KYC and transfer flows end to end on testnet first.

    Output
    New token and test evidence

  3. Distribute and reconcile

    Credit each holder from the snapshot, handle holders who have not associated, and reconcile totals between old and new tokens.

    Output
    Reconciliation report

  4. Retire the old token

    Burn or wipe the remaining units where keys allow, update integrations and listings, and keep the snapshot as audit evidence.

    Output
    Retirement record

Questions and answers

Should NFTs on Hedera be native HTS collections or ERC-721 contracts?

The same reasoning applies. Native HTS NFT collections give you protocol-level keys and built-in royalty fees, and contracts can read them through the HIP-218 facade. An ERC-721 contract makes sense when you need custom minting or transfer logic, or rely on calls the facade does not support, such as safeTransferFrom with receiver hooks.

Can a smart contract create and administer an HTS token?

Yes. The token service system contract exposes functions to create tokens and to mint, burn, freeze, grant KYC and transfer them, so a contract can run the token under its own logic. This hybrid is often the right answer when a token needs rules HTS lacks: native balances and controls, with a contract enforcing the extra conditions. Audit that contract as carefully as you would an ERC-20.

Do holders of an ERC-20 contract token on Hedera need to associate with it?

No. Association is a Hedera Token Service concept, and an ERC-20 contract keeps balances in its own storage, so any address can receive it. That is simpler for onboarding, but it also means the spam protection association provides does not apply, and wallets show the token only if they index the contract.

Sources

  1. Hedera Token Service (HTS): native tokenization — Hedera documentation · checked 10 October 2026
  2. System smart contracts — Hedera documentation · checked 10 October 2026
  3. HIP-218: Smart contract interactions with Hedera token accounts — Hiero Improvement Proposals · checked 10 October 2026
  4. HIP-376: Support approve/allowance/transferFrom standard calls from ERC20 and ERC721 — Hiero Improvement Proposals · checked 10 October 2026
  5. HIP-719: Associate and dissociate tokens via facade contract — Hiero Improvement Proposals · checked 10 October 2026
  6. Fee model — Hedera documentation · checked 10 October 2026
  7. Gas and fees — Hedera documentation · checked 10 October 2026

More in Hedera Token Service (HTS)

Back to Hedera Token Service (HTS)

Next step

Get a recommendation on your token's issuance route

Send the token's purpose, its transfer rules and any multi-chain plans. We will recommend HTS, a contract or a hybrid, and list what each choice means for audit, onboarding and operations.

Ask about issuance routes