EIP-0000 Preferential Gas Costs for Native ETH Operations – Draft for feedback

crypDuck · August 5, 2026, 7:37pm

Discussion topic for Preferential Gas Costs for Native ETH Operations (early draft)

Update Log

2026-08-05: Initial draft published

External Reviews

None as of 2026-08-05.

Outstanding Issues

Final confirmation of the 0.75 factor by client teams after benchmarking against concurrent state-access changes (e.g. EIP-8038)
Whether the factor should also apply to SELFBALANCE and/or CALLVALUE (currently left open)
Residual value handling in SELFDESTRUCT (if still relevant)

Context

This is the second proposal aiming to increase ETH’s role as a “digital reserve currency”. One way to achieve this is to make operations that use native balances structurally cheaper and more convenient than the equivalent operations on other tokens. While simple top-level transfers already enjoy a cost advantage, internal value-bearing calls still pay a significant surcharge (and have no advantage over using any other token). Reducing that friction is intended as a demand-side improvement rather than a change to issuance or staking economics.

Proposal

Apply a multiplicative factor of 0.75 to:

The value-transfer gas component of CALL, CALLCODE, CREATE and CREATE2 when value > 0
The cold and warm access costs of BALANCE

The value-transfer component is defined with reference to the Yellow Paper’s G_callvalue and the EIP-8038 decomposition (ACCOUNT_WRITE + CALL_STIPEND).

Repo (README + both drafts):

Specific draft:

github.com/crypDuck/eip-drafts

02-preferential-gas-costs-for-native-eth-operations.md

main

---
title: Preferential Gas Costs for Native ETH Operations
description: Apply a preferential gas factor to the value-transfer component of CALL/CREATE-family opcodes and to BALANCE access costs, reinforcing native ETH as the preferred medium of exchange and unit of account.
author: crypDuck
discussions-to: https://ethereum-magicians.org/t/preferential-gas-costs-for-native-eth-operations-draft-for-feedback/29302
status: Draft
type: Standards Track
category: Core
created: 2026-08-04
requires: 2929, 3529
related: Native ETH as ERC-20 Precompile
---

## Abstract

This EIP applies a multiplicative preferential factor to the value-transfer gas component of `CALL`, `CALLCODE`, `CREATE` and `CREATE2` when `value > 0`, and to both the cold and warm access costs of `BALANCE`. The change makes operations that move or query native ETH balances cheaper relative to the same operations on other tokens, reinforcing ETH as the preferred medium of exchange, unit of account, and digital reserve asset.

## Motivation

A plain native ETH transfer costs 21 000 gas. A typical ERC-20 transfer costs 45 000–65 000 gas. Balance queries via `BALANCE` are also cheaper than an ERC-20 `balanceOf`. These structural differences already favour native ETH for simple top-level transfers.

This file has been truncated. show original

Feedback is particularly welcome on the magnitude of the factor, the precise definition of the scaled component, and whether the ultra-cheap context opcodes should also be included. There is a related companion proposal that introduces a native-ETH ERC-20 interface at 0x20 in the same repository (discussion topic).

Snek · August 10, 2026, 6:26am

This is a hard but simple no for me.

I don’t see the problem this is solving that justifies adding another special case to Ethereum’s gas pricing. Gas costs should primarily reflect resource usage, and deviations from that should have a very strong protocol-level justification.

“Increase ETH’s role” isn’t enough for me. ETH already has the strongest possible structural advantage: it is the native asset of Ethereum and the only asset directly used for staking and protocol security. I don’t think it needs additional protocol-engineered incentives just to make it more attractive relative to ERC-20s.

Every special rule adds complexity that clients, specifications and future protocol changes have to carry indefinitely. Unless the benefit is genuinely important, simplicity wins.

So for me the burden of proof here is very high, and I don’t think “give ETH another demand-side advantage” clears it.

crypDuck · August 11, 2026, 10:29am

Thank you for the clear and direct feedback.

You raise a fair point: any deviation from resource-cost pricing requires strong justification, and every special rule carries permanent complexity for clients, specifications, and future protocol changes. I addressed the trade-off in the On resource-cost pricing section, where strengthening ETH as the native medium of exchange and unit of account is treated as a goal that can justify this limited exception.

I agree the burden of proof is high. The current draft does not yet contain a quantitative analysis of the implementation and maintenance overhead versus the expected impact on ETH’s role (and on reducing wrapping and intermediate-token state growth). Without that analysis, both positions remain largely judgment-based.

Is your objection primarily principles-based - i.e., you would remain opposed to adding any such special case at this stage of the roadmap regardless of the measured benefit - or would clearer quantification of costs and benefits potentially change the evaluation?