Ethereum Charges for Gas Used. Solana Legacy/v0 Prices Requested Compute.

Ethereum generally charges execution against gas actually used. Solana legacy/v0 calculates the native priority fee from the requested compute-unit limit. Unused CU headroom can therefore cost money even when execution uses less than requested.

In this illustrative comparison, one user sets a 150,000 gas limit on Ethereum and requests 300,000 CU on Solana legacy/v0. The transactions use 100,000 gas and 180,000 CU respectively. They are not matched historical observations.

Fig. 1. Requested vs. realized resources in the illustrative example.

One user, two transactions

Fig. 2. Order of operations: Ethereum settles after execution reports gas used; Solana legacy/v0 computes the native priority fee from requested CU, so consumed CU never enters it. Displayed rates and amounts are illustrative.

Gas and CU are chain-specific accounting units. The comparison here is narrower: how unused capacity enters payment and inclusion on each chain.

Ethereum: the fee settles on what ran

The gas limit is the transaction's execution ceiling. The EVM records gas used after execution, and the receipt exposes gas used, status, and effective gas price [1,3]. Unused gas-limit headroom is not the settled execution quantity.

For a type-2 transaction, the effective gas price is determined by the protocol base fee together with the transaction's max fee and max priority fee caps — not simply base fee plus a raw tip. In this illustrative case, assume an effective gas price of 22 gwei:

execution fee = gas used × effective gas price
              = 100,000 × 22 gwei
              = 0.0022 ETH

The base fee itself is protocol-computed, not user-set: parent-block gas usage relative to target determines the next block's adjustment — above-target usage raises it, below-target usage lowers it [2].

The gas schedule and capacity regime are protocol-defined and can change through upgrades. Glamsterdam activated on Sepolia on October 6, 2026. The planned Hoodi activation was postponed on October 22, with no replacement date announced. Mainnet activation remains unscheduled [10]. Glamsterdam's gas-accounting changes are context for schedule mutability, not a third lane in this comparison.

Solana legacy/v0: priority fees price requested compute

This section concerns one path: the native priority fee for legacy/v0 transactions. Base/signature fees, runtime CU consumption, scheduler cost evaluation, and private ordering are separate mechanisms.

A legacy/v0 transaction can include SetComputeUnitLimit and SetComputeUnitPrice. The CU price is denominated in micro-lamports per requested CU [4,5]:

priority fee (lamports)
  = ceil(CU price in micro-lamports/CU × requested CU limit / 1,000,000)
  = ceil(10,000 × 300,000 / 1,000,000)
  = 3,000 lamports

The division by 1,000,000 converts the micro-lamport product to lamports; the implementation uses integer ceiling semantics. The native priority-fee amount is determined by the requested CU limit and CU price, independently of realized CU consumption: the 180,000 CU used at runtime is recorded but does not change the 3,000 lamports. This does not imply that runtime resource usage is irrelevant to inclusion; fee calculation and scheduling are separate mechanisms.

CU price alone is insufficient to characterize inclusion under the cited scheduler model. The cited Agave scheduler ranks transactions using validator fee reward relative to estimated transaction cost [4,5]:

priority = validator reward × 1,000,000 / (estimated cost + 1)

The reward includes the native priority fee and the validator-retained base-fee portion. Estimated cost adds signature, write-lock, instruction-data, program-execution, and loaded-account-data costs [4,5]. In the cited legacy/v0 cost model, the requested CU limit supplies the program-execution component. Raising the limit can therefore raise both the priority-fee payment and the denominator. It need not yield a proportional gain in this score, because the other terms do not move in lockstep. This describes how that Agave implementation dequeues transactions, not a universal landing guarantee: writable-account cost is not observed account contention, and private or block-engine paths can order transactions differently [9].

How large the headroom is onchain

A Solana.com analysis of the proposed Resource and Inclusion Fee puts consumed Cost Units at about 20% of requested Cost Units on aggregate [12]. Cost Units are the scheduler's cost-model quantity, which adds signature, write-lock, and data costs to execution CU [5]; the ratio does not measure priority-fee overpayment.

Syndica reported about 30% average utilization of requested compute through 2024 and early 2025, and modeled roughly 8,600 SOL per day in excess priority fees during 2024 without fully publishing the method [11]. Not all of that estimated overpayment was avoidable: a tighter requested limit can increase execution-failure risk, and the limit is set before realized consumption is known. The two ratios use different resource definitions and samples, so they are not a trend.

SGP-0003 proposed a burned resource fee on requested Cost Units and left the priority-fee formula intact. It drew 53.9% of participating stake, abstentions included, against a two-thirds requirement and was rejected [13].

Failure does not erase the fee

Failed transactions make the distinction concrete. On Ethereum, an included transaction that fails still pays for gas consumed up to the point of failure; unused gas-limit headroom is not billed as gas used [1,3]. Out-of-gas is a special case — it can consume the gas supplied rather than only the gas actually used before it — but the general rule is still consumption-based, not limit-based. On Solana legacy/v0, the base and native priority fees are charged whether execution succeeds or fails [4]; the native priority-fee amount depends on the requested CU limit and CU price, not on realized consumption, so a failed transaction pays the same priority fee a successful one at the same limit and price would.

Zheng et al. document frequent failed transactions among the bot accounts they study, but do not estimate requested-versus-consumed CU headroom or the fee attached to unused CU [8]. The practical point is narrower: a transaction can pay a priority fee set by its requested budget and still fail for reasons unrelated to compute exhaustion.

Solana v1 sits outside this comparison, but it is active on mainnet, devnet, and testnet. Its message configuration carries the priority fee as an absolute number of lamports, rather than the legacy/v0 price-times-limit rule; its resource limits also move out of ComputeBudget instructions [6,7]. The legacy/v0 arithmetic in this post should not be generalized to v1.

Closing

The object both chains support is headroom:

headroom = (requested limit - realized use) / requested limit

This normalizes safety-margin behavior; it does not make gas and CU physically equivalent.

Requested limits, realized consumption, fee payment, execution outcome, and contention are separate variables. Keep them separate before attributing a fee to priority or inclusion.

For legacy/v0, simulate CU consumption where feasible, then apply a justified safety margin. Solana's documentation uses a 10% margin as a starting point for that workflow [4], not as a universal optimum. With a positive CU price, an arbitrarily high requested limit raises the native priority fee; a limit trimmed too tightly raises failure risk. The choice is execution reliability versus unnecessary native priority-fee payment—not minimizing CU limits at any cost.

Appendix

Measurement note. A future empirical study would need requested limits, realized consumption, CU prices, fees paid, transaction outcomes, and defensible congestion or contention measures. It could examine unused headroom, its priority-fee component, and its relationship to inclusion or latency. This article does not estimate those relationships.

References

1. Ethereum gas documentation
2. EIP-1559
3. Ethereum Execution API schema
4. Solana fee structure and compute budget docs
5. Agave compute_budget_limits.rs, transaction_priority.rs, cost model, tag v4.2.2
6. Solana versioned transactions
7. SIMD-0385: Transaction v1
8. Zheng et al., "Why Does My Transaction Fail? A First Look at Failed Transactions on Solana," PACM SE 2 (ISSTA), 2025, doi:10.1145/3728943
9. Gerzon et al., "Quantifying the Threat of Sandwiching MEV on Jito," ACM IMC, 2025, doi:10.1145/3730567.3764493
10. Ethereum Foundation, Glamsterdam Testnet Announcement (Sepolia) and Glamsterdam on Hoodi Postponed (October 22, 2026)
11. Syndica, Deep Dive: Solana Onchain Activity – February 2025, March 13, 2025
12. Solana, Resource and Inclusion Fee: Digging into Data
13. SGP-0003: Resource and Inclusion Fee (status: Rejected); final tally reported by CryptoSlate, August 28, 2026