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.
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, 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.
| 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 |
STATE_BYTES_PER_NEW_ACCOUNT | State bytes created per account | 120 | EIP-8037 |
WARM_ACCESS | Touch of an already warm account or storage slot | 100 | EIP-8038 |
COLD_ACCOUNT_ACCESS | Cold touch of an account | 3000 | EIP-8038 |
ACCOUNT_WRITE | Surcharge applied when an account leaf is modified for the first time | 9000 | EIP-8038 |
The behavior of CREATE2 is defined in EIP-1014.
TCREATE behaves identically to CREATE2 except for the following changes:
keccak256(0xfe || deployer_address || salt || keccak256(init_code))[12:] where || denotes byte concatenation.CREATE2. A target account is considered non-empty during the transaction, and address collisions therefore revert execution in accordance with EIP-7610. The semantics are clarified further here.At the end of the transaction, the account state of every contract created by TCREATE is finalized as follows:
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.
SSTORE and SLOADWithin 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 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.
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. 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) 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.
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.
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.
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.
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, 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 handlingMapping 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 is intentionally invisible to contracts. It exists solely to simplify client implementations while preserving the expected semantics of both storage models.
Removing balance accounting entirely would simplify gas accounting but would reintroduce a special case that EIP-8246 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.
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 by charging only for state that remains after transaction execution and refilling charges when transient state is completely eliminated.
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.
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.
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 and related rights waived via CC0.