Introduction
Ephemeral accounts are accounts that serve solely as execution containers, similar to any smart contract on Ethereum, but are deleted at the end of the transaction. They provide protocol-native, temporary execution environments without introducing persistent state.
Under the current protocol rules, such an account can already be implemented on Ethereum by creating a contract with CREATE/CREATE2, executing arbitrary EVM code, and subsequently removing the newly created account at any point within the same transaction using SELFDESTRUCT. However, this approach faces two major limitations.
-
The cost of account creation is prohibitively high. Each account creation incurs state-creation costs. Under EIP-8037, the account creation cost is
183600gas. If the account stores code during execution, the creator must additionally pay the dynamic code-deposit costL * CPSB. Under EIP-8038, the creator must also payCREATE_ACCESS = 12000and the base cost ofSELFDESTRUCTof5000gas, in addition to ancillary costs such as memory expansion and initcode hashing. These ancillary costs are comparatively small relative to the state-creation and state-access costs. As a result, a single ephemeral-account invocation currently costs at least200600gas. This is approximately equivalent to 9.5 basic ETH transfers at 21000 gas each under EIP-2780, or roughly the cost of a token swap on Uniswap. -
SELFDESTRUCTis deprecated and its semantics continue to change. Designs that depend onSELFDESTRUCTare therefore inherently unstable. Glamsterdam currently includes EIP-8246, which removes the Ether-burning behavior ofSELFDESTRUCT. Under that change, sending Ether to the self-destructing account itself will no longer remove Ether from the total supply. Hegota currently includes EIP-4758, which proposes removing the remaining functionality specified by EIP-6780. This would make the opcode effectively equivalent to thePAYopcode defined by EIP-5920 when transferring the account’s entire balance to an arbitrary address.
These constraints make ephemeral accounts both economically inefficient and difficult to rely upon as a stable protocol primitive. The author argues that this is not an intended property of the protocol, but an incidental consequence of network-protection measures and technical-debt removal that has inadvertently penalized a valid and increasingly common use case on Ethereum.
This document presents arguments for recognizing ephemeral accounts as a legitimate execution primitive and evaluates several possible implementation approaches with different complexity and efficiency trade-offs. These approaches could be considered for inclusion in a future hard fork, potentially as early as Glamsterdam through relatively small modifications to the EIP-8037 accounting rules.
Arguments in Favor
Ephemeral accounts allow arbitrary execution logic without coupling that logic to the lifetime of an account. State channels and one-time accounts are existing use cases for this design. Ephemeral accounts can also be useful for account abstraction by serving as execution hooks, for example, to validate conditions or perform transaction-specific workflow adjustments.
Ephemeral accounts do not inherently create persistent state. Although execution within an ephemeral account may create additional state through its code, such state is not part of the ephemeral account itself and is charged according to EIP-8037.
The existing construction is therefore technically feasible, but its cost is prohibitively high and its behavior is not sufficiently stable. Reducing the associated costs and defining the semantics of the underlying operations more explicitly would make this construction substantially more useful.
If EIP-8037 is deployed without additional modifications, the same cost structure is likely to be inherited by other EVM-compatible chains, potentially making this use case even less practical across the ecosystem.
Introducing a dedicated protocol primitive, such as a new TCREATE opcode, would provide a clean implementation but would also introduce additional protocol complexity. Since core developers generally prefer to avoid new execution primitives when existing mechanisms can be adapted, the existing CREATE/SELFDESTRUCT semantics should be reconsidered first.
A detailed statistic of same-transaction SELFDESTRUCT operations collected by @chfast provides a clearer picture of actual usage. The data shows meaningful and slightly increasing usage over time, with approximately 8,000 to 14,000 transactions per 100,000 blocks. If ephemeral accounts were explicitly supported by the protocol, their usage would be expected to increase further.
Potential Objections
The usage statistics above may appear insufficient to justify a protocol-level change. However, the author argues that observed usage is itself constrained by the current protocol rules.
This can be illustrated by analogy with a city that imposes strict restrictions on motorcycles. If a subsequent survey finds that only 200 motorcycles are used per day, this does not establish that residents no longer prefer motorcycles. Rather, users may have reduced their usage to avoid losing the benefits associated with their activity.
Similarly, the current cost and instability of ephemeral accounts suppress demand for the primitive. Removing these constraints is therefore expected to increase usage over time, potentially reaching a substantially higher steady-state level.
Implementation Complexity
Implementation complexity is a legitimate concern. However, the complexity can be justified by the user benefits and by the long-term scalability potential of ephemeral execution.
More importantly, the proposed implementation approaches have different complexity profiles. Simpler approaches can be prioritized for Glamsterdam, while more sophisticated accounting mechanisms can be deferred to future upgrades such as Hegota.
Arbitrary Code Execution
Executing arbitrary code introduces legitimate security considerations, but the execution context must be distinguished from code execution within the calling account.
If an account executes arbitrary code within itself, accepting untrusted input may introduce unexpected behavior, as in a hypothetical RUNCODE primitive. The ephemeral account described here instead executes code in a separate account context. Its state changes are isolated unless the caller explicitly uses DELEGATECALL into the ephemeral account. In that case, the execution falls back into the same security model as RUNCODE.
Otherwise, this construction is no different in principle from a wallet calling a router contract.
Even when the code is fixed and deployed on-chain, however, there is no guarantee that its behavior is immutable. One example is the interpreter contract developed by Analog Labs, where the caller supplies calldata containing EVM bytecode compiled from Solidity and the interpreter executes it as though the bytecode were running in the constructor of a CREATE operation.
The primary drawback of such interpreter-based approaches is their execution overhead. This is precisely the cost that native ephemeral execution aims to eliminate by allowing the code to execute directly in the EVM.
Implementation Approaches
This section evaluates several possible implementation approaches. Each approach represents a different trade-off between execution efficiency, accounting complexity, and implementation complexity.
Defer the Refund Until the End of the Transaction
This is the simplest approach and is well suited to the accelerated timeline of Glamsterdam.
The implementation would record accounts that have executed SELFDESTRUCT and have no remaining state at the end of the transaction, and then apply the corresponding refund. A similar mechanism existed in earlier pull requests but was subsequently removed.
The refund components can be considered at different levels of priority:
-
Account creation (
183600gas): This should have the highest priority because the creator cannot avoid this cost when creating the ephemeral account. Refunding this cost therefore directly addresses the primary inefficiency. -
Code deposit (
L * CPSB): The creator may temporarily deploy code to the account to enable more advanced execution patterns, such as handling callbacks or installing fixed code that can subsequently be invoked with arbitrary calldata. -
Storage (
97920gas per slot): Storage has no clear economic benefit for the ephemeral-account use case. However, supporting storage refunds would provide compatibility with contracts that use storage during temporary execution. Solidity does not support advanced data types such as mappings in transient storage, so using regular storage may require substantially more complex code. In addition, some EVM-compatible networks do not support EIP-1153.
The main drawback of this approach is that the transaction sender must specify a sufficiently large gas limit at transaction start to ensure that enough gas remains available throughout execution. This makes such transactions more difficult to include in blocks.
Furthermore, on some blockchains such as Monad, where transactions always consume their entire gas limit, the refund would not provide any effective benefit.
Charge Only at the End of the Creation Frame
Instead of charging the account-creation cost when entering the creation frame, the cost could be deferred until the frame exits.
If the account remains empty and the frame terminates with STOP or RETURN, the account-creation cost is charged.
If the frame terminates with REVERT, SELFDESTRUCT, or another exceptional condition, no account-creation charge is applied.
This approach requires modifying the point at which frame-level state-creation costs are accounted for. It also does not support the more advanced use cases described above, but it avoids requiring an excessively large transaction gas limit.
Refund on Same-Transaction SELFDESTRUCT
Any account that is created and subsequently destroyed within the same transaction would receive a refund, expected to cover the account-creation cost and code-deposit cost.
If the network adopts EIP-8246 and an account that has been marked for deletion subsequently receives Ether, the previously issued account-creation refund would need to be reversed.
This approach requires more complex internal accounting to track the relevant state transitions, but it follows the state-diff principle more closely.
Native Ephemeral Accounts
The cleanest way to provide low-cost ephemeral accounts is to introduce a dedicated protocol primitive, such as a TCREATE opcode.
This would allow the protocol to define ephemeral-account accounting directly and avoid repurposing the semantics of existing account-creation and account-deletion operations.
However, such a change requires a hard fork and introduces a new execution primitive into the protocol.
Further Optimizations
Even after optimizing state-creation costs, state-access costs remain significant. Creating and destroying an account requires at least CREATE_ACCESS and the base cost of SELFDESTRUCT, for a minimum total of 17000 gas.
The author proposes considering a reduction of CREATE_ACCESS by allowing ACCOUNT_WRITE = 9000 to be refunded immediately when the account is deleted.
In addition, the original motivation for the high SELFDESTRUCT cost—to mitigate denial-of-service attacks since EIP-150—is no longer applicable. Since EIP-6780, SELFDESTRUCT no longer performs the same I/O-intensive state operations. It is therefore reasonable to consider reducing its cost to the base cost of CALL.
More broadly, SELFDESTRUCT has undergone several semantic restrictions intended to make the opcode safer. From the author’s perspective, these changes have progressively reduced the opcode to a much narrower operation and can be viewed as bringing it closer to the principle that each opcode should provide a single, well-defined function.
Historically, SELFDESTRUCT combined several responsibilities, including account deletion, state cleanup, refunds, and Ether burning. Most of these behaviors have now been removed. Its remaining useful behavior is primarily the cleanup of state created during short-lived execution.
Rather than continuing to treat SELFDESTRUCT as a deprecated opcode, the author proposes assigning it a new, more descriptive name, such as CLEAR, and presenting it as a stable protocol primitive to developers without introducing additional functionality.