---
id: TIP-1016
title: Exempt Storage Creation from Gas Limits
description: Storage creation gas costs are charged but don't count against transaction or block gas limits, using a reservoir model aligned with EIP-8037 for correct GAS opcode semantics and EVM compatibility.
authors: Dankrad Feist @dankrad, Dragan Rakita @rakita
status: Backlog
related: TIP-1000, TIP-1010, TIP-1060, EIP-8037, EIP-8011, EIP-7825, EIP-7623
protocolVersion: TBD
---

# TIP-1016: Exempt Storage Creation from Gas Limits

## Abstract

Storage creation operations (new state elements, account creation, contract code storage) continue to consume and be charged for gas, this gas does not count against block gas limit but it is capped by max tx gas limit [EIP-7825](https://eips.ethereum.org/EIPS/eip-7825). Gas accounting uses a **reservoir model** (aligned with [EIP-8037](https://eips.ethereum.org/EIPS/eip-8037)) that splits gas into execution and reservoir gas, ensuring the `GAS` opcode accurately reflects the execution budget. This allows increasing contract code pricing to 2,500 gas/byte without preventing large contract deployments, and prevents new account creation from reducing effective throughput. 

## Motivation

TIP-1000 increased storage creation costs to 250,000 gas per operation and 1,000 gas/byte for contract code. This created two problems:

1. **Contract deployment constraints**: 24KB contracts require ~26M gas, forcing us to:
   - Keep transaction gas cap at 30M (would prefer 16M)
   - Keep general gas limit at 30M (would prefer lower)
   - Limit contract code to 1,000 gas/byte (would prefer 2,500)

2. **New account throughput penalty**: TIP-20 transfer to new address costs ~300,000 gas total (~55k execution + 245k state) vs ~50,000 gas to existing. At 500M payment lane gas limit:
   - Without exemption (single dimension): only ~1,700 new account transfers/block = ~3,400 TPS
   - With reservoir model (block limits apply to execution gas only): ~9,090 new account transfers/block = ~18,200 TPS
   - Existing account transfers: ~10,000 transfers/block = ~20,000 TPS
   - ~5x throughput improvement for new accounts by exempting state gas from block limits

The root cause: state gas counts against limits designed for execution time constraints. Storage creation is permanent (disk) not ephemeral (CPU), and shouldn't be bounded by per-block execution limits.

### Why a reservoir model

Simply exempting state gas from protocol limits without changing EVM internals creates two problems:

1. **`GAS` opcode inaccuracy**: The `GAS` opcode would return remaining gas from `tx.gas` minus all gas consumed (execution + state), which doesn't reflect the actual execution gas budget. A transaction with a high gas limit that has used 15.9M execution gas with a 16M EIP-7825 per-transaction gas limit would see `GAS` report millions of gas remaining, but OOG after just ~100k more execution gas.

2. **Broken gas patterns**: Contracts relying on `gasleft()` for loop guards, subcall gas forwarding (63/64 rule), and relay/meta-transaction patterns would see incorrect values, potentially leading to unexpected OOG reverts.

The reservoir model (from [EIP-8037](https://eips.ethereum.org/EIPS/eip-8037)) solves this by maintaining three internal counters:
* execution `remaining` gas is reflecting execution budget, used by cpu and state creation. Returned by `GAS` opcode.
* `reservoir` is holding overflow can be only be used for state creation
* `state_gas` is tracking cumulative state gas consumed during execution.

---

# Specification

## Gas Dimensions

All operations consume gas in two dimensions:

- **Execution gas** (`execution_gas`): Compute, memory, calldata, and the computational cost of storage operations (writing, hashing). This is the execution-time resource.

- **State gas** (`state_gas`): The permanent storage burden of state creation operations. This is the long-term state growth resource.

At the transaction level, the user pays for both. At the block level, only execution gas counts toward block and EIP-7825 max transaction gas limits; state gas is exempt.

## Storage Gas Operations

Storage creation operations split their cost between execution gas (computational overhead) and state gas (permanent storage burden).

The SSTORE split is inherited from [TIP-1060](tip-1060.md): the TIP-1000 creation cost (`SSTORE_CREATE_COST = 250,000`) is already split there into the residual (`SSTORE_SET_COST = 5,000`, charged by the SSTORE gas function on clean creations) and the creditable portion (`STORAGE_CREDIT_VALUE = 245,000`, governed by the storage-credit mechanism). TIP-1016 mirrors the TIP-1060 gas table entries exactly and only moves the creditable portion from execution gas into state gas — a clean creation costs exactly what it does under TIP-1060, but only the residual counts toward protocol limits.

| Operation | Execution Gas | Storage Gas | Total |
|-----------|---------------|-------------|-------|
| Cold SSTORE (zero → non-zero) | 7,200 | 245,000 | 252,200 |
| Hot SSTORE (non-zero → non-zero) | 2,900 | 0 | 2,900 |
| Account creation (nonce 0 → 1) | 25,000 | 225,000 | 250,000 |
| Contract code storage (per byte) | 200 | 2,300 | 2,500 |
| Contract creation (fixed upfront cost) | 32,000 | 468,000 | 500,000 |
| EIP-7702 delegation (per auth) | 25,000 | 225,000 | 250,000 |

For zero-to-non-zero `SSTORE`, Tempo keeps revm's decomposed Berlin accounting, with the same
table entries as TIP-1060: `GAS_WARM_ACCESS` (100) plus `sstore_set_without_load_cost`
(`SSTORE_SET_COST` = 5,000), for a 5,100 execution-gas write path. When the slot is cold, the
existing Berlin cold-slot access charge (`GAS_COLD_SLOAD = 2,100`) is retained on top of that
write component, for a total of 7,200 execution gas before state gas.

### EIP-7702 Delegation Pricing

Each EIP-7702 authorization writes a 23-byte delegation designator (`0xef0100 || address`) to the authority account's code field. This is permanent state: redelegation overwrites the account's code pointer but the old code entry persists in the code database.

The base cost per authorization is **25,000 execution gas + 225,000 state gas = 250,000 total**, matching account creation. This reverts the TIP-1000 reduction to 12,500 gas per authorization.

For authorizations where `auth.nonce == 0` (new account), the account creation cost (25,000 execution + 225,000 state) applies in addition to the delegation cost, for a total of 500,000 gas.

### Keychain Authorization Pricing

Keychain `authorize_key` is charged as intrinsic gas (T1B+). The SSTORE components use the same execution/state split as standard EVM SSTOREs:

| Component | Execution Gas | State Gas | Notes |
|-----------|-------------|-----------|-------|
| Signature verification | 3,000+ | 0 | ecrecover + P256/WebAuthn if applicable |
| Existing key check (SLOAD) | 2,100 | 0 | Cold SLOAD |
| Key slot write (SSTORE) | 5,000 | 245,000 | Zero-to-non-zero write component only; cold-slot access charged separately |
| Per spending limit (SSTORE × N) | 5,000 × N | 245,000 × N | Zero-to-non-zero write component only per token limit; cold-slot access charged separately |
| Buffer (TSTORE, keccak, event) | 2,000 | 0 | Computational overhead |

**Total per authorization:** ~12,100 + 5,000 × N execution gas, 245,000 × (1 + N) state gas.

The table above isolates the write component itself. Any first access to a cold storage slot still
incurs the standard Berlin cold-access charge separately.

### Precompile and Intrinsic Storage Operations

The execution/state gas split applies uniformly to all SSTORE and code deposit operations regardless of call site. Precompile storage operations route through the same path as standard EVM SSTOREs and inherit the split automatically. Intrinsic gas charges that include SSTORE costs (e.g. keychain authorization) use the same split.

Opcode-level `CREATE`/`CREATE2` follows the deployment flow above, including `HASH_COST(L)` for deployed bytecode.

**Exception:** Expiring nonce writes (TIP-1009) use `WARM_SSTORE_RESET` (2,900 gas) with zero state gas because they are ephemeral — entries are evicted from a fixed-size circular buffer and do not contribute to permanent state growth.

**Notes:**
- Execution gas reflects computational cost (writing, hashing) and counts toward protocol limits
- State gas reflects permanent storage burden and does NOT count toward protocol limits
- All gas (execution + state) counts toward user's `gas_limit` and is charged at `base_fee_per_gas`
- All other operations (non-state-creating) are charged entirely as execution gas
- Execution gas is set to at least the pre-TIP-1000 (standard EVM) cost for each operation, ensuring that exempting state gas from limits never makes an operation cheaper against protocol limits than it was before TIP-1000

## Transaction Validation

Before transaction execution, `calculate_intrinsic_cost` returns three values:

- `intrinsic_execution_gas`: Base transaction cost, calldata, access lists, and other non-state-creating intrinsic costs
- `intrinsic_state_gas`: State gas components of intrinsic cost (e.g., account creation for contract deployment transactions)
- `calldata_floor_gas_cost`: The [EIP-7623](https://eips.ethereum.org/EIPS/eip-7623) calldata floor, defined as `TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata + 21000`

`validate_transaction` rejects transactions where:

```
tx.gas < intrinsic_execution_gas + intrinsic_state_gas
```

or where:

```
max(intrinsic_execution_gas, calldata_floor_gas_cost) > max_transaction_gas_limit
```

The `max` ensures that calldata-heavy transactions cannot pass validation when their floor cost exceeds the per-transaction execution gas limit. The calldata floor is a execution gas concept — it does not interact with `intrinsic_state_gas` or `state_gas_reservoir`.

`validate_transaction` also returns `intrinsic_execution_gas`, `intrinsic_state_gas`, and `calldata_floor_gas_cost`.

## Transaction-Level Gas Accounting (Reservoir Model)

Since transactions have a single gas limit parameter (`tx.gas`), gas accounting is enforced through a **reservoir model**, in which `gas_left` and `state_gas_reservoir` are initialized as follows:

```python
intrinsic_gas = intrinsic_execution_gas + intrinsic_state_gas
available_gas = tx.gas - intrinsic_gas
execution_gas_budget = max_transaction_gas_limit - intrinsic_execution_gas
gas_left = min(execution_gas_budget, available_gas)
state_gas_reservoir = available_gas - gas_left
```

The `state_gas_reservoir` holds gas that exceeds the per-transaction execution gas budget (`max_transaction_gas_limit`, per EIP-7825). The two counters operate as follows:

- **Execution gas** charges deduct from `gas_left` only.
- **State gas** charges deduct from `state_gas_reservoir` first; when the reservoir is exhausted, from `gas_left`.
- When an opcode requires both execution and state gas, the execution gas charge MUST be applied first. If the execution gas charge triggers an out-of-gas error, the state gas charge is not applied.
- The **`GAS` opcode** returns `gas_left` only (excluding the reservoir).
- The reservoir is passed **in full** to child frames (no 63/64 rule). On child success, the remaining `state_gas_reservoir` is returned to the parent.
- On child **revert** or **exceptional halt**, all state gas consumed by the child, both from the reservoir and any that spilled into `gas_left`, is restored to the parent's reservoir. On child **exceptional halt**, only `gas_left` is consumed (zeroed). State gas is fully preserved on failure because state changes are reverted, so no state was actually grown.
  - **Note**: State gas that originally spilled from the reservoir into `gas_left` is restored as reservoir gas, not as `gas_left`. A child frame that performs cold SSTOREs drawing from `gas_left` (because the reservoir was exhausted) and then reverts will return that gas to the parent's reservoir, where it can only be used for future state operations — not for execution gas. This is a known consequence of the EIP-8037 design that avoids tracking the original source of state gas charges per frame. The effect is bounded: it can only convert `gas_left` that was spent on state operations into reservoir gas, and only on child failure paths.
- On **exceptional halt**, remaining `gas_left` is attributed to `execution_gas_used` and set to zero (all execution gas consumed), consistent with existing EVM out-of-gas semantics. The `state_gas_reservoir` is not consumed — it is returned to the parent frame or preserved at the top level, consistent with the principle that state gas pays for long-term state growth which does not occur on failure.
- **System transactions** are not subject to the `max_transaction_gas_limit` cap; their entire `available_gas` is placed in `gas_left` with `state_gas_reservoir = 0`.

The two counters are returned by the transaction output. Besides the two counters, the EVM also keeps track of `execution_state_gas_used` and `execution_gas_used` during block execution. `state_gas` costs are added to `execution_state_gas_used` while `execution_gas` costs are added to `execution_gas_used`. These two counters are also returned by the transaction output.

## Transaction Gas Used

At the end of transaction execution, the gas used before and after refunds is defined as:

```python
tx_gas_used_before_refund = tx.gas - tx_output.gas_left - tx_output.state_gas_reservoir
tx_gas_refund = tx_output.refund_counter
tx_gas_used_after_refund = max(
    tx_gas_used_before_refund - tx_gas_refund,
    calldata_floor_gas_cost
)
```

**Divergence from EIP-8037**: EIP-8037 caps the refund at 20% of gas used (EIP-3529); Tempo applies `refund_counter` in full, as [TIP-1060](./tip-1060.md) removed the cap. The `max` with `calldata_floor_gas_cost` ([EIP-7623](https://eips.ethereum.org/EIPS/eip-7623)) ensures the user always pays at least the calldata floor, even if refunds would bring the total below it. Refunds apply only to user-paid gas; block-level accounting uses `tx_execution_gas` (execution gas only, no refund subtracted) — see [Block-Level Gas Accounting](#block-level-gas-accounting).

**Note**: EIP-8037 uses `tx_gas_used` in the refund and post-refund formulas, but that variable is not defined in the same code block. TIP-1016 uses `tx_gas_used_before_refund` consistently to avoid ambiguity.

## Block-Level Gas Accounting

At block level, only **execution gas** counts toward block gas limits. State gas is exempt — it is not tracked at the block level and does not constrain block capacity.

```python
tx_execution_gas = intrinsic_execution_gas + tx_output.execution_gas_used

block_output.block_execution_gas_used += max(tx_execution_gas, calldata_floor_gas_cost)
```

The `max` with `calldata_floor_gas_cost` ([EIP-7623](https://eips.ethereum.org/EIPS/eip-7623)) ensures calldata-heavy transactions consume at least the floor cost worth of block capacity. The floor applies to execution gas only — state gas remains fully exempt from block limits.

Per [EIP-7778](https://eips.ethereum.org/EIPS/eip-7778), `tx_execution_gas` is the pre-refund value: `tx_gas_refund` is **not** subtracted from block accounting. This prevents block gas limit circumvention via refundable operations while preserving user incentives to clean up state.

The block header `gas_used` field is set to:

```python
gas_used = block_output.block_execution_gas_used
```

The block validity condition uses this value:

```python
assert gas_used <= block.gas_limit, 'invalid block: too much gas used'
```

The base fee update rule uses this same value:

```python
gas_used_delta = parent.gas_used - parent.gas_target
```

**Note**: Tempo has two block limits — general gas limit (~25M) for contracts and payment lane limit (500M) for simple transfers. In both lanes, only execution gas counts toward the limit; state gas is exempt.

**Divergence from EIP-8037**: EIP-8037 uses a bottleneck model where `gas_used = max(block_execution_gas, block_state_gas)`, effectively capping state gas at the block gas limit. TIP-1016 instead exempts state gas entirely from block limits, relying on fixed high prices (250,000 gas per state element) as the economic deterrent for state growth.

## SSTORE Slot Restoration

Slot restoration (0→X→0 within one transaction) is settled in two dimensions:

- **Execution gas**: the write component (`SSTORE_SET_COST` = 5,000; EIP-8037 equivalent: 2,800) is refunded via `refund_counter`. The EIP-3529 clearing refund remains zero per TIP-1060. Refunds on `refund_counter` are dropped when the recording frame reverts.
- **State gas**: the 245,000 creditable portion never flows through `refund_counter` — it follows [TIP-1060](./tip-1060.md) storage credits, with TIP-1016 changing only the gas dimension: creations charge state gas, and end-of-transaction settlement returns `min(pending, balance) × 245,000` via a reservoir refill, so `state_gas_spent` reflects only state actually created. In the default `Refund` mode a 0→X→0 pattern therefore gets the 245,000 back at settlement (the x→0 clear mints the credit that settlement consumes); other modes and non-creditable slots follow TIP-1060 (credit kept in `Preserve`, spent directly in `Direct`, no mint for non-creditable slots).

**Divergence from EIP-8037**: EIP-8037 restores 0→x→0 state gas by refilling the reservoir directly at the restoring SSTORE; TIP-1016 reaches the same result for the default `Refund` mode via credit mint plus settlement, but the outcome is mode- and slot-dependent per TIP-1060.

## Revert Behavior for State Gas

State gas charged for account creation (`CREATE`, `CALL` to new account, and EOA delegation) is consumed even if the frame reverts — state changes are rolled back but gas is not refunded. This is consistent with pre-EIP-8037 behavior where `GAS_NEW_ACCOUNT` was consumed on revert.

This is achieved structurally: `GAS_NEW_ACCOUNT` state gas is charged in the **parent frame** before creating the child frame. On child revert, `handle_reservoir_remaining_gas` rolls back only the child's own state-gas charges (per Invariant 14) — the parent's prior charge is preserved. Similarly, `GAS_CREATE` state gas for contract deployment is charged in the parent before the child initcode runs.

## Receipt Semantics

Receipt `cumulative_gas_used` tracks the cumulative sum of `tx_gas_used_after_refund` (post-refund, post-floor) across transactions. This means `receipt[i].cumulative_gas_used - receipt[i-1].cumulative_gas_used` equals the gas paid by transaction `i`.

## Contract Creation Pricing

Contract code storage cost increases from 1,000 to **2,500 gas/byte** (200 execution + 2,300 state).

### Contract Deployment Cost Calculation

When a contract creation transaction or opcode (`CREATE`/`CREATE2`) is executed, gas is charged differently based on whether the deployment succeeds or fails. Given bytecode `B` (length `L`) returned by initcode and `H = keccak256(B)`:

**When opcode execution starts:** Always charge `GAS_CREATE` (Tempo: 32,000 execution + 468,000 state; EIP-8037: 9,000 execution + `112 × cpsb` state)

**During initcode execution:** Charge the actual gas consumed by the initcode execution

**Success path** (no error, not reverted, and `L ≤ MAX_CODE_SIZE`):
- Charge `GAS_CODE_DEPOSIT * L` (200 execution + 2,300 state per byte) and persist `B` under `H`, then link `codeHash` to `H`
- Charge `HASH_COST(L)` where `HASH_COST(L) = 6 × ceil(L / 32)` to compute `H`

**Failure paths** (REVERT, OOG/invalid during initcode, OOG during code deposit, or `L > MAX_CODE_SIZE`):
- Do NOT charge `GAS_CODE_DEPOSIT * L` or `HASH_COST(L)`
- No code is stored; no `codeHash` is linked to the account
- The account remains unchanged or non-existent

This is aligned with EIP-8037's deployment flow, where `GAS_CODE_DEPOSIT` is charged only on the success path.

### Example: 24KB Contract Deployment

Operation | Execution gas | State gas
----------|---------|----------
Contract code | `24,576 × 200 = 4,915,200` | `24,576 × 2,300 = 56,524,800`
Contract fixed upfront | `32,000` | `468,000`
Deployment logic | ~2M | 0
----------|---------|----------
**Totals:** | ~7M (counts toward protocol limits via `gas_left`) | ~57M (served from `state_gas_reservoir`, doesn't count toward protocol limits)

Total gas: ~64M (user must authorize with `gas_limit >= 64M`)

**Can deploy with protocol max_transaction_gas_limit = 16M** (only ~7M execution gas counts)

## Examples

### TIP-20 Transfer to New Address
- Transfer logic: ~50,000 execution gas
- New balance slot: 5,100 execution gas + 245,000 state gas
- **Total**: ~55,000 execution gas + 245,000 state gas = ~300,000 gas
- User must authorize: `gas_limit >= 300,000`
- Counts toward block limit: ~55,000 execution gas
- Reservoir initialization (assuming `max_transaction_gas_limit = 16M`):
  - `intrinsic_gas = intrinsic_execution + intrinsic_state ≈ 21,000 + 0 = 21,000`
  - `available_gas = 300,000 - 21,000 = 279,000`
  - `execution_gas_budget = 16M - 21,000 ≈ 15,979,000`
  - `gas_left = min(15,979,000, 279,000) = 279,000`
  - `state_gas_reservoir = 279,000 - 279,000 = 0`
  - Since total < `max_transaction_gas_limit`, all gas fits in `gas_left`; state gas draws from `gas_left`
- `GAS` opcode accurately reflects execution budget (~279,000 before execution)
- Block accounting: adds ~55,000 to `block_execution_gas_used` (state gas is exempt from block limits)
- Total cost: ~300,000 gas

### TIP-20 Transfer to Existing Address
- Transfer logic: ~50,000 execution gas
- Update existing slot: included in transfer logic
- **Total**: ~50,000 execution gas
- User must authorize: `gas_limit >= 50,000`
- Counts toward block limit: ~50,000 execution gas
- Total cost: ~50,000 gas

### Block Throughput
At 500M payment lane gas limit (only execution gas counts toward block limits):

- **New account transfers**: ~55k execution gas each → ~9,090 transfers/block ≈ 18,200 TPS
- **Existing account transfers**: ~50k execution gas each → ~10,000 transfers/block ≈ 20,000 TPS
- **Mixed workload**: Only execution gas constrains capacity. A block can contain any mix of new and existing transfers as long as total execution gas ≤ 500M. State gas doesn't reduce block capacity.
- **vs TIP-1000**: ~9,090 new account transfers/block vs ~1,700 without exemption (~5x improvement)

---

# Invariants

1. **User Authorization**: Total gas used (execution + state) MUST NOT exceed `transaction.gas_limit` (prevents surprise costs)
2. **Protocol Transaction Limit**: Execution gas (via `gas_left`) MUST NOT exceed `max_transaction_gas_limit` (EIP-7825 limit, e.g. 16M)
3. **Protocol Block Limits**: Block `execution_gas` MUST NOT exceed applicable limit:
   - General transactions: `general_gas_limit` (25M target, currently 30M)
   - Payment lane transactions: `payment_lane_limit` (500M)
4. **State Gas Exemption**: State gas MUST NOT count toward protocol limits (transaction or block). State gas is uncapped at the block level.
5. **Reservoir Model**: Gas accounting MUST use the reservoir model — `gas_left` and `state_gas_reservoir` initialized from `tx.gas`, with state gas drawing from reservoir first
6. **GAS Opcode**: The `GAS` opcode MUST return `gas_left` only (excluding `state_gas_reservoir`)
7. **Reservoir Passing**: The `state_gas_reservoir` MUST be passed in full to child frames (no 63/64 rule). Unused reservoir MUST be returned to parent on child completion
8. **Exceptional Halt**: On exceptional halt, `gas_left` MUST be set to zero; `state_gas_reservoir` MUST be preserved (returned to parent or kept for refund)
9. **Execution Gas Component**: Storage creation operations MUST charge execution gas for computational overhead (writing, hashing)
10. **Total Cost**: Transaction cost MUST equal `(execution_gas + state_gas) × (base_fee_per_gas + priority_fee)`
11. **Gas Split**: Storage creation operations MUST split cost into execution gas (computational) and state gas (permanent burden)
12. **Hot vs Cold**: Hot SSTORE (non-zero → non-zero) has NO state gas component; cold SSTORE (zero → non-zero) has both
13. **Refund via Counter**: The execution write component of SSTORE slot restoration (`SSTORE_SET_COST`) MUST be refunded via `refund_counter`, not direct gas decrements; the 245,000 creditable portion MUST NOT — it is settled via TIP-1060 credits and reservoir refill (see [SSTORE Slot Restoration](#sstore-slot-restoration))
14. **Revert Behavior**: On child revert or exceptional halt, the child's state-gas charges MUST be rolled back — the reservoir-drawn portion to the parent's `state_gas_reservoir`, the spilled portion to regular `remaining` (consumed on exceptional halt) — **except** state gas for account creation (`GAS_NEW_ACCOUNT`), which MUST be consumed even on revert
15. **Execution Gas Floor**: The execution gas component of each storage creation operation MUST be at least the pre-TIP-1000 (standard EVM) cost for that operation (account creation: 25,000, CREATE base: 32,000, code deposit: 200/byte), except SSTORE, whose execution component mirrors the TIP-1060 gas table (`SSTORE_SET_COST = 5,000` as the write component, on top of the standard access gas) so that clean creations are priced identically to TIP-1060
16. **EIP-7702 Delegation**: Each EIP-7702 authorization MUST charge 25,000 execution gas + 225,000 state gas (250,000 total). Authorizations with `auth.nonce == 0` MUST additionally charge the account creation cost (25,000 execution + 225,000 state)
17. **Precompile Consistency**: All precompile storage operations MUST use the same gas accounting path as standard EVM SSTORE, inheriting the execution/state gas split automatically
18. **Keychain Authorization**: Keychain `authorize_key` intrinsic gas MUST split SSTORE costs using the same execution/state ratio as standard EVM SSTOREs (5,000 execution + 245,000 state per new slot, access charges separate)
19. **Calldata Floor (EIP-7623)**: The calldata floor (`TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata + 21000`) MUST apply to execution gas only — it MUST NOT interact with `state_gas_reservoir`. Transaction validation MUST reject when `max(intrinsic_execution_gas, calldata_floor_gas_cost) > max_transaction_gas_limit`. Post-execution `tx_gas_used_after_refund` and block `block_execution_gas_used` MUST be at least `calldata_floor_gas_cost`

---

# Alignment with EIP-8037

This TIP adopts the **reservoir model** from [EIP-8037](https://eips.ethereum.org/EIPS/eip-8037) for transaction-level gas accounting, with the following Tempo-specific differences:

| Aspect | EIP-8037 | TIP-1016 |
|--------|----------|----------|
| State gas pricing | Dynamic `cost_per_state_byte` scaling with block gas limit | Fixed costs (e.g., 245,000 per slot) — Tempo uses fixed high prices for state growth protection |
| Gas cost harmonization | Harmonizes all state creation to uniform cost-per-byte | Maintains Tempo-specific pricing from TIP-1000 |
| Target state growth | 100 GiB/year dynamic target | Economic deterrence via fixed high costs |
| Block-level gas accounting | Bottleneck model: `max(block_execution_gas, block_state_gas)` | Execution gas only; state gas fully exempt from block limits |
| Block gas limit range | 60M–300M+ (Ethereum L1 scaling) | 25M general + 500M payment lane (Tempo dual-lane) |
| Quantization | Top-5 significant bits with offset for `cost_per_state_byte` | Not applicable (fixed costs) |

The core EVM mechanism — reservoir model, `GAS` opcode semantics, revert behavior, contract deployment flow, and receipt semantics — is shared with EIP-8037, minimizing implementation divergence from upstream. Two divergences remain: at the block level, TIP-1016 exempts state gas entirely from block limits rather than using EIP-8037's bottleneck model; and slot restoration flows through TIP-1060 storage credits rather than EIP-8037's direct state-gas refill (see [SSTORE Slot Restoration](#sstore-slot-restoration)).