Large-scale applications — token platforms, gaming ecosystems, enterprise onboarding pipelines — often need to create thousands of entities in short bursts. Today, Hiero's standard throttle limits can become a bottleneck for these workloads during peak usage.
HIP-1313, recently approved by the Technical Steering Committee, introduces a parallel high-volume throttle lane for entity creation. Developers opt in with a single transaction flag and agree to pay a variable fee during busy periods. Standard throttling and pricing remain completely unchanged for everyone else.
Introduction and Background
Hiero uses throttle buckets to cap the rate of each transaction type, protecting the network from storage overload, processing strain, and bandwidth exhaustion. For everyday use these limits are more than sufficient. However, applications that need to create many accounts, tokens, or files in rapid succession — such as large-scale user onboarding flows or NFT minting pipelines — can run into these caps during peak periods and face delays waiting for available slots.
The existing model offers no way for high-throughput callers to access extra capacity, even if they are willing to pay for it. HIP-1313 solves this by introducing a second, independent throttle system running alongside the standard one.
What is HIP-1313?
HIP-1313 adds a new optional boolean field, high_volume, to the base TransactionBody protobuf message:
bool high_volume = 25;
When a supported creation transaction sets this flag to true, it is routed through a dedicated high-volume throttle bucket instead of the standard one. The key design properties are:
- Separate capacity — high-volume transactions do not consume any standard throttle capacity
- Variable pricing — fees scale with how busy the high-volume lane currently is, encouraging efficient use
- User-controlled cost ceiling — developers can set a
maxTransactionFeeto cap what they will pay - No priority advantage — all transactions, standard or high-volume, are processed in arrival order
Motivation and Goals
The proposal targets several distinct goals:
- Allow developers to create entities at higher rates without being blocked by standard throttles
- Keep standard throttles and fixed pricing fully unchanged for users not opting in
- Make high-volume pricing predictable through a governed formula, not market speculation
- Deter abuse by making sustained high utilization progressively more expensive
- Preserve fair transaction ordering across both systems
Technical Implementation
Supported Transaction Types
The high_volume flag is meaningful on the following transactions:
CryptoCreateCryptoTransfer(for auto-account creation only)TokenCreateTokenMintTokenAssociateToAccountTokenAirdrop/TokenClaimAirdropFileCreateScheduleCreateConsensusCreateTopicContractCreate(HAPI call)CryptoApproveAllowance
EVM-initiated entity creation is explicitly excluded from this HIP and will be handled in a future proposal.
Throttle Configuration
High-volume buckets are defined separately in the network's throttle configuration with a "highVolume": true marker. A network may define both per-type buckets (e.g. for CryptoCreate and ScheduleCreate) and a combined total-entity-creation ceiling. Transactions that exceed either bucket are rejected the same as standard throttle violations.
Variable Rate Pricing
Pricing is governed by a VariableRateDefinition attached to the fee schedule:
- A
max_multiplierfield caps the maximum fee as a multiple of the standard fee, preventing extreme cost spikes - An optional
PricingCurve(piecewise linear) maps current lane utilization (0–100%) to a multiplier value - If no curve is configured, the multiplier is linearly interpolated between 1× and
max_multiplier
The final fee is: fee = standard_fee × multiplier, never exceeding the user's maxTransactionFee.
The actual multiplier applied is returned as the high_volume_pricing_multiplier field in the transaction receipt, giving callers full transparency on what they were charged and at what utilization level.
SDK Usage
AccountCreateTransaction tx = new AccountCreateTransaction()
.setKey(publicKey)
.setInitialBalance(Hbar.from(10))
.setHighVolume(true)
.setMaxTransactionFee(Hbar.from(5));
Developers can also pre-check the current high-volume rate via the Mirror Node before deciding whether to opt in.
Impact on the Ecosystem
For developers: a single flag unlocks high-throughput entity creation with transparent, predictable pricing. Setting maxTransactionFee gives full cost control.
For Mirror Node consumers: the /api/v1/transactions and /api/v1/accounts/{id} APIs will expose high-volume fields, including the applied multiplier, for analytics and fee estimation.
For network operators: high-volume capacity and pricing curves are independently configurable, allowing fine-grained control over throughput allocation and abuse deterrence.
For regular users: no change whatsoever — standard throttles, capacity, and fixed pricing are entirely unaffected.
Conclusion
HIP-1313 is a well-scoped improvement that unblocks a real category of use cases without compromising the base network experience. The parallel throttle design keeps both systems clean and independent, the governed pricing model avoids unpredictable cost spikes, and the opt-in flag means zero impact on existing applications.
As Hiero continues to grow, proposals like this — expanding capability through additive, non-breaking design — will be key to supporting a diverse and high-performance ecosystem.
