Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.hedera.com/llms.txt

Use this file to discover all available pages before exploring further.

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 file 0.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.
TermDefinition
Base FeeThe fixed minimum fee in tinycents for a transaction or query before any extras are applied.
ExtrasAdditional cost factors on top of the base fee, such as signatures, bytes, keys, or gas. Each has a per-unit fee and an optional included count.
Included CountUnits of an extra included for free in the base fee before additional charges apply.
TinycentThe smallest fee unit. 10⁸ tinycents = 1 cent USD. 10¹⁰ tinycents = 1 USD.
Node FeeFee paid to the submitting node. Same calculation for all transaction types.
Network FeeA multiplier of the node fee covering consensus and storage.
Service FeeCovers execution costs. Varies by transaction type.

Fee Components

Every transaction fee is split into three components:
ComponentWhat It CoversHow It’s Calculated
NodeCompensates the submitting node for pre-checking and forwarding the transactionbaseFee + extras (processing bytes, signatures). Identical formula for all transaction types.
NetworkCovers gossip, consensus, signature verification, and blockchain storageA configurable multiplier of the node fee (default: 9×).
ServiceCovers execution costs, state changes, and blockstream outputbaseFee + transaction-specific extras (keys, token types, gas, etc.). Varies by transaction type.
totalFee = nodeFee + networkFee + serviceFee
The node and network fees are uniform across all transaction types — only the service fee varies per transaction.

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 a base 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:
ExtraDescription
SignaturesSignature verifications on the transaction. 1 included in base fee.
KeysKeys defined when creating or updating an entity. 1 included in base fee.
AccountsAccounts loaded during handling. 2 included on CryptoTransfer.
TokenTypesDistinct token types referenced in a transfer. 1 included in base fee.
GasGas consumed by hook program execution within transfers and by ContractCallLocal queries.
AllowancesAllowances granted on ApproveAllowance, or NFT allowances deleted on DeleteAllowance. 1 included in base fee.
AirdropsPending airdrops created — applies only when the recipient hasn’t pre-associated the token.
TokenTransferBaseApplies once per CryptoTransfer with one or more token transfers when no token has custom fees.
TokenTransferBaseCustomFeesApplies once per CryptoTransfer with at least one custom-fee token.
TokenCreateWithCustomFeeAdded to TokenCreate when custom fees or a fee_schedule_key are defined.
TokenMintNftNFT serials minted on TokenMint. 1 included in base fee.
TokenMintNftBaseAdded once per TokenMint operation that mints NFTs (not fungible).
NftUpdateNFTs updated on TokenUpdateNfts. 1 included in base fee.
TokenAssociateToken associations on TokenAssociate or auto-associations during a transfer. 1 included in base fee.
ConsensusCreateTopicWithCustomFeeAdded to ConsensusCreateTopic when the new topic has custom fees defined.
ConsensusSubmitMessageWithCustomFeePer message submitted to a topic with custom fees.
ConsensusSubmitMessageWithCustomFeeBytesPer byte of message payload on a custom-fee topic. First 1,024 bytes included in base fee.
ConsensusSubmitMessageWithoutCustomFeeBytesPer byte of message payload on a regular topic. First 100 bytes included in base fee.
ScheduleCreateContractCallBaseAdded to ScheduleCreate when the scheduled inner operation is a contract call.
RecordsRecords returned by TransactionGetRecord. 1 included in base fee.
StateBytesBytes persisted to state on FileCreate, FileUpdate, or FileAppend. 1,000 bytes included per transaction.
ProcessingBytesTransaction body bytes processed by the node. 1,350 included in the base fee.
EvmDispatchSurchargeA 20% premium added to the HAPI fee of any operation invoked from a smart contract via Hedera’s system contracts (HTS, HAS, HSS). Does not apply to pure-EVM operations.
Hedera transaction and query fees follow a base fee + extras fee model defined by HIP-1261 (Simple Fees).
The included count means you don’t pay extra for typical usage. For example, the node fee includes a default allotment of processing bytes and one signature — a small, single-signature transaction pays zero byte and signature extras on the node component.

Fee Calculation Example

Consider a basic CryptoCreate transaction with a single key and 150 bytes:
1

Calculate the node fee

The node fee applies the same formula to all transactions:
Node baseFee:           100,000 tinycents
ProcessingBytes extra:  150 bytes used, 1,024 included → 0 charged → 0
Signatures extra:       1 signature, 1 included → 0 charged → 0
─────────────────────────────────────────────────────────────────────
Node fee total:         100,000 tinycents
2

Calculate the network fee

The network fee is a multiplier of the node fee:
Network fee = 9 × 100,000 = 900,000 tinycents
3

Calculate the service fee

The service fee is specific to CryptoCreate:
Service baseFee:    499,000,000 tinycents
Keys extra:         1 key used, 1 included → 0 charged → 0
──────────────────────────────────────────────────────────
Service fee total:  499,000,000 tinycents
4

Sum the total

Total = 100,000 + 900,000 + 499,000,000 = 500,000,000 tinycents ≈ $0.05 USD
This amount is converted to HBAR at the current exchange rate and charged to the payer.
If the same transaction used two keys instead of one, the service fee would increase by the per-key extra fee (e.g., 10,000,000 tinycents), because the included count of 1 key is exceeded by 1.

Transaction Outcomes and Fees

Not all transactions succeed. The fee charged depends on how far the transaction progresses:
OutcomeDescriptionWho PaysComponents Charged
SuccessfulTransaction executed normallyPayerNode + Network + Service
BadPassed due-diligence but failed during execution (e.g., out of gas, semantically wrong, inconsistent with state)PayerNode + Network + Service (full)
UnhandledWell-formed but not executed (e.g., throttled, duplicate, unexecuted portion of an atomic batch)PayerNode + Network
InvalidFailed due-diligence checks by the submitting node (e.g., payer can’t afford the fee, incompatible fields)Submitting nodeNetwork only
UnreadableBytes cannot be parsed as a valid protobuf TransactionSubmitting nodePunitive flat fee
Bad transactions are charged full freight (node + network + service) to protect the network from denial-of-service attacks. This applies even if the transaction fails due to a bug (FAIL_INVALID).

Congestion Pricing

HIP-1313 introduces an optional high-volume lane for entity-creation transactions above the standard throttle. When a transaction opts in with setHighVolume(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 file 0.0.113. It defines:
SectionPurpose
extrasAll available extra fee definitions (name + per-unit fee)
nodeNode fee configuration (base fee + extras with included counts)
networkNetwork fee configuration (multiplier)
servicesPer-service groupings of transaction and query fee definitions
unreadablePunitive fee for unparsable transaction bytes
{
  "version": 0,
  "extras": [
    { "name": "Signatures", "fee": 100000 },
    { "name": "ProcessingBytes", "fee": 10000 },
    { "name": "Keys", "fee": 10000000 }
  ],
  "node": {
    "baseFee": 100000,
    "extras": [
      { "name": "ProcessingBytes", "includedCount": 1024 },
      { "name": "Signatures", "includedCount": 1 }
    ]
  },
  "network": { "multiplier": 9 },
  "services": [
    {
      "name": "CryptoService",
      "transactions": [
        {
          "name": "CryptoCreate",
          "baseFee": 499000000,
          "extras": [
            { "name": "Keys", "includedCount": 1 }
          ]
        }
      ],
      "queries": []
    }
  ],
  "unreadable": { "fee": 100000000000 }
}
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:
POST /api/v1/network/fees?mode=intrinsic
Content-Type: application/protobuf

<Transaction protobuf binary>
The endpoint supports two modes:
ModeBehavior
intrinsic (default)Estimates based on the transaction’s inherent properties (size, signatures, keys)
stateEstimates using the mirror node’s latest known state (e.g., checks if accounts exist)
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 as free 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 file 0.0.113.

FeeSchedule

Top-level message defining the complete fee configuration.
FieldTypeDescription
nodeNodeFeeScheduleHow to compute the node fee component. Required.
networkNetworkFeeScheduleHow to compute the network fee component. Required.
unreadableUnreadableTransactionFeeScheduleFee for unparsable transaction bytes. Optional.
extrasrepeated ExtraFeeDefinitionAll available extra fee definitions. No duplicate names.
servicesrepeated ServiceFeeScheduleFee configs per network service. No duplicate names.

ExtraFeeDefinition

Defines a single extra fee — an additional charge for a specific cost factor.
FieldTypeDescription
namestringUnique name. Must match [A-Za-z].*[A-Za-z0-9]*. Required.
feeuint64Fee per unit in tinycents. Must be > 0. Required.

NodeFeeSchedule

Node fee configuration. Applied identically to all transaction types.
FieldTypeDescription
base_feeuint64Base fee in tinycents. Defaults to 0.
extrasrepeated ExtraFeeReferenceExtras for computing the node fee. No duplicate references.

NetworkFeeSchedule

Network fee configuration. Calculated as a multiplier of the node fee.
FieldTypeDescription
multiplieruint32Multiplied by the node fee. Must be ≥ 1. Required.

ServiceFeeSchedule

Groups transaction and query fee configs for a single gRPC service.
FieldTypeDescription
namestringService name (e.g., CryptoService). Required.
schedulerepeated ServiceFeeDefinitionTransaction/query fee configs. Must not be empty.

ServiceFeeDefinition

Fee definition for a single transaction or query.
FieldTypeDescription
namestringTransaction/query name (e.g., CryptoCreate). Required.
base_feeuint64Base fee in tinycents. Defaults to 0.
extrasrepeated ExtraFeeReferenceExtras for this transaction/query. No duplicate references.
freeboolIf true, base_fee and extras are ignored — the operation is free.

ExtraFeeReference

References an ExtraFeeDefinition with an optional included count.
FieldTypeDescription
namestringName of the referenced extra. Must match a defined extra. Required.
included_countuint32Units included for free in the base fee. Defaults to 0.

UnreadableTransactionFeeSchedule

Punitive fee for nodes that submit unparsable bytes.
FieldTypeDescription
feeuint64Punitive fee in tinycents. Optional (may be 0).

Validation Rules

Before a new fee schedule takes effect, the network validates it. If any rule fails, the schedule is rejected.
The JSON must parse and conform to the FeeSchedule protobuf message. All required fields must be present and types must match. No unrecognized fields.
All baseFee and fee fields must be non-negative integers. For extras, fee must be strictly > 0.
The multiplier in network must be a positive integer ≥ 1.
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.
Every extra reference must point to a defined extra. No duplicate references within a single list.
If free is true, baseFee and extras are ignored during calculation but must still comply with all validation rules if present.

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.