---
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 balance throughput penalty**: A TIP-20 transfer to an address without an existing balance slot uses ~47,000 execution gas + 245,000 state gas = ~292,000 gas total, versus ~43,000 execution gas when the balance slot already exists. At a 500M payment lane gas limit:
   - Without exemption (single dimension): only ~1,712 new-balance transfers/block = ~3,424 TPS
   - With reservoir model (block limits apply to execution gas only): ~10,638 new-balance transfers/block = ~21,276 TPS
   - Existing-balance transfers: ~11,627 transfers/block = ~23,254 TPS
   - ~6.2x throughput improvement for new balances 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)) maintains four internal accounting counters:

* `remaining` holds regular execution gas. Execution charges always draw from it, state-gas charges draw from it only after the reservoir is exhausted, and the `GAS` opcode returns it.
* `reservoir` holds gas above the regular execution budget and can only pay state-gas charges.
* `state_gas_spent` is the signed net state gas charged by the frame. It can become negative when a child restores state created by its parent.
* `state_gas_spilled` is local to each frame and tracks the portion of that frame's state gas drawn from `remaining` after the reservoir was exhausted. This lets frame rollback return gas to the pool from which it was charged; on successful frame completion, the counter is propagated to the parent so a later parent rollback can restore it correctly.

---

# 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 split 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 preserves these values and moves the creditable portion from execution gas into state gas.

| Operation | Execution Gas | Storage Gas | Total |
|-----------|---------------|-------------|-------|
| Cold SSTORE creation (zero → non-zero, no credit applied) | 7,200 | 245,000 | 252,200 |
| Warm SSTORE update (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 transaction (intrinsic surcharge) | 32,000 | 468,000 | 500,000 |
| `CREATE`/`CREATE2` (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 TIP-1060's decomposed Berlin accounting:
`GAS_WARM_ACCESS` (100) plus `SSTORE_SET_COST` (5,000), for a 5,100 execution-gas warm write
path. A cold slot adds `GAS_COLD_SLOAD` (2,100), for 7,200 execution gas before state gas.
TIP-1060 keeps the storage-clearing refund at zero because storage-credit minting replaces it.
The SSTORE creation row shows the upfront cost without a storage credit applied; its 245,000
state-gas component is governed by TIP-1060's credit mode and settlement rules.

### 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 remains **25,000 execution gas + 225,000 state gas = 250,000 total**. 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 every child outcome, the parent adopts the child's resulting `state_gas_reservoir`.
- On child **success**, unused `gas_left` is returned to the parent. The child's net `state_gas_spent`, frame-local `state_gas_spilled`, and execution refund counter are added to the parent's counters.
- On child **revert** or **exceptional halt**, the child first rolls back its own state-gas charges in last-in, first-out order: `gas_left += state_gas_spilled` and `state_gas_reservoir += state_gas_spent - state_gas_spilled`. Both state-gas counters are then reset to zero, and the child's execution refund counter is dropped.
  - On **revert**, the child's resulting `gas_left`, including the returned spill, is returned to the parent. The restored reservoir is adopted by the parent, but no child state-gas or refund counters are propagated.
  - On **exceptional halt**, the same state-gas rollback occurs first, then the child's `gas_left` is set to zero and is not returned to the parent. The restored reservoir is still adopted by the parent, but no child state-gas or refund counters are propagated.
- **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 transaction output returns the remaining gas counters and `execution_gas_used`. Tempo does not track an `execution_state_gas_used` counter: state gas is accounted within the gas tracker through `state_gas_spent` for charging, refill, and transaction settlement, but it is not accumulated into a block state-gas counter. `execution_gas_used` records execution-only gas consumption before refunds and is used with intrinsic execution gas, the execution-gas refund, and the calldata floor to calculate the transaction's contribution to `block_execution_gas_used`.

## 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. The same execution-gas refund also reduces block-level execution gas — 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_before_refund = intrinsic_execution_gas + tx_output.execution_gas_used
tx_execution_gas_after_refund = tx_execution_gas_before_refund - tx_gas_refund

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

Tempo intentionally does not adopt [EIP-7778](https://eips.ethereum.org/EIPS/eip-7778). [TIP-1060](./tip-1060.md) removes the storage-clearing refund and replaces it with storage credits, so the refund counter cannot reduce block gas for a committed storage deletion. The remaining execution refunds reverse restore-to-original write charges and therefore reduce the transaction's execution gas before its block contribution is calculated. State gas cannot absorb these refunds and remains fully exempt from block limits.

`tx_gas_refund` cannot exceed `tx_execution_gas_before_refund`, so the subtraction does not require saturation or a zero floor.

The `max` with `calldata_floor_gas_cost` ([EIP-7623](https://eips.ethereum.org/EIPS/eip-7623)) is applied after the refund, ensuring calldata-heavy transactions still consume at least the floor cost worth of block capacity.

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 — a general gas limit of 30M gas for contracts and a payment lane limit of 500M gas 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 (for example, 245,000 state gas per storage slot) as the economic deterrent for state growth.

## Interaction with TIP-1060

[TIP-1060](./tip-1060.md) remains authoritative for storage-credit minting, consumption, modes, and settlement. TIP-1016 does not introduce a separate SSTORE slot-restoration mechanism or change which storage transitions mint or consume credits.

TIP-1060 accounts the 245,000 gas-backed value represented by a storage credit as execution gas. Under TIP-1016, the same amount is charged as state gas instead. The 5,000 `SSTORE_SET_COST` component and warm or cold access charge remain execution gas.

The TIP-1060 behavior is otherwise unchanged:

- A committed nonzero-to-zero storage transition mints one account-local storage credit instead of receiving a storage-clearing refund.
- A zero-to-nonzero storage transition either charges 245,000 state gas or consumes one storage credit, depending on the account's `Refund`, `Preserve`, or `Direct` mode.
- In `Refund` mode, the creation charges 245,000 state gas upfront. End-of-transaction settlement consumes available credits and returns the corresponding state gas through reservoir refill, not through the execution-gas `refund_counter`.
- In `Preserve` mode, the creation charges 245,000 state gas and leaves the credit balance unchanged.
- In `Direct` mode, an available credit covers the 245,000 state-gas charge synchronously; otherwise the creation charges state gas normally.
- Credit minting, consumption, pending settlement, account locality, journaling, and exclusions for protocol bookkeeping slots continue to follow TIP-1060.

## Revert Behavior for State Gas

State gas for conditional account creation by `CALL`, `CREATE`, or `CREATE2` is charged in the creating frame before entering the child. If the child reverts or halts exceptionally, or creation otherwise completes without creating the account leaf, the upfront state-gas charge is refilled in LIFO order because no durable state was created. A successful creation keeps the charge.

EIP-7702 authorization changes are applied during pre-execution and persist even if subsequent EVM execution reverts, so their state-gas charges are not refilled for an execution-frame failure.

## 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 creation starts:** Charge the 32,000 execution-gas portion of `GAS_CREATE`. If the destination account does not exist and the creation will add a new account leaf, charge the 468,000 state-gas portion in the creating frame before entering the initcode frame. If the destination already has an account leaf, the account-creation state portion is not charged.

**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** (address collision, 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
- If the 468,000 account-creation state-gas portion of `GAS_CREATE` was charged, refill it in LIFO order: first to `gas_left` up to the creating frame's `state_gas_spilled`, then to `state_gas_reservoir`. Decrement `state_gas_spent` by the same amount. The 32,000 execution-gas portion and execution gas consumed by the failed creation are not refilled.
- Apply the same state-gas refill rule to a failed top-level contract-creation transaction.

This is aligned with EIP-8037's deployment flow: the account-creation state charge is conditional and refilled when no account is created, while `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 (new account) | `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

The TIP-20 figures below are rounded up from the T12 transfer test fixture. Exact execution gas can vary slightly with calldata and the policy or reward path.

### TIP-20 Transfer to Address Without an Existing Balance Slot
- Execution, including the new balance-slot path: ~47,000 gas
- New balance slot: 245,000 state gas
- **Total**: ~47,000 execution gas + 245,000 state gas = ~292,000 gas
- User must authorize: `gas_limit >= 292,000`
- Counts toward block limit: ~47,000 execution gas
- Reservoir initialization (assuming `max_transaction_gas_limit = 16M`):
  - `intrinsic_gas = intrinsic_execution + intrinsic_state ≈ 21,000 + 0 = 21,000`
  - `available_gas ≈ 292,000 - 21,000 = 271,000`
  - `execution_gas_budget = 16M - 21,000 ≈ 15,979,000`
  - `gas_left = min(15,979,000, 271,000) = 271,000`
  - `state_gas_reservoir = 271,000 - 271,000 = 0`
  - Since total < `max_transaction_gas_limit`, all gas fits in `gas_left`; state gas draws from `gas_left`
- `GAS` opcode accurately reflects the available gas (~271,000 before execution, using the approximate intrinsic gas above)
- Block accounting: adds ~47,000 to `block_execution_gas_used` (state gas is exempt from block limits)
- Total cost: ~292,000 gas

### TIP-20 Transfer to Address With an Existing Balance Slot
- Execution, including the existing balance-slot update: ~43,000 gas
- State gas: 0
- **Total**: ~43,000 execution gas
- User must authorize: `gas_limit >= 43,000`
- Counts toward block limit: ~43,000 execution gas
- Total cost: ~43,000 gas

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

- **New-balance transfers**: ~47,000 execution gas each → ~10,638 transfers/block ≈ 21,276 TPS
- **Existing-balance transfers**: ~43,000 execution gas each → ~11,627 transfers/block ≈ 23,254 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**: ~10,638 new-balance transfers/block vs ~1,712 without exemption (~6.2x 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` (30M gas)
   - 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. **SSTORE State Gas**: Warm or cold access affects only the execution-gas access charge. A zero-to-nonzero storage transition follows TIP-1060: its 245,000 state-gas component is charged, covered by a credit, or returned at settlement according to the account's mode and available credits. A nonzero-to-nonzero transition has no state-creation gas
13. **TIP-1060 Storage Credits**: TIP-1016 MUST NOT introduce a separate SSTORE restoration mechanism. TIP-1060 remains authoritative for credit minting, consumption, modes, and settlement. Its credit-backed creation amount MUST be accounted as 245,000 state gas rather than execution gas, and settlement MUST return that amount through reservoir refill rather than `refund_counter` (see [Interaction with TIP-1060](#interaction-with-tip-1060))
14. **Revert Behavior**: On child revert or exceptional halt, the child's state-gas charges MUST be refilled in LIFO order — first to the child's regular `remaining` up to its frame-local `state_gas_spilled`, then to `state_gas_reservoir`. On revert, the resulting `remaining` returns to the parent; on exceptional halt, it is consumed. Upfront state gas for a conditional `CALL`/`CREATE` account creation MUST also be refilled when no account leaf is created
15. **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)
16. **Precompile Consistency**: All precompile storage operations MUST use the same gas accounting path as standard EVM SSTORE, inheriting the execution/state gas split automatically
17. **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)
18. **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`
19. **Block Refunds**: Tempo MUST intentionally omit EIP-7778 because TIP-1060 removes the storage-clearing refund and replaces it with storage credits. The full remaining execution-gas refund MUST be subtracted from execution gas before calculating the transaction's contribution to `block_execution_gas_used`; the calldata floor MUST be applied after this subtraction

---

# 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 |
|--------|----------|----------|
| Gas cost harmonization | Harmonizes all state creation to uniform cost-per-byte | Maintains Tempo-specific pricing from TIP-1000 |
| Target state growth | 120 GiB/year at a 150M reference block gas limit | 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) | 30M general + 500M payment lane (Tempo dual-lane) |

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 storage creation and deletion continue to use TIP-1060 storage credits, with the credit-backed amount moved to state gas (see [Interaction with TIP-1060](#interaction-with-tip-1060)).