HIP-1313 adds a second lane for entity creation on Hedera. The new lane is sized for short bursts of high-rate workloads. Setting high_volume = true on a supported transaction routes it into a dedicated throttle bucket and applies a predictable pricing curve indexed to that lane’s utilization. The standard lane keeps its fixed pricing and its existing throughput. HIP-1313 was shipped in the v0.73 network release, May 2026.
In practice, this gives builders a dedicated path for event-driven spikes: launch-day account onboarding for a new product, KYC migrations on a regulator’s deadline, or NFT distributions to large recipient lists. Pricing scales with real-time lane saturation and setMaxTransactionFee caps each transaction’s exposure, so a burst can run on the team’s own schedule and stay within a known budget ceiling.
What HIP-1313 Adds
The high-volume lane has three parts:
- An opt-in flag on the transaction body (high_volume = true) that routes a transaction into the high-volume lane.
- Dedicated throttle buckets for each supported transaction type, sized to absorb sustained high-rate traffic.
- Per-transaction pricing curves, committed to simpleFeesSchedules.json and reviewable in the consensus node repository, that set a fee multiplier based on real-time utilization of the corresponding bucket.
Transactions that do not set the flag continue to use the standard lane with no behavioral or pricing change.
Workload Patterns
The high-volume lane opens a new way to serve workloads that require creating many entities in short windows. Typical patterns include:
- Large-scale user onboarding during product launches or expansions into new markets.
- Bulk account or token creation for regulated migrations and identity workflows.
- NFT mint events that require thousands of mints in short time windows.
- Burst topic, schedule, or contract creation for orchestration-heavy applications.
Steady-state traffic should continue to use the standard lane at its fixed price.
Supported Transaction Types
When high_volume = true is set on a TransactionBody, the network applies the high-volume lane to fourteen entity-creation operations:
- ConsensusCreateTopic
- ContractCreate (HAPI)
- CryptoApproveAllowance
- CryptoCreate
- CryptoTransfer (only when it triggers account auto-creation)
- FileAppend
- FileCreate
- ScheduleCreate
- TokenAirdrop
- TokenAssociateToAccount
- TokenClaimAirdrop
- TokenCreate
- TokenMint
The flag is silently ignored for any other transaction type, ContractCall, EthereumTransaction, FileUpdate, AtomicBatch outer transactions, and scheduled inner transactions. A synthetic child CryptoCreate triggered by auto-create on a parent CryptoTransfer inherits the parent’s high_volume value.
High-Volume Throttle Capacity
Each supported transaction type has its own dedicated high-volume bucket plus a network-wide aggregate cap. Sustained throughput per bucket:
- CryptoCreate, CryptoApproveAllowance, ScheduleCreate, FileCreate, TokenCreate, TokenAssociateToAccount, TokenAirdrop: 10,000 TPS each
- TokenClaimAirdrop: 10,500 TPS
- TokenMint: 12,500 TPS
- ContractCreate: 17,500 TPS
- ConsensusCreateTopic: 25,000 TPS
- FileAppend: 50,000 TPS each
- Aggregate (HVTotalThrottles) cap across all fourteen operations plus CryptoTransfer: 31,500 TPS
These values are committed to throttles.json and are identical across mainnet, testnet, and previewnet upgrade configurations.
Pricing Curves
The supported entity-creating transactions are priced at standard_fee × multiplier. The multiplier is interpolated from a piecewise-linear curve indexed to the effective throughput on that transaction’s dedicated high-volume bucket. Curves are set by network governance and committed alongside the fee schedule, with a per-transaction maximum multiplier that caps the highest price the curve can produce.
Per-transaction curves, base prices, multiplier ceilings, and worked examples are published in the Hedera fees documentation: https://docs.hedera.com/hedera/core-concepts/high-volume-entity-creation
Capping Total Exposure
Set setMaxTransactionFee to cap total exposure. If the calculated fee would exceed the cap, the transaction returns INSUFFICIENT_TX_FEE instead of overcharging.
Code Examples
Set setHighVolume(true) on a supported transaction body to route it into the high-volume lane. The standard setMaxTransactionFee cap applies and bounds total exposure.
Hedera SDK for Java (v2.71+):
AccountCreateTransaction tx = new AccountCreateTransaction()
.setKey(publicKey)
.setInitialBalance(Hbar.from(10))
.setHighVolume(true)
.setMaxTransactionFee(Hbar.from(5));Hedera SDK for Go (v2.79+):
tx := hedera.NewAccountCreateTransaction().
SetKey(publicKey).
SetInitialBalance(hedera.HbarFrom(10)).
SetHighVolume(true).
SetMaxTransactionFee(hedera.HbarFrom(5))
Hedera SDK for JavaScript (v2.83+):
const tx = new AccountCreateTransaction()
.setKey(publicKey)
.setInitialBalance(Hbar.from(10))
.setHighVolume(true)
.setMaxTransactionFee(Hbar.from(5));
Reading the Applied Multiplier
The Mirror Node REST API is the canonical place to confirm the multiplier the network applied. After consensus, fetch the transaction by ID and divide high_volume_pricing_multiplier by 1000:
GET /api/v1/transactions/{transactionId}
Sample response (relevant fields):
{
"transactions": [
{
"transaction_id": "0.0.1234-1715000000-000000000",
"result": "SUCCESS",
"high_volume": true,
"high_volume_pricing_multiplier": 1750
}
]
}
A returned value of 1750 corresponds to a 1.75x multiplier on the standard fee. The same fields appear on /api/v1/transactions/{id} and on the transactions arrays in /api/v1/accounts/{id}.
Getting Started
The high-volume lane is live on testnet and mainnet today. To try it:
- Upgrade an SDK to the supported version (Java v2.71+, Go v2.79+, or JavaScript v2.83+).
- Set high_volume = true on the entity-creation transaction.
- Set setMaxTransactionFee to a cap that reflects acceptable spend.
- Read the multiplier back from the Mirror Node REST API (GET /api/v1/transactions/{transactionId}) to confirm what the network applied.
Mirror Node Updates
Mirror Node REST endpoints are extended to surface high-volume context:
- Transaction list and detail endpoints (/api/v1/transactions, /api/v1/transactions/{id}, transactions arrays in /api/v1/accounts/{id}) include a high_volume boolean and a high_volume_pricing_multiplier value.
- Fee estimation (POST /api/v1/network/fees) returns a high_volume_multiplier alongside the standard total. Callers multiply the returned total by high_volume_multiplier / 1000 to see the high-volume-priced equivalent. A single call covers both standard and high-volume estimates.
These updates ship in mirror node version 0.153.0 and later.
FAQ
Does the high-volume lane jump the queue? No. Transactions in either lane are processed in the order they reach consensus. The flag buys access to additional capacity, not priority within the consensus order.
What happens if high_volume = true is set on a transaction type the HIP does not list? The flag is ignored and the transaction processes through the standard lane at standard pricing.
How can runaway costs be avoided? As the fees are predictable and easy to calculate, setting setMaxTransactionFee to a maximum acceptable amount ensures the transaction fails with INSUFFICIENT_TX_FEE if the calculated fee would exceed that cap. Allowing you to calculate the maximum fee that you are willing to pay for a specific transaction and set the cap appropriately.
Do synthetic child transactions inherit the flag? A CryptoCreate synthesized from auto-create on a parent CryptoTransfer inherits the parent’s high_volume value. No other propagation occurs, and scheduled inner transactions cannot opt in.
Are EVM transactions covered in v0.73? EVM transactions ignore the flag in this release. A follow-up HIP will define how JSON-RPC relays surface the opt-in to Ethereum tooling such as MetaMask, Hardhat, and Remix.
Availability
HIP-1313 is gated by a network feature flag and was shipped in the v0.73 release, May 2026. SDK support is available in:
- Hedera SDK for Java: v2.71 and later
- Hedera SDK for Go: v2.79 and later
- Hedera SDK for JavaScript: v2.83 and later
Mirror Node API support arrives in version 0.153.0 and later.
Read the HIP and Join the Conversation
The high-volume lane is built for organizations running large-scale entity creation events. It is not a replacement for the standard lane and not the right tool for everyday traffic. Teams planning major onboarding events or bulk creation can read the full HIP-1313 specification at hips.hedera.com/hip/hip-1313 and join the discussion in Hedera’s Discord.
