Update EIP-8175: Add TX_GAS_LIMIT opcode

Merged by EIP-Bot.

Author: rakita

EIPS/eip-8175.md

@@ -13,13 +13,13 @@ requires: 2, 1559, 2718
 
 ## Abstract
 
-This EIP introduces a new [EIP-2718](./eip-2718.md) transaction type with [EIP-1559](./eip-1559.md) gas fields, typed `capabilities` (CALL and CREATE) that define the transaction's operations, a separate `signatures` list for authentication, a `fee_auth` field that executes account code to sponsor gas, and three new opcodes — `RETURNETH`, `SIG`, and `SIGHASH` — for fee delegation and in-EVM signature introspection.
+This EIP introduces a new [EIP-2718](./eip-2718.md) transaction type with [EIP-1559](./eip-1559.md) gas fields, typed `capabilities` (CALL and CREATE) that define the transaction's operations, a separate `signatures` list for authentication, a `fee_auth` field that executes account code to sponsor gas, and four new opcodes — `RETURNETH`, `SIG`, `SIGHASH`, and `TX_GAS_LIMIT` — for fee delegation and in-EVM transaction introspection.
 
 ## Motivation
 
 Each Ethereum upgrade has introduced new transaction types for new capabilities: [EIP-1559](./eip-1559.md) for priority fees, [EIP-4844](./eip-4844.md) for blobs, and [EIP-7702](./eip-7702.md) for authorizations. Both [EIP-4844](./eip-4844.md) and [EIP-7702](./eip-7702.md) extend and reuse mostly the fields from [EIP-1559](./eip-1559.md), yet each required an entirely new transaction type. This leads to linear growth of transaction types with overlapping gas-payment semantics. This EIP proposes a single extensible transaction format where new features are added as typed capabilities without defining new transaction types.
 
-Transaction sponsorship — where a third party pays gas on behalf of the sender — has been a long-sought feature. [EIP-8141](./eip-8141.md) proposes a solution using execution frames, new opcodes (`APPROVE`, `TXPARAM`), and per-frame gas budgets. This EIP achieves sponsorship with a simpler `fee_auth` field and three focused opcodes.
+Transaction sponsorship — where a third party pays gas on behalf of the sender — has been a long-sought feature. [EIP-8141](./eip-8141.md) proposes a solution using execution frames, new opcodes (`APPROVE`, `TXPARAM`), and per-frame gas budgets. This EIP achieves sponsorship with a simpler `fee_auth` field and four focused opcodes.
 
 ## Specification
 
@@ -39,9 +39,11 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 | `RETURNETH_OPCODE` | `0xf6` |
 | `SIG_OPCODE` | `0xf7` |
 | `SIGHASH_OPCODE` | `0xf8` |
+| `TX_GAS_LIMIT_OPCODE` | `0xf9` |
 | `RETURNETH_GAS` | `2` |
 | `SIG_BASE_GAS` | `2` |
 | `SIGHASH_GAS` | `2` |
+| `TX_GAS_LIMIT_GAS` | `2` |
 | `PER_SIG_SECP256K1_GAS` | `3000` |
 | `PER_SIG_ED25519_GAS` | `3000` |
 
@@ -165,7 +167,7 @@ When `fee_auth` is non-empty, the account at `fee_auth` sponsors the transaction
 | `CALLDATA` | empty |
 | `GAS` | `gas_limit` minus intrinsic gas |
 
-The `fee_auth` code MUST use `RETURNETH` to credit ETH into the transaction-scoped **fee escrow**. The amount credited MUST be at least `gas_limit * max_fee_per_gas` (the maximum possible fee). The `fee_auth` code MAY use `SIG` and `SIGHASH` to introspect signatures for authorization.
+The `fee_auth` code MUST use `RETURNETH` to credit ETH into the transaction-scoped **fee escrow**. The amount credited MUST be at least `gas_limit * max_fee_per_gas` (the maximum possible fee). The `fee_auth` code MAY use `TX_GAS_LIMIT` and `GASPRICE` to compute this required amount on-chain. The `fee_auth` code MAY use `SIG` and `SIGHASH` to introspect signatures for authorization.
 
 If `fee_auth` execution reverts, or the fee escrow is insufficient after `fee_auth` returns, the transaction is **invalid** and MUST NOT be included in a block.
 
@@ -241,6 +243,22 @@ Behavior:
 - Pushes `compute_base_hash(tx)` onto the stack as a 256-bit value.
 - The `fee_auth` code can reconstruct `sig_message` from `base_hash` + signature data obtained via `SIG`, then verify signatures using the `ecrecover` precompile or future Ed25519 precompiles.
 
+#### `TX_GAS_LIMIT` (`0xf9`)
+
+Returns the transaction's `gas_limit` field.
+
+| | |
+| --- | --- |
+| **Stack input** | (none) |
+| **Stack output** | `gas_limit` — the transaction's gas limit as a 256-bit value |
+| **Gas** | `TX_GAS_LIMIT_GAS` (2) |
+
+Behavior:
+
+- Pushes the `gas_limit` field of the current transaction onto the stack.
+- This opcode is available in all execution contexts, not only `fee_auth`.
+- The returned value is the transaction's total gas limit as specified by the sender, distinct from `GAS` (remaining gas) and `GASLIMIT` (block gas limit).
+
 ### Execution order
 
 The state transition for a Composable transaction proceeds as follows:
@@ -391,6 +409,10 @@ State changes made during `fee_auth` execution persist even if the main transact
 
 These opcodes enable in-EVM signature introspection. The `fee_auth` code loads signatures via `SIG`, obtains the base hash via `SIGHASH`, reconstructs `sig_message`, and verifies signatures using `ecrecover`. This allows arbitrary sponsor authorization without off-chain coordination beyond collecting signatures.
 
+### `TX_GAS_LIMIT` opcode
+
+The `fee_auth` code must escrow exactly `gas_limit * max_fee_per_gas` wei via `RETURNETH`. While `max_fee_per_gas` is accessible through `GASPRICE`, no existing opcode exposes the transaction's `gas_limit` — `GAS` returns remaining gas (which decreases during execution) and `GASLIMIT` returns the block gas limit. `TX_GAS_LIMIT` fills this gap, enabling `fee_auth` contracts to compute the required escrow amount on-chain without relying on calldata or hardcoded values.
+
 ### CALL and CREATE as capabilities
 
 Rather than embedding `to`, `value`, and `data` as top-level transaction fields, these are expressed as typed capabilities. This makes the transaction envelope a pure fee-paying and authentication container, while the actual operations — message calls and contract creation — are composable payload items. A transaction may contain multiple capabilities, enabling batched execution within a single transaction. Future capability types (e.g., blob data, authorization lists) extend the same list without modifying the envelope format.