EIP-8387: Stateless Accounts

Abstract

This proposal extends EIP-8130 with a new account_changes entry, stateless (0x03). An ephemeral account is a stateless account: unique user_salt, empty config-change chain, the same initial_actors tuples as EIP-8130 create, an EIP-7702 delegation that exists only for this transaction, and no Keystore write. That is the privacy / one-shot path.

The same entry also enables long-lived stateless accounts: reuse (user_salt, initial_actors) across transactions, resubmit following 0x01 entries as a calldata witness (applied only to a transaction-scoped image, never the Keystore), and retarget wallet code per transaction. The transaction MUST be nonce-free. Leftover ETH or tokens are recovered by submitting another stateless entry with the same initial_actors birth parameters. No opcodes, statuses, or revert semantics are added.

Motivation

EIP-8130 create deploys runtime bytecode, writes initial_actors into Keystore storage, and leaves a permanent account. Privacy and one-shot flows need the opposite: an address that can originate calls without Keystore state, persistent code, or a nonce slot.

That is the primary use. An ephemeral (stateless) account is create's initial_actors with those writes removed: fresh user_salt, no following config-changes, sender_auth one of initial_actors. During execution the account is delegated so wallet code can run; at settlement the indicator is cleared. Replay protection is EIP-8130's existing nonce-free ring buffer. Application-level nullifiers (privacy pools) live in calls, not in this entry. Session keys, ERC-1271, and Keystore reads work because the overlay is EVM-visible.

The same entry also enables long-lived stateless accounts. Reuse (user_salt, initial_actors). Following config-changes are later mutations of the account: a rotation, an expiry, a POLICY manager. A following delegation entry, or a different delegation on the next 0x03, retargets wallet code at the same address. sender_auth is checked against the post-chain image. There is no on-chain actor map to update.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

This EIP applies only on chains that implement EIP-8130. An EIP-8130 chain that has not adopted this EIP MUST reject stateless entries as an unknown account_changes type.

Constants

Stateless Entry

EIP-8130 account_changes gains type 0x03:

rlp([
  0x03,               // type: stateless
  user_salt,          // bytes32: User-chosen uniqueness factor (in the address)
  delegation,         // address: EIP-7702 target for this transaction only (not in the address)
  initial_actors,     // Array of [actorId, authenticator, scope, policyData] tuples
  uniqueness          // bytes32: per-tx discriminator; in replay_id, not in the address
])

initial_actors uses the same tuple, sorting, policyData, and authorizeActor rules as EIP-8130 create: non-empty, strictly ascending actorId, authenticator >= K1_AUTHENTICATOR. expiry is not expressible. Every scope grant is allowed except NONCE (0x04): reject the entry if any initial actor has scope & NONCE != 0. Admin (scope == 0x00) and SENDER / POLICY / SELF_PAYER / SPONSOR_PAYER remain expressible. The transaction itself MUST use nonce_key == NONCE_KEY_MAX and nonce_sequence == 0; a stateless entry on a sequenced nonce_key is invalid.

The stateless entry MUST be first. Combining it with create (0x00) is invalid: create persists code and Keystore state. Config-change entries (0x01) MAY follow; they are calldata only: the protocol applies them to the account image and MUST NOT write Keystore storage, call applySignedAccountChanges, or emit actor logs. The number of following 0x01 entries MUST NOT exceed MAX_STATELESS_CHAIN_ENTRIES. The next transaction that needs the same mutations resubmits the same 0x01 entries. uniqueness is not part of the address; it is part of account_changes and therefore of EIP-8130 replay_id. Recurring payments at the same address MUST vary uniqueness. A repeated uniqueness with the same calls and window is the same logical transaction and is rejected until the ring entry elapses.

A single EIP-8130 delegation entry (0x02) MAY follow (after any 0x01 entries). That is the same create-then-delegate pattern as a Keystore-backed account, and it is how wallet code is retargeted: the implementation is not frozen in the address. After a stateless entry the 0x02 is transaction-scoped — it overrides 0x03's delegation for this transaction and is cleared at settlement; it MUST NOT persist the indicator the way a standalone 0x02 does. It is authorized by the transaction's sender_auth against the post-chain image (admin), not by EIP-8130's EOA-only delegation rule. target == address(0) clears the indicator for this transaction. At most one 0x02. See Execution.

An ephemeral transaction is a stateless entry with no following 0x01 entries. A long-lived stateless transaction reuses the same (user_salt, initial_actors) plus a config-change chain. The protocol does not distinguish them except by whether 0x01 entries are present.

Stateless is authorized by the transaction's sender_auth; there is no separate authorization field on the 0x03 entry. There is no createStateless Keystore function and no portable EVM equivalent of transaction-scoped delegation.

Address Derivation

Addresses are the trailing 20 bytes of a domain-separated hash over user_salt and initial_actors. Chained config-changes, delegation, and uniqueness do not participate. initial_actors uses the same hash-the-leaves-then-hash-the-list commitment as EIP-8130 create:

// initial_actors MUST already be sorted by actorId (strictly ascending); reject otherwise

leaf_i            = keccak256(actorId_i || authenticator_i || scope_i || policyData_i)
actors_commitment = keccak256(leaf_0 || leaf_1 || ... || leaf_n)

address = keccak256(STATELESS_PREFIX || user_salt || actors_commitment)[12:]

user_salt and actors_commitment are 32 bytes each. The prefix domain-separates this space from EIP-8130 CREATE2 create addresses. Off-chain address prediction MUST apply the same initial-actor validation as the stateless entry, including the NONCE-bit ban, so a predicted address always corresponds to an entry the protocol will accept.

The same (user_salt, initial_actors) therefore always produces the same address, independent of which implementation this transaction delegates to. That is the recovery path: leftover ETH or tokens are swept by a later stateless transaction with the same birth parameters (any delegation). The protocol does not increment the account's EVM nonce and does not require CREATE2 freshness (code_size == 0 && nonce == 0); uniqueness comes from the hash, and reuse is intentional (ephemeral use picks a fresh user_salt instead).

Account Image

When a stateless entry is present, the protocol materializes a transaction-scoped account image in EIP-1153 transient storage of KEYSTORE_ADDRESS instead of SSTOREing Keystore slots. TLOAD / TSTORE are per-contract: the overlay MUST live on the Keystore, so getActorConfig, validateSignature, and account ERC-1271 (which call into the Keystore) see the same actor map a persistent create would have written. Transient storage is discarded at the end of the transaction; nothing is deserialized to disk.

The protocol writes the overlay as if KEYSTORE_ADDRESS had executed TSTORE (the same client journal as protocol-set EIP-7702 code). It MUST NOT SSTORE. Following 0x01 entries are decoded from account_changes calldata, applied to the overlay, and TSTOREd; they are never an on-chain Keystore update.

Layout. A per-account flag TLOAD(IMAGE_ACTIVE(account)) == 1 means the overlay is live, where the flag slot is defined as:

IMAGE_ACTIVE(account) = keccak256("EIP-8387" || account)

Actor, policy, and packed account-state words for account use the same slot derivation as persistent Keystore storage, stored under those slot numbers in the Keystore's transient storage. While the flag is set, Keystore reads (getActor, getActorConfig, validateSignature) MUST TLOAD those slots and MUST NOT SLOAD them. Keystore initialized-ness checks that reject a second importAccount (local_sequence / multichain counter non-zero) MUST keep using persistent SLOAD: the overlay must not look like a prior import, or graduation is bricked. The Keystore MUST NOT expose a user-facing TSTORE API that can write overlay slots; only the protocol writes the overlay.

1. Initialize from initial_actors as EIP-8130 create initializes from that set: those actors are live, local_sequence = 1, lock state is the create default, DEFAULT_EOA_REVOKED is set unless a self-actor is among initial_actors. TSTORE the flag, packed state, and each actor_config (and policy words if POLICY is set). No SLOADs, no SSTOREs, no persistent CONTRACT_ESTABLISHED, no AccountCreated.
2. Apply each following config-change entry (0x01) to the overlay in order, using EIP-8130's applySignedAccountChanges rules (batch auth MUST be admin against the overlay after previous entries, channel/sequence MUST match the overlay counters, AuthorizeActor / RevokeActor / IncrementLocalEpoch mutate the overlay via TSTORE). Lock and Unlock MUST be rejected: there is no durable lock state. Already-applied skipping does not apply; every tx rehydrates from initial_actors and MUST replay the chain from the post-create counters. Reject the transaction if the number of 0x01 entries exceeds MAX_STATELESS_CHAIN_ENTRIES. Each batch's authentication is charged as intrinsic gas before execution (see Gas). Batch auth and sender_auth MAY be aggregated per Aggregation.
3. Authenticate sender_auth against the overlay after all config-change entries. Resolved actorId and authenticator MUST match a live actor. Scope and policyData for the rest of the transaction (including the POLICY gate's manager) are taken from that actor in the overlay.
4. Discard is EIP-1153: transient storage is cleared at transaction end, together with the EIP-7702 indicator. No explicit TSTORE of zeros is required.

A transaction with only the 0x03 entry is the empty chain (ephemeral): sender_auth is one of initial_actors. A transaction with 0x03 then one or more 0x01 entries is a witnessed account: the birth set is in the address, and later mutations — a rotation, an expiry, a policy manager — are the signed chain, visible to ERC-1271 for this transaction only.

The next long-lived transaction that wants the same live actor set MUST resubmit the same prefix chain. Nothing about the overlay survives in Keystore storage.

Aggregation

Each 0x01 batch auth and the transaction's sender_auth use EIP-8130's authenticator || data shape. data is authenticator-defined. An authenticator that supports aggregation MAY encode in data a share, a proof, or a handle into an aggregate covering this digest (the config-change batch digest, or the AA signing hash). authenticate(H, data) MUST still return the actorId that authorized this hash. How shares are combined at block level (a sidecar, an aggregate blob, a precompile) is defined by that authenticator; this EIP does not add a chain-specific aggregation envelope. An authenticator that does not support aggregation is verified standalone, as on the EIP-8130 AA path.

Post-quantum (PQ) signatures make a long witness large; aggregation is how that stays on the EIP-8130 authenticator interface instead of a new envelope. A compact proof of chain — one proof that the overlay is a valid descendant of initial_actors, replacing replay of every batch — is not specified. A later EIP MAY add it if MAX_STATELESS_CHAIN_ENTRIES becomes the bottleneck. Until then the witness is the explicit 0x01 list, aggregatable per-auth.

Graduation (importAccount)

To leave the stateless path at the same address, calls MAY invoke Keystore importAccount for sender. Create (0x00) cannot: its CREATE2 address is a different space, and combining 0x03 with 0x00 is invalid.

During this transaction the overlay is live, so ERC-1271 on sender succeeds against the in-tx actor map. importAccount's "already initialized" check reads persistent channels (still zero). On success it SSTOREs actors, CONTRACT_ESTABLISHED, and DEFAULT_EOA_REVOKED as today. Settlement still clears the EIP-7702 indicator and the overlay; the next EIP-8130 transaction omits 0x03, reads Keystore, and auto-delegates. Other Keystore writes from sender during a stateless transaction (applySignedAccountChanges) are not the graduation path and MUST NOT be relied on to persist the overlay.

Validation

When a stateless entry is present in account_changes:

1. Parse [0x03, user_salt, delegation, initial_actors, uniqueness] where each actor is [actorId, authenticator, scope, policyData]. Apply EIP-8130 create's initial_actors rules (non-empty, strictly ascending actorId, policyData). Reject if delegation is address(0). uniqueness is a 32-byte value with no other validity constraint.
2. Reject if any initial actor has scope & NONCE != 0.
3. Require nonce_key == NONCE_KEY_MAX and nonce_sequence == 0.
4. Require the 0x03 entry is first. Reject if any create (0x00) entry is present. Config-change (0x01) entries MAY follow, at most MAX_STATELESS_CHAIN_ENTRIES of them. At most one delegation entry (0x02) MAY follow those, last. Reject a 0x02 anywhere else.
5. Compute actors_commitment and expected per Address Derivation.
6. Require sender == expected (sender MUST be set; this is the configured-actor path).
7. Build the account image overlay and apply following 0x01 entries. Reject Lock / Unlock. Reject any AuthorizeActor whose scope & NONCE != 0 (the overlay MUST not gain a NONCE actor; the transaction remains nonce-free).
8. Validate sender_auth against the resulting overlay (resolved actorId and authenticator MUST match a live actor). Scope and policyData for the rest of the transaction are taken from that actor in the overlay, not from persistent Keystore storage.
9. If a 0x02 entry is present, require that resolved actor is admin (scope == 0x00). Do not apply EIP-8130's EOA-only delegation rule.

Mempool acceptance uses the image as the effective actor state (no Keystore read). Auto-delegation to DEFAULT_ACCOUNT_ADDRESS is suppressed when a stateless entry is present.

Execution

During EIP-8130 block execution, a stateless entry:

1. Suppresses auto-delegation to DEFAULT_ACCOUNT_ADDRESS.
2. Sets code(sender) = 0xef0100 || target before calls, where target is the 0x02 target if a delegation entry is present, otherwise the 0x03 delegation. If that target is address(0), the indicator is not installed (this transaction has no wallet code). A 0x02 after 0x03 MUST NOT persist; it only selects this transaction's target.
3. Does not SSTORE Keystore storage, set persistent CONTRACT_ESTABLISHED, or emit AccountCreated / DelegationApplied / ActorAuthorized. Config-change entries that follow TSTORE only the overlay. They MUST NOT SSTORE Keystore slots. importAccount during calls is the graduation exception and SSTOREs as specified there.
4. After calls settle (every phase succeeded or any phase reverted), clears the indicator and resets the account's code hash to the empty code hash. EIP-1153 discards the overlay.

The temporary code is visible to EXTCODESIZE / EXTCODECOPY / CALL / DELEGATECALL / STATICCALL targeting sender for the remainder of this transaction only. Subsequent transactions see an empty-code account unless another stateless entry with the same (user_salt, initial_actors) is included.

EIP-8130 protocol-injected receipt logs MUST NOT be emitted for a stateless entry, for config-changes applied to its image, or for a 0x02 that follows 0x03. A failed transaction's earlier phases, nonce-free replay_id insertion, and gas payment still persist; the indicator and the image do not.

In-EVM Keystore reads during calls see the overlay: getActorConfig, validateSignature, and account isValidSignature / ERC-1271 behave as after a persistent create. Wallet implementations intended for stateless use MUST go through those Keystore read paths (which TLOAD) and MUST NOT SSTORE Keystore for sender except via importAccount.

Gas

A stateless entry does not charge EIP-8130 bytecode_cost (no permanent deploy) and does not charge Keystore slot writes. Calldata is already metered by EIP-8130 tx_payload_cost; this EIP does not double-count it.

CREATE_STATELESS_GAS_COST =
    2 * STATELESS_INDICATOR_COST                // install before calls, clear at settlement
  + STATELESS_IMAGE_BASE_COST                   // IMAGE_ACTIVE flag + packed account-state
  + STATELESS_IMAGE_ACTOR_COST * n_words        // TSTORE words: 1 per actor, +2 if POLICY

account_changes_cost += CREATE_STATELESS_GAS_COST
  + Σ chain_auth_cost_i                         // one term per 0x01 entry, i = 1 .. n_chain

chain_auth_cost_i is the authenticator-execution component of EIP-8130 sender_auth_cost for that batch's auth (canonical: the enshrined constant; otherwise STATICCALL bounded by MAX_AUTHENTICATION_GAS). Actor-config lookup is TLOAD (100), not an actor_config SLOAD. A 0x02 after 0x03 does not add a second indicator deposit; install-and-clear is already in CREATE_STATELESS_GAS_COST.

All of the above is intrinsic and is charged before execution, including when calls revert and when the image is discarded. Nonce-free nonce_key_cost is unchanged from EIP-8130.

Rationale

One type, two uses. An ephemeral account is a stateless account (fresh salt, empty chain). Reused salt plus a config-change witness is the same account living across transactions without Keystore slots. Privacy is the adoption; long-lived is the extra. Splitting them would duplicate address derivation, the image, and settlement.

initial_actors, not a single actor. The birth set is create's array: admin plus a restricted app key, several recovery actors, a POLICY manager with an external manager. They are committed in the address, so the empty chain already has a full account. A single-actor special case would force every second key through a config-change even at birth.

Why chain config-changes on top, and why they stay in calldata. expiry and manager = account are not expressible at create. Later rotations are signed batches, not a new birth set (a new birth set is a new address). Replaying those batches against the overlay reuses EIP-8130 auth, channels, sequences, and AuthorizeActor — without applySignedAccountChanges and without Keystore slots. The entire account is the 0x03 entry plus the 0x01 chain in calldata; a Keystore-backed account is the same objects with the writes left on.

Why transient storage, not an invisible client image. EIP-1153 TLOAD/TSTORE are the EVM-visible account map. Protocol TSTOREs on KEYSTORE_ADDRESS so existing validateSignature / ERC-1271 / getActorConfig paths work unchanged during calls. Overlay reads; persistent SLOAD emptiness is what lets importAccount graduate. TLOAD is legal inside STATICCALL; the overlay is discarded with the transaction. A purely in-client image would force every wallet to special-case Tx Context and would break ERC-1271.

No persistent Keystore write. Durable (address → actor) state is exactly what these flows cannot afford. Authentication uses the overlay. An unanchored stateless entry's validity does not depend on persistent sender Keystore, sender nonce, or sender code — the strongest fork-choice enforced inclusion lists (FOCIL, EIP-7805) citizen EIP-8130 can offer. Payer balance, the nonce-free replay ring, and (if non-canonical) authenticator bytecode remain.

Why sender_auth is against the post-chain image. That is what makes a post-birth rotation usable on this transaction: an admin in initial_actors signs AuthorizeActor(new), and sender_auth is the new actor. EIP-8130 create authenticates against initial_actors and then writes the chain to storage for later transactions. Here there is no later storage, so the chain has to take effect before origin.

Why uniqueness is on the entry, not left to calldata. EIP-8130 replay_id already binds account_changes, calls, metadata, and valid_before. Identical recurring payments (same calls, same chain, same window) collide until the ring evicts. uniqueness is in account_changes so it is in replay_id, and out of the address so it does not fork the account. Wallets that forget it fail closed. Varying calls or metadata is not the specified path.

Why MAX_STATELESS_CHAIN_ENTRIES. Keystore-backed 0x01 can skip already-applied batches (one SLOAD). Stateless must verify every batch signature every transaction. An uncapped chain is unbounded authentication work on the validation path. Eight is enough for a rotation witness and is a protocol constant, not a mempool SHOULD. PQ signatures inflate calldata; aggregation (above) shrinks verification, not the entry cap. A proof-of-chain EIP would be the way to raise the cap without replaying n authentications.

Code is not frozen. The address does not commit the EIP-7702 target. 0x03 names this transaction's default implementation; a following 0x02 retargets it (create-then-delegate); the next transaction may name a different 0x03 delegation at the same address. Committing delegation in the address would make implementation a new account. A 0x02 after 0x03 is cleared at settlement so the account stays stateless; persistence is what a Keystore-backed 0x02 is for.

Transaction-scoped EIP-7702. calls need wallet code at sender. A persistent EIP-7702 indicator or deployed bytecode would be leftover state. Installing 0xef0100 || target for the transaction and clearing it at settlement is the minimum that lets the account execute.

Mandatory nonce-free. A sequenced nonce_key writes a Nonce Manager slot at (sender, nonce_key) forever. Forbidding NONCE on every initial actor (and on any AuthorizeActor in the chain) and requiring NONCE_KEY_MAX keeps the only protocol footprint on EIP-8130's existing capacity-bounded ring buffer.

Recovery via recreate. The address is a pure function of user_salt and initial_actors. The same birth parameters produce the same address (any implementation), so stranded funds are swept by a later stateless transaction. CREATE2 freshness is not required; reuse is the point for long-lived use and the recovery path for ephemeral use.

No logs. Protocol-injected create/delegation/actor logs would advertise the session. Calldata already contains the entry and the chain; this EIP adds no further receipt record.

Backwards Compatibility

No changes to EIP-8130 transactions that do not carry a stateless entry. An EIP-8130 chain that has not activated this EIP rejects type 0x03 as unknown. Contracts cannot currently observe transaction-scoped EIP-7702, so no existing code changes meaning. Chained 0x01 / 0x02 entries after 0x03 are a new combination: the 0x02 is tx-scoped when it follows 0x03, and persistent when it does not. Keystore-backed create+config-change+delegation transactions are unchanged.

Security Considerations

Trust model (unanchored). An unanchored stateless account has EOA-equivalent key-compromise semantics. Birth actors are irrevocable: every transaction rehydrates from initial_actors, so a witness that omits later 0x01 entries is valid. Rotation via the chain is advisory against an omitting adversary. RevokeActor of a birth actor binds only that transaction. Durable retirement needs Keystore (or some other stored commitment) and is out of scope. Treat initial_actors as cert roots; chained actors are additional keys, not a replacement root. For any long-lived unanchored use, the admin birth actor should be a threshold authenticator. Extra admin birth actors do not raise the bar: the empty chain can originate as any one of them. Unlinkability across transactions is the wallet's (fresh salt, how much of the chain is reused), not the protocol's; calldata is public.

Address commitment. The address commits initial_actors under STATELESS_PREFIX, not the EIP-7702 target and not uniqueness. A different authenticator set cannot claim a prefunded counterfactual. Implementation is chosen per transaction by whoever can satisfy sender_auth. Without a birth key, an attacker cannot originate (so they cannot re-point code). With a birth key they can.

Multichain delegation code. The same (user_salt, initial_actors) yields the same address on every adopting chain. The committed identity is the actor set, not bytecode at delegation. A prefunded counterfactual on chain B can be executed under whatever code sits at that address there — the same class of issue as a Keystore import whose factory is not CREATE2-identical across chains. Delegation targets should be deterministic-deployment (same CREATE2) on every chain that will see the address, e.g. DEFAULT_ACCOUNT_ADDRESS or a factory salt shared with the canonical account.

Replay / uniqueness. replay_id suppresses the same logical transaction inside NONCE_FREE_EXPIRY_WINDOW. Recurring payments must vary uniqueness per the Stateless Entry rule (fail closed if they do not). A later transaction with a new uniqueness, calls, delegation, or chain is a new replay_id. Config-change signatures are meant to be re-submitted; their sequence counters live only in the overlay.

In-EVM Keystore and ERC-1271. The overlay is Keystore transient storage, so getActorConfig, validateSignature, and account ERC-1271 work for this transaction as if create had just run. Protocol-applied 0x01 entries TSTORE only. importAccount during calls is the persist path (ERC-1271 against the overlay, initialized-check against persistent SLOADs). Other Keystore SSTOREs from sender are not graduation. EVM TSTORE on KEYSTORE_ADDRESS into overlay slots could clobber the image, which is why the Keystore must not expose those keys through a user-facing TSTORE API (see Account Image).

Account storage. Delegated code that SSTOREs to the account leaves storage after the indicator is cleared; implementations used as delegation should be stateless.

Ring-buffer capacity. High-volume stateless traffic shares REPLAY_BUFFER_CAPACITY with every other nonce-free transaction. Each chained 0x01 pays full chain_auth_cost as intrinsic, so validation work is prepaid; the chain cap is what keeps that work bounded.

Copyright

Copyright and related rights waived via CC0.