Skip to main content

​
Overview

Managing token decimals is critical when working with HBAR, HTS tokens, and ERC tokens on Hedera, as each system has distinct precision standards. These differences impact how token balances are calculated, displayed, and transferred across various tools and environments.

​
Token Decimal Comparison and API Context

The table below compares the decimal handling of HBAR, HTS tokens, and ERC tokens on Hedera, incorporating details about their representation across APIs and services. This overview highlights differences in precision and context.
API/ServiceDecimalsExplanation
Hedera API (HAPI)8 decimalsHBAR is represented with 8 decimal places, aligning with its native smallest unit tinybar.
Hedera Smart Contract Service (EVM execution)8 decimalsWithin the EVM, HBAR is tinybar-scaled: msg.value, address(this).balance, and the value passed to call/send/transfer are all 8 decimals during execution.
JSON-RPC Relay (Arguments)8 decimalsWhen HBAR values are passed as arguments in JSON-RPC calls, they are represented with 8 decimal places.
JSON-RPC Relay (msg.value / gasPrice) — RPC boundary only18 decimalsEthereum tooling submits and reads the transaction value and gasPrice in 18-decimal weibar at the JSON-RPC boundary. The relay converts weibar to tinybar (÷1010) before the EVM executes, so the msg.value your contract actually sees is 8-decimal tinybar — not 18-decimal wei. See the warning below.
HTS TokensConfigurable (up to 8 decimals)HTS tokens allow token creators to define precision at token creation, offering flexibility for various use cases.
ERC TokensDefault 18 decimalsERC tokens on Hedera follow Ethereum token standards, with 18 decimals as the default unless specified otherwise.
Key Impacts:
  • Account for scaling differences when converting HBAR between APIs, especially when using JSON-RPC.
  • HBAR fees are always calculated in tinybars, regardless of the API or service used.
  • The 18-decimal representation is a JSON-RPC boundary convention only — inside the EVM, native value is tinybar (8 decimals). Do not assume msg.value is wei-scale (see warning).
Inside a contract, native value is tinybar (8 decimals), not wei (18). msg.value, address(this).balance, and the value you pass to call/send/transfer are all tinybar-denominated during EVM execution. Two cases to design for:
  • Transactions from tooling (relay path). When you send 1 HBAR as value: 1 ether (1e18 weibar), the relay divides by 1010, so your contract sees msg.value == 1e8. A contract that stores msg.value — e.g. a WETH-style wrapper reporting decimals() = 18 — will record a balance 1010 smaller than an Ethereum developer would expect.
  • Contract-to-contract calls (no conversion). payable(x).call{value: 1 ether}("") compiles 1 ether to 1e18 and sends it as tinybar (= 1010 HBAR), which either reverts (insufficient balance) or over-transfers. Specify the value in tinybar instead.

​
Conversion Helpers

Utility functions are essential for managing discrepancies between HBAR (measured in tinybars, 8 decimals), HTS tokens (which can have configurable decimal places), and ERC tokens (measured in wei, 18 decimals). These conversions ensure consistency across your smart contracts, front-end applications, and APIs. Code Example: Decimal Conversion Helpers
Reference: Smart Contracts Gas and Fees

​
Additional Resources