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 (Aug 20)" reflects master after PR #12173 (merged August 14, 2026).
Structural Comparison
| Aspect | Original (Oct 14) | Latest (Aug 20) |
|---|---|---|
| Configuration system | Account Configuration Contract with most internal mechanics repeated in the EIP | Keystore at KEYSTORE_ADDRESS; PR #12135 (Aug 11) makes the canonical Base contracts authoritative for lower-level mechanics |
| 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 with account- and chain-scoped replaySafeHash from PR #12135 |
| Sender field name | from | sender, renamed in PR #11526 (May 11) to disambiguate from EVM/JSON-RPC from semantics |
| 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: SENDER, POLICY, NONCE, SELF_PAYER, SPONSOR_PAYER, with bits 5-15 spare. Current grants landed in PR #11918; width and packing changed in PR #12135 |
| 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 | Unified transaction account_changes, plus one applySignedAccountChanges Keystore path for AuthorizeActor, RevokeActor, IncrementLocalEpoch, Lock, and Unlock |
| 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 | CONTRACT_ESTABLISHED prevents a previously established, later code-less contract from being treated as an implicit EOA after EIP-6780 |
| Transaction type bytes | AA_TX_TYPE and AA_PAYER_TYPE both TBD placeholders | AA_TX_TYPE = 0x79, AA_PAYER_TYPE = 0x7A. First assigned 0x7B/0x7C in PR #11757 (Jun 2), renumbered in PR #11903 (Jul 8) after karlb flagged that 0x7b collided with the type used for Celo's CIP-64 fee-currency transactions 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 | 2D nonce_key (uint256) / nonce_sequence (uint64), still two RLP fields; nonce-free mode via the NONCE_KEY_MAX sentinel (2^256-1), hardened by replay_id deduplication. Nonce-free mode introduced in PR #11478 (Apr 2), replay_id added in PR #11752 (Jun 2) |
| Transaction validity | One optional Unix-seconds expiry | Millisecond valid_after and valid_before window; nonce-free mode requires finite valid_before (PR #12135) |
| 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 | Explicit DEFAULT_EOA_REVOKED bit in the packed account-state slot; createAccount/importAccount revoke the implicit EOA owner by default unless re-registered. Revocation relocated to a REVOKED_AUTHENTICATOR sentinel in PR #11478 (Apr 2), then folded into the DEFAULT_EOA_REVOKED state flag with the default flipped 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 | Single PAYER grant split into SELF_PAYER (payer == sender) and SPONSOR_PAYER (payer != sender), each independently gated. PAYER bit introduced in PR #11388 (Mar 9), split in PR #11918 (Jul 13) |
| Canonical authenticator set | None. No canonical/allowlisted set concept existed | Canonical Authenticator Set (k1, p256, passkey, delegate), maintained via a companion ERC; nodes MUST accept the baseline set. Introduced as the "canonical verifier set" in PR #11647 (May 11), renamed with the authenticator terminology in PR #11785 (Jun 9) |
| Actor call policies | None | policyTarget/manager-gated call initiation, enforced during execution. Draft attempt PR #11648 closed as unmergeable; shipped as PR #11766 (Jun 4) |
| Transaction Context mechanism | EIP-1153 transient storage (TSTORE) directly on the Account Configuration Contract (getCurrentPayer()/getCurrentSigner()) | Dedicated Transaction Context precompile at TX_CONTEXT_ADDRESS (ITransactionContext: getTransactionSender/getTransactionPayer/getTransactionSenderActorId). Precompile introduced in PR #11388 (Mar 9), dropping requires: 1153; naming finalized in PR #11764 (Jun 4) |
| ERC-1271 signing authority | No distinct signing model prior to the scope system; once introduced, any key with the SIGNATURE bit could sign | Reframed as "operational authority": admin || (SENDER && !POLICY). Standalone SIGNER bit removed in PR #11918 (Jul 13) |
| Metadata / opaque annotation field | None | Dedicated opaque, signed metadata transaction field, resolving a month-long debate between draft PRs #11578 (opaque_input) and #11655 (metadata sink). Shipped in PR #11805 (Jun 15) |
requires header | 1153, 2718 | 155, 170, 712, 1271, 1559, 2028, 2718, 2929, 4337, 6780, 7702, 7708, 7819, expanded in PR #12135 to state the actual dependency surface |
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.
Active Proposals That May Change the Comparison
As of August 20, 2026, three PRs remain open against EIP-8130 that could extend this comparison table.
| Proposal | PR | Impact |
|---|---|---|
| Opaque input bytes field | #11578 | Would restore a tx-level opaque_input metadata role mirroring the legacy input field, for attribution suffixes such as ERC-8021. Superseded in spirit by the merged metadata field (PR #11805), which took a different, calls-model approach; chunter-cb responded favorably to the general idea but pointed at his own alternative draft (PR #11655, since closed). Likely needs reconciliation with #11805's shipped design rather than a merge as-is |
| Expiry at create and import | #11919 | Would add an optional uint48 expiry to each initial actor at createAccount/importAccount time, previously only settable via a post-deployment config change. Commits expiry into the per-actor address-derivation preimage so a front-runner cannot alter it. Opened the same day PR #11918 merged, as a direct extension of that PR's policyData-at-create work; no review comments yet |
| Adoption profiles and bounded authentication | #12204 | Would define permissive L1 and canonical-only L2 profiles, cap authenticator gas, expose transaction context during authentication, and accept second or millisecond timestamps. Open with no review comments at the August 20 snapshot |
If #11919 merges, the create/import expiry gap closes. If #11578 merges, the metadata row needs reconciliation. If #12204 merges, the validity, authenticator, transaction-context, and gas rows all change.