What Changed From Original to Latest
The "Original (Oct 14)" column reflects the baseline established by PR #11186, the first version of eip-8130.md merged into the ethereum/EIPs repo (merged February 28, 2026). October 14, 2025 is the EIP's created frontmatter date (concept inception; the EthMagicians thread itself opened October 24); no spec text existed in the repo at that time, so the comparison below is against the substance of #11186, not a document that existed on that calendar date. "Latest (Oct 21)" reflects master after PR #12386 (merged October 8, 2026). Since that PR, transaction-format rows describe EIP-8430, the open draft (PR #12385) that now carries the transaction type EIP-8130 used to define.
Structural Comparison
| Aspect | Original (Oct 14) | Latest (Oct 21) |
|---|---|---|
| Spec scope and title | "Account Abstraction by Account Configuration": one EIP defining a transaction type, its validation rules, and the Account Configuration Contract | "Keystore Accounts": the Keystore only, specified as transport-neutral for native transactions, EIP-8141 frame accounts, ERC-4337, and applications. Renamed in PR #12295 (Sep 3); transaction type moved to EIP-8430 in PR #12386 (Oct 8) |
| Configuration system | Account Configuration Contract with most internal mechanics repeated in the EIP | Keystore at KEYSTORE_ADDRESS; the canonical Base contracts are authoritative for lower-level mechanics (PR #12135, Aug 11). Consumers must authenticate equivalently to authenticateActor |
| Authority-holder terminology | "Keys," identified by keyId, stored in key_config | "Actors," identified by actorId, stored in actor_config. Renamed keys to owners in PR #11380 (Mar 6), then owners to actors in PR #11764 (Jun 4) |
| Signature-verification terminology | "Verifiers," via IAuthVerifier.verify() | "Authenticators," via IAuthenticator.authenticate(), plus typed local/multichain validateSignature envelopes (PR #12135). The spec now notes validateSignature can run natively as a precompile |
| Sender field name | from | sender, renamed in PR #11526 (May 11); the field now lives in EIP-8430 |
| Scope/grant model | No scope bits; only a key_policy bitfield (revoked, requireSponsor), so a requireSponsor key could authenticate but not spend account ETH on gas. Otherwise all keys had equal authority | uint16 grant mask: OPERATOR 0x01, SELF_PAYER 0x02, SPONSOR_PAYER 0x04, POLICY 0x08, NONCE 0x10, bits 5-15 spare. Grants landed in PR #11918 (Jul 13); PR #12333 (Sep 14) reordered them and renamed SENDER to OPERATOR. Draft PR #12462 would cut the mask to OPERATOR and POLICY |
| Admin authority | Not a formal concept (no scope model existed) | Predicate scope == 0x00, not a grantable bit. A separate CONFIG bit existed briefly (PR #11388) before PR #11918 (Jul 13) replaced it with the zero-scope predicate |
| Account mutation fields | Two separate fields: account_initialization and key_changes | One signed SignedAccountChanges batch for AuthorizeActor, RevokeActor, IncrementLocalEpoch, Lock, and Unlock. On EIP-8430 it rides config-change entry 0x03, creation rides 0x02, and delegation is EIP-8430's own 0x01 |
| Local change sequencing | One local monotonic sequence | Packed local_epoch and local_sequence (uint32 each), with UNSEQUENCED changes and epoch-wide invalidation from PR #12135 |
| Account Lock | None | Lock and Unlock are signed local Keystore change types; the packed state retains lock and delayed-unlock status |
| Contract identity flag | None | None. CONTRACT_ESTABLISHED was added in PR #12135 (Aug 11) and removed in PR #12250 (Aug 27), which shifted the remaining flags down one bit |
| Transaction type bytes | AA_TX_TYPE and AA_PAYER_TYPE both TBD placeholders | 0x79/0x7A, now defined by EIP-8430 rather than EIP-8130. First assigned 0x7B/0x7C in PR #11757 (Jun 2), renumbered in PR #11903 (Jul 8) after karlb flagged a collision with Celo's CIP-64 type on the OP Stack (forum posts #20-22) |
| Nonce system | 2D nonce_key (uint192) / nonce_sequence (uint64) via a Nonce Manager precompile; no nonce-free mode | Now in EIP-8430: nonce_key 0 is the ordinary account nonce, keys 1..NONCE_KEY_MAX-1 live in the Nonce Manager, and NONCE_KEY_MAX selects nonce-free mode with replay_id deduplication. Nonce-free mode from PR #11478 (Apr 2), replay_id from PR #11752 (Jun 2) |
| Transaction validity | One optional Unix-seconds expiry | valid_after/valid_before window (PR #12135), accepting seconds or milliseconds by magnitude against TIMESTAMP_MS_THRESHOLD (PR #12204, Aug 19); now defined in EIP-8430 |
| Address-derived actorId | Address converted directly to bytes32 without one explicit alignment rule | Right-aligned address in the low 20 bytes, bytes32(uint256(uint160(address))), standardized by PR #12173 |
| Default EOA revocation | An empty key_config slot meant the implicit EOA key was authorized; revocation used an explicit revoked bit in key_policy | DEFAULT_EOA_REVOKED (0x01 since PR #12250) in the packed account-state slot; creation and import revoke the implicit owner unless re-registered. Sentinel form in PR #11478 (Apr 2), state flag and flipped default in PR #11815 (Jun 18) |
| Gas sponsorship / payer modes | Self-pay, delegate payer, K1 sponsor, and "verifier sponsor," with no scope-gating on who could act as payer | SELF_PAYER and SPONSOR_PAYER grants, split from one PAYER bit in PR #11918 (Jul 13). EIP-8430 adds an open payer mode (payer = 0x00) recovered from payer_auth |
| Canonical authenticator set | None. No canonical/allowlisted set concept existed | k1, p256, passkey, delegate, catalogued by a companion ERC still without a number. PR #12204 (Aug 19) added permissive (L1) and canonical-only (L2) acceptance with MAX_AUTHENTICATION_GAS, and states that a base layer changes the enshrined set only by hard fork. Introduced as the "canonical verifier set" in PR #11647 (May 11) |
| Actor call policies | None | Manager-gated initiation enforced during execution. PR #12333 made slot storage depend on policyData length and let OPERATOR override POLICY. Shipped in PR #11766 (Jun 4) |
| Transaction Context mechanism | EIP-1153 transient storage (TSTORE) directly on the Account Configuration Contract (getCurrentPayer()/getCurrentSigner()) | Precompile at TX_CONTEXT_ADDRESS, now defined by EIP-8430 with getTransactionPayer() for every transaction type; Keystore integration adds sender, calls, and gas-limit getters readable during authentication (PRs #12204, #12386) |
| ERC-1271 signing authority | No distinct signing model prior to the scope system; once introduced, any key with the SIGNATURE bit could sign | Operational authority: admin or any scope carrying OPERATOR. SIGNER bit removed in PR #11918 (Jul 13); the "SENDER and not POLICY" carve-out dropped with PR #12333 (Sep 14) |
| Metadata / opaque annotation field | None | Opaque, signed metadata field from PR #11805 (Jun 15), now carried by EIP-8430 |
| Native call value | Calls dispatched with msg.value = 0; ETH moved only inside account code | EIP-8430 calls are [to, value, data] with native value. EIP-8130 forbids value for policy-gated actors and canonical account bytecode (PR #12386, Oct 8) |
| Account import | None | Parameterless importAccount() called by the account itself, installing the set its confirmKeystoreImport() returns (PR #12333, Sep 14) |
requires header | 1153, 2718 | 170, 1014. Expanded to thirteen EIPs in PR #12135, trimmed to 170, 2718, 7623 in PR #12320 (Sep 16), then to 170, 1014 when the transaction type left in PR #12386 |
Key Philosophical Shifts
1. From Raw Keys to Scoped Actors
The original model treated authority-holders as literal cryptographic key material: keyId, key_config, an entity indistinguishable from the key it held. PR #11380 (Mar 6, "Simplify for initial EIP") renamed keys to owners and simultaneously dropped on-chain public-key storage, letting authenticators resolve the public key from calldata at signing time instead. PR #11764 (Jun 4) completed the arc, renaming owners to actors. The PR body states the rationale directly: "Many of these entities are scoped credentials (PAYER-only, SIGNATURE-only, session-style keys), so 'owner' overstated their authority; 'actor' describes a scoped signing entity more accurately." The two renames track the scope model's own maturation. PR #11388 (Mar 9) had already introduced the first permission bits a few days after the "owner" rename; once authority could be partial, the terminology needed to admit that a registered credential is a role, not a possession.
2. From Verification to Separated Authentication and Authorization
The original interface, IAuthVerifier.verify(), conflated two distinct questions: who is this, and what may they do. PR #11388 (Mar 9) dropped the redundant "Auth" prefix (IAuthVerifier to IVerifier) while introducing the first scope model, but the interface still returned identity only. PR #11785 (Jun 9, "Rename verifier -> authenticator") completed the conceptual split: IVerifier to IAuthenticator, verify() to authenticate(). The diff's own rationale states that the authenticator "authenticates the actor (it returns the actor's actorId); scope and policy then authorize what that authenticated actor may do." Identity resolution is now an explicit protocol step separate from permission checking, a distinction the original "verify" language obscured. PR #11794 (Jun 10) reinforced this by expanding authenticateActor's return signature to surface scope and policy alongside the actor identity in one call, so a single lookup can serve both authentication and authorization consumers.
3. Admin Redefined as Absence of Restriction, Not a Grant
Originally, admin authority was not a formal concept at all; any authorized key had full authority (PR #11186). Once a scope model existed, an early formulation (PR #11388) included a CONFIG bit as one grant among several (SIGNATURE, SENDER, PAYER, CONFIG). PR #11918 (Jul 13), the largest structural rewrite since #11367, replaced this with a predicate: admin is exactly scope == 0x00, not a bit that can be granted. The spec's own "Why Admin Is Scope Zero" rationale explains the reasoning: a dedicated config-only grant bit "would be indistinguishable from full access since any key that can rewrite actor_config can grant itself scope == 0x00," so naming admin as absence-of-restriction makes self-escalation explicit rather than hiding it behind a bit that looks like ordinary permission. The same PR split the original single PAYER bit into SELF_PAYER and SPONSOR_PAYER, and removed the standalone SIGNER bit, reframing ERC-1271 signing as an encoding of already-held operational authority rather than a separate capability.
4. Quantum-Safe-by-Default EOA Revocation
In the original model an empty key_config slot meant the implicit EOA key was authorized, and revocation was expressed through an explicit revoked bit in key_policy. PR #11478 (Apr 2) relocated implicit-EOA revocation to a REVOKED_AUTHENTICATOR sentinel address written into the slot. PR #11815 (Jun 18, "fold default-EOA revocation into a state flag") went further, replacing that sentinel-address trick with a single DEFAULT_EOA_REVOKED bit in the packed account-state slot, and flipped the default so that createAccount/importAccount revoke the implicit secp256k1 owner unless it is explicitly re-registered in initial_actors. The spec calls this a quantum-safe default: freshly created or imported accounts no longer carry a live secp256k1 owner by omission. Community contributor pochenai had separately raised a related concern in closed PR #11612 (an implicit EOA owner acting as a "permanent backdoor around delegated wallet logic" when an account delegates elsewhere), though chunter-cb rejected that PR's specific auto-revoke-on-delegation proposal ("we do not want to auto revoke the EOA key when the account is delegated to as it would disable using the EOA"). The shipped default addresses only the account-genesis case, not #11612's broader delegation-triggered rule.
5. From Transaction Type to Transport-Neutral Keystore
For ten months EIP-8130 was a transaction type that happened to define an account-configuration contract. The August alignment (PR #12135) made the contracts authoritative for mechanics; the September rename (PR #12295) made the Keystore the proposal's name; PR #12386 (Oct 8) made it the proposal's whole scope. Its new rationale states that authority over an account "should not depend on which transaction format carries an action." EIP-8130 now names EIP-8141 frame accounts and ERC-4337 accounts as consumers alongside the split-out EIP-8430, which turns the site's long-running EIP-8130-versus-EIP-8141 framing into a question of transports versus authority layers. The cost is that the canonical repository holds a merged Keystore integrating with an unmerged transaction type.
Active Proposals That May Change the Comparison
As of October 21, 2026, eight PRs remain open against EIP-8130, plus the EIP-8430 draft that now carries the transaction format.
| Proposal | PR | Impact |
|---|---|---|
| AA Transaction Type (EIP-8430) | #12385 | Would give every transaction-format row above a merged home. Until it merges, those rows describe an open draft |
| Simplify the Keystore | #12462 | Draft. Would cut scope to OPERATOR and POLICY, remove the policy manager slots and account lock, and add multichain epochs. Would rewrite the scope, policy, lock, and payer rows |
| Two-track epochs and transient actors | #12334 | Draft. Multichain epoch and unsequenced mode, IncrementEpoch, and a one-transaction actor tier in transient storage |
| Four-tier authenticator classes | #12210 | Draft. CANONICAL, PURE, BOUNDED, ARBITRARY mempool tiers over the permissive acceptance policy |
| Checkpointed Keystore / actors | #12293, #12313 | Two alternative designs for admin-co-approved, offchain-maintained non-admin actor sets |
| Model-neutral change digest | #12341 | Optional digest letting one signed actor change apply across models and chains |
| Expiry at create and import | #11919 | Would let initial actors carry expiry; written against pre-#12333 import text |
| Opaque input bytes field | #11578 | A second tx-level annotation field; would now need retargeting at EIP-8430 |
If #12462 merges, the scope, policy, lock, and sponsorship rows change again, reversing much of the July 13 grant model.