HIP-1261 introduces Simple Fees, a unified base + extras pricing model where every Hedera transaction is calculated from a single JSON schedule. The model is live on testnet today and is targeted for mainnet in the v0.73 release in May 2026. Developers building on Hedera can validate fee impact for their applications on testnet ahead of the mainnet transition.
What Simple Fees Does
Simple Fees applies one consistent pricing model to every transaction on Hedera. A transaction’s total fee is the sum of three components: a node fee, a network fee, and a service fee. Each component is calculated as base + Σ(extras), where extras measure the cost of specific resources used by the transaction.
The new fee configuration lives in a single JSON file at system file 0.0.113. The fee schedule at file 0.0.111 is preserved in its current format and remains accessible to existing consumers.
For builders, this turns transaction cost into a property of the application code that can be planned for, asserted against, and audited. CI pipelines can check that a representative transaction stays under a dollar budget before the application ships. Wallets can show the exact fee before the user signs. Cost reviews can attribute every fraction of a cent to a specific signature, byte, key, or NFT serial, all from the same published schedule the consensus node enforces.
The same arithmetic yields the same fee everywhere it is calculated. Three concrete benefits follow for builders:
- Per-resource transparency. Each cost driver (signatures, bytes, keys, NFT serials, gas) has an explicit price published in the schedule.
- Exact predictable pricing. A serialized transaction can be priced before submission using the REST API fees endpoint, or directly in the SDK using the FeeEstimateQuery call.
- Tooling parity. SDKs, mirror nodes, and explorers return identical fee calculations for identical inputs.
How It Works
The three fee components in the canonical mainnet schedule:
- Node fee. A flat base of $0.00001 plus extras for PROCESSING_BYTES (1,350 included free) and SIGNATURES (1 included free). Compensates the submitting node for pre-check and submission work.
- Network fee. Calculated as 9 × node fee. Covers gossip, consensus, signature verification, and blockstream storage.
- Service fee. A per-transaction base plus service-specific extras. Reflects execution and state cost.
All three components are accumulated in the Fee Collection Account 0.0.802 and redistributed to nodes 0.0.98, 0.0.800, and 0.0.801 each staking period.
All values are computed in USD (stored as tinycents in the canonical schedule, where 1 USD = 1010 tinycents) and converted to HBAR using the network exchange rate at handle time. Dollar amounts shown throughout this post are derived directly from the canonical schedule values. The conversion logic is unchanged.
The canonical schedule defines extras across several categories:
- Per-payload metering: SIGNATURES, STATE_BYTES, PROCESSING_BYTES, KEYS, ALLOWANCES, RECORDS
- Token operations: TOKEN_TYPES, NFT_SERIALS, TOKEN_ASSOCIATE, TOKEN_TRANSFER_BASE, TOKEN_TRANSFER_BASE_CUSTOM_FEES, TOKEN_CREATE_WITH_CUSTOM_FEE, TOKEN_MINT_NFT_BASE, TOKEN_MINT_NFT, NFT_UPDATE, AIRDROPS
- Account and accumulators: ACCOUNTS
- Compute: GAS
- Hedera Consensus Service (HCS): CONSENSUS_CREATE_TOPIC_WITH_CUSTOM_FEE, CONSENSUS_SUBMIT_MESSAGE_WITH_CUSTOM_FEE, CONSENSUS_SUBMIT_MESSAGE_WITH_CUSTOM_FEE_BYTES, CONSENSUS_SUBMIT_MESSAGE_WITHOUT_CUSTOM_FEE_BYTES
- Schedule-specific: SCHEDULE_CREATE_CONTRACT_CALL_BASE
The complete, canonical JSON schedule is committed to the implementation repository at hedera-node/configuration/mainnet/upgrade/simpleFeesSchedules.json and is byte-identical across mainnet, testnet, and previewnet.
A Worked Example
A CryptoCreate transaction with three signatures and one key, computed from the canonical mainnet schedule:
- nodeFee = $0.00001 + (3 – 1) × $0.00001 = $0.00003
- networkFee = 9 × $0.00003 = $0.00027
- serviceFee = $0.0499; the single key is within the KEYS included count
- Total: ~$0.0502, converted to HBAR at handle time
This calculation is deterministic and consistent across different tools.
What Stays the Same
The core fee experience for most workloads is preserved under Simple Fees:
- USD-denominated pricing, paid in HBAR. Fees are computed in USD and converted at the network exchange rate at handle time. The conversion logic is unchanged.
- Free network queries. CryptoGetAccountBalance and TransactionGetReceipt remain free.
- The fee schedule at file 0.0.111 remains accessible. It is preserved in its current format for consumers who read it directly.
- The existing mirror node fee endpoint is unchanged. GET /api/v1/network/fees continues to return gas estimates for ContractCall, ContractCreate, and EthereumTransaction. The JSON-RPC relay and other tooling that depend on it continue to work without changes.
For most application patterns, the practical impact at the wallet layer is minimal: a transaction submitted on v0.73 lands a fee in the same neighborhood as on v0.72, with the most pronounced pricing differences concentrated in a few specific patterns described in the next section.
Fee Pricing by Transaction Type
The table below lists canonical price points from the v0.73 schedule. As of May 2026, mainnet runs v0.72; testnet runs v0.73 (Simple Fees). Builders can submit identical transactions on both networks and read TransactionRecord.transactionFee to see the exact dollar fee for their workload on each network. Please note, the USD value used in the below table are calculated using the
| Transaction Pattern | Simple Fees Math | Approximate USD |
| Simple HBAR CryptoTransfer, 2 accounts, 1 sig | node $0.00001 + network $0.00009 + service via extras | ~$0.0001 |
| ContractCall (typical) | nodeNetworkFeeExempt: true; pays only EVM gas | gas only |
| HCS ConsensusSubmitMessage, ≤100 bytes, 1 sig (no custom-fee topic) | node $0.00001 + network $0.00009 + service base $0.00007 | ~$0.00017 |
| HCS ConsensusSubmitMessage, 101 to 1024 bytes (no custom-fee topic) | as above + (bytes – 100) × $0.00000068 per extra byte | ~$0.0002 to $0.0008 |
| HCS ConsensusSubmitMessage, custom-fee topic, ≤1024 bytes | node + network + service base $0.00007 + custom-fee surcharge $0.04983 | ~$0.0500 |
| ScheduleCreate with inner ContractCall | node + network + service base $0.0099 + SCHEDULE_CREATE_CONTRACT_CALL_BASE $0.09 | ~$0.10 |
| ContractCreate | node + network + service base $0.9999 + bytecode/gas extras | starts at ~$1.00, scales with bytecode |
| TokenCreate (no custom fee) | node + network + service base $0.9999 + key extras | ~$1.00 |
| TokenCreate with custom fee | as above + TOKEN_CREATE_WITH_CUSTOM_FEE $1.00 | ~$2.00 |
| Multi-key CryptoUpdate, 5 keys | service base $0.00012 + (5 – 1) × KEYS $0.01 | ~$0.04 |
| Other queries (default) | service base ~$0.0000000084 | <$0.0001 |
To verify any value above, the canonical schedule is published at mainnet/upgrade/simpleFeesSchedules.json. The same file ships unchanged for testnet and previewnet. Pricing is set by the Hedera Council.
Testing with Simple Fees
Simple Fees is live on testnet today and targeted for the v0.73 mainnet release in May 2026. Developers building on Hedera can validate fee impact for their applications now by testing manually or by pointing their application at testnet and running a transaction mix that mirrors production traffic.
Transaction patterns worth validating on testnet:
- Multi-signature or multi-key administrative updates (TopicUpdate, CryptoUpdate, TokenUpdate)
- HCS messages on non-custom-fee topics that exceed the 1024-byte included threshold
- Smart contract creation (gas-driven)
- Token creation with custom fees
Custom setMaxTransactionFee() configurations
Estimating Fees Before Submission
The mirror node REST API includes an endpoint for fee estimation: POST /api/v1/network/fees. The endpoint accepts a serialized Hedera API (HAPI) transaction in binary protobuf form and returns a deterministic fee breakdown. It is live on both testnet and mainnet (mirror node v0.153.1 as of May 2026).
Two estimation modes are supported via a mode query parameter:
- INTRINSIC (default): estimates from the transaction payload alone (size, signatures, declared keys, gas). Fast, deterministic, and stateless.
- STATE: estimates using the transaction plus the mirror node’s latest known state (alias-to-account mapping, required token associations, custom-fee tokens). Closer to the actual on-network charge for transactions whose cost depends on the existing state.
The hiero-sdk-java, hiero-sdk-go, hiero-sdk-rust, and hiero-sdk-js libraries expose this endpoint through a FeeEstimateQuery, with a convenience Transaction.estimateFee() method on every transaction type. The query is available in hiero-sdk-js v2.83.0; consult each SDK’s release notes for the version that introduces FeeEstimateQuery support.
Estimating Fees with the SDKs
Transaction.estimateFee() returns the fee breakdown for a built transaction without submitting it or consuming HBAR. It dispatches a FeeEstimateQuery against the mirror node estimator under the hood, so the lower-level FeeEstimateQuery API returns the same payload for callers that need it. Submitting on testnet and reading TransactionRecord.transactionFee is the complementary ground-truth check against the estimator. Below is an example response of Transaction.estimateFee():
{
"node": {
"base": 100000, // $0.00001
"extras": [
{
"name": "SIGNATURES",
"included": 1,
"count": 3,
"charged": 2,
"fee_per_unit": 100000, // $0.00001 per chargeable signature
"subtotal": 200000 // $0.00002 (2 chargeable × $0.00001)
}
]
},
"network": {
"multiplier": 9,
"subtotal": 2700000 // $0.00027 (9 × node total $0.00003)
},
"service": {
"base": 499000000, // $0.0499
"extras": []
},
"high_volume_multiplier": 1,
"total": 502000000 // $0.0502
}All values are in tinycents, where 1 USD = 1010 tinycents. The fields in this response:
- node.base is the $0.00001 flat charge; node.extras lists each chargeable resource driver. Here SIGNATURES shows included: 1 (free), count: 3 (used), charged: 2 (paid for), at fee_per_unit: 100000 ($0.00001) each, with subtotal: 200000 ($0.00002).
- network.multiplier is the fixed 9× factor; network.subtotal is the multiplier × the full node fee (base + extras). Here: 9 × 300,000 = 2,700,000 tinycents = $0.00027.
- service.base is the per-transaction service fee for CryptoCreate ($0.0499). service.extras is empty because the single key fits inside the included KEYS count.
- high_volume_multiplier is the high-volume pricing multiplier (1× when no surge applies).
- total is the sum across components: 300,000 + 2,700,000 + 499,000,000 = 502,000,000 tinycents = $0.0502.
The same extras shape applies to every component (included, count, charged, fee_per_unit, subtotal), so any line item in a fee can be attributed to a specific resource driver from the schedule.
1. Build the exact transaction shape your application sends in production. Match the memo, key set, message size, chunking configuration, and signer set. Then call freeze() to finalize the transaction body for serialization and signing.
2. Estimate via FeeEstimateQuery. Call Transaction.estimateFee() (or construct a FeeEstimateQuery directly) to get the deterministic node, network, service, and total breakdown without consuming HBAR.
3. Set realistic fee caps. Call setMaxTransactionFee() with enough headroom for the Simple Fees pricing. Tight caps can produce an INSUFFICIENT_TX_FEE result rather than a successful execution.
4. Submit on testnet (v0.73, Simple Fees) for ground-truth. Use payloads representative of production traffic, including signature counts, key counts, and message sizes.
5. Read the actual fee paid from the transaction record. TransactionRecord.transactionFee returns the fee charged by the consensus node, in tinybars. Compare against the estimator output from step 2.
6. Audit at scale via the mirror node. The transactions endpoints on the mirror node return the same fee values across batches, which makes it straightforward to baseline thousands of representative transactions in a single pass.
Next Steps
Simple Fees is live on testnet today. Test manually or point an application at testnet, run a representative transaction mix through FeeEstimateQuery (or submit and read TransactionRecord.transactionFee), and compare the resulting fees against current production budgets on mainnet before the v0.73 mainnet release in May 2026.
The full HIP-1261 specification is published at hips.hedera.com/hip/hip-1261. The canonical fee schedule is at hedera-node/configuration/mainnet/upgrade/simpleFeesSchedules.json. Implementation progress is visible in the hiero-consensus-node and hiero-mirror-node repositories, and the model can be discussed in the Hedera Developer Discord.
FAQs
Will Simple Fees change the current fees I am paying for transactions?
No. Simple Fees defines a unified pricing model (base + extras); the actual prices are set by Hedera Council governance. Many common transactions, including HBAR CryptoTransfer, typical ContractCall, balance queries, and transaction receipts, remain priced in cents or fractions of a cent under the Simple Fees schedule. An example where you may see an increase in cost, is a transaction that requires multiple signatures.
What tool should developers use to estimate fees today?
FeeEstimateQuery (or Transaction.estimateFee()) returns a deterministic breakdown from the mirror node’s POST /api/v1/network/fees endpoint without submitting the transaction. The endpoint is live on both testnet and mainnet mirror node endpoints today. Submitting and reading TransactionRecord.transactionFee via the SDK remains a useful ground-truth check.
Will mirror nodes provide Simple Fees estimates?
Yes. The estimator endpoint POST /api/v1/network/fees is live on both testnet and mainnet (mirror node v0.153.1 as of May 2026). INTRINSIC mode shipped in v0.151.0 and STATE mode shipped in v0.152.0.
What about programmatic fee checks in the SDK?
FeeEstimateQuery is available in hiero-sdk-js, hiero-sdk-java, and hiero-sdk-go from v2.83.0 onward and calls the live mirror node estimator on both testnet and mainnet. Submitting on testnet and reading TransactionRecord.transactionFee remains a useful ground-truth check against the estimator.
