Scope: the site's 365 daily reports from 2025-11-12 to 2026-11-11 and the original sources they cite; the current status of each standard was also checked on 2026-11-11 (UTC+7) against the ethereum/EIPs and ethereum/ERCs repositories and the Hegotá meta EIP (EIP-8081). After each claim, the brackets link first to that day's report on this site and then to the original source; links marked "checked" are original pages read directly on 2026-11-11. Status labels: live means activated on Ethereum mainnet, or a Final standard already used by wallets and contracts; Scheduled for Inclusion (SFI) means scheduled for an upgrade, final form not settled; candidate (CFI) means Considered for Inclusion, in an upgrade's scope but still subject to change; proposed means Draft, PFI, or an unmerged PR; rejected means DFI or turned down on a call; withdrawn means Withdrawn. Items marked "our recommendation" are a judgment drawn from the sources, not a decision by any team.
Key takeaways
- You can assemble most features today, but you must choose between keeping your address and being able to rotate the root key.EIP-7702 lets an EOA run contract code and went live with Pectra (daily 2026-02-18 · source); ERC-4337 became Final on 2026-06-02 (daily 2026-06-02 · source); ERC-7913 became Final on 2025-12-16 (daily 2025-12-16 · source). But after a 7702 delegation the original ECDSA key keeps full control (daily 2026-04-10 · source), and EIP-7851, which would switch it off, was declined for Hegotá (daily 2026-09-15 · source). So today, rotating the root key or moving to post-quantum signatures means deploying a smart account at a new address (Path A2 below).
- L1 native AA is Scheduled for Inclusion as EIP-8141 frame transactions, final form not settled.On 2026-08-27 EIP-8141 became SFI for Hegotá, with a note that the implementation, including the EIP number, may still change (daily 2026-08-27 · source); ACDE #245 on 2026-09-10 made it Hegotá's execution-layer headliner (daily 2026-09-10 · source) (checked 2026-11-11: Ethereal news #39); the consensus-layer headliner is FOCIL (daily 2026-04-10 · source). Base says it will ship EIP-8130 on L2 (daily 2026-08-21 · source); 8130 has been narrowed to the Keystore only (daily 2026-10-08 · source), and the split-out transaction type is proposed in PR #12385, still unmerged as of 2026-11-11. The number "EIP-8430" so far comes from the discussion thread and an Ethereal news roundup, not from a merged EIP (daily 2026-09-29 · source) (daily 2026-10-08 · source).
- Privacy follows "the protocol provides primitives, apps build privacy".EIP-8250 keyed nonces, EIP-8272 recent roots and EIP-7906 transaction assertions became Hegotá candidates (CFI) on 2026-09-24 (daily 2026-09-24 · source), while EIP-8182, in-protocol private transfers, was declined at ACDE #245 and recorded in the meta EIP on 2026-09-15 (daily 2026-09-15 · source).
- The year's biggest account security incident came down to authorization paths, not cryptography. The Binance incident on 2026-10-29 affected about $6.3B (daily 2026-10-30 · source). The preliminary report says that once the attacker controlled the signing service, it took 50 transactions to set up a malicious 7702 delegation, and revoking it took longer because the wallets used MPC (daily 2026-11-03 · source). lightclient, one of the 7702 authors, called 7702 "just an accelerant for an existing attack" (daily 2026-11-03 · source).
- Post-quantum support only goes as far as "swappable and aggregatable"; no scheme is chosen.EIP-8141 moved signatures into a separate list, leaving room for future aggregation including post-quantum signatures, merged 2026-05-22 (daily 2026-05-22 · source); EIP-8288 (post-quantum signature and STARK aggregation frames) was merged as Draft on 2026-09-09 (daily 2026-09-09 · source), and EIP-8425 (quantum freeze and account recovery) as Draft on 2026-10-24 (daily 2026-10-24 · source); PR #12616, adding lean SPHINCS hash signatures to 8141, was opened on 2026-11-04 and is unmerged as of 11-11 (daily 2026-11-04 · source).
1. The key features
The table lists what an ideal account should be able to do, the standards behind each capability in our sources, and where they stand. Capabilities that never came up in the sources are left out.
| Capability | What the ideal account does | Standards | Status (date) |
|---|---|---|---|
| Native AA and programmable validation | Account code decides validation, payment and execution, with no off-chain bundler | EIP-8141; in the meantime ERC-4337 (with ERC-7562 validation rules) and EIP-7702 | 8141 SFI, made the execution-layer headliner on 2026-09-10, final form not settled; 4337 Final (2026-06-02); 7702 live (daily 2026-09-10 · source) (checked 2026-11-11: Ethereal news #39); ERC-7562 in Review (checked 2026-11-11: ERC-7562) |
| Choice of signature algorithm (passkey, P256) | Sign with a passkey in the phone's secure chip; the account understands several algorithms; apps can verify contract-account signatures | EIP-7951 secp256r1 precompile, ERC-7913, ERC-1271, EIP-7932 | 7951 is part of Fusaka, which activated on mainnet on 2025-12-04 (daily 2025-11-24 · source); 7913 Final; ERC-1271 Final (checked 2026-11-11: ERC-1271); EIP-7932 and EIP-8030 P256 transactions were declined for Glamsterdam on 2025-12-04 (daily 2025-12-04 · source) |
| Key rotation and recovery | Change keys without changing address; recover by preset rules after a loss | A deployed smart account (such as Safe); EIP-8130 Keystore, ERC-8403, ERC-8231 | A deployed smart account can rotate owners today (daily 2026-04-01 · source); a 7702 EOA cannot rotate its root key (see Path A1); 8130, 8403 and 8231 proposed (daily 2026-10-08 · source) (daily 2026-09-03 · source) |
| Post-quantum migration | Switch to post-quantum signatures and disable the old ECDSA key | EIP-8141 signature list, EIP-8288, EIP-8425, EIP-8151, EIP-8298 | Signature list in the 8141 spec (2026-05-22); 8288 and 8425 Draft; 7851 rejected (daily 2026-09-15 · source); 8151 and 8298 became Hegotá candidates (CFI) on 2026-10-08 (daily 2026-10-08 · source) |
| Gas sponsorship and ERC-20 fees | A third party or a token pays gas; the user needs no ETH | ERC-4337 paymaster, EIP-8141 payer, payer in the AA transaction type split from EIP-8130 | 4337 Final; 8141 SFI, and the payer can approve before the sender (merged 2026-04-29) (daily 2026-04-29 · source); the split-out transaction type is still the unmerged PR #12385 (daily 2026-09-29 · source) |
| Batching and parallel nonces | One transaction runs several steps atomically; transactions do not block each other | EIP-5792 wallet_sendCalls, EIP-8141 atomic batches, EIP-8250 keyed nonces | EIP-5792 Final (checked 2026-11-11: EIP-5792); 8141 batching merged into the spec on 2026-05-13; 8250 candidate (2026-09-24) (daily 2026-05-13 · source) (daily 2026-09-24 · source) |
| Private transfers and stealth addresses | Receive without exposing the main address; withdraw privately without a relayer | ERC-5564, ERC-6538, ERC-8441, EIP-8272 | 8441 merged as a draft (2026-10-29); 8272 is a candidate (daily 2026-10-29 · source) |
| Cross-chain and cross-L2 | One address format readable across chains; the account itself carries out cross-L2 actions | ERC-7930, ERC-7828, EIL, ERC-7683 | 7930 and 7828 moved to Review (2026-04-28) (daily 2026-04-28 · source); EIL is a research proposal (daily 2025-11-13 · source) |
| Delegation and permissions | Give session keys and agents limited permissions; delegation can be revoked or permanently disabled | EIP-7702, ERC-7579 with ERC-8286, 8130 actor policies, EIP-8476, EIP-8477 | 7702 live; 8286 Draft (2026-07-28); 8476 and 8477 proposed (daily 2026-07-28 · source) (daily 2026-10-30 · source); EIP-7819 SETDELEGATE was declined for Glamsterdam on 2025-12-04 and again declined for Hegotá (daily 2025-12-04 · source) (daily 2026-09-15 · source) |
| Readable signing and transaction assertions | Understand what you sign; revert the whole thing if the result differs | ERC-7730, EIP-7906 | Clear Signing based on ERC-7730 launched on 2026-05-12 (the standard itself is still Draft) (daily 2026-05-12 · source 1 · source 2); 7906 candidate (2026-09-24), a failed assertion reverts the execution part (daily 2026-10-09 · source) |
2. Which standard each component follows, and how they fit together
Architecture diagram
The diagram shows the ideal account's components by layer. Solid boxes are standards that are live, in use, or Scheduled for Inclusion (SFI); dashed boxes are candidates or proposals.
Components and standards
| Component | Standard | What it does | Status and dates |
|---|---|---|---|
| Transaction and account core | EIP-8141 frame transactions | A transaction is a set of frames: a validation prefix (including payer approval) plus an execution body; EOAs can use it through default code | Proposed as headliner candidate 2026-01-29; CFI 2026-03-26; SFI 2026-08-27; execution-layer headliner 2026-09-10; final form not settled (daily 2026-03-26 · source) (daily 2026-03-10 · source) (daily 2026-10-09 · source) |
| ERC-4337 and ERC-7562 | Contract-level AA: EntryPoint, bundlers, paymasters; 7562 sets the validation rules for the bundler mempool | 4337 Final, 2026-06-02 (daily 2026-06-02 · source); 7562 in Review, and a 2026-10-12 PR proposes banning SETCODEFROM during validation (daily 2026-10-12 · source) | |
| EIP-7702 | An EOA delegates to contract code with a single signature | Live (Pectra, 2025) (daily 2026-02-18 · source) | |
| EIP-8130 and the split-out transaction type | 8130 keeps only the Keystore; the transaction type moves to a new EIP (called EIP-8430 in discussion), giving existing EOAs batching, sponsorship and 2D nonces, possibly first on L2 | 8130 proposed, narrowed 2026-10-08 (daily 2026-10-08 · source); the new type's PR #12385 is unmerged as of 2026-11-11 and the number is not yet in the repository (daily 2026-09-29 · source) (daily 2026-09-30 · source) | |
| Validation and signatures | EIP-7951 | A secp256r1 (P256) precompile, the curve passkeys use | Activated with Fusaka on 2025-12-04 (daily 2025-11-24 · source) |
| ERC-7913 | Verifies public keys that have no Ethereum address | Final, 2025-12-16 (daily 2025-12-16 · source) | |
| EIP-7932 | A protocol-level registry of signature algorithms; it dropped its own transaction wrapper on 2025-12-03 | Proposed; kept out of Glamsterdam on 2025-12-04 (daily 2025-12-03 · source) | |
| 8141 signature rules | The P256 path requires low-s signatures to rule out malleability | Merged into the spec on 2026-07-22 (daily 2026-07-22 · source) | |
| Parallelism | EIP-8250 | One sender can have several independent nonce sequences, so privacy protocols can share a sender; single-use keys can act as nullifiers | Merged as Draft 2026-05-12 (daily 2026-05-12 · source); CFI 2026-09-24; PR #12467 for single-use spent flags was closed unmerged on 2026-10-23 (checked 2026-11-11: PR #12467); instead single-use keys are marked with MAX_NONCE_SEQ (#12511, merged 10-16) (daily 2026-10-15 · source) and exempted from data pricing (#12534, merged 10-19) (daily 2026-10-19 · source) |
| Permissions, modules and recovery | ERC-7579 and ERC-8286 | Modular accounts; 8286 defines how 7579 modules validate inside frame transactions | 8286 is a draft, 2026-07-28 (daily 2026-07-28 · source) |
| EIP-8130 actor policies | Limit what a key can call and when it expires, a basis for session keys | Proposed (daily 2026-06-04 · source) (daily 2026-07-02 · source) | |
| ERC-8403, ERC-8231 | The lifecycle of an account's authorities; registering, rotating and revoking post-quantum public keys | Under discussion (daily 2026-09-03 · source) (daily 2026-04-14 · source) | |
| Delegation safety | EIP-8476 | Lets an EOA switch off 7702 delegation permanently | Proposed, 2026-10-30 (daily 2026-10-30 · source) |
| EIP-8477 | Authorizations must anchor to one of the last 256 blocks, so signed but unused ones expire | Proposed in PR #12601 on 2026-10-30 (daily 2026-10-30 · source) (daily 2026-11-04 · source) | |
| EIP-7851 | Let the delegated wallet code disable the original ECDSA key | PFI 2026-06-09; rejected (DFI) for Hegotá (daily 2026-06-09 · source) (daily 2026-09-15 · source) | |
| EIP-8151, EIP-8298 | 8151: once an account has regular code (not a 7702 delegation indicator), ecRecover no longer returns its address, so the old key can no longer sign permit-style approvals; 8298: an account adopts the code of a deployed contract, from an idea combining the goals of 7851 and 8058 | Both Hegotá candidates (CFI), 2026-10-08 (daily 2026-10-08 · source) (daily 2026-06-12 · source) (checked 2026-11-11: EIP-8151) | |
| Post-quantum | EIP-8288 | Post-quantum signatures and STARKs become transaction dependencies, aggregated in the mempool into one recursive proof | Submitted 2026-06-06, merged as Draft 2026-09-09 (daily 2026-06-06 · source) (daily 2026-09-09 · source) |
| EIP-8425 | Freezes legacy ECDSA authorization and recovers accounts that never migrated | Draft, merged 2026-10-24 (daily 2026-10-24 · source) | |
| Privacy | EIP-8272 | Lets a transaction reference a recent state root, one prerequisite for privacy pool withdrawals | Merged as a draft 2026-06-06; CFI 2026-09-24 (daily 2026-06-06 · source) |
| ERC-5564, ERC-6538, ERC-8441 | Stealth addresses; 8441 mixes ML-KEM-768 with secp256k1 ECDH so future quantum computers cannot unmask recipients | 5564 and 6538 Final (checked 2026-11-11: ERC-5564) (checked 2026-11-11: ERC-6538); 8441 Draft, 2026-10-29 (daily 2026-10-29 · source) | |
| EIP-8182 | In-protocol private ETH and ERC-20 transfers | Rejected (DFI) for Hegotá, recorded in the meta EIP on 2026-09-15 (daily 2026-03-04 · source) (daily 2026-09-15 · source) | |
| FOCIL (EIP-7805) | Inclusion lists force inclusion, so private transactions are harder to censor | Hegotá consensus-layer headliner, SFI (daily 2026-04-10 · source) (checked 2026-11-11: EIP-8081) | |
| Interaction and cross-chain | EIP-7906 | A transaction asserts its state changes and reverts if they do not match | CFI, 2026-09-24 (daily 2026-09-24 · source) |
| ERC-7930, ERC-7828 | Interoperable cross-chain address formats | Review, 2026-04-28 (daily 2026-04-28 · source) |
Putting it together
Path A1: keep the existing EOA address (works today; our recommendation for everyday, small-balance accounts).
- Delegate the EOA with EIP-7702 to an audited ERC-7579 modular account implementation to get batching, sponsorship and a passkey validation module. 7702 is live and 4337 is Final (daily 2026-02-18 · source) (daily 2026-06-02 · source).
- Limit: the root key cannot be rotated. The original ECDSA key always keeps full control (daily 2026-04-10 · source) and can sign a new delegation that replaces any recovery or limit policy written into the account (daily 2026-11-02 · source). EIP-7851, which would disable the original key, was rejected (daily 2026-09-15 · source).
- No post-quantum migration path: for an EOA the key is the account, so migration cannot just swap keys (daily 2026-01-16 · source). EIP-8151 and EIP-8298 are Hegotá candidates; if both ship, a 7702 account could switch to regular code and the old key would stop working with ecRecover. This is our inference from the two specs, not a settled path (daily 2026-10-08 · source) (checked 2026-11-11: EIP-8151).
- Receive through ERC-5564/6538 stealth addresses; kohaku-cli has shown a transfer and its announcement bundled into one 4337 UserOp (daily 2026-08-10 · source).
Path A2: deploy a smart account at a new address (works today; our recommendation for large or long-lived accounts).
- Deploy an ERC-4337 compatible smart account (for example an ERC-7579 modular account or a Safe). Its address differs from the old EOA, so assets have to move.
- The validation module accepts passkeys: P256 is checked on chain through the EIP-7951 precompile, non-address keys through the ERC-7913 interface (daily 2025-12-16 · source), and the account presents contract signatures to apps through ERC-1271 (checked 2026-11-11: ERC-1271). dankrad argues, though, that a passkey is not the same as a hardware wallet built into the phone; it mainly suits quickly created hot wallets (daily 2026-05-31 · source).
- An ERC-4337 paymaster sponsors gas, account code runs batches, and wallets can start them with EIP-5792 wallet_sendCalls (checked 2026-11-11: EIP-5792).
- Rotation and recovery: Safe already offers a path that keeps the Safe address and rotates owners to quantum-resistant hash-based signers (daily 2026-04-01 · source); there is also discussion of guardian-free timelock recovery for 4337/7579 accounts (daily 2026-07-14 · source); post-quantum signatures can be tried inside 4337 contract accounts first, such as the WOTS-39 wallet based on Winternitz one-time signatures (daily 2026-06-05 · source).
Path B: the L1 target after Hegotá (Scheduled for Inclusion plus candidates, final form not settled).
- Switch to EIP-8141 frame transactions: a validation frame calls the account's own validation logic, a payer frame approves the fee, and execution frames batch calls atomically (daily 2026-05-13 · source).
- EIP-8250 keyed nonces let transactions run in parallel and let protocols such as privacy pools share one sender (daily 2026-05-12 · source).
- EIP-8272 lets transactions reference recent state roots. soispoke argues that together with FOCIL, this set gives Ethereum native, trustless, censorship-resistant private transactions in Hegotá (daily 2026-05-26 · source).
- EIP-7906 assertions let a wallet show exactly what a transaction will do, and revert it if the result does not match (daily 2026-11-06 · source 1 · source 2).
- Existing ERC-7579 modules plug into frame transactions through ERC-8286, which keeps migration costs down (daily 2026-07-28 · source).
Path C: L2 first.Base plans to ship EIP-8130 (daily 2026-08-21 · source); the transaction type split from 8130 gives existing EOAs batching, sponsorship and 2D nonces and may land on L2 first, while L1 goes with EIP-8141. Their transaction fields and mempool rules differ, so SDKs need to support both (daily 2026-09-29 · source) (daily 2026-09-30 · source). That transaction type's PR is still unmerged as of 2026-11-11.
3. Security and privacy: what to measure and how
| Dimension | Question to answer | How to evaluate | Evidence from this year |
|---|---|---|---|
| Threat model and authorization paths | Who can make the account act? How many authorization paths are there? | List every party that can authorize (original key, 7702 delegation, Keystore actors, modules, payer) and work through what happens if each is stolen; for a 7702 EOA, check separately what the original key can do by re-delegating | donnoh_eth bypassed a timelock wallet's timelock with EIP-8130 on a Base testnet (daily 2026-08-29 · source); when a key can re-delegate, account-level policy can be swapped out wholesale, and account-level limits do not stop existing transferFrom approvals, so one proposal moves rate limits into the asset (daily 2026-11-02 · source) |
| Key loss and recovery | After a lost or stolen key, how fast can you stop the damage and recover? Can the root key be rotated? | Drill it: how many transactions, signatures and how much time to revoke a delegation, rotate keys, regain control; treat a 7702 EOA (root key not rotatable) separately from a deployed smart account | Binance's report: pausing withdrawals does not invalidate on-chain 7702 authorizations, and MPC has no single key to revoke them at once (daily 2026-11-03 · source); a 7702 EOA's original key keeps full control (daily 2026-04-10 · source) |
| Signature replay | Can a signature be reused on another account, another chain, or at another time? | Check the fields covered by the signature hash: chain ID, sender, payer, nonce, validity window | 8130 payer signatures replayable across senders, fixed 2026-05-04 (daily 2026-05-04 · source); PR #11612 flagged four critical authorization and replay issues (daily 2026-05-07 · source), but it was closed unmerged on 2026-05-14 (checked 2026-11-11: PR #11612), and the sources do not record whether those issues were fixed another way; when a delegation reverts for lack of gas, the signed 7702 authorization can be reused by anyone (INV-8) (daily 2026-11-06 · source) |
| Delegation risk | Does a delegation act as a standing instruction? | Audit what your signing systems can approve; check that post-delegation code and initialization are bound to the signature | Trail of Bits: once an attacker holds a valid signature, the delegation lets them move funds deposited later too (daily 2026-11-07 · source); Köppelmann said 7702 was only used to carry out the attack efficiently and was not the root cause (daily 2026-10-30 · source) |
| Post-quantum | Can an account whose public key is already exposed migrate without changing address? | Check whether the signature scheme can be switched, whether the old ECDSA key can be disabled, and what post-quantum signatures cost in gas and data | Post-quantum signatures can be dozens of times larger than ECDSA, and keeping them in a separate list is what makes later aggregation possible (daily 2026-05-22 · source); the EIP-8425 draft deals with accounts that never migrate (daily 2026-10-24 · source) |
| Privacy leakage | What is exposed: sender, recipient, amount, IP address, the wallet itself? | Go layer by layer: onchain sender, relayers, announcement logs, RPC reads, wallet software | On frame transactions a privacy pool can be the sender and pay its own gas, with no relayer (daily 2026-11-06 · source); binji_x points out that onchain privacy is useless if the wallet itself is compromised (daily 2026-04-05 · source) |
| Gas and usability cost | How much extra gas does each security and privacy feature cost? Is the validation budget large enough? | Measure first transactions, delegations and proof verification under the target fork's rules; expect the numbers to move with draft specs | Measured by the glamsterdam-gas-invariants repository against the draft Amsterdam spec, one 7702 authorization to an empty account rises from 25,000 to 235,606 gas under EIP-8037; these changes are not live, and the Hoodi fork has been postponed (daily 2026-11-06 · source) (daily 2026-10-22 · source). The same batch includes EIP-2780, resource-based intrinsic transaction gas (Last Call on 2026-10-07) (daily 2026-10-07 · source), and a plan to raise the gas limit from 60M to 200M after Glamsterdam (daily 2026-10-18 · source). Validation budget: a privacy pool withdrawal costs about 679,322 gas, and proof verification exceeds the 100k MAX_VERIFY_GAS (daily 2026-11-06 · source); Nethermind's benchmark found 300k workable with a client-side protection, at the cost of the mempool admitting only 12% to 27% of honest frame transactions during an attack (daily 2026-11-07 · source); PR #12644, opened 2026-11-10, proposes 300,000 and is unmerged (daily 2026-11-10 · source) |
| Mempool and censorship resistance | Can transactions safely enter the public mempool without being censored? Do they depend on bundlers? | Check what state validation can read, batching limits, inclusion-list compatibility, and the fallback when bundlers or relayers are offline | 8130 limits validation to known verifiers and world state so mempools can handle it safely (daily 2026-03-06 · source); 8141 allows atomic batches of any frames but bans batching in the public mempool's validation prefix (daily 2026-05-13 · source); without native AA, smart-account transactions go through bundlers or relayers that FOCIL cannot protect, and Vitalik calls FOCIL and AA strongly complementary (daily 2026-02-19 · source) |
| Spec maturity | Is the spec still taking breaking changes? | Track breaking changes in spec PRs and client implementation status | 8141 merged a breaking nonce-boundary fix on 2026-11-01 (daily 2026-11-01 · source); ethrex runs two public testnets, one dedicated to frame transactions (daily 2026-09-11 · source) |
4. Trade-offs and open questions
The main trade-offs
- A general platform or a turnkey account. lightclient argues that half of 8130 is application-layer detail that does not belong in the protocol, and that 8141 leaves room for permissionless innovation (daily 2026-08-22 · source). Ethlabs' weekly update describes 8130 as a turnkey account with strong defaults and 8141 as a platform for accounts (daily 2026-08-31). The cost: 8141 is flexible but leaves wallets to implement validation, while 8130 is easier to integrate but limits the patterns available (daily 2026-08-22 · source).
- Privacy in the protocol, or primitives for apps. 8182 was declined while 8250 and 8272 became candidates (see above), so privacy features will mostly live in apps and wallets.
- Protect the account or protect the asset. If a key can re-delegate, any policy written into the account can be swapped out, which is why some argue for putting rate limits in the asset (daily 2026-11-02 · source).
- 7702's convenience versus its standing risk. One signature upgrades an EOA, and that is just as efficient for an attacker (daily 2026-10-30 · source). EIP-8476 gives institutions a way to opt out of delegation for good, and EIP-8477 makes unused authorizations expire.
- Post-quantum: switch the EOA's scheme directly, or go through a smart account. EIP-8202 lets an EOA pick its signature algorithm with a scheme_id and no smart account, a different route from 8141 and 8164 (daily 2026-04-23 · source).
Still open
- Hegotá mainnet timing: the sources give no date; Ethereal news #39 says it targets 2027 (checked 2026-11-11: Ethereal news #39). Glamsterdam's Hoodi fork was postponed over EIP-8037 contract compatibility, with no new date (daily 2026-10-22 · source), and ACDE #249 on November 19 will discuss the audit results (daily 2026-11-11 · source).
- The final shape of 8141: the SFI decision said the implementation and even the EIP number could change (daily 2026-08-27 · source). Derek Chiang added that SFI only signals Ethereum will ship AA in Hegotá, not that the current text is fixed, and weekly calls are now trying to converge 8141 and 8130 (daily 2026-08-27 · source) (daily 2026-08-28 · source).
- Validation gas limit: Nethermind found 300k workable with a client-side protection (daily 2026-11-07 · source); PR #12644 proposing 300,000 is unmerged (daily 2026-11-10 · source), as is PR #12617, which leaves signature calldata cost out of MAX_VERIFY_GAS (daily 2026-11-04 · source).
- EIP-8298 SETCODEFROM is a Hegotá candidate (CFI) (daily 2026-10-08 · source), but design questions such as cleaning up dangling bytecode are still being discussed (daily 2026-10-07 · source).
- No agreed post-quantum signature scheme: Falcon, ML-DSA and hash-based signatures all have drafts or implementation discussions (daily 2026-04-11 · source) (daily 2026-06-05 · source); PR #12616, adding lean SPHINCS to 8141, is unmerged (daily 2026-11-04 · source).
- Delegation safeguards: EIP-8476 (PR #12600) and EIP-8477 (PR #12601) are both unmerged proposals.
5. What the sources do not cover
- ERC-6900, ERC-7715, ERC-7710 and ERC-7739 never appeared in this year's reports, so we do not assess them.
- ERC-7579 is still Draft in the repository; the sources only record the related ERC-7780 module types and ERC-8286 (checked 2026-11-11: ERC-7579).
- There is nothing in the sources on which L2s support the P256 precompile, or on market share or audits of specific wallets.
- The sources have no Hegotá mainnet date and no full picture of how far each client has implemented EIP-8141.
6. Method
This article uses only information collected in this site's daily reports and the original links they cite. Each status reflects the most recent call decision or merged PR in the sources, with call outcomes taken from Ethereal news or the EIP-8081 meta EIP. All dates are UTC+7. If you spot a mistake or a gap, please email us.