--- eip: 8387 title: Stateless Accounts description: Adds ephemeral (privacy) accounts with no Keystore write; the same entry also enables long-lived stateless use author: Chris Hunter (@chunter-cb) discussions-to: https://ethereum-magicians.org/t/eip-8387-stateless-accounts/29473 status: Draft type: Standards Track category: Core created: 2026-08-21 requires: 1153, 1271, 7702, 8130 --- ## Abstract This proposal extends [EIP-8130](./eip-8130.md) 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](./eip-7702.md) 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](./eip-1271.md), 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](https://www.rfc-editor.org/rfc/rfc2119) and [RFC 8174](https://www.rfc-editor.org/rfc/rfc8174). 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 | Name | Value | Comment | | ---- | ----- | ------- | | `STATELESS_PREFIX` | ASCII `"STATELESS"` (9 bytes) | Domain separator for address derivation | | `MAX_STATELESS_CHAIN_ENTRIES` | `8` | Consensus cap on `0x01` entries after `0x03`. Stateless chains replay every batch signature every transaction; this bounds validation-time authentication | | `STATELESS_INDICATOR_COST` | `4,600` | One EIP-7702 indicator deposit (200 × 23 bytes), same as EIP-8130 `auto_delegation_cost` | | `STATELESS_IMAGE_BASE_COST` | `200` | `TSTORE` of `IMAGE_ACTIVE(sender)` and the packed account-state word | | `STATELESS_IMAGE_ACTOR_COST` | `100` | [EIP-1153](./eip-1153.md) `TSTORE` per birth-actor `actor_config` word (`POLICY` actors add two more words at the same 100 each) | | `CREATE_STATELESS_GAS_COST` | see [Gas](#gas) | Intrinsic; no Keystore writes | ### 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](./eip-8130.md#create-entry): 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](#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](./eip-8130.md) 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](#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](./eip-1153.md) 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](./eip-1271.md) (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 `TSTORE`d; 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: ```text 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](#gas)). Batch `auth` and `sender_auth` MAY be aggregated per [Aggregation](#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](#address-derivation). 6. Require `sender == expected` (`sender` MUST be set; this is the configured-actor path). 7. Build the [account image](#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](#graduation-importaccount) 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](./eip-1271.md) 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](./eip-1153.md) `TLOAD`/`TSTORE` are the EVM-visible account map. Protocol `TSTORE`s 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](./eip-7805.md)) 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](#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](./eip-1271.md) 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-image)). **Account storage.** Delegated code that `SSTORE`s 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](../LICENSE.md).