--- rip: 7767 title: Gas to Ether contract description: A contract that burns gas and returns a portion of the gas burned to the caller as Ether author: Vectorized (@Vectorized), Mark Tyneway (@tynes), Zak Cole (@zscole), Charles Cooper (@charles-cooper) discussions-to: https://ethereum-magicians.org/t/rip-7767-gas-to-ether-precompile/21005 status: Draft type: Standards Track category: Core created: 2024-09-12 --- ## Abstract This proposal describes a contract that allows the caller to burn a specific amount of gas, and returns a portion of the gas burned to the caller as Ether. ## Motivation Contract Secured Revenue (CSR) enables contract developers to earn gas fees on their contracts. It enables new revenue streams in a composable, interoperable, enforceable way. CSR works with any existing token standard and applications. It does not require developers to break or create new contract standards for the sake of capturing value. However, implicit CSR which is metered by gas spent on every opcode can lead to negative externalities. Developers are incentivized to write bloated contracts, such as using a loop to perform unnecessary storage writes and compute. This standard proposes making CSR explicit with a special contract, `GASBACK`, which converts burned gas into Ether with a constant cost. Developers are incentivized to write efficient contracts, so that they can have more gas room to use for `GASBACK`. `GASBACK` offers the following advantages: - Composability, since Ether is to be paid back immediately to the caller. Also, `GASBACK` provides a standardized interface for explicit CSR, enabling reusable integration code in tooling and applications. - Permissionlessness, since contracts integrating `GASBACK` do not need to be vetted by a centralized team to ensure that they are not intentionally writing bloated code. - Transparency, since `GASBACK` can be implemented in Solidity with verified code. This gives developers better clarity and confidence over traditional implicit CSR operated by opaque CRON jobs. - Maintainability, since `GASBACK` is simple and flexible. - Usability, since the gas burned in `GASBACK` can be easily segmented from regular gas. ## Specification We will refer to this contract as the `GASBACK` contract. ### Behavior The `GASBACK` contract takes in calldata `bytes32(uint256(gasToBurn))`. The actual amount of gas burned may vary but SHOULD be proportional to `gasToBurn`. The `GASBACK` contract MUST be `O(1)` in state and compute costs with respect to `gasToBurn`. The `GASBACK` contract SHOULD give the caller a fraction of the gas burned back as Ether (or native currency). The `GASBACK` contract SHOULD do a best-effort transfer of Ether to the caller. If transferring Ether with a `call` fails, the `GASBACK` contract MAY create a new contract that use the `SELFDESTRUCT` opcode to force-transfer the Ether. The `GASBACK` contract MUST return `bytes32(uint256(amountOfEtherGivenBackToCaller))`. The amount of Ether obtained from the burned gas MUST not exceed `basefee * actualGasBurned`. The gas burned in `GASBACK` MAY be excluded from [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) and block gas limits. `GASBACK` can co-exist with traditional implicit CSR, but it is RECOMMENDED for chains to fully migrate to `GASBACK` if possible for maximum benefits. ### Beacon To support a variety of L2 implementations, there is no designated address for the `GASBACK` contract. Chains implementing `GASBACK` SHOULD include its address in their documentation. To facilitate onchain discovery, we designate a canonical beacon contract deployed by Nick's `CREATE2` factory. This beacon contract returns `abi.encode(gasbackAddress)` when called. ```solidity // SPDX-License-Identifier: CC0-1.0 pragma solidity ^0.8.28; // solc = 0.8.28, evm = london, optimization = 1000. contract GasbackBeacon { fallback() external payable { assembly { mstore(0x40, sload(returndatasize())) if xor(caller(), 0xffffFFFfFFffffffffffffffFfFFFfffFFFfFFfE) { return(0x40, 0x20) } sstore(returndatasize(), calldataload(returndatasize())) } } } ``` Final address of the beacon contract TBD. Implementation of the `GASBACK` beacon contract is OPTIONAL, as some chains do not support `CREATE2` deployments. ## Rationale `GASBACK` can be implemented as a preinstall, predeploy, precompile. On the Optimism stack, it is possible to implement `GASBACK` as a predeploy without modifying the client. The behavior is deliberately kept simple and flexible so that `GASBACK` can be implemented in the most suitable way for each EVM chain. ## Security Considerations Implementers must make sure that the precompile does not cause a net increase in the total amount of Ether on the network. EVM chains hosting any retroactive funding based on gas burned metrics should subtract the total amount of gas burned via the `GASBACK` precompile. ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md).