Feedback Evolution
This page traces how community feedback and PR review shaped EIP-8130 (Account Abstraction by Account Configuration) from its October 2025 forum origin through the July 2026 transaction-type renumbering. It is organized into chronological, thematic phases. Each phase cites the PR or forum post that drove a change and explains the reasoning behind it, not just the mechanical diff (mechanics live on Merged Changes).
Phase 1: Concept to Submission (October 2025 – February 2026)
Chris Hunter (chunter, Coinbase/Base) opened the EthMagicians thread on October 24, 2025 (post #1), describing "an account abstraction protocol that is designed performant, flexible, arbitrary account abstraction by enabling nodes to add native implementations of validation logic (ie k1, p256, webauth)" while keeping custom validation code permissionless to deploy. The core bet from day one was separating cheap, node-native signature schemes from arbitrary smart-contract logic, so mempool inclusion checks would never require simulating wallet bytecode.
The proposal sat as a forum draft for three months. On January 21, 2026 (post #2), chunter announced the move to a formal EIP submission, opening PR #11144 as the first draft. A duplicate PR, #11186, was opened six days later; maintainer abcoathup asked chunter to consolidate ("Can you close #11144 if this is going to be the PR for EIP-8130 moving forward?"), and #11144 closed January 29 in favor of #11186, which merged February 28, 2026 and established the baseline spec.
Early forum review (posts #5-10, January 22-29) shaped two decisions before the spec even merged. First, rmeissner (post #5) questioned bundling authentication and gas-payment logic into a single EIP, arguing from past experience that combined scope "lowers the chances of adoption by the core team due to complexity" and suggesting a split. chunter agreed (post #6) to separate the concerns, and defended the self-call execution model on the grounds that it keeps tx.origin equal to the wallet address and lets wallets detect the AA entry pattern via msg.sender == tx.origin == address(this) without a dedicated entrypoint contract. Second, Helkomine (post #7) argued that token-based gas payment should stay ordinary ERC-20 storage rather than becoming a first-class transaction-format attribute, warning that baking payment semantics into the tx format increases protocol complexity; this concern anticipated the later closure of the separate "Token Gas Payments for EIP-8130" companion PR (#11194, opened January 28, closed March 2 without a stated inline rejection, consistent with deferring token-gas-payment mechanics out of the core EIP).
Safe's rmeissner and chunter also worked through a concrete compatibility question (posts #8-9): whether Safe's existing self-call config-change detection would remain compatible with the AA entrypoint pattern, and how to disambiguate the initial AA invocation from a later self-call triggered by contract code. They converged on a transient-storage flag set on the initial frame, reasoning that a later call "from a different address... caller can't be msg.sender," though chunter noted he "haven't thought too deeply on it" beyond the common case. In post #10 (January 29), chunter laid out the proposal's central tradeoff explicitly: trading arbitrary validation-code execution for fixed account configurations eliminates wasted, unpaid computation and keeps inclusion checks fast, at the cost of custom recovery logic; he argued this was acceptable because the large majority of wallets rely on single-key verification (secp256k1, P-256, WebAuthn, BLS), and existing ERC-4337 accounts could migrate by registering keys with a precompile rather than being locked out.
The original PR #11186 submission used terminology and structure that would not survive the next month of review: "keys" (not actors) identified by "keyId," "verifiers" (not authenticators) performing checks via IAuthVerifier.verify(), two separate transaction fields for account mutation (account_initialization and key_changes), no scope/permission model at all (any authorized key had full authority), and a Transaction Context delivered through EIP-1153 transient storage directly on the Account Configuration contract. AA_TX_TYPE and AA_PAYER_TYPE were both TBD placeholders. Every one of these choices was revised within the next several PRs, covered in Phase 2.
Phase 2: The First Structural Rewrite — Scope, Owners, and the Payer Precompile (March 2026)
March 2026 saw the single densest run of structural change in the spec's history, all authored by chunter within an eleven-day window.
Unifying account mutation and introducing Account Lock (PR #11367, merged March 3). The original submission's two separate mutation fields, account_initialization for new accounts and key_changes for portable key-change operations, collapsed into one typed account_changes array with entry types for create, account/policy change, and key change. This PR also introduced Account Lock for the first time: an account could freeze its own key configuration, rejecting all modification paths while locked, and added an ERC-1271 isValidSignature fallback authorization path so already-deployed wallets without registered keys could still authorize account changes during migration. This is the largest restructuring PR before the terminology renames began, and it established the "unified typed entry list" pattern that every later account-mutation section builds on.
"Keys" become "owners" (PR #11380, merged March 6, "Simplify for initial EIP"). key_config became owner_config, keyId became ownerId, and on-chain public-key storage was dropped entirely: verifiers began resolving the public key from calldata at signing time rather than reading it from storage. The stated motivation was simplifying the MVP and reframing these entities as generic authority-holders rather than raw cryptographic keys, since a delegate- or verifier-routed entry doesn't literally hold "a key" the way a secp256k1 owner does.
The first scope model and the payer precompile (PR #11388, merged March 9, "Enable permissionless payer"). This PR did two things at once: it renamed IAuthVerifier to IVerifier (dropping a redundant prefix), and, more consequentially, introduced the first permission bitmask: 0x01 SIGNATURE, 0x02 SENDER, 0x04 PAYER, 0x08 CONFIG, with scope == 0x00 meaning unrestricted. The rationale quoted directly in the spec diff makes the motivation explicit: "Without scope, all owners have equal authority... This is insufficient when accounts have owners serving different roles, like for example running a payer for ERC-20 tokens." The same PR replaced the EIP-1153-transient-storage-based Transaction Context with a dedicated Transaction Context precompile, dropping the EIP-1153 requirement from the frontmatter. Both changes came from the same underlying pressure: a single flat authority model couldn't support a permissionless-payer use case where a payer key should be able to fund gas without also being able to rewrite the account's configuration.
Smaller PRs in the same window (#11372 motivation wording, #11374 verifier gas and cross-chain signature tweaks, #11378 removing hardcoded storage-slot derivation formulas from the normative text, #11382 K1/ECDSA behavior clarifications, #11428 account-config interface cleanup) rounded out the month, mostly following on from the owners rename and scope model rather than introducing new debate.
Phase 3: Nonce Rework and the First Security Fix (April 2026)
Nonce-free mode and EOA revocation cleanup (PR #11478, merged April 2, "Eip 8130 nonce and EOA delegation changes"). The original two-dimensional nonce design (a separate nonce_key/nonce_sequence pair) was repacked into a single nonce field, and a genuinely new capability was added: nonce-free mode, selected via the NONCE_KEY_MAX sentinel, letting a transaction skip nonce reads entirely and rely on expiry alone for replay protection. This PR also tightened the implicit-EOA-owner revocation model, moving from an ambiguous "empty slot = authorized" convention toward an explicit revocation marker that distinguishes "revoked" from "never touched," and added the ECRECOVER_VERIFIER sentinel constant to formalize native ecrecover as a registrable verifier type in its own right. The nonce-free mode introduced here would not get hardened replay protection until replay_id shipped two months later (PR #11752, Phase 4).
requires: 7702 was dropped in PR #11492 (April 14, "Fix sentinel addresses"), meaning EIP-8130 no longer formally depended on EIP-7702, though EOA-delegation interoperability with 7702 remained part of the informal design discussion.
First externally-reported security fix (PR #11591, merged May 4). Community contributor pochenai flagged and fixed a real cross-sender payer signature replay issue: a payer authorization was not properly bound to the resolved sender, meaning the same payer signature could potentially be reused across different senders. This is the first PR in the spec's history authored by someone other than chunter, and it set a pattern, followed twice more later in the year (PRs #11609 and #11612), of external contributors surfacing concrete authorization and replay gaps that chunter's own review cycle had not caught.
Phase 4: Canonical Sets, Field Renames, and a Contested Security PR (May – Early June 2026)
Canonical verifier set (PR #11647, merged May 11). For the first time, the spec formalized a node-conformance baseline: nodes MUST accept a baseline set of well-known verifiers deployed at deterministic CREATE2 addresses, maintained in a companion ERC, and MAY extend with non-canonical ones. This moved the spec away from an implicit "whatever the node feels like allowlisting" model toward an explicit, extensible baseline, and directly set up the later verifier-to-authenticator terminology fight (Phase 5), since a canonical set needed a settled name for the thing being canonicalized. PR #11651 (May 12) tightened the MUST/MAY language immediately following, and #11654 (May 12) updated gas and verifier validation details in the same vein.
from becomes sender (PR #11526, merged May 11). The top-level transaction field from was renamed sender throughout, disambiguating it from the EVM/JSON-RPC notion of from, which for an AA transaction is not necessarily the literal envelope signer in the way it is for a legacy transaction. The rename cascaded through every field reference in the validation, signature-payload, and gas-cost sections.
A partially-accepted, partially-rejected security PR (PR #11612, opened May 7, closed May 14). pochenai raised four claimed authorization and replay vulnerabilities in a single PR: (C1) the implicit-EOA rule was scoped too loosely, since any verifier returning bytes32(bytes20(from)) could pass; (C2) the payer hash didn't bind the sender's verifier choice; (C3) multichain owner changes had no expiry, making them replayable on any future chain that deploys the Account Configuration contract; (C4) there was no auto-revocation of the implicit EOA owner on first delegation, leaving a permanent backdoor around delegated-wallet logic. chunter's response split cleanly: C1 and C2 were agreed and folded into PR #11654. C3 and C4 were explicitly rejected with stated reasoning. On C3: "It is intentional that there is no expiration. Multi-chain changes are meant for full owners, local changes can be used for any per chain policies and give an instant expiration when applied." On C4: "We do not want to auto revoke the EOA key when the account is delegated to as it would disable using the EOA. The account code is decoupled from its accepted verifier list, it shouldn't matter if its delegated to or not." pochenai closed the PR after acknowledging the two rejections made sense, noting the accepted half was "well addressed" elsewhere. This exchange is the clearest example in the spec's history of the author drawing an explicit line between what he considered a real bug versus an intentional design tradeoff being second-guessed.
Constants finally pinned, and a nonce-free dedup mechanism (PRs #11757 and #11752, both merged June 2). After more than three months of TBD placeholders, AA_TX_TYPE and AA_PAYER_TYPE were assigned concrete byte values, 0x7B and 0x7C. The same day, PR #11752 defined replay_id = keccak256(resolved_sender || sender_signature_hash) for nonce-free-mode deduplication, deliberately excluding the authentication blobs from the hash so that fee-bumped or re-signed variants of the same logical transaction collapse to a single mempool slot rather than being treated as distinct transactions. This directly hardened the nonce-free mode introduced back in PR #11478 (Phase 3), closing the gap between "nonce-free mode exists" and "nonce-free mode has real replay protection."
EIP-170 code-size guard (PR #11609, merged June 2 after roughly four weeks of review). pochenai's create-entry guard PR converged, through review exchange with chunter, on matching CREATE2 freshness semantics exactly (code_size(from)==0 && nonce(from)==0), with chunter arguing a separate "owner_config emptiness" check the PR originally proposed was unnecessary once the code-size and nonce checks were in place. requires: 170 (EIP-170 max code size) was added as a result, closing out the review with chunter's own comment: "Agree on enforcing the EIP-170 max code size."
Phase 5: The Actor Rename and the Policy Model (June 4 – June 10, 2026)
"Owners" become "actors" (PR #11764, merged June 4, "rename owners to actors and finalize Transaction Context naming"). The spec's second major terminology overhaul renamed ownerId to actorId, owner_config to actor_config, and the associated structs and functions (authorizeOwner/revokeOwner to authorizeActor/revokeActor, applySignedOwnerChanges to applySignedActorChanges). The PR body gives 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 rename was a direct consequence of the scope model introduced back in PR #11388: once an authorized entry could hold a narrow permission like PAYER-only, calling it an "owner" was misleading. The same PR finalized the Transaction Context precompile's getter naming (ITxContext to ITransactionContext), and a same-day follow-up (PR #11765) renamed IAccountConfiguration.verify to verifyActor to disambiguate it from IVerifier.verify, which returns a different kind of value.
Actor call policies, landed on the second attempt (PR #11766, merged June 4). The policyType/policyTarget/manager-gated call-initiation feature, which restricts a scoped actor to calling a single designated contract, first appeared as draft PR #11648 (opened May 11). That PR was closed June 4 after becoming, per its own successor's description, "unmergeable due to some eth-bot bug," and was replaced by a clean rebase in #11766 the same day. This was a mechanical rebase-and-resubmit rather than a substantive rejection; the design itself carried over unchanged. A related PR, #11758 (opened June 2, closed June 4), had separately proposed trimming the Transaction Context precompile down to three identity-only getters, arguing the removed getters' only historical consumers, stateful payer verifiers, were superseded by the new policy managers. PR #11764 (merged the same week) kept #11758's naming conventions but explicitly reversed its removals, retaining the full interface.
"Verifier" becomes "authenticator" (PR #11785, merged June 9, "Rename verifier -> authenticator"). The third and final major terminology overhaul renamed IVerifier to IAuthenticator, verify() to authenticate(), and the "Canonical Verifier Set" (introduced in PR #11647, Phase 4) to the "Canonical Authenticator Set." The diff's own prose captures the semantic distinction driving the change: the authenticator "authenticates the actor (it returns the actor's actorId); scope and policy then authorize what that authenticated actor may do," disambiguating the identity-resolution step from the permission-checking step, which the word "verify" had conflated. A one-day-later follow-up (PR #11794, June 10) expanded authenticateActor's return signature from a bare scope byte to (scope, policyType, policyTarget), letting a single call surface the full authorization gate to callers like ERC-4337 UserOp validators.
By the end of Phase 5, the spec had gone through three complete renaming passes in roughly three months: keys to owners (March), owners to actors (June), and verifiers to authenticators (June). Each rename tracked a real semantic shift, from unscoped key-holders, to scoped-but-uniformly-authorized actors, to actors whose authentication and authorization were now cleanly separated concerns.
Phase 6: Metadata, Replay Hardening, and the Quantum-Safe Default (June 15 – June 18, 2026)
Metadata field resolution (PR #11805, merged June 15). This closed out a month-long design debate between two competing drafts: PR #11578 ("add opaque_input bytes field," opened April 29 by pochenai, never merged) proposed a dedicated top-level field mirroring the legacy input field's attribution role; PR #11655 ("Add metadata sink," opened May 12 by chunter, explicitly marked "DO NOT MERGE, just for discussion") proposed instead representing wallet attribution data as a protocol-recognized no-op call composing with the existing calls array. PR #11805 shipped a third design: a standalone opaque, signed metadata transaction field, restoring the tx-level annotation role that legacy input played (for example ERC-8021-style attribution suffixes) without polluting EVM calldata dispatch. #11655 was closed once this shipped; #11578 remains open as of this writing, effectively superseded in spirit but not formally reconciled with the shipped design (see Active/Open PRs in Merged Changes).
Delegate-authenticator payer-hash binding (PR #11808, merged June 16). This closed a genuine cross-account replay hole: the payer signature hash did not previously bind the payer field itself, so a delegate authenticator, which authorizes one key across many accounts, could have its vouching signature redirected across accounts by swapping the payer field. The fix mirrored the existing sender-side binding that already protected against the analogous sender-side issue.
Folding EOA revocation into a state flag, and a quantum-safe default (PR #11815, merged June 18, "fold default-EOA revocation into a state flag"). The REVOKED_AUTHENTICATOR magic-address sentinel trick was removed entirely and replaced with a single DEFAULT_EOA_REVOKED bit packed into the existing account-state slot. ECRECOVER_AUTHENTICATOR was renamed K1_AUTHENTICATOR, unifying the implicit-default and explicitly-registered secp256k1 paths under one identity. The most consequential change in this PR, though, was a default flip: createAccount and importAccount now revoke the implicit EOA owner by default, framed explicitly as a "quantum-resistant default," meaning a freshly created or imported account no longer leaves a live secp256k1 owner in place unless one is explicitly listed in initial_actors. A same-arc follow-up (PR #11816, also June 18) moved the default-EOA's secp256k1 scope and expiry inline into the packed account-state slot itself, so the account's own key resolves in a single storage read instead of two.
Rounding out this window: PR #11809 (June 16) relaxed a delegate-import restriction, PR #11812 (June 17) fixed an intrinsic-gas under-accounting bug where create-entry actor registration had previously been free, and PR #11813 (June 17) clarified that the intrinsic-gas schedule is a recommended reference rather than a protocol constant, leaving room for future EVM repricing.
Phase 7: The Celo Migration Question and the Transaction-Type Collision (June – July 2026)
This phase runs two threads in parallel: a forum discussion about migrating an existing production account-abstraction system onto EIP-8130, and the spec-side scope-grant redesign that was landing at the same time.
The Celo CIP-64 migration discussion (posts #12-22, June 5 – July 8). karlb opened the thread (post #12, June 5) proposing that letting a chain set a default verifier at the protocol level "could make it easier to migrate from a previous account abstraction system (e.g. Celo's CIP-64) without modifying the state of all user accounts," avoiding a requirement that every existing account write an on-chain configuration entry just to keep working post-migration. chunter followed up (post #13, June 8) asking whether CIP-64 signs over non-standard fields alongside ordinary secp256k1, and whether karlb wanted to preserve CIP-64's native feeCurrency token-payment feature or move that flow onto EIP-8130 natively.
karlb laid out two migration options (posts #15-16, June 8). Option 1: a fully backward-compatible bridge where wallets keep signing CIP-64 exactly as today (tx type 0x7b), an RPC shim repackages each CIP-64 transaction as an EIP-8130 transaction, and a CIP64Verifier contract validates the original CIP-64 signature by reconstructing its hash and calling ecrecover inside the EIP-8130 authentication framework, with the fee paid as a phase-0 transfer in the designated fee currency; this requires a chain-level default verifier so existing users don't each need to write an owner_config entry. Option 2 (post #18, June 9): wallets transition to signing native EIP-8130 transactions directly, with fee abstraction handled via a two-phase call structure, a phase-0 transfer(payer, maxFeeAmount) on the fee token followed by the user's actual call, and the sequencer acting as payer, periodically swapping accumulated fee-token back to native to top up its float. karlb characterized Option 2 as "the cleaner option in the long run" but noted migration would be slower, since every wallet needs to add support for it.
chunter proposed a middle path (post #19, June 29): wallets keep signing existing CIP-64 transactions unchanged, an authenticator verifies signatures against a hash computed from the CIP-64 preimage, and an RPC layer performs a deterministic, lossless conversion into EIP-8130 transactions, with feeCurrency mapped through metadata or a separate call phase; at a future hardfork, tx type 0x7b would become native EIP-8130 and CIP-64 would survive only as an RPC-ingress compatibility shim before eventual deprecation.
The collision that forced a renumbering (post #20, June 30). karlb identified a concrete deployment conflict: EIP-8130's assigned transaction type, 0x7b (set in PR #11757, Phase 4), collided with a transaction type number already in use for CIP-64-related work on the OP Stack, which "will prevent us from adding EIP-8130 support before we phased out CIP-64." karlb requested a different AA_TX_TYPE to let EIP-8130 and CIP-64 deploy in parallel on OP-Stack chains, and noted that detecting wrapped CIP-64 transactions and computing hashes accordingly was a possible intermediate step but not the preferred long-term approach, since he had hoped to avoid execution-client modifications entirely. chunter agreed (post #21, July 6) to explore alternative numbers, noting the practical constraint that a fork for the CIP-64 changes already existed on the OP Stack and would remain present at the execution layer until that fork was deprecated.
Resolution (PR #11903, merged July 8; post #22, July 8). AA_TX_TYPE moved from 0x7B to 0x79, and AA_PAYER_TYPE moved from 0x7C to 0x7A. chunter announced the fix directly on the forum the same day: "We've updated to move it to txn type 0x79 and 0x7a for payer magic byte!" This is a case of a real deployment conflict identified by a downstream chain integrator, not a design-review objection, driving a constant change after the value had already been "finalized" a month earlier in PR #11757. The same PR added an eth_call/eth_estimateGas RPC extension, priced from an unsigned representative authentication blob so gas estimation doesn't require producing or verifying a real signature.
The scope-grant redesign (PR #11918, merged July 13, "Scope grants, PAYER split, operational ERC-1271, account lock"). Landing five days after the renumbering, this is the largest single structural rewrite since the original unification in PR #11367, and the biggest diff of any PR after the original submission. Four changes compose into a coherent redesign of the authority model. First, admin was redefined as a predicate, scope == 0x00, rather than a separate CONFIG grant bit, on the reasoning (given directly in the spec's "Why Admin Is Scope Zero" rationale) that a dedicated config-only bit would be indistinguishable from full access anyway, since any key that can rewrite actor_config can grant itself scope == 0x00, so naming admin as absence-of-restriction makes the self-escalation risk explicit rather than hiding it behind a named permission. Second, scope became five independent grant bits: SENDER, POLICY, NONCE, SELF_PAYER, and SPONSOR_PAYER, with three bits reserved for future pure grants. Third, and most consequential for gas-sponsorship design, the single PAYER bit from PR #11388 split into SELF_PAYER and SPONSOR_PAYER, defined relationally by whether the payer account equals the sender account rather than as an absolute mode; this lets a dedicated gas key fund a sibling key on the same account (SELF_PAYER) while a paymaster's hot key can be sponsor-only over a locked treasury (SPONSOR_PAYER), a materially different security boundary than a single undifferentiated PAYER grant. Fourth, the standalone SIGNER bit was removed entirely: ERC-1271 signing is now reframed as an encoding of operational authority (operational := admin || (SENDER && !POLICY)) rather than a separate grant, on the reasoning that an operational key can already call approve/transfer directly, so letting it also produce a signature grants nothing it didn't already have; a POLICY-gated actor, by contrast, is never operational and must not sign off-gate. The same PR simplified the Account Lock lifecycle to a strict lock-then-unlock sequence with no re-lock or cancel option, moved to a dedicated applySignedLockChanges entry point.
A same-day follow-up, PR #11919 (opened July 13, still open as of this writing), extends #11918's work by adding an optional expiry to initial actors at account-create and account-import time, previously only settable via a post-deployment config change; it commits expiry into the per-actor address-derivation preimage so a front-runner cannot alter it before inclusion.
Where Things Stand
As of July 15, 2026, EIP-8130 carries requires: 170, 2718 and has moved through three complete terminology overhauls (keys to owners, owners to actors, verifier to authenticator), one canonical tx-type renumbering forced by a real-world OP Stack collision, and a scope model that has gone from a single flat authority bit to five independently composable grants. Two PRs remain open: #11578 (the still-unreconciled opaque_input proposal, superseded in spirit by the shipped metadata field) and #11919 (expiry-at-create, a direct extension of the July 13 scope redesign). The Celo CIP-64 migration discussion (Phase 7) has not yet produced a merged spec change beyond the transaction-type renumbering; the question of whether a chain-level default verifier ships to support that migration path remains open on the forum thread as of post #22.
For the mechanical PR-by-PR record, see Merged Changes. For the spec as it stands today, see Current Spec.