Skip to main content
Gas is a core mechanism on OpenGDP for managing network resources and ensuring system security. It determines how transactions consume computation and storage, how fees are charged, and how blockspace is allocated.

​
The Role of Gas

Gas serves two purposes:
  • Network Protection: Every operation has a cost. By charging for gas, the network makes spam and denial-of-service attacks economically unfeasible.
  • Blockspace Allocation: Each block has a fixed gas capacity, called the block gas limit. This forces users to incentivize the validator by giving higher fees, since only a limited number of transactions can fit in each block.

​
How Transaction Costs Are Determined

A transaction’s fee is calculated as:
Transaction Fee = Gas Used × Gas Price
  • Gas Used: The total gas consumed by the transaction’s operations. Simple transfers cost little, while storage writes and complex contract executions consume more.
  • Gas Price: The amount the sender is willing to pay per unit of gas, denominated in uusdc (the smallest unit of USDC, where 1 USDC = 1,000,000 uusdc).
Each transaction specifies a gas limit, which is the maximum gas it may consume. If the transaction exceeds the limit, execution halts, and the sender pays for the gas consumed up to that point. Since fees are denominated in USDC, users must hold a USDC balance to pay transaction costs.

​
The Transaction Gas Meter

Each transaction is evaluated against its own gas meter, defined by the gas limit set by the sender.
  • Purpose: Prevents a single transaction from consuming more resources than the sender is willing to pay for.
  • Mechanism: The gas limit specifies the maximum gas units the sender authorizes. As the transaction executes, each operation consumes gas, which is deducted from this limit.
  • Outcome: If execution completes before the gas limit is reached, the transaction succeeds. If execution runs out of gas, the transaction fails. All state changes are reverted, but the sender still pays for the gas consumed up to the limit. This makes setting a sufficient gas limit critical.

​
The Block Gas Meter

Blocks are also evaluated against a global gas meter, defined by the block gas limit.
  • Purpose: Ensures the total computational load of a block stays within predictable bounds, maintaining consistent block times and network stability.
  • Mechanism: When building a block, the proposer initializes the block gas meter to the block gas limit. Each included transaction reduces the remaining capacity.
  • Outcome: Transactions can be added until the meter is depleted. Once the limit is reached, no further transactions can be included in that block, regardless of the fees offered. This prevents any block from overloading validators.

​
Estimating Gas Before Execution

OpenGDP provides a simulation method via JSON-RPC that estimates gas usage without committing the transaction on-chain:
  • Simulation: The node runs the transaction in a sandbox environment, producing a gas estimate without changing state or charging fees.
  • Result: The estimated gas is returned, allowing applications to set a proper gas limit.
  • Best Practice: Add a buffer (typically 20–30%) to the estimate when setting the final gas limit. This prevents failures caused by small execution variations.

​
How Inclusions Are Determined

Transaction inclusion is determined by validators:
  • Validator Minimums: Each validator sets a minimum gas price (for example, 0.01 uusdc). Transactions below this value are excluded from that validator’s mempool.
  • Proposer Selection: When a validator is chosen as proposer, it selects transactions from its mempool, prioritizing those with higher gas prices. Transactions below its minimum are ignored.