diff --git a/protocol/adopt-eip-8130-on-op-stack.md b/protocol/adopt-eip-8130-on-op-stack.md new file mode 100644 index 00000000..83cd65d2 --- /dev/null +++ b/protocol/adopt-eip-8130-on-op-stack.md @@ -0,0 +1,404 @@ +# Adopt EIP-8130 on the OP Stack + +| | | +| ------------------ | -------------------------------------------------- | +| Author | Chris Hunter | +| Created at | 2026-04-13 | +| Initial Reviewers | TBD | +| Need Approval From | TBD | +| Status | Draft | + +## Purpose + +This document proposes adopting [EIP-8130](https://eips.ethereum.org/EIPS/eip-8130) on OP Stack +L2s and identifies the protocol, client, and tooling work required to ship it safely. + +## Summary + +EIP-8130 introduces a new typed transaction and an Account Configuration system that enables +native account abstraction with custom authentication, batching, gas sponsorship, and portable +accounts and owner management. + +We propose that the OP Stack adopt 8130 as an L2 protocol feature in a hardfork. The +implementation should target semantic compatibility with the upstream EIP wherever possible and +should not require any OP Stack-specific divergence, as no EVM changes / opcodes are needed. + +This document is an adoption proposal, not a replacement for the upstream 8130 spec. The EIP +should remain the normative source for exact transaction encoding and execution behavior. + +## Problem Statement + Context + +Existing account abstraction solutions such as ERC-4337 address many UX problems but do so outside +of the base transaction model. That approach requires specialized mempools, bundlers, and +validation of wallet behavior before inclusion. This approach adds latency, cost, and integration burden. + +EIP-8130 offers a native account abstraction standard. Authentication is separated from wallet logic +through verifier contracts and account configuration storage. Transactions explicitly identify the +sender, payer, and authentication path. This gives sequencers and nodes better visibility into +validation cost and opens a path to native support for passkeys, sponsorship, multisig, and new +signature schemes without forcing every validator to simulate arbitrary wallet code during +transaction acceptance. + +Other account abstraction approaches can mitigate some of the same UX problems, but they often do +so with more complex mempool rules and a less uniform model across account types. 8130 instead +provides a standard transaction surface for EOAs, existing smart accounts, and new smart accounts +while keeping validation explicit and comparatively simple. + +That simplicity matters for both nodes and builders. In proposals where validity depends on broader +wallet execution or more dynamic state, ingress may require simulation and tracing just to +determine whether a transaction is admissible, and builders take on more wasted compute and packing +risk when invalidation is harder to track. 8130 aims to directly address these issues while still providing +flexibility. It also gives wallets a clearer standard to target for cross-chain support, and directly +includes features we care about such as 2D nonces, key rotation, and transaction expiration. + +## Proposed Solution + +We propose to adopt EIP-8130 on the OP Stack via a scheduled hardfork and to treat the upstream +EIP as the source of truth for execution semantics. + +### Scope of Adoption + +The OP Stack implementation should include the core 8130 feature set: + +- the new AA transaction type +- the Account Configuration system contract +- the Nonce Manager precompile (if offering 2D or nonceless tx) +- the Transaction Context precompile +- account creation, config changes, and delegation entries in `account_changes` +- payer authorization and sponsored transactions +- call phases and receipt extensions +- protocol-injected logs and RPC extensions described by the EIP + +The goal should be to ship 8130 as an additive feature. Existing EOAs, smart contracts, and +ERC-4337 flows should continue to work. 8130 should provide a native path for wallets that want +protocol-level account abstraction, not require the ecosystem to abandon existing wallet patterns. + +### OP Stack Integration + +Adopting 8130 on the OP Stack requires coordinated work across the protocol and the surrounding +stack: + +- `op-reth` must implement the new transaction type, intrinsic gas accounting, validation flow, + state transition logic, precompile behavior, receipt fields, and protocol-injected logs. +- `op-node`, sequencer transaction ingestion, and batch submission paths must support the new typed + transaction end to end. +- fixed addresses for the Account Configuration contract, Nonce Manager, Transaction Context, + initial verifier set, and default account implementation must be standardized for chains + that opt into the feature. These addresses are TBD until the upstream spec is final. +- SDKs, wallets, explorers, and indexers must be updated to understand the new transaction type, + receipt shape, and RPC extensions. + +The required contract surface should remain limited. Once the final 8130 spec is agreed upon, OP +Stack chains should include the Account Configuration contract and the initial verifier set at +standard addresses. The remaining required functionality is expected to be precompile-based. + +### Spec Dependencies to Pin + +The OP Stack adoption should be conditional on pinning the final upstream EIP values and artifacts +before activation: + +- `AA_TX_TYPE` and payer domain-separation byte +- fixed addresses for the Account Configuration contract, Nonce Manager precompile, Transaction + Context precompile, initial verifier set, and default account implementation +- Account Configuration contract bytecode and storage layout +- canonical verifier bytecode and deployment process +- default account implementation bytecode +- precompile interfaces and gas behavior +- receipt fields and RPC extension shapes + +### Activation, Derivation, and System Transactions + +8130 should activate in a named OP Stack hardfork. The fork name and activation schedule are TBD. +Before activation, the new transaction type must be rejected. After activation, it should be +accepted as a standard [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) typed transaction. + +Because 8130 is an EIP-2718 transaction type, no special derivation rule changes are expected. +Batches should continue to carry opaque transaction bytes, and execution validity should be enforced +by the execution client after activation. `op-node` and the batcher still need compatibility work so +that the new transaction type is accepted, propagated, included, and decoded correctly throughout the +stack. + +Deposit transactions and OP Stack system transactions should not have special 8130 behavior in the +initial adoption. They should continue to use their existing transaction paths. Future upgrades may +choose to leverage 8130 for deposits or system transactions, but that is not part of this proposal. + +### OP Stack Policy + +8130 allows nodes to maintain a verifier allowlist, and the OP Stack should help define a canonical +verifier set as part of the standard. This verifier set should be agreed upon by the client and +chain teams implementing 8130. + +OP Stack chains should agree on which verifiers belong in this canonical set, and chains that claim +conformance with the standard must accept every verifier in the set. This gives wallets and SDKs a +single standard baseline to target across chains. + +Chains may choose to enable additional verifiers beyond the canonical set, but that behavior should +be treated as "out of spec". Wallets and applications should not assume those extensions are +available on other OP Stack chains. + +The OP Stack will adopt the exact 8130 canonical verifier set agreed upon by the teams implementing +the standard. For an initial rollout, the canonical set is planned to be conservative: + +- Secp256k1 +- P256 +- P256 WebAuthn / passkey +- Delegate, enabling a sub-account model + +No other validation paths are considered part of the OP Stack 8130 spec at this time. Additional +canonical verifiers would need to be agreed upon by the teams implementing 8130 and, ideally, +standardized upstream. + +Protocol-native verifier paths are acceptable when their behavior and standard gas costs are defined +at the fork. Delegate should charge an additional SLOAD cost for resolving the delegated owner, plus +the underlying wrapped signature verification cost. Verifier contracts themselves must not be +delegated accounts. + +### Consensus and Mempool Validation Boundary + +The consensus requirements for an included 8130 transaction should be lighter and more mechanical +than the full mempool policy. At minimum, a valid included 8130 transaction means: + +- `sender_auth` was valid at inclusion time +- `payer_auth`, when present, was valid at inclusion time +- the payer had enough ETH to cover the transaction +- the nonce was valid under the chain's supported nonce mode +- `account_changes` were valid +- sender authentication was validated again at the end of the flow + +Other limits should be treated as mempool policy and agreed upon by client teams. Examples include +limits on owner changes, payer authorization complexity, and other transaction shape constraints +that prevent expensive or pathological validation before inclusion. + +The OP Stack may choose whether to support nonceless 8130 transactions. An initial deployment could +also defer nonceless mode if that produces a simpler and safer first fork. + +### Account Semantics Adopted from 8130 + +The OP Stack should explicitly adopt the following EIP semantics: + +- a code-empty EOA that sends its first 8130 transaction is auto-delegated to + `DEFAULT_ACCOUNT_ADDRESS` unless the transaction creates the account or supplies its own + delegation entry +- calls carry no protocol-level ETH value; ETH transfers must be initiated by wallet bytecode +- each call executes with `msg.sender = from`, `tx.origin = from`, and `msg.value = 0` +- calls execute in ordered phases; each phase is atomic, completed phases persist, and later phases + are skipped after a phase failure +- owner scope checks and account lock behavior are consensus-critical +- config changes with `chain_id = 0` are intentionally portable across chains and should be treated + as an audit focus + +Auto-delegation is a significant UX and safety surface. The default account implementation must be +pinned and audited before activation, and wallet UX should make clear when a user's account will be +delegated by sending an 8130 transaction. + +### Delegation and Existing OP Stack Semantics + +8130 reuses the 7702 delegation-indicator model. This means adoption must be checked against existing +OP Stack logic that treats EOAs and contracts differently. + +At minimum, implementation work should explicitly review: + +- address aliasing behavior for delegated accounts +- bridge convenience methods and any EOA-only checks +- assumptions about `tx.origin`, `msg.sender`, and code presence +- tooling that currently treats "has code" and "is a contract" as equivalent + +The expected direction is that OP Stack behavior should remain internally consistent with the +mental model already established for delegated EOAs: a delegated account may have code, but it is +not equivalent to a general smart contract for every protocol decision. + +### Rollout + +Because 8130 touches consensus logic, node policy, and user-facing RPC behavior, it should be +rolled out in stages: + +1. ratify the adoption design and complete a companion FMA +2. choose constants and fixed addresses in coordination with the upstream EIP +3. prototype the feature in `op-reth` +4. validate mempool behavior, tooling compatibility, and verifier policy in devnets +5. complete multiple audit cycles across the EIP, OP Stack implementation, verifier contracts, and + wallet integration flows +6. ship in a named OP Stack hardfork after testnet coverage and async review + +The devnet checklist should include: + +- positive and negative transaction validity vectors for the new EIP-2718 transaction type +- verifier acceptance and rejection behavior for the canonical verifier set +- payer authorization, insufficient-balance, nonce, expiry, and `account_changes` failure cases +- receipt fields, protocol-injected logs, and RPC compatibility +- `eth_getAcceptedVerifiers`, extended `eth_getTransactionCount` with `nonceKey`, receipt `payer`, + and receipt `phaseStatuses` +- mempool policy limits for transaction shape, owner changes, payer authorization, and validation + cost +- auto-delegation to the default account implementation and explicit delegation override behavior +- owner scope checks, account lock behavior, and portable `chain_id = 0` config changes +- phased call execution, including `msg.value = 0`, persisted completed phases, and skipped later + phases after failure +- wallet, SDK, explorer, and indexer integration tests owned by Base for the initial rollout + +Implementation ownership should be made explicit before approval: + +- `op-reth` implementation and consensus tests +- `op-node`, sequencer ingestion, and batcher compatibility +- Account Configuration contract, initial verifier set, precompile behavior, and fixed-address + assignments +- wallet, SDK, explorer, and indexer support +- security review, audit scheduling, and FMA signoff + +### Resource Usage + +8130 increases protocol complexity relative to standard 1559-style transactions. Validation can +include verifier execution, payer authorization, config-change simulation, and nonce-channel +handling. Restricting acceptance to the canonical verifier set keeps these costs bounded and +predictable; unknown or stateful verifier paths are explicitly out of scope for the first rollout +because they would materially increase validation complexity. + +The proposal also increases state usage. Owner configuration consumes one slot per owner, accounts +carry lock state, and nonce state grows per `(account, nonce_key)`. Transaction payloads may be +larger than standard transactions because of `account_changes`, richer signatures, and phased call +data, which increases L2 data footprint. + +These tradeoffs are acceptable if the OP Stack keeps the initial verifier profile conservative and +standardizes enough node policy to avoid pathological validation costs. + +### Single Client and Consensus Considerations + +New OP Stack feature development, including the next Karst hardfork, is expected to happen on +`op-reth` only. `op-geth` remains supported for security patches and critical bug fixes through May +31, 2026, after which support ends. Because 8130 targets new hardfork functionality, the adoption +plan should assume a single execution client implementation in `op-reth`. + +This removes the cross-client divergence risk, but the consensus-critical implementation surface +remains. `op-reth` must implement and test: + +- transaction decoding and signature hashing +- intrinsic gas accounting +- authorization and scope checks +- nonce and expiry behavior +- delegation-indicator semantics +- protocol-injected logs and receipt fields +- RPC behavior for new and extended methods + +The Account Configuration contract bytecode, initial verifier set, storage layout assumptions, +default account implementation, and reserved addresses also become consensus-critical inputs. These +must be pinned carefully before activation and tested against the final `op-reth` implementation. + +There is also an interoperability risk if verifier acceptance policy diverges too much. A +canonical verifier set reduces this risk by giving wallets a guaranteed baseline, but chain-local +extensions can still fragment behavior if applications depend on them. The OP Stack should +therefore treat the canonical set as the in-spec compatibility surface. + +## Failure Mode Analysis + +The companion FMA lives at +[`security/adopt-eip-8130-on-op-stack-fma.md`](../security/adopt-eip-8130-on-op-stack-fma.md) and +should be reviewed alongside this proposal. + +## Impact on Developer Experience + +If adopted, 8130 would give OP Stack developers a native transaction model for: + +- batching +- sponsorship +- passkey and custom-auth wallets +- efficient high-throughput nonce lanes +- portable owner management across chains + +This is a meaningful UX improvement relative to plain EOAs and reduces dependence on bundlers for +many account abstraction use cases. + +At the same time, the change introduces new developer surface area. Wallets, SDKs, explorers, +testing frameworks, and local dev environments will all need support for new encoding, new receipt +fields, new system contracts, and verifier discovery or policy awareness. Base will own wallet, SDK, +and indexer compatibility for its rollout, while additional ecosystem integrations should be +encouraged where possible. + +The migration path is still attractive because 8130 is additive. Existing ERC-4337 wallets can +continue to operate and can migrate incrementally through the onchain import patterns described in +the EIP instead of requiring users to switch to entirely new addresses. + +## Alternatives Considered + +### Continue with EOAs Plus ERC-4337 Only + +This is the lowest-risk protocol option because it avoids a hardfork-level account abstraction +change. However, it keeps key AA features outside the base transaction model and preserves the need +for separate bundler and mempool infrastructure. + +### Design an OP Stack-Specific Account Abstraction Scheme + +This could optimize for rollup-specific requirements, but it would fragment the ecosystem and +duplicate standardization work already happening in 8130. + +### Wait for 8130 to Mature Further Before Adopting + +This reduces the risk of following a moving draft, but it delays native AA support and leaves the +OP Stack dependent on external AA infrastructure for longer. + +### Wait for an L1 Account Abstraction Decision + +The OP Stack could choose to wait for Ethereum L1 to converge on a protocol-level AA direction +before adopting 8130. This is a different consideration from waiting for 8130 alone to mature. It +would avoid committing to an L2-native path before the broader ecosystem decides which base-layer +AA model it prefers. + +This alternative is especially relevant if `EIP-8141` continues to emerge as the front-runner for +L1 AA. Waiting could reduce the risk that the OP Stack adopts a model that later diverges from the +main Ethereum path and would let the stack inherit more of the eventual L1 standardization and +tooling momentum. + +The downside is that this delays native AA on the OP Stack for reasons that may be orthogonal to +L2 needs. It also gives up the opportunity for the OP Stack to move earlier on a design that may +still be valuable even if L1 ultimately chooses a different approach. + +It is also not clear that an eventual L1-first direction such as `EIP-8141` will match OP Stack +requirements as well as 8130. Relative to 8130, this direction appears to require more complex +ingress rules: nodes may need to simulate and trace transactions to determine whether they satisfy +admission rules such as `EIP-7562`, validation may depend on broader dynamic state, and builders +may take on more wasted compute and packing risk when invalidation is harder to track. Those costs +are especially undesirable when the computation is effectively unbilled. + +There are also open questions about whether that direction cleanly supports the feature set the OP +Stack wants. 8130 directly supports 2D nonces, key rotation, expiration, and high-throughput +accounts, while more general models may push important rules into helper contracts or off-protocol +conventions. That can increase divergence across chains and reduce the confidence wallets have in a +standard cross-chain integration path. + +### Adopt Only a Subset of 8130 + +For example, the OP Stack could adopt verifier and account-configuration concepts without adopting +the transaction type. This would shrink the initial scope, but it would also leave much of the UX +benefit on the table and complicate the overall design. + +## Open Decisions Before Approval + +The following decisions should be resolved, or explicitly accepted as TBD, before this proposal is +ready for approval: + +- fork name and activation schedule +- fixed addresses for the Account Configuration contract, precompiles, verifier set, and default + account implementation +- exact canonical verifier bytecode and deployment process +- whether the first OP Stack deployment supports nonceless transactions or defers `NONCE_KEY_MAX` + while supporting standard and user-defined nonce keys +- default account implementation bytecode and wallet UX requirements for auto-delegation +- agreed mempool policy limits for validation cost, owner changes, payer authorization, and + transaction shape +- final RPC extension shapes, including accepted-verifier discovery, 2D nonce queries, and receipt + extensions +- final `op-reth` implementation scope and required consensus test coverage +- audit owners, audit scope, and signoff criteria for each audit cycle + +## Risks & Uncertainties + +- 8130 is still draft and may continue to change upstream. +- The final transaction type, reserved addresses, default wallet bytecode, and canonical verifier + set bytecode and addresses are not yet settled. +- If chains or applications come to depend on verifiers outside the canonical verifier set, wallet + interoperability may still fragment. +- Delegation semantics must be audited carefully anywhere the OP Stack currently distinguishes EOAs + from contracts. +- The change spans consensus logic, node policy, RPC, tooling, and wallet infrastructure, so + rollout coordination is non-trivial. +- Initial deployments may need tighter verifier and nonceless-mode limits than the upstream EIP + theoretically permits. diff --git a/security/adopt-eip-8130-on-op-stack-fma.md b/security/adopt-eip-8130-on-op-stack-fma.md new file mode 100644 index 00000000..5d8a8a5b --- /dev/null +++ b/security/adopt-eip-8130-on-op-stack-fma.md @@ -0,0 +1,189 @@ +# Adopt EIP-8130 on the OP Stack: Failure Modes and Recovery Path Analysis + +| | | +| ------------------ | -------------------------------------------------- | +| Author | Chris Hunter | +| Created at | 2026-04-27 | +| Initial Reviewers | TBD | +| Need Approval From | TBD | +| Status | Draft | + +## Introduction + +This document analyzes failure modes for adopting +[EIP-8130](https://eips.ethereum.org/EIPS/eip-8130) on the OP Stack. The feature introduces a new +EIP-2718 account abstraction transaction type, Account Configuration storage, canonical verifiers, +new precompiles, sponsored transactions, account creation, phased call execution, and new RPC and +receipt surfaces. + +This FMA covers the OP Stack adoption risks. It does not replace the upstream EIP security review or +audits of the Account Configuration contract, default account implementation, or `op-reth` +implementation. + +References: + +- Design doc: [Adopt EIP-8130 on the OP Stack](../protocol/adopt-eip-8130-on-op-stack.md) +- Upstream spec: [EIP-8130](https://eips.ethereum.org/EIPS/eip-8130) +- Generic hardfork FMA: [fma-generic-hardfork.md](./fma-generic-hardfork.md) +- Generic contracts FMA: [fma-generic-contracts.md](./fma-generic-contracts.md) + +## Summary + +| Severity Level | Outcome | Likelihood | Key Mitigations | +| --- | --- | --- | --- | +| High | Invalid block acceptance or consensus implementation bug | Possible | Pin spec artifacts, consensus test vectors, devnets, multiple audits | +| High | Account takeover or stranded accounts | Possible | Audit Account Configuration, owner scopes, default account, and wallet UX | +| Medium | Mempool DoS or sequencer validation overload | Possible | Bounded canonical verifier set, mempool limits, defer nonceless mode | +| Medium | Receipt phase status misinterpreted | Likely | RPC/receipt compatibility testing, Base-owned integration checklist | +| Medium | Cross-chain owner changes misunderstood | Possible | Explicit docs and tests for `chain_id = 0` portability | + +## Failure Modes and Recovery Paths + +### FM1: Consensus Implementation Bug + +- **Description:** `op-reth` incorrectly implements transaction decoding, signature hashing, + intrinsic gas, verifier behavior, account changes, nonce handling, receipt fields, + protocol-injected logs, or precompile behavior. This can produce invalid block acceptance or an + execution rule that must be fixed by client release or hardfork. +- **Risk Assessment:** High severity, possible likelihood. +- **Mitigations:** + - Pin all upstream EIP constants, bytecode, storage layouts, fixed addresses, precompile behavior, + and RPC/receipt shapes before activation. + - Create positive and negative consensus vectors for every transaction path. + - Run devnets with the final `op-reth` implementation. + - Complete multiple audit cycles across spec, `op-reth`, contracts, and wallet flows. +- **Detection:** + - Hive-style tests and fuzzing for transaction parsing and execution. + - Devnet and testnet monitoring for unexpected state roots, receipt roots, logs, or transaction + rejection behavior. +- **Recovery Path(s):** + - Before mainnet activation, fix implementations and regenerate vectors. + - After activation, recovery may require emergency client releases or a hardfork depending on the + bug. + +### FM2: Account Takeover or Stranded Accounts + +- **Description:** Bugs in owner authorization, owner revocation, owner scope, account lock, + auto-delegation, default account bytecode, or wallet UX allow the wrong party to control an + account or prevent the legitimate user from recovering control. +- **Risk Assessment:** High severity, possible likelihood. +- **Mitigations:** + - Audit Account Configuration bytecode, storage layout, owner scope checks, account lock lifecycle, + and default account implementation. + - Make auto-delegation explicit in wallet UX. + - Test implicit EOA owner behavior, revocation, lock/unlock flows, and delegation clearing. + - Treat `chain_id = 0` portable owner changes as an explicit audit focus. +- **Detection:** + - Devnet and testnet scenarios for owner rotation, revocation, lock/unlock, import, and + auto-delegation. + - Indexer checks for owner and delegation events. + - User support and wallet telemetry during testnet rollout. +- **Recovery Path(s):** + - User-level recovery may be possible through configured recovery owners, unlock flows, or + delegation clearing. + - Widespread account-stranding bugs may require wallet releases, contract mitigations, or a + hardfork depending on the root cause. + +### FM3: Mempool DoS or Sequencer Validation Overload + +- **Description:** Attackers submit transactions that are expensive to validate, hard to invalidate, + or cause excessive pre-inclusion work through complex account changes, payer auth, nonceless mode, + or verifier behavior. +- **Risk Assessment:** Medium severity, possible likelihood. +- **Mitigations:** + - Keep the canonical verifier set conservative and bounded. + - Define mempool policy limits for owner changes, payer authorization complexity, transaction + shape, and validation cost. + - Defer `NONCE_KEY_MAX` nonceless mode unless client teams agree it is ready. + - If nonceless mode is enabled, require short expiry windows and duplicate-hash exclusion by + builders. +- **Detection:** + - Sequencer validation latency and rejection-rate metrics. + - Devnet load tests with invalid transactions and adversarial transaction shapes. + - Mempool profiling for verifier and account-change costs. +- **Recovery Path(s):** + - Tighten mempool policy and release updated node software. + - Tighten or defer nonceless mode where policy permits. + +### FM4: Receipt Phase Status Misinterpreted + +- **Description:** Wallets, SDKs, explorers, indexers, and testing frameworks mishandle the new + receipt status model. 8130 receipts can include `phaseStatuses`, so tools cannot treat the receipt + as only a single success/failure value when displaying or indexing phased transactions. +- **Risk Assessment:** Medium severity, likely likelihood. +- **Mitigations:** + - Base owns wallet, SDK, and indexer compatibility for its rollout. + - Include receipt `status` and `phaseStatuses` in compatibility tests. + - Document how completed phases can persist even when a later phase fails. +- **Detection:** + - Devnet integration tests across wallets, SDKs, explorers, indexers, and local dev tooling. + - Testnet monitoring for malformed transaction displays and incorrect phase-status indexing. +- **Recovery Path(s):** + - Release tooling and SDK fixes before mainnet activation. + - If compatibility gaps are severe, delay activation until critical integrations are ready. + +### FM5: Cross-Chain Owner Changes Misunderstood + +- **Description:** Config changes with `chain_id = 0` are intentionally portable across chains. If + wallets, users, or operators treat these as chain-local changes, owner updates may apply more + broadly than expected. +- **Risk Assessment:** Medium severity, possible likelihood. +- **Mitigations:** + - Document portable owner changes clearly in wallet and developer guidance. + - Test both `chain_id = 0` and chain-specific config changes. + - Require wallet UX to distinguish portable owner changes from chain-local owner changes. +- **Detection:** + - Devnet tests that apply portable owner changes across multiple chains. + - Indexer checks that surface whether config changes are portable or chain-specific. +- **Recovery Path(s):** + - Users can apply follow-up owner changes to restore intended owner configuration. + - Widespread UX issues should block mainnet rollout until wallet behavior is fixed. + +## Action Items + +Below is what needs to be done before launch to reduce the chance of the above failure modes and to +ensure they can be detected and recovered from: + +- [ ] Resolve all comments on this FMA and incorporate them into the document. +- [ ] Pin final EIP constants, fixed addresses, bytecode artifacts, storage layouts, precompile + behavior, RPC shapes, and receipt fields. +- [ ] Decide whether the first OP Stack rollout supports or defers `NONCE_KEY_MAX` nonceless mode. +- [ ] Define mempool policy limits for validation cost, owner changes, payer authorization, and + transaction shape. +- [ ] Produce consensus, RPC, receipt, account-change, and nonce test vectors. +- [ ] Run devnets with wallet, SDK, explorer, indexer, sequencer, batcher, and `op-reth` + compatibility tests. +- [ ] Complete multiple audit cycles covering the upstream EIP, OP Stack implementation, Account + Configuration contract, default account implementation, and wallet flows. +- [ ] Assign owners for monitoring, incident response, and launch readiness signoff. + +## Audit Requirements + +This feature should require multiple audits. It changes consensus behavior, introduces new account +authorization paths, adds precompile behavior, depends on consensus-critical contract bytecode and +storage layout, and creates new wallet flows that can affect user funds. + +Audit scope should include: + +- upstream EIP semantics and specification completeness +- `op-reth` implementation and consensus tests +- Account Configuration contract and storage layout +- default account implementation and auto-delegation behavior +- wallet and SDK integration flows +- RPC, receipt phase status, and protocol-injected log compatibility + +## Appendix + +### Appendix A: Initial Rollout Assumptions + +The current adoption proposal assumes: + +- 8130 activates in a named OP Stack hardfork. +- Deposit transactions and OP Stack system transactions do not receive special 8130 behavior in the + first rollout. +- The canonical verifier set is limited to Secp256k1, P256, P256 WebAuthn/passkey, and Delegate. +- Unknown or stateful verifier acceptance is outside the OP Stack 8130 conformance surface for the + first rollout. +- Delegated-account behavior should match the delegated-EOA model already established for EIP-7702. +- Standard and user-defined nonce keys are supported; `NONCE_KEY_MAX` may be deferred. +- Wallet, SDK, and indexer compatibility for the Base rollout is owned by Base.