Skip to main content

​
Gas

When executing smart contracts, the EVM requires the amount of work paid in gas. The “work” includes computation, state transitions, and storage. Gas is the unit of measurement used to charge a fee per opcode executed by the EVM. Each opcode has a defined gas cost. Gas reflects the cost necessary to pay for the computational resources used to process transactions.
Following HIP-1249, Hedera has implemented operational-based throttling and eliminated minimum gas charges, providing more predictable resource management and fairer billing for smart contract operations.

​
Weibar

Gas information for EVM operations is returned in weibar (introduced in HIP-410).
  • 1 weibar = 10^-18 HBAR
  • 1 tinybar = 10^10 weibar
As noted in HIP-410, this maximizes compatibility with third-party tools that expect ether units to be operated on in fractions of 10^18, also known as a Wei.

​
Gas Schedule and Fee Calculation

Gas charges apply to ContractCall, ContractCreate, and EthereumTransaction. Other smart contract-related transactions (e.g., ContractDelete, ContractGetInfo) use standard Hedera network, node, and service fees in HBAR. Gas fees for EVM transactions consist of:
  • Intrinsic Gas: The minimum amount of gas required to execute a transaction
  • EVM Opcode Gas: The gas required to execute the defined opcodes for the smart contract call
  • Hedera System Contract Gas: The required gas associated with Hedera-defined transactions, such as using the Hedera Token Service system contract

​
Intrinsic Gas

A transaction submitted to the smart contract service must be sent with enough gas to cover intrinsic gas. With the Cancun fork of the EVM update, intrinsic gas is calculated as: 
21000 + 4 × (number of zero bytes) + 16 × (number of non-zero bytes) = intrinsic gas
  • 21,000: The base gas cost for any transaction
  • 4 × (zero bytes): The cost of each zero byte in the transaction payload
  • 16 × (non-zero bytes): The cost for each non-zero byte in the transaction payload
If insufficient gas is submitted, the transaction will fail during precheck and no record will be created.
This applies to both standard transactions and jumbo EthereumTransactions introduced by HIP-1086, which allow larger callData payloads.

​
EVM Opcode Gas

Execution costs in the EVM include both fixed and dynamic costs:
  • Fixed Cost: Base cost per opcode execution
  • Dynamic Cost: Varies by parameters (e.g., cold vs warm storage access)
Example: For the SLOAD opcode, which loads data from storage:
  • Fixed Cost: 100 gas units (base cost per execution)
  • Dynamic Cost (Cold Access): 2,100 gas units (first-time access to the storage slot)
  • Dynamic Cost (Warm Access): 100 gas units (subsequent access within the transaction)
If SLOAD accesses a storage slot twice within the same transaction, the total gas cost would be calculated as follows:
  • First Access (Cold) = 100 + 2,100 = 2,200 gas
  • Second Access (Warm) = 100 + 100 = 200 gas
  • Final Gas Cost Total = 2,400 gas
📣 Explore opcodes in Cancun fork.

​
Hedera System Contract Gas

Hedera system contract gas fees apply only when using a native Hedera service. They are calculated by converting the transaction cost in USD to gas using a set conversion rate, then adding a 20% surcharge for overhead and variations in gas usage. Example: For a $0.10 transaction with a conversion rate of 1,000,000 gas per USD:
  • Base Gas Cost = 0.10 × 1,000,000 = 100,000 gas
  • Total Gas Cost = 100,000 × 1.2 = 120,000 gas
  • Final gas cost total = 120,000 gas
Following HIP-1249, system contract operations also contribute to operational throttling through measured ops costs, providing layered resource protection alongside gas-based billing.

​
System Contract View Functions

The gas requirements for HTS view functions can be calculated in a slightly modified manner. The transaction type of getTokenInfo can be used and a nominal price need not be calculated. This implies that converting the fee into HBAR is not necessary as the canonical price ($0.0001) can be directly converted into gas by using the conversion factor of 852 tinycents. Add 20% markup. Thus gas cost is:
  • Base gas cost = (1000000 + 852000 - 1) × 1000 / 852000 = 2173 gas
  • Total Gas Cost = 2173 × 1.2 = 2607 gas
Final gas cost total = 2607 gas
Example System Contracts:Learn More: Our detailed gas calculation reference explains the precise steps for calculating gas fees on Hedera.

​
Gas for Jumbo Transactions

Jumbo EthereumTransactions that include large callData under HIP-1086 follow the same gas model as standard EVM transactions. This gas pricing applies only to EthereumTransaction type; standard HAPI transactions are unaffected.

​
Formula

The gas cost for callData is based on byte content: 
callData gas = (4 × zero bytes) + (16 × non-zero bytes)
This is added to the base gas and execution gas to calculate the total gas required. 📣 Learn more about Ethereum jumbo transactions

​
Example Calculation

For 100KB of callData with 10,000 zero bytes and 90,000 non-zero bytes:
  • Zero byte gas: 4 × 10,000 = 40,000
  • Non-zero byte gas: 16 × 90,000 = 1,440,000
  • Total callData gas = 1,480,000
Ensure both gasLimit (RLP) and maxGasAllowance (wrapper) are set high enough to cover the total.
🔹 Size Caps: Jumbo EthereumTransactions are capped at 24KB (creation) and 128KB (call). Larger payloads require callDataFileId.
🔹 Throttling: Jumbo transactions are subject to dedicated operational throttling based on transaction type and complexity.

​
Gas Limit

The gas limit is the maximum amount of gas you are willing to pay for an operation. The current opcode gas fees are reflective as of the 0.22 Hedera Service release.
OperationCancun Cost (Gas)Current Hedera (Gas)
Code deposit200 * bytes200 * bytes

BALANCE
(cold account)

26002600

BALANCE
(warm account)

100100
EXP10 + 50/byte10 + 50/byte

EXTCODECOPY
(cold account)

2600 + Mem2600 + Mem

EXTCODECOPY
(warm account)

100 + Mem100 + Mem

EXTCODEHASH
(cold account)

26002600

EXTCODEHASH
(warm account)

100100

EXTCODESIZE
(cold account)

26002600

EXTCODESIZE
(warm account)

100100

LOG0, LOG1, LOG2,
LOG3, LOG4

375 + 375*topics
+ data Mem

375 + 375*topics
+ data Mem

SLOAD
(cold slot)

21002100

SLOAD
(warm slot)

100100

SSTORE
(new slot)

22,10022,100

SSTORE
(existing slot,
cold access)

2,9002,900

SSTORE
(existing slot,
warm access)

100100

SSTORE
refund

As specified by the EVMAs specified by the EVM

CALL et al.
(cold recipient)

2,6002,600

CALL et al.
(warm recipient)

100100

CALL et al.
HBAR/ETH Transfer Surcharge

9,0009,000

SELFDESTRUCT
(cold beneficiary)

26002600

SELFDESTRUCT
(warm beneficiary)

00
TSTORE100100
TLOAD100100
MCOPY3 + 3*words_copied + memory_expansion_cost3 + 3*words_copied + memory_expansion_cost
The terms ‘warm’ and ‘cold’ in the above table correspond with whether the account or storage slot has been read or written to within the current smart contract transaction, even within a child call frame. ‘CALL et al.’ includes with limitation: CALL, CALLCODE, DELEGATECALL, and STATICCALL Reference: HIP-206, HIP-865

​
Operational-Based Throttling

While most EVM-compatible networks use per-block gas limits for resource control, Hedera uses time-based throttling. Following HIP-1249, Hedera has transitioned from gas-per-second to operations-per-second (ops/sec) throttling, controlling network throughput based on actual computational demands rather than gas estimates. This potentially supports significantly higher throughput while maintaining EVM compatibility. Ops costs are derived from nanosecond performance benchmarks with safety margins, covering EVM opcodes, precompiles, and system contracts. Gas continues for user billing and per-transaction limits, separating cost calculation from throttling.
Performance: Real-world testing shows substantial improvements, with Uniswap achieving over 150 million gas/sec compared to the previous 15 million gas/sec limit.

​
Transaction Execution Outcomes

With operational-based throttling, transaction processing follows specific patterns based on resource availability: Ops Throttle Exhausted: When the operations-per-second throttle is exhausted either before execution begins or during execution, transactions fail with a THROTTLED_AT_CONSENSUS error and are charged only the intrinsic gas fee. Gas Limit Exhausted: If a transaction’s gas limit is exhausted before the ops throttle, it fails with an out-of-gas error and users are charged for the full gas used, with ops deducted for work completed. Successful Execution: For successful transactions, users are charged for the exact gas used and the corresponding ops units are deducted from the throttle bucket.

​
Gas Reservation and Unused Gas Refund

Hedera throttles transactions before consensus, and nodes limit the number of transactions they can submit to the network. At consensus time, if the maximum number of transactions is exceeded, the excess transactions are not evaluated and are canceled with a busy state. Throttling by variable gas amounts provides challenges to this system, where the nodes only submit a share of their transaction limit. To address this, Hedera now uses operational-based throttling that applies only at consensus. The system operates with:
  • Frontend (ingest/precheck): Uses TPS limits only with no gas-based throttling
  • Backend (consensus): Applies operations-per-second (ops) throttling based on actual computational work performed
It is impossible to know the actual evaluated gas pre-consensus because the network state can directly impact the flow of the transaction, which is why pre-consensus uses the gasLimit field and will be referred to as the gas reservation. Contract query requests are unique and bypass the consensus stage altogether. These requests are executed solely on the local node that receives them and only influence that specific node’s precheck throttle. To ensure transactions can execute properly, setting a higher gas reservation than will be used by execution is common. On Ethereum mainnet, the entire reservation is charged to the account before execution, and the unused portion is credited back. However, Ethereum utilizes a memory pool (mempool) and does transaction ordering at block production time, allowing the block limit to be based only on used and not reserved gas. Users are charged only for the actual gas used during transaction execution, with unused gas being fully refunded. This aligns with Ethereum’s billing model and eliminates the previous minimum charge requirements.

​
Maximum Gas Per Transaction

Each transaction on Hedera is capped by a per-transaction gas limit. If a transaction’s gasLimit exceeds this cap, it is rejected during precheck with the INDIVIDUAL_TX_GAS_LIMIT_EXCEEDED error and does not proceed to consensus. This gas metering approach ensures efficient resource use, preventing excessive consumption while allowing flexibility for larger, more complex smart contracts. Per-transaction gas limits remain unchanged (e.g., 15 million gas per transaction), while network throughput is now managed through operational-based throttling. Refer to HIP‑1249 for implementation details. Reference: HIP-185