Title: EIP_7791__GAS2ETH_opcode
Category: EIPs

Author: pcaversaccio
Date: 2024-10-20T16:08:08.944Z

EIP-7791: GAS2ETH opcode
Abstract
This EIP introduces a new GAS2ETH opcode that enables the direct conversion of gas/mana into ether (ETH).
Motivation
This EIP is based on the premise that smart contract authors and compiler teams 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.
Introducing the GAS2ETH opcode offers contract authors 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.

Author: trebor
Date: 2025-04-02T22:32:13.564Z

Maybe I’m missing something, but can’t this functionality be implemented right now with current opcodes?
# Push `gas_amount` * `gas_price` to stack
PUSH1 0x01 # `gas_amount`
GASPRICE
MUL

# Call to transfer the value to `addr`
PUSH0
PUSH0
PUSH0
PUSH0
SWAP4
PUSH20 0xaa  # `addr`
PUSH2 0x0834 # 2100

I get your point about wanting to use gas as a variable pricing strategy for monetization.  I don’t understand how adding an opcode to simplify already-possible behavior will make people more likely to use this approach.

Author: charles-cooper
Date: 2025-04-03T11:34:12.599Z

The opcode doesn’t just perform a computation. It actually converts gas to ether and sends it. It’s not already possible because existing opcodes deduct ether from the currently executing contract; while GAS2ETH effectively deducts from the transaction originator (or whoever is paying for gas).

Author: fiddy
Date: 2025-04-10T12:44:26.583Z

This is Fiddy, a researcher at Lido and ex-core developer at Curve (DEX). I have a lot of experience building in the application layer, and this particular EIP is also very interesting for use cases other than funding smart contract developers. The following statements are independent of my representation, but they are something I deeply stand by.
Disclaimer: the following is co-authored by an LLM (Google Gemini 2.5 Pro).
GAS2ETH introduces a fundamental mechanism enabling smart contracts to directly convert transaction gas, already paid by the sender, into ETH credited to the contract’s balance. While seemingly simple, this opcode offers a powerful primitive for simplifying on-chain fee structures and reducing operational risks for various applications, particularly those requiring dynamic fee adjustments. I believe this EIP warrants strong consideration and push from the application layer due to its significant potential benefits.
The Current Complexity of On-Chain Fee Management
Currently, smart contracts needing to implement dynamic fee structures face considerable complexities and inherent risks:

Indirect Fee Mechanisms: Contracts often cannot directly charge fees based on network congestion (i.e., gas prices). Instead, they rely on proxy metrics, such as tracking usage frequency via storage variables, to infer periods of high demand or volatility and adjust fees accordingly. This is an indirect and often imprecise method.
Fee Token Management: Many protocols, especially Decentralized Exchanges (DEXes), collect fees in the tokens being traded. This necessitates a multi-step, often cumbersome process:


Accumulation: Fees accrue in various, potentially volatile or illiquid, tokens.
Conversion: The protocol (or its DAO/operators/keepers) must periodically execute transactions to swap these accumulated fee tokens into a desired base asset like ETH or a stablecoin.
Risks: This conversion process introduces significant risks:

Market Volatility & Depegging: The value of accumulated fee tokens can drastically decrease between accumulation and conversion due to market fluctuations or events like stablecoin depegs.
Liquidity Issues & Slippage: Converting large amounts of fee tokens can face insufficient liquidity, leading to significant price slippage.
MEV Exposure: Fee conversion transactions themselves can be targets for Maximal Extractable Value (MEV), further eroding the collected value.
Operational Overhead: Managing this process requires dedicated infrastructure, transaction costs, and governance overhead.



EIP-7791: A Direct and Elegant Solution
EIP-7791 introduces the GAS2ETH opcode, offering a direct solution to these challenges.
Clarifying the Mechanics: GAS2ETH vs. PAY
It is crucial to distinguish the proposed GAS2ETH opcode’s function from that of potential complementary opcodes like PAY. Based on discussions surrounding the EIP’s design, GAS2ETH leverages the gas already supplied and paid for by the transaction initiator (effectively, the entity covering the transaction’s gas costs: tx.origin). When a contract executes GAS2ETH(g), it consumes g gas provided by the initiator, calculates the equivalent ETH value based on the transaction’s gas price, and credits this ETH to its own balance. Conversely, an opcode like PAY would serve a different purpose: deducting ETH from the current contract’s balance to transfer it externally, potentially offering benefits like reentrancy protection. Therefore, GAS2ETH is about the contract receiving ETH funded by the transaction initiator’s gas, while PAY would facilitate the contract sending ETH from its own reserves. This distinction underscores how GAS2ETH enables direct fee capture in ETH from the user interacting with the contract.
Mechanism: A contract executing GAS2ETH(g) would:

Consume g amount of gas from the transaction’s available gas limit (this gas cost is ultimately borne by the transaction sender as part of their overall gas payment).
Calculate the corresponding ETH value based on g * effective_gas_price (using the gas price context of the transaction).
Credit this calculated ETH amount directly to the smart contract’s own balance.

Benefits:


Intrinsic Dynamic Fees: Fees charged via GAS2ETH are inherently tied to network demand. When blockspace is contested and gas prices are high, the ETH value derived from consuming a fixed amount of gas (g) increases proportionally. This allows contracts to automatically adjust their fee levels based on real-time network conditions without complex logic or storage reads.


Simplified Fee Logistics: It entirely eliminates the need to handle intermediate fee tokens. Fees are collected directly in ETH, the network’s native asset.


Risk Mitigation: By receiving fees directly in ETH, protocols circumvent exposure to the volatility, depegging risks, liquidity constraints, and slippage associated with converting diverse fee tokens.


Reduced Transactional Overhead: The entire process of accumulating, managing, and converting fee tokens is bypassed, reducing the number of transactions required and associated gas costs.


Use Case: Revolutionizing DEX Fee Structures
Let’s revisit the DEX example:

Without GAS2ETH: A DEX facilitating a stablecoin pair swap collects fees in those stablecoins. If $500k worth of fees are collected on Friday, market turmoil over the weekend (e.g., a depeg) could reduce their value significantly before they can be converted to ETH on Monday/Tuesday, further impacted by slippage and potential MEV during the conversion swaps.
With GAS2ETH: The DEX contract could, as part of the swap execution, include a GAS2ETH operation. This consumes a predetermined amount of gas (g) paid by the user initiating the swap. The contract immediately receives the corresponding ETH value (g * tx.gasprice). If network congestion is high (high tx.gasprice), the ETH fee collected is higher, reflecting the increased demand for the DEX’s service during that period. The collected ETH can then be efficiently transferred to a designated withdrawal address, potentially using a complementary mechanism like the PAY opcode (often discussed alongside gas-related EIPs). This entire process is atomic, direct, and avoids intermediate token risks.

Conclusion and Call for Support
EIP-7791 (GAS2ETH) offers a foundational improvement to smart contract economics on Ethereum. By enabling direct conversion of gas cost to ETH revenue for contracts, it provides a robust, elegant, and risk-minimizing mechanism for implementing dynamic fees. This is particularly valuable for high-throughput applications like DEXes, but its utility could extend to lending protocols, NFT marketplaces, oracle services, and others that require a seamless fee management infrastructure.
The primary hurdle for such a valuable, low-level primitive is often demonstrating clear demand and utility from the application layer. Simplifying core economic interactions like fee collection in ETH strengthens the entire ecosystem. I urge developers, protocol designers, and the broader Ethereum community to recognize the potential of GAS2ETH, discuss its applications, and voice support for its inclusion in a future network upgrade.

Author: Vectorized
Date: 2025-04-12T00:29:40.470Z

I like this opcode.
It opens a whole new design space for smart contracts. Anything that requires a callback can use this opcode to pay the fees for the callback. No longer do we need the cumbersome quote + msg.value workflow for stuff like LayerZero.
While it’s technically possible to build this on the application layer, it breaks compatibility with existing routers and onchain superstructures. Additionally, paying via gas allows for transparency and minimal hassle workflows. People know how much they are going to pay. Contrast this with approving and pulling some ERC20 (needs simulation, and fragments liquidity).
To prevent the risk of DDoS via gas recycling, this opcode needs to take a cut of all gas that passes through it. A 10% cut should be Goldilocks.
I have outlined additional advantages of such an approach in a similar RIP RIP-7767: Gas to Ether Precompile

Author: charles-cooper
Date: 2025-04-12T07:54:03.211Z

Vectorized:

To prevent the risk of DDoS via gas recycling,


What do you mean by “gas recycling” here?

Author: Vectorized
Date: 2025-04-12T16:47:03.557Z

The amount of gas burned by a txn will increase the base fees via EIP-1559.
If this opcode refunds all the gas burned as ETH, one can use it to burn gas → get back the full gas → burn gas → get back the full gas …
So we need some decay factor.

Author: charles-cooper
Date: 2025-04-12T22:29:31.511Z

Discussed a bit offline, and the issue is that the opcode can be used to grief the base fee via EIP-1559 mechanics. It’s a good point, and I think the proper fix is to just not allow gas deducted via GAS2ETH to affect the base fee.
I think there are other benefits to the 10% decay factor, but I need to think about it more.

Author: charles-cooper
Date: 2025-04-12T22:38:41.431Z

A couple slightly weird things about this opcode:

It’s disconnected from gas mechanics, e.g. a contract can call GAS2ETH with arbitrarily large gas.
A contract can charge GAS2ETH to enable it to take an action it wasn’t able to before, like pass a balance check.

For these reasons, I am considering:

A limit on how much gas can be consumed with GAS2ETH in a given transaction. It should probably be capped at something like 15% of the entire gas limit of a transaction. This also fixes weird edge cases with eth_estimateGas (like gas consumed at runtime could be wildly different from the estimated gas)
Only applying the balance changes at the end of the transaction. This could have another benefit of making GAS2ETH cheaper(!), since it removes data dependency in the transaction on the new account value. For instance, in the previous example, the contract could charge GAS2ETH all day, but it still can’t pass the balance check. This pattern of deferring state changes to the end of a transaction has a precedent in historical SELFDESTRUCT behavior, when the account removal was deferred to the end of the transaction.

Author: fiddy
Date: 2025-04-14T07:25:41.416Z

It should probably be capped at something like 15% of the entire gas limit of a transaction.

I think this could work, however it does kill the various nifty defi use-cases and makes this opcode not very appealing at all. I think a solution must take Defi use-cases into account.