Yashotantra Academy logo
Core Architecture · Execution Economics

What are Gas Fees? The Multi-Chain Execution Economics Handbook

Every distributed ledger is a shared state machine with finite computational bandwidth. Gas fees represent the unit cost of executing operations, storing state, and prioritizing transactions across decentralized networks.

01

What is a Gas Fee?

In computer science, solving the Halting Problem means a blockchain cannot know in advance whether a smart contract will run forever. Gas solves this by allocating an execution budget: every computational instruction (addition, hashing, writing memory, state storage) consumes a predetermined unit of "gas." If the gas runs out mid-execution, state reverts, preventing denial-of-service (DoS) spam.

02

Why is it Not Constant?

Block space is strictly scarce (e.g. Ethereum's 30M gas limit or Bitcoin's 4M weight units). When global transaction demand exceeds block capacity, fees fluctuate according to auction theory:

  • EIP-1559 Elastic Blocks: Algorithmic base fees auto-adjust based on prior block congestion.
  • Mempool Bidding: Users outbid one another to secure fast block inclusion.
  • State Access Contention: High-frequency hot accounts (like DEX pools) bid up localized fees.
03

Who Gets the Fee?

Depending on the chain's tokenomics, fees are split between:

  • Protocol Burn (Destroyed): Reduces circulating supply to reward all token holders (e.g., Ethereum Base Fee, 50% Solana Base Fee, TON Burn).
  • Validators & Miners: Priority tips or full PoW fees directly pay block builders for hardware, security, and bandwidth.
  • Storage Funds: Move chains (Sui/Aptos) lock storage fees to subsidize future node operators.
Low-Level Execution Diagnostics

EVM Opcode Gas Profiler

In the Ethereum Virtual Machine, not all operations are created equal. Memory arithmetic is essentially free (3 gas), while writing permanent state to SSD disks (SSTORE) costs thousands of times more.

Click an opcode to inspect its internal mechanics:
Permanent Storage

SSTORE (Init 0 -> Non-Zero)

Allocating a brand new 32-byte storage slot permanently to the global state trie.

Fixed Gas Cost:20,000 units
Cost at 30 Gwei ($3,000 ETH):$1.8000
Cost on Layer 2 (0.05 Gwei):$0.003000
💡 Optimization takeaway: Cache storage variables (SLOAD) into local stack memory variables before running loops to avoid repeated 2,100 gas penalty fees.
EVM Execution Hierarchy

L1 vs L2 vs L3: Why EVM Gas Quantity and Price Vary

Even inside the EVM family, gas behaves completely differently across execution layers. On Layer 1, you pay for raw validation, global execution, and state storage. On Layer 2 (Rollups), execution is offloaded and batched into compressed EIP-4844 data blobs. Layer 3 rollups settle recursively onto L2 for microsecond hyper-scaling.

Select Transaction Scenario:
Simulate L1 Ethereum Base Fee:30 Gwei

Layer 1 (Ethereum)

L1 Base Layer

Full security and state consensus. Every node globally executes the smart contract opcode.

Gas Required:150,000 units
Effective Gas Price:32 Gwei
DA Data Cost:Direct Calldata
$14.40
0.00480 ETH
L2

Layer 2 (Base / Arbitrum)

~95% Cheaper

Rolls hundreds of transactions off-chain, verifies state transitions, and posts lightweight blobs to L1.

Gas Required:165,000 units
Effective Gas Price:~0.05 Gwei
DA Data Cost:EIP-4844 Blobs
$0.0248
0.0000083 ETH
L3

Layer 3 (Appchains)

Micro-cent

Dedicated appchains (gaming, high-frequency DeFi) settling recursively onto L2 with custom gas tokens.

Gas Required:132,000 units
Effective Gas Price:< 0.005 Gwei
Settlement Target:L2 State Root
$0.00037
0.00000012 ETH
Interactive Runtime Simulator

Cross-Chain Gas & Fee Calculator

Computed Fee Output
$1.7010
0.0005670 ETH (567,000 Gwei)
Burned Base Fee:0.0005250 ETH
Validator Priority Tip:0.0000420 ETH
Formula:21000 × (25 + 2) Gwei
Values recompute in real-time based on live opcode parameters and mathematical limits.
Cross-Chain Comparison

Execution & Pricing Models by Network

EVM Chains (Ethereum, Base, Arbitrum, Polygon)

EIP-1559 Dynamic Base Fee + Priority Tip

evm
Unit of Denomination: Gwei (1 Gwei = 10⁻⁹ ETH) / Wei
Mechanism: Every transaction specifies a Gas Limit and Tip. The protocol computes Base Fee dynamically per block based on target vs. actual gas usage. Total Cost = Gas Used × (Base Fee + Priority Fee). On Layer-2s, an L1 Data Availability (DA) blob fee is added.
Primary Cost Drivers:
  • Network Congestion — Blocks above 50% target capacity raise the Base Fee by up to 12.5% per block.
  • Opcode Complexity — SLOAD/SSTORE (storage), cryptographic pairings, and contract deployments consume far more gas units than simple transfers (21,000 gas).
  • L1 Calldata/Blob Posting — For Rollups, the cost of posting proofs/blobs to Ethereum L1.
Fee Recipient: Base Fee is permanently burned (deflationary). Priority fee (tip) goes directly to the block Validator / Proposer / Sequencer.
💡 Developer / Student TipNever increase your gas limit to speed up a transaction. Increase the Priority Fee (tip). In Solidity, optimize storage writes (SSTORE) first, as they are the costliest operations (up to 20,000 gas).

Solana (SVM)

Deterministic Base Fee + Local Priority Micro-Auctions

svm
Unit of Denomination: Lamports (1 SOL = 10⁹ lamports)
Mechanism: Solana charges a deterministic base fee per signature (typically 5,000 lamports / 0.000005 SOL) plus optional Compute-Budget prioritization fees. Fees are localized per write-locked state account rather than throttling the entire network.
Primary Cost Drivers:
  • Compute Units (CU) — Instructions have a default 200,000 CU cap, but optimized transactions request only what they need.
  • Signer Count — Every additional cryptographic signature adds 5,000 lamports.
  • Account-Specific Hotspots — Bidding up fees on a congested smart contract does not raise fees for unrelated token transfers elsewhere.
Fee Recipient: 50% of the base fee is burned, and 50% is awarded to the block Leader (validator). Prioritization fees go to the validator.
💡 Developer / Student TipAlways call SetComputeUnitLimit in your web3 transactions. If you do not set it, the SVM reserves the default limit and your transaction may be rejected during block building.

Bitcoin (UTXO Architecture)

Pure First-Price Mempool Auction

btc
Unit of Denomination: sats/vByte (Satoshis per Virtual Byte)
Mechanism: Bitcoin blocks are constrained by weight units (4M Weight Units / ~1MB-4MB virtual size). Miners sort transactions in their mempool strictly by the fee-rate (sats/vByte) offered to maximize their block reward.
Primary Cost Drivers:
  • Virtual Size (vBytes) — Total inputs, outputs, and witness data. More unspent outputs (UTXOs) consolidated = higher byte weight.
  • Script & Signature Type — Legacy (P2PKH) is heavy, Native SegWit (bech32) offers a 75% witness discount, and Taproot (Schnorr) is the most compact for multi-sig.
  • Mempool Congestion — High demand from Ordinals/Runes or global transfers forces users to outbid competing pending transactions.
Fee Recipient: 100% of the transaction fee is collected directly by the Proof-of-Work Miner that solves and broadcasts the winning block.
💡 Developer / Student TipConsolidate UTXOs during low-fee weekend windows. A 10-input legacy transaction can cost 10x more than a single Taproot (P2TR) transfer.

TRON (TVM)

Dual Resource Model + TRX Staking Freeze

tron
Unit of Denomination: Bandwidth & Energy (or Sun burned)
Mechanism: TRON separates network bandwidth (byte size) and computational energy (smart contract execution). Accounts get daily free bandwidth. Freezing (staking) TRX generates daily replenishing Bandwidth/Energy, avoiding fee burns entirely.
Primary Cost Drivers:
  • Byte Array Size — Consumes Bandwidth points (e.g., ~268 points for TRX transfer, ~345 points for TRC-20).
  • VM Opcode Cycles — Contract execution consumes Energy points (e.g., 32,000–65,000+ Energy for USDT transfers).
  • Direct Sun Burn — If an account lacks frozen Energy/Bandwidth, TRX is burned at a fixed rate (e.g., 280 Sun per Energy unit).
Fee Recipient: Burned TRX is destroyed permanently (reducing supply). Super Representatives (SRs) receive network block generation rewards.
💡 Developer / Student TipHigh-volume dApps and traders rent Energy from peer-to-peer liquidity pools instead of burning TRX directly, reducing operational costs by over 60%.

Sui & Aptos (Move Ecosystem)

Decoupled Computation Units + Dynamic Storage Fund & Rebates

sui
Unit of Denomination: MIST (Sui: 1 SUI = 10⁹ MIST) / Octas (Aptos: 1 APT = 10⁸ Octas)
Mechanism: Move chains separate the cost of transient execution (CPU/IO) from permanent on-chain state storage. When a transaction creates objects, you pay a refundable storage fee. When you delete old state objects, you receive a storage rebate.
Primary Cost Drivers:
  • Computation Units — Standardized execution steps surveyed and anchored by validators per epoch.
  • State Allocation — Bytes added to the persistent global object store.
  • Storage Deletion — Deleting old state items returns up to 99% of storage fees via the Storage Fund rebate.
Fee Recipient: Computation fees reward the current epoch's validators. Storage fees enter the protocol Storage Fund to subsidize future validators preserving the history.
💡 Developer / Student TipDesign smart contracts with garbage collection or prune old state objects. On Sui, deleting expired objects can result in a net-negative fee (the rebate exceeds the execution cost).

TON (The Open Network)

Actor-Model Asynchronous Message Fees

ton
Unit of Denomination: Nanotons (1 TON = 10⁹ nanotons)
Mechanism: Because TON is an asynchronous multi-shard network, transactions are chains of internal and external messages. Fees are split into 5 stages: Inward Message Fee, Storage Fee (rent per day), Gas Fee (TVM execution), Outward Forward Fee, and Action Fee.
Primary Cost Drivers:
  • Actor Message Hops — Multi-contract calls incur a separate forwarding fee for each inter-shard message routing hop.
  • Contract Storage Rent — TON accounts pay rent based on seconds stored and cell bits consumed. If balance reaches zero, the contract is frozen.
  • Cell Creation / Merkle Trees — Constructing new BoC (Bag of Cells) structures.
Fee Recipient: 50% of the gas fee is burned; the remaining 50% is distributed to the Masterchain and Workchain Validators.
💡 Developer / Student TipAlways maintain a small TON buffer in contract wallets. If an account runs out of gas mid-execution, partial sub-messages can complete while subsequent hops bounce back.

Dogecoin

Low-Floor UTXO Policy

doge
Unit of Denomination: DOGE per kB (or Koinu)
Mechanism: Inherits Bitcoin's UTXO fee structure but with a distinct, drastically lower default relay fee policy and a 1-minute block time, preventing mempool bidding wars under normal conditions.
Primary Cost Drivers:
  • Byte Size — Input/output consolidation volume in kilobytes.
  • Miner Policy Defaults — Minimum soft/hard relay fee configurations enforced by mining nodes.
Fee Recipient: 100% paid to Dogecoin Scrypt Proof-of-Work Miners (often auxiliary PoW-mined alongside Litecoin).
💡 Developer / Student TipModern Doge wallets enforce a 0.01 DOGE/kB standard. Avoid micro-dust transactions that bloat UTXO sets and make subsequent spend transactions bulky.

Architecture Matrix Summary

High-level comparison across consensus families

EVM (Ethereum, L2s)
Formula:Gas × (BaseFee + Tip)
Denomination:Gwei (10⁻⁹ ETH)
Recipient / Burn:Base burned; Tip to validator
SVM (Solana)
Formula:Base Sig + CU Priority
Denomination:Lamports (10⁻⁹ SOL)
Recipient / Burn:50% base burned; 50% + tips to leader
Bitcoin (UTXO)
Formula:vBytes × Fee Rate
Denomination:sats/vByte
Recipient / Burn:100% to PoW miner
TRON (TVM)
Formula:Bandwidth + Energy
Denomination:Points (or Sun)
Recipient / Burn:Uncovered fees burned
Move (Sui / Aptos)
Formula:Exec + Storage − Rebate
Denomination:MIST / Octas
Recipient / Burn:Gas to validators; storage to pool
TON
Formula:Msg + Storage + Gas
Denomination:Nanotons
Recipient / Burn:50% burned; 50% to validators
Dogecoin
Formula:Size × Flat Rate
Denomination:DOGE / kB
Recipient / Burn:100% to Scrypt PoW miner

How to Estimate Gas Accurately

  1. Simulate Call First: Use eth_estimateGas, Tenderly, or Solana preflight simulation to verify transactions before broadcasting.
  2. Inspect Live Mempools: Monitor mempool aggregators (mempool.space for BTC, Etherscan Gas Tracker for EVM) to time non-urgent transactions.
  3. Buffer Gas Limits: Add a 10%–20% safety pad to the Gas Limit on EVM to prevent Out-of-Gas errors while paying only for actual gas consumed.

Critical Gas Optimization Rules

  • Packing Storage Slots: Group uint128 or bool variables into single 32-byte slots in Solidity to avoid multi-SSTORE costs.
  • Clean On-Chain State: On Sui and Aptos, prune outdated state objects to harvest storage fee refunds.
  • SegWit / Taproot Encodings: Never spend from legacy Bitcoin addresses when creating high-input multi-sig transactions.

Practice Gas Optimization in the Staking Sandbox

Test staking, reward claims, and contract deployments live on Base Sepolia using our in-browser IDE with real EIP-1559 gas simulations.

Open Staking Sandbox →