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, marking when chunter-cb first floated the concept on EthMagicians; 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 (Jul 15)" reflects master as of July 15, 2026, after PR #11918 (merged July 13, 2026).
Structural Comparison
| Aspect | Original (Oct 14) | Latest (Jul 15) |
|---|---|---|
| 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(). IAuthVerifier renamed IVerifier in PR #11388 (Mar 9), then IVerifier renamed IAuthenticator in PR #11785 (Jun 9) |
| Sender field name | from | sender, renamed in PR #11526 (May 11) to disambiguate from EVM/JSON-RPC from semantics |
| Scope/grant model | None. Any authorized key had full authority | Five independent grant bits: SENDER (0x01), POLICY (0x02), NONCE (0x04), SELF_PAYER (0x08), SPONSOR_PAYER (0x10). First introduced as SIGNATURE/SENDER/PAYER/CONFIG in PR #11388 (Mar 9), redesigned to the current bit set in PR #11918 (Jul 13) |
| 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 (CREATE2 new-account creation) and key_changes (portable cross-chain key-change operations) | Unified typed account_changes array (create 0x00, config change 0x01, delegation 0x02), introduced in PR #11367 (Mar 3) |
| Account Lock | None | LOCKED/UNLOCK_INITIATED flags packed into the account-state slot; strict lock-then-unlock lifecycle via applySignedLockChanges. Introduced in PR #11367 (Mar 3), lifecycle simplified in PR #11918 (Jul 13) |
| 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 an OP Stack CIP-64 collision (forum posts #20-22) |
| Nonce system | 2D nonce_key/nonce_sequence via a Nonce Manager precompile; no nonce-free mode | Packed single nonce field; 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) |
| Default EOA revocation | Ambiguous by construction: an empty actor_config slot meant authorized; distinguishing "revoked" from "never touched" required an out-of-band convention | Explicit DEFAULT_EOA_REVOKED bit in the packed account-state slot; createAccount/importAccount revoke the implicit EOA owner by default unless re-registered. Explicit marker added in PR #11478 (Apr 2), folded into a 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 | policyType/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 | 170, 2718. 1153 dropped in PR #11388 (Mar 9); 7702 added in PR #11367 (Mar 3) and dropped in PR #11492 (Apr 14); 170 added in PR #11609 (Jun 2) |
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
The original implicit-EOA-owner model was ambiguous by construction: an empty actor_config slot meant authorized, and distinguishing "revoked" from "never touched" required an out-of-band convention. PR #11478 (Apr 2) introduced an explicit revocation marker. PR #11815 (Jun 18, "fold default-EOA revocation into a state flag") went further, replacing the REVOKED_AUTHENTICATOR 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. This was framed explicitly as a quantum-resistant 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 July 15, 2026, two PRs remain open against EIP-8130 that would 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 |
If either PR merges, the "Not expressible at create" and "Not expressible at import" gaps noted in the current spec for expiry would close, and the metadata-field row above would need a note on whether opaque_input and metadata end up coexisting or converging.