High-Volume Entity Creation

Understand how high-volume throttles work, how variable-rate pricing affects your transaction fees, and how to use the high_volume flag effectively.

Hedera’s standard throttle system limits entity creation transactions (like CryptoCreate, TokenCreate, and TokenMint) to relatively modest per-second rates. This protects the network but can be a bottleneck for applications that need to create entities at scale — for example, bulk user onboarding, large NFT drops, or automated token deployments.

HIP-1313 introduces a high-volume throttle system that runs in parallel alongside the standard system. By setting high_volume = true on a supported transaction, you opt into dedicated capacity with higher throughput limits. The tradeoff: fees are variable and increase with utilization.

The standard throttle system is completely unaffected. Existing applications that do not set the high_volume flag will work exactly as before — same capacity, same pricing.

---

How It Works

Two Parallel Throttle Systems

When you submit an entity creation transaction, the network routes it to one of two independent throttle systems based on the high_volume flag:

	Standard Throttles	High-Volume Throttles
Opt-in	Default (no flag needed)	Set high_volume = true
Capacity	Current published limits	Dedicated high-volume buckets
Pricing	Fixed fee schedule	Variable-rate (scales with utilization)
Priority	Consensus order	Consensus order (no priority boost)

The two systems have completely separate capacity pools. Using one does not consume capacity from the other.

Variable-Rate Pricing

This is the most important thing to understand before using high-volume mode.

Unlike standard transactions where fees are predictable from the fee schedule, high-volume fees change dynamically based on how much of the high-volume capacity is currently in use:

1. The network measures utilization

   The network calculates how much of the high-volume throttle capacity is currently being consumed, expressed as a utilization percentage from 0% (idle) to 100% (saturated).

2. A pricing curve maps utilization to a multiplier

   A governance-configured pricing curve converts the utilization percentage into a fee multiplier. The curve is defined as a piecewise linear function — a series of (utilization, multiplier) breakpoints with linear interpolation between them. For example, given points (0%, 1.0×), (50%, 2.0×), and (100%, 5.0×), a utilization of 75% would produce a multiplier of 3.5×.

3. The multiplier is applied to the standard fee

   The base transaction fee (from the normal fee schedule) is multiplied by the current multiplier to produce the final fee. A max_multiplier caps how high the multiplier can go, preventing extreme pricing even at 100% utilization.

4. Your maxTransactionFee protects you

   If the calculated fee exceeds the maxTransactionFee you set on the transaction, the transaction fails with INSUFFICIENT_TX_FEE and you are not charged. This is your primary cost-control mechanism.

Depending on the governance-configured pricing curve, high-volume transactions may cost more than the same transaction sent through the standard throttle — even when there is no congestion. Always check the current multiplier before committing to a batch.

Pricing Curve

The base curve below is set by Hedera governance and defines how the fee multiplier scales with throughput in the high-volume lane. The multiplier is expressed relative to the standard base fee, and the throughput rate is expressed as a multiplier of the base entity creation rate.

High-Volume Throughput (× base create rate)	Fee Multiplier (× base price)
1	4×
1.5	8×
2.5	10×
3.5	15×
5	20×
7.5	30×
10	40×
25	60×
50	80×
100	100×
250	150×
500	200×
5,000	200×

Between breakpoints, the multiplier is linearly interpolated. The curve assumes the standard (low-throughput) lane is running at its maximum rate concurrently.

At the base create rate (1×), high-volume transactions already cost 4× the standard fee. At 100× throughput, the multiplier reaches 100×. The curve caps at 200× regardless of how much higher throughput goes. Always set maxTransactionFee to protect against unexpected costs.

This curve may be updated by Hedera governance. Use the Mirror Node fee estimation endpoint to see the current multiplier in effect.

---

Supported Transaction Types

The high_volume flag is supported on the following entity creation transactions:

View all 14 supported transaction types

Transaction Type	SDK Class	Notes
ConsensusCreateTopic	TopicCreateTransaction
ContractCreate	ContractCreateTransaction	HAPI only, not EVM
CryptoApproveAllowance	AccountAllowanceApproveTransaction
CryptoCreate	AccountCreateTransaction
CryptoTransfer	TransferTransaction	Only the account-creation portion
FileAppend	FileAppendTransaction
FileCreate	FileCreateTransaction
HookStore	—	Future transaction type
ScheduleCreate	ScheduleCreateTransaction
TokenAirdrop	TokenAirdropTransaction
TokenAssociateToAccount	TokenAssociateTransaction
TokenClaimAirdrop	TokenClaimAirdropTransaction
TokenCreate	TokenCreateTransaction
TokenMint	TokenMintTransaction	Fungible and NFT

The official Hedera SDKs expose setHighVolume() only on the transaction types listed above. If you are using a custom SDK or constructing protobuf transactions directly and set high_volume = true on a transaction type not in this list, the transaction will not fail. The flag is silently ignored and the transaction processes through the standard throttle system at standard pricing.

EVM transactions are excluded

Contract creations via CREATE / CREATE2 opcodes in the EVM do not participate in the high-volume system. A subsequent HIP will address EVM-specific high-volume behavior.

---

High-Volume Throttle Capacity

The high-volume system uses a two-level throttle structure. The HIP provides the following example configuration (actual mainnet values will be set by governance):

Throttle Bucket	Transaction Types	Example Capacity
HighVolumeCryptoThrottles	CryptoCreate + ScheduleCreate	10,500 ops/sec
HighVolumeTotalThrottles	All 14 supported types combined	31,500 ops/sec

These values are from the HIP’s example throttle configuration. Final mainnet and testnet capacity values will be set by Hedera governance and may differ.

A transaction must pass both its per-type bucket and the total bucket to be accepted. If either is exhausted, the transaction receives a BUSY response.

For comparison, the current standard AccountCreateTransaction throttle is 2 tps on mainnet. The high-volume system offers orders-of-magnitude more capacity for applications willing to pay the variable-rate fees.

---

How to Use High-Volume Mode

Step 1: Check Current Pricing

Before submitting high-volume transactions, query the Mirror Node fee estimation endpoint to see the current high_volume_multiplier. The HIP specifies that this field will be added to the existing fee estimation response:

curl "https://mainnet.mirrornode.hedera.com/api/v1/network/fees"

Look for the high_volume_multiplier field in the response. This value is divided by 1000 to produce the actual multiplier (e.g., a value of 1000 = 1.0×, 2000 = 2.0×). The fee totals in the response are not pre-multiplied — multiply the fee total by high_volume_multiplier / 1000 to calculate the high-volume price.

Step 2: Set the Flag and a Fee Cap

Java

// Create an account using high-volume throttles
AccountCreateTransaction tx = new AccountCreateTransaction()
    .setKey(publicKey)
    .setInitialBalance(Hbar.from(10))
    .setHighVolume(true) // Opt into high-volume throttles
    .setMaxTransactionFee(Hbar.from(5)); // ALWAYS set a fee cap

TransactionResponse response = tx.execute(client);
TransactionReceipt receipt = response.getReceipt(client);
AccountId newAccountId = receipt.accountId;

System.out.println("Account created: " + newAccountId);

Step 3: Handle Fee Failures Gracefully

If the current multiplier pushes the fee above your maxTransactionFee, the transaction will fail with INSUFFICIENT_TX_FEE. Your application should:

1. Catch the error
2. Re-query the current multiplier
3. Decide whether to retry with a higher cap, wait for utilization to drop, or fall back to the standard throttle system

---

Best Practices

Always set maxTransactionFee. This is not optional guidance — it is the only mechanism protecting you from unexpectedly high fees during utilization spikes.

Check the multiplier before batches. If you are about to submit 10,000 account creations, query the fee estimation endpoint first. A multiplier of 5× on 10,000 transactions is the difference between $500 and$2,500.

Implement adaptive fee caps. For long-running batch jobs, periodically re-check the multiplier and adjust your maxTransactionFee up or down. If the multiplier rises above your acceptable threshold, pause and retry later.

Consider time-of-day patterns. Like any shared resource, high-volume utilization may follow patterns. Off-peak hours may offer lower multipliers.

---

Verifying High-Volume Transactions

After a high-volume transaction reaches consensus, you can confirm its status via the Mirror Node REST API:

curl "https://mainnet.mirrornode.hedera.com/api/v1/transactions/{transactionId}"

The response includes:

• high_volume: true — confirms the transaction used the high-volume system
• charged_tx_fee — the actual fee charged (reflecting the variable-rate multiplier)

The TransactionResult protobuf (exposed via block streams) includes a high_volume_pricing_multiplier field (uint64, field number 13) showing the exact multiplier that was applied. This value is divided by 1000 to get the actual multiplier.

---

What High-Volume Mode Does NOT Do

No priority. High-volume transactions are processed in the same consensus order as all other transactions. Paying more does not make your transaction execute sooner.

No guaranteed throughput. The high-volume throttle provides additional capacity, but if that capacity is fully utilized by other users, your transaction will receive a BUSY response just like the standard system.

No impact on standard users. Applications that do not use the high_volume flag are completely unaffected — same throttle limits, same fixed-fee pricing.

---

Related Resources

HIP-1313 Specification

Full technical specification including pricing curve protobuf definitions

Transaction Fees

Standard fee schedule for all transaction types

Mainnet Throttles

Current standard and high-volume throttle limits

Modify Transaction Fields

SDK reference for setHighVolume() and other TransactionBody fields