> ## 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.

# 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](https://hips.hedera.com/hip/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.**

<Info>
  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.
</Info>

***

## 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](/learn/networks/mainnet/fees), high-volume fees change dynamically based on how
much of the high-volume capacity is currently in use:

<Steps>
  <Step title="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).
  </Step>

  <Step title="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×.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Warning>
  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.
</Warning>

### Pricing Curve

The base curve below is set by Hedera Council 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.

<Warning>
  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.
</Warning>

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

***

## Supported Transaction Types

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

<Accordion title="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                  |
</Accordion>

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.

<Note>
  #### **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.
</Note>

***

## 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   |

<Note>
  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.
</Note>

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

<Steps>
  <Step title="Step 1: Check Current Pricing">
    Before submitting high-volume transactions, price the **exact** transaction you intend
    to submit against the Mirror Node fee estimation endpoint. The `GET /api/v1/network/fees`
    endpoint returns generic per-type averages and does **not** include a
    `high_volume_multiplier`. To get an accurate high-volume estimate, build and freeze your
    transaction, then POST the serialized protobuf bytes to `/api/v1/network/fees`.

    The SDK's `toBytes()` returns a `TransactionList` wrapper; the mirror node fee endpoint
    expects a single `Transaction` protobuf, so unwrap the list before sending (shown as
    `extractFirstTransaction` below).

    <CodeGroup>
      ```javascript Account creation wrap theme={null}
      const tx = await new AccountCreateTransaction()
          .setKey(publicKey)
          .setInitialBalance(Hbar.from(10))
          .setHighVolume(true)
          .setMaxTransactionFee(new Hbar(100))
          .freezeWith(client);

      const txBytes = extractFirstTransaction(tx.toBytes());

      const response = await fetch(`${MIRROR_NODE_URL}/api/v1/network/fees`, {
          method: "POST",
          headers: { "Content-Type": "application/x-protobuf" },
          body: txBytes,
      });

      const estimate = await response.json();
      const multiplier = estimate.high_volume_multiplier / 1000;
      const highVolumeTotal = estimate.total * multiplier;
      ```

      ```javascript Token creation wrap theme={null}
      const tx = await new TokenCreateTransaction()
          .setTokenName("Fee Check Token")
          .setTokenSymbol("FEE")
          .setTokenType(TokenType.FungibleCommon)
          .setTreasuryAccountId(treasuryAccountId)
          .setInitialSupply(0)
          .setHighVolume(true)
          .setMaxTransactionFee(new Hbar(100))
          .freezeWith(client);

      const txBytes = extractFirstTransaction(tx.toBytes());

      const response = await fetch(`${MIRROR_NODE_URL}/api/v1/network/fees`, {
          method: "POST",
          headers: { "Content-Type": "application/x-protobuf" },
          body: txBytes,
      });

      const estimate = await response.json();
      const multiplier = estimate.high_volume_multiplier / 1000;
      const highVolumeTotal = estimate.total * multiplier;
      ```
    </CodeGroup>

    The response includes a `high_volume_multiplier` field scaled by 1000
    (e.g., `1000` = 1.0×, `2000` = 2.0×). The `total` field is **not** pre-multiplied —
    multiply `total` by `high_volume_multiplier / 1000` to get the high-volume price in
    tinycents.

    <Note>
      Mirror node data is near real-time but brief lag is possible between consensus and
      ingestion. Use this value to gauge current pricing. The multiplier applied when your
      transaction is processed may differ; expect the actual fee to vary.
    </Note>
  </Step>

  <Step title="Step 2: Set the Flag and a Fee Cap">
    <CodeGroup>
      ```javascript Account creation wrap theme={null}
      const tx = new AccountCreateTransaction()
          .setKey(publicKey)
          .setInitialBalance(Hbar.from(10))
          .setHighVolume(true)
          .setMaxTransactionFee(new Hbar(5));

      const response = await tx.execute(client);
      const receipt = await response.getReceipt(client);
      const newAccountId = receipt.accountId;

      console.log("Account created: " + newAccountId);
      ```

      ```javascript Token creation wrap theme={null}
      const tx = new TokenCreateTransaction()
          .setTokenName("My Token")
          .setTokenSymbol("MTK")
          .setTokenType(TokenType.FungibleCommon)
          .setTreasuryAccountId(treasuryAccountId)
          .setInitialSupply(0)
          .setHighVolume(true)
          .setMaxTransactionFee(new Hbar(5));

      const response = await tx.execute(client);
      const receipt = await response.getReceipt(client);
      const newTokenId = receipt.tokenId;

      console.log("Token created: " + newTokenId);
      ```
    </CodeGroup>
  </Step>

  <Step title="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
  </Step>
</Steps>

***

## Best Practices

<Tip>
  **Always set `maxTransactionFee`.** This is not optional guidance — it is the only
  mechanism protecting you from unexpectedly high fees during utilization spikes.
</Tip>

<Tip>
  **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.
</Tip>

<Tip>
  **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.
</Tip>

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

***

## Verifying High-Volume Transactions

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

```bash wrap theme={null}
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

<Info>
  **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.
</Info>

<Info>
  **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.
</Info>

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

***

## Related Resources

<CardGroup cols={2}>
  <Card title="HIP-1313 Specification" icon="file-lines" href="https://hips.hedera.com/hip/hip-1313">
    Full technical specification including pricing curve protobuf definitions
  </Card>

  <Card title="Transaction Fees" icon="coins" href="/learn/networks/mainnet/fees">
    Standard fee schedule for all transaction types
  </Card>

  <Card title="Fee Model" icon="coin" href="/learn/core-concepts/fee-model">
    Simplified `base-fee-plus-extras` pricing model
  </Card>

  <Card title="Mainnet Throttles" icon="gauge-high" href="/learn/networks/mainnet">
    Current standard and high-volume throttle limits
  </Card>

  <Card title="Modify Transaction Fields" icon="code" href="/native/transactions/modify-fields">
    SDK reference for `setHighVolume()` and other TransactionBody fields
  </Card>

  <Card title="Estimate a Fee" icon="calculator" href="/native/fees/fee-estimation">
    SDK reference for FeeEstimateQuery and fee estimation workflows
  </Card>
</CardGroup>