EIP-0000 Native ETH as ERC-20 System Contract – Draft for feedback

Discussion topic for Native ETH as ERC-20 System Contract (early draft) Update Log 2026-08-05: Initial draft published External Reviews None as of 2026-08-05. Outstanding Issues Final confirmation of the exact gas constants by client teams (targets are currently illustrative) Final confirmation of address 0x20 by AllCoreDevs Edge cases around the balance invariant under EIP-7702 temporary code Selector-collision risk on the optIn() method for legacy contracts Context Native ETH currently lacks a uniform ERC-20 interface. Protocols that want to treat ETH the same way as other tokens either special-case native transfers or route through WETH. This creates ongoing overhead, extra transactions, and state growth. The broader goal is to encourage the use of native ETH vs. other tokens, thereby strengthening ETH’s role as the preferred medium of exchange and unit of account by increasing its utility and making it the preferred token at the protocol level. The ultimate goal is enhancing ETH’s status as the “reserve currency of the digital economy”. Proposal Introduce a stateful system contract at address 0x20 that: Exposes native ETH balances through a standard ERC-20 + ERC-2612 interface Moves real account balances (no token-balance mapping) Never executes recipient code Carries a preferential gas schedule so the native path is cheaper than ordinary ERC-20s or WETH This revives and updates an idea previously discussed on Magicians in 2022: EIP: ETH as ERC20 Precompile EIPs Simple Summary Precompile allowing ETH to directly be treated as and transferred as an ERC20 token, without intermediary wrapping / unwrapping steps. Motivation WETH is a very popular contract, almost constantly in the “top 30-40 gas guzzlers” according to etherscan . WETH provides the very useful ability for contracts to have a unified interface to transact in both ERC20 tokens and the native EVM asset (Ether ETH on Ethereum). Furthermore it gives ETH some added features due to its compliance … Repo (README + both drafts): github.com GitHub - crypDuck/eip-drafts: Be the change you want to see Be the change you want to see Specific draft: github.com/crypDuck/eip-drafts 01-native-eth-as-erc20-precompile.md main --- title: Native ETH as ERC-20 Precompile description: Introduce a system contract at address 0x20 that exposes native ETH balances through a standard ERC-20 (and ERC-2612) interface, with a preferential gas schedule that makes the native path cheaper than ordinary ERC-20 tokens or wrapped ETH. author: crypDuck discussions-to: https://ethereum-magicians.org/t/native-eth-as-erc-20-system-contract-draft-for-feedback/29301 status: Draft type: Standards Track category: Core created: 2026-08-04 requires: 20, 2612, 7528 --- ## Abstract This EIP introduces a system contract at address `0x20` that implements the ERC-20 and ERC-2612 interfaces against native ETH balances. Transfers through the contract move real account balances, emit standard `Transfer` events, and never execute recipient code. The methods are given a preferential gas schedule so that using native ETH via the standard ERC-20 interface is cheaper than the same operations on ordinary ERC-20 tokens or on wrapped ETH. The change removes the need for most WETH wrapping while preserving native ETH semantics for gas payment and value transfers. Although the title retains the familiar term “precompile” for continuity with prior discussion and existing implementations, the facility is implemented as a stateful system contract. State is required to store allowances and nonces. ## Motivation This file has been truncated. show original Feedback is especially welcome on the system-contract design, the opt-in mechanism for legacy contracts, the illustrative gas schedule, and any edge cases. There is a related companion proposal on preferential gas costs for native ETH operations in the same repository. 1 post - 1 participant Read full topic