---
eip: 8360
title: TCREATE Opcode
description: Introduce a new opcode for creating contracts that exist only for the duration of a single transaction
author: Helkomine (@Helkomine), abc-123-c (@abc-123-c)
discussions-to: https://ethereum-magicians.org/t/eip-8360-tcreate-opcode/29258
status: Draft
type: Standards Track
category: Core
created: 2026-08-03
requires: 161, 1014, 1153, 3529, 7610, 8037, 8038
---

## Abstract

This EIP introduces a new EVM opcode, `TCREATE`, where `T` stands for transient, providing an official, gas-efficient, and state-aware mechanism for deploying temporary contracts.

## Motivation

Many Ethereum applications do not require deployed code to persist beyond a single transaction. Examples include state-channel contracts, single-use accounts, and other ephemeral execution environments.

Today, such patterns rely on a combination of `CREATE`/`CREATE2` and `SELFDESTRUCT`. However, `SELFDESTRUCT` has no longer provided gas refunds since [EIP-3529](./eip-3529.md), can only delete contracts created within the same transaction since the Cancun upgrade, and is expected to undergo further semantic restrictions in future protocol upgrades. As a result, the deploy-and-self-destruct pattern is no longer economically attractive, nor can its long-term behavior be relied upon.

Providing a dedicated EVM opcode for temporary contract deployment offers a lower-cost alternative while improving state management by preventing unnecessary long-term code accumulation. This proposal also provides a gradual migration path away from `SELFDESTRUCT`.

The proposal is fully compatible with account abstraction. Existing account semantics remain unchanged, while accounts may deploy transient contracts to implement extended execution logic entirely through calldata, for example, hook-based execution. Such hooks may execute dedicated logic or serve as reusable code templates that are invoked through `DELEGATECALL`.

## Specification

### Parameters

| Parameter| Description| Value | Source |
| --- | --- | --- | --- |
| `TCREATE` | New opcode | TBD | This EIP |
| `BASE_OPCODE_COST` | Base opcode cost | 100 | This EIP |
| `CPSB` | State gas price per byte | 1530 | [EIP-8037](./eip-8037.md) |
| `STATE_BYTES_PER_NEW_ACCOUNT`| State bytes created per account| 120 | [EIP-8037](./eip-8037.md) |
| `WARM_ACCESS` | Touch of an already warm account or storage slot| 100 | [EIP-8038](./eip-8038.md) |
| `COLD_ACCOUNT_ACCESS` | Cold touch of an account | 3000 | [EIP-8038](./eip-8038.md) |
| `ACCOUNT_WRITE` | Surcharge applied when an account leaf is modified for the first time | 9000 | [EIP-8038](./eip-8038.md) |

### Semantics

The behavior of `CREATE2` is defined in [EIP-1014](./eip-1014.md).

`TCREATE` behaves identically to `CREATE2` except for the following changes:

- The address is computed as `keccak256(0xfe || deployer_address || salt || keccak256(init_code))[12:]` where `||` denotes byte concatenation.
- At the end of the transaction, all code, nonce, and storage created during transaction execution are removed from the target account. The account balance is preserved. An account that becomes empty is removed from the state trie at the end of the transaction in accordance with [EIP-161](./eip-161.md). The semantics are clarified further [here](#state-transition-handling).
- Code deployment rules and collision semantics are identical to `CREATE2`. A target account is considered non-empty during the transaction, and address collisions therefore revert execution in accordance with [EIP-7610](./eip-7610.md). The semantics are clarified further [here](#state-transition-handling).

### State transition handling

At the end of the transaction, the account state of every contract created by `TCREATE` is finalized as follows:

- The account nonce is reset to 0.
- The account code is removed.
- All storage associated with the account is removed.
- The account balance is preserved.

For the deploying account, an implementation must maintain a temporary record of the account's original nonce together with all permanent nonce increments that occur during the transaction (for example, those resulting from `CREATE` or `CREATE2`).

When transaction execution completes, the deployer's nonce is restored to `original_nonce + permanent_nonce_increments`, where `permanent_nonce_increments` excludes nonce increments introduced solely by `TCREATE`.

### Opcode Behavior Changes

#### `SSTORE` and `SLOAD`

Within the execution context of a contract deployed via `TCREATE`, `SLOAD` and `SSTORE` operate on an ephemeral storage space rather than the persistent storage trie.

This ephemeral storage is local to the `TCREATE` account and is discarded when the transaction completes together with the account's transient state. Consequently, writes performed through `SSTORE` are never committed to the global state, and subsequent transactions observe the storage as empty.

The separation between this ephemeral storage and the transient storage defined by [EIP-1153](./eip-1153.md) is an implementation detail. Clients must ensure that writes performed through `SSTORE` are isolated from persistent storage while preserving the observable semantics of the `SLOAD` and `SSTORE` opcodes.

### Gas Accounting

Each execution of `TCREATE` is charged `BASE_OPCODE_COST` together with the execution-gas costs that normally apply to `CREATE2`, including initcode execution, jumpdest analysis, memory expansion, copying costs, and other execution-related charges.

`TCREATE` does not incur the account-creation charges associated with `CREATE2`, such as `GAS_NEW_ACCOUNT` or code-deposit costs.

Account access costs continue to follow [EIP-8038](./eip-8038.md). In particular, accesses to cold accounts are charged `COLD_ACCOUNT_ACCESS` as appropriate.

State-gas accounting is defined separately by this EIP. Rather than charging for account creation itself, state-gas is charged only for state changes that cannot be reasonably reclaimed by the end of the transaction, and refilled when those state changes are reverted within the same transaction.

Any operation that modifies the balance of the target account of a `TCREATE` operation, including during contract initialization, performs state-gas accounting according to the following table.

| Original balance | Current balance | New balance | Description | State-gas charges/refills |
| --- | --- | ---- | --- | --- |
| 0 | x | 0 | Balance restored to zero when the initial transaction balance was zero | `STATE_BYTES_PER_NEW_ACCOUNT × CPSB` refilled |
| 0 | 0 | x | First balance written to the account | `STATE_BYTES_PER_NEW_ACCOUNT × CPSB` charged |
| 0 or x | y | z | Existing account balance updated | No state-gas adjustment |

Execution-gas accounting for account updates (following the principles introduced in [EIP-8038](./eip-8038.md)) is defined as follows.

| Original balance | Current balance | New balance | Description | Regular-gas charges/refills |
| --- | --- | --- | --- | --- |
| x | y | x | Balance restored to its value at the beginning of the transaction | `ACCOUNT_WRITE` refunded |
| x | x | y | First balance modification | `ACCOUNT_WRITE` charged |
| 0 or x | y | z | Subsequent balance modification | No regular-gas adjustment |

Additionally, the gas costs of `SSTORE` and `SLOAD` are reduced to match those of `TSTORE` and `TLOAD`, respectively, since they operate exclusively on transient storage within `TCREATE` execution.

## Rationale

### Lower Deployment and Execution Costs

Today, combining `CREATE` with `SELFDESTRUCT` is the only mechanism for implementing temporary contracts. This approach is relatively expensive and no longer benefits from gas refunds, reducing incentives for efficient state management.

By making the cost of temporary contracts comparable to that of a regular `CALL`, this proposal encourages experimentation with transient execution models while avoiding unnecessary long-term state growth.

### Address Prefix Selection

The `0xfe` prefix is chosen to ensure that the address derivation scheme used by `TCREATE` cannot collide with that of `CREATE2`, which uses the `0xff` prefix as specified in [EIP-1014](./eip-1014.md).

Selecting the adjacent value `0xfe` preserves the existing address derivation structure while providing a distinct domain separator. This choice also remains outside the range of prefixes that can be generated by RLP encoding, whose maximum representable payload size is many orders of magnitude larger (up to petabyte-scale objects). Consequently, no ambiguity is introduced with existing contract address derivation mechanisms.

### Temporary Nonce Semantics

Although `TCREATE` creates only transient account state, its execution temporarily follows the existing nonce semantics of `CREATE2`.

This avoids introducing additional exceptional rules for address collision handling during contract creation. In particular, the target account becomes non-empty during execution by virtue of its temporary nonce, preventing multiple initialization frames from executing simultaneously at the same address before code deposition.

Resetting the nonce of transient accounts at the end of the transaction preserves the stateless nature of `TCREATE` while allowing implementations to reuse existing contract creation logic with minimal modifications.

Similarly, restoring the deployer's nonce to its original value plus only permanent nonce increments ensures that transient deployments do not affect the persistent account state.

For EOAs delegated through [EIP-7702](./eip-7702.md), this property also improves transaction simulation and mempool analysis, since the sender's post-transaction nonce depends only on permanent account-creation operations and remains independent of transient deployments.

### `SSTORE` and `SLOAD` handling

Mapping `SLOAD` and `SSTORE` to ephemeral storage preserves compatibility with existing contract code that assumes the availability of state storage while preventing persistent state growth. Prohibiting these opcodes entirely would introduce unnecessary incompatibilities, whereas allowing writes to persistent storage would conflict with the ephemeral nature of `TCREATE` accounts and the requirement that no storage root remains after transaction completion.

The distinction between ephemeral storage used by `SLOAD` and `SSTORE` and the transient storage defined by [EIP-1153](./eip-1153.md) is intentionally invisible to contracts. It exists solely to simplify client implementations while preserving the expected semantics of both storage models.

### State-Gas Accounting for Balance Transfers

Removing balance accounting entirely would simplify gas accounting but would reintroduce a special case that [EIP-8246](./eip-8246.md) sought to eliminate.

Preserving balance semantics while accounting only for temporary state changes provides a more consistent design. This decision may be revisited if native balance-burning mechanisms are introduced in the future.

### Extended state accounting method

Unlike `CREATE2`, whose state-gas accounting is tied to permanent account creation, `TCREATE` accounts are ephemeral. Therefore, charging for account creation itself would overestimate the persistent state introduced by the opcode. Instead, this EIP generalizes the state-accounting model of [EIP-8037](./eip-8037.md) by charging only for state that remains after transaction execution and refilling charges when transient state is completely eliminated.

## Backwards Compatibility

### Contract Execution Flow

Deployment workflows for temporary-use contracts remain unchanged except that no deployed bytecode is retained after the transaction completes.

Applications requiring persistent code or storage should continue to use `CREATE` or `CREATE2`.

## Security Considerations

### Repeated Contract Deployment

Because target addresses are derived using the same rules as `CREATE2`, while all account state except balance is removed after transaction completion, such accounts become valid deployment targets again under [EIP-7610](./eip-7610.md).

Contracts whose runtime code depends on execution context (for example, using `NUMBER`, `ORIGIN`, or similar opcodes) may exhibit different behavior across deployments if appropriate safeguards are not implemented.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).