This EIP introduces a new GAS2ETH opcode that enables the direct conversion of gas into ether (ETH).
This EIP is based on the premise that smart contract authors, compiler teams, and public goods projects in general should be compensated for their contributions. Moreover, their compensation should scale with the usage of their contracts. A widely used and popular contract offers significant value to its users through its functionality and to the network by driving demand for blockspace — Ethereum's raison d'être. This increased demand also benefits miners and validators, who are rewarded for executing these contracts.
Monetizing smart contracts in a scalable manner remains challenging at the time of this writing. This difficulty is evident from existence of many different monetization strategies employed across various smart contracts — ranging from fee structures to the issuance of tokens with "tokenomics" of varying levels of complexity. Additionally, many public goods projects struggle to secure funding.
Introducing the GAS2ETH opcode offers contract authors, as well as the tools they use, a new way to achieve their monetization objectives. By charging gas, they integrate with an established user experience that is both familiar and understood by users. The proposed instruction ensures that existing transaction creation and processing tools remain unchanged. Moreover, by charging gas, contract authors align economically with network activity; they benefit from higher compensation during periods of intense network usage and receive less when activity is low. This helps align the incentives of smart contract authors, validators, and the broader network.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
A new opcode, GAS2ETH (0xFC), is introduced to enable direct conversion of gas into ETH within the EVM. This opcode operates under a new budgeting mechanism: each transaction maintains a global GAS2ETH budget initialized to the transaction gas limit (tx.gas_limit), and each call frame derives a local allowance from the gas forwarded to it. These budgets cap the total amount of gas that can be converted into ETH, both per call frame and across the entire transaction.
The GAS2ETH (0xFC) opcode executes according to the following rules:
addr then gas_amount. If there are fewer than two values on the stack, the calling context MUST fail with stack underflow.gas_amount from both the current call frame's local GAS2ETH allowance and the transaction-global GAS2ETH budget.
gas_amount is greater than the current call frame's local GAS2ETH allowance or the remaining transaction-global GAS2ETH budget, set gas_amount to min(gas_amount, remaining_local_allowance, remaining_global_GAS2ETH_budget).wei_val by multiplying gas_amount by the current transaction context's gas_price (EELS).addr with wei_val wei.wei_val onto the stack.On reverts (e.g., through the REVERT opcode or any exceptional halt), any gas paid out via GAS2ETH MUST be refunded to both the transaction-global and the parent call frame's budgets.
Note that the transfer of wei_val to the target account cannot fail. In particular, the destination account code (if any) is not executed, or, if the account does not exist, the balance is still added to the given address addr.
Gas consumed by GAS2ETH does not affect the base fee, burn, block gasUsed, or the transaction fee. Instead, the ETH transfer represents a direct payment from the transaction signer (i.e. tx.origin) to the recipient address, outside the block reward and fee accounting mechanisms. This ensures no duplication of ETH between the COINBASE reward and the amount transferred via GAS2ETH.
GAS2ETH Budgeting ModelA transaction maintains a single global GAS2ETH budget initialized to the transaction gas limit (tx.gas_limit). Each call frame also maintains a local allowance, derived automatically from the gas forwarded to it:
CALL, CALLCODE, or STATICCALL: allowance = min(forwarded_gas, remaining_global_GAS2ETH_budget).DELEGATECALL: the callee shares the caller's allowance.GAS2ETH deductions within that call frame are refunded to both the transaction-global and parent frame's budgets.GAS2ETH budget.This model ensures that untrusted callees cannot consume more GAS2ETH than the gas explicitly forwarded to them, while keeping total GAS2ETH creation bounded by the transaction's gas limit.
The proposed cost of this opcode is identical to the recently proposed PAY opcode.
| Constant | Definition |
|---|---|
WARM_STORAGE_READ_COST | EIP-2929 |
COLD_ACCOUNT_ACCESS_COST | EIP-2929 |
GAS_NEW_ACCOUNT | EELS |
GAS_CALL_VALUE | EELS |
addr in accessed_addresses?
WARM_STORAGE_READ_COST;COLD_ACCOUNT_ACCESS_COST.addr exist or is val zero?
GAS_NEW_ACCOUNT.val zero?
GAS_CALL_VALUE.GAS2ETH vs. pro-rata: The pro-rata model incentivizes inflating contract gas usage to artificially increase fees. In contrast, this proposal allows contract authors to charge their desired amount directly, eliminating the need for unnecessary gas consumption.gas_price, use the same gas price as which is used to calculate the tx cost in ETH. This leads to the most consistent computation between GAS2ETH and the user's experience when creating a transaction.GAS2ETH can interfere with the actual budget needed for execution of the contract. (For example, a target contract can "waste" gas with GAS2ETH, resulting in the caller not having enough gas to finish execution). This also results in GAS2ETH usage not affecting the burn rate. The intuition is that, since it doesn't actually use computational resources (which gas normally "accounts" for), it shouldn't affect blockspace computations or the base fee.GAS2ETH spending. In the future, a new EIP-2718-based transaction type could be added which includes an explicitly user-specified GAS2ETH budget.gas_amount exceeds the remaining budgets, both the current call frame's local GAS2ETH allowance and the transaction-global GAS2ETH budget. Since these budgets are not introspectable, the contract would otherwise have no way to gracefully avoid an exceptional halt.GAS2ETH than the gas explicitly forwarded to them.No backward compatibility issues found.
TBD
TBD
Like the PAY opcode and beacon withdrawals, GAS2ETH enables ETH transfers that occur without code execution in the recipient account. To prevent denial-of-service (DoS) attacks from untrusted callees, each call frame receives a local GAS2ETH allowance automatically derived from the gas forwarded to it, while a transaction-global GAS2ETH budget enforces an overall cap equal to the transaction's gas limit. This ensures that:
GAS2ETH budget beyond the gas explicitly forwarded to them.GAS2ETH spending capacity is naturally limited by its gas stipend.GAS2ETH in a transaction is strictly bounded.It's important to note that GAS2ETH introduces an economic incentive for malicious contracts to consume as much of their allowance as possible, converting previously non-profitable griefing vectors into potentially profitable ones. Contract authors SHOULD minimize forwarded gas and GAS2ETH exposure when interacting with untrusted code, similar to existing best practices for limiting gas stipends or ETH transfers.
Copyright and related rights waived via CC0.