Overview
Hedera uses a simplified fee model where every transaction cost is calculated as a base fee plus extras. Introduced in HIP-1261, this model replaces the previous resource-weighted fee schedule with transparent, predictable pricing. All fees are defined in USD as tinycents and converted to HBAR at the current network exchange rate before being charged. The fee schedule is stored as a JSON document in system file0.0.113 on the network.
What is a tinycent? One cent USD = 10⁸ tinycents. One dollar USD = 10¹⁰ tinycents. Tinycents provide high precision for fee calculations without floating-point math.
Key terms
Key terms
Fee Components
Every transaction fee is split into three components:Extras
Extras are additional cost factors applied on top of a base fee. Each extra has a name, a per-unit fee (in tinycents), and an optional included count — the number of units included for free before additional charges apply. Hedera transaction and query fees follow abase fee + extras fee model defined by HIP-1261 (Simple Fees). For current per-unit fees in USD, see the mainnet fees page.
The following extras are defined in the fee schedule:
Hedera transaction and query fees follow a
base fee + extras fee model defined by HIP-1261 (Simple Fees).Fee Calculation Example
Consider a basicCryptoCreate transaction with a single key and 150 bytes:
1
Calculate the node fee
The node fee applies the same formula to all transactions:
2
Calculate the network fee
The network fee is a multiplier of the node fee:
3
Calculate the service fee
The service fee is specific to
CryptoCreate:4
Sum the total
Transaction Outcomes and Fees
Not all transactions succeed. The fee charged depends on how far the transaction progresses:Congestion Pricing
HIP-1313 introduces an optional high-volume lane for entity-creation transactions above the standard throttle. When a transaction opts in withsetHighVolume(true), the network may apply a fee multiplier if the high-volume throttle bucket is under load. The multiplier scales with congestion level and is reflected in the high_volume_multiplier field of the fee estimate response.
The high_volume_multiplier field uses a 1-based scale (1 = 1×, 4 = 4×). TransactionRecord.highVolumePricingMultiplier — available after execution — uses a 1000-based scale (1000 = 1×, 4000 = 4×). Both represent the same multiplier.
To simulate the fee at a specific congestion level before committing, use setHighVolumeThrottle() on FeeEstimateQuery. See Estimating Fees with the SDK for code examples.
Fee Schedule Configuration
The fee schedule is a JSON document stored in system file0.0.113. It defines:
Example fee schedule structure (JSON)
Example fee schedule structure (JSON)
The legacy fee schedule in system file
0.0.111 remains available in its existing format for backward compatibility, but it will not receive further updates.Fee Estimation
You can estimate transaction fees before submitting them using the Mirror Node REST API:
See Mirror Node REST API Network for the full endpoint specification and response format.
Queries
Queries follow the same base-fee-plus-extras structure as transactions. Some queries are marked asfree in the fee schedule (e.g., CryptoGetAccountBalance, TransactionGetReceipt). For non-free queries, the SDK creates a CryptoTransfer payment transaction to pay the node, network, and service fees.
Fee Schedule Schema (Protobuf)
The fee schedule is defined as a set of protobuf messages. The wire format is JSON, stored in system file0.0.113.
FeeSchedule
Top-level message defining the complete fee configuration.ExtraFeeDefinition
Defines a single extra fee — an additional charge for a specific cost factor.NodeFeeSchedule
Node fee configuration. Applied identically to all transaction types.NetworkFeeSchedule
Network fee configuration. Calculated as a multiplier of the node fee.ServiceFeeSchedule
Groups transaction and query fee configs for a single gRPC service.ServiceFeeDefinition
Fee definition for a single transaction or query.ExtraFeeReference
References an ExtraFeeDefinition with an optional included count.UnreadableTransactionFeeSchedule
Punitive fee for nodes that submit unparsable bytes.Validation Rules
Before a new fee schedule takes effect, the network validates it. If any rule fails, the schedule is rejected.Parsing and schema compliance
Parsing and schema compliance
The JSON must parse and conform to the
FeeSchedule protobuf message. All required fields must be present and types must match. No unrecognized fields.Monetary values
Monetary values
All
baseFee and fee fields must be non-negative integers. For extras, fee must be strictly > 0.Multiplier constraint
Multiplier constraint
The
multiplier in network must be a positive integer ≥ 1.Name uniqueness and format
Name uniqueness and format
All names must match
[A-Za-z].*[A-Za-z0-9]*. Extra names, service names, and transaction/query names within each service must be unique.Extra references
Extra references
Every extra reference must point to a defined extra. No duplicate references within a single list.
Free transactions and queries
Free transactions and queries
If
free is true, baseFee and extras are ignored during calculation but must still comply with all validation rules if present.Related
HIP-1261: Simple Fees
The full Hiero Improvement Proposal specification.
Transaction and Query Fees
Fee tables for all transaction and query types on mainnet.
Gas and Fees
Gas schedule and fee calculation for smart contracts.
HIP-1259: Fee Collection
The fee collection account model that Simple Fees depends on.