Monthly EIP - Sep 2026 (ft. Making Ethereum’s Ideals Work)

Key Takeaways

• September saw as many new EIPs as August, but fewer existing proposals advanced. Core proposals focused on new authentication methods and lower verification and storage overhead, while ERCs centered on transaction protection, AI agent state and permissions, and common standards for contract modules.
• With quantum resistance targeted for 2029, the EF linked its long-term research roadmap to upgrade priorities, identifying censorship resistance and native account abstraction as central to Hegotá. It also stressed that ETH issuance policy requires discussion across the ecosystem.
• As demand for institutional adoption and ETH’s economic value grows, Ethereum must turn its principles into real-world use and growth. Researchers, developers, and operators need to assess policy outcomes alongside practical constraints altogether, and demonstrate how their choices contribute to Ethereum.

Ethereum pioneered the concept of smart contracts by integrating programmability into a distributed ledger architecture, thereby expanding the functional scope of blockchain systems. This design philosophy has been progressively formalized through the Ethereum Improvement Proposal (EIP) process, enabling the network to evolve beyond a simple store of value into an infrastructure capable of supporting real-world businesses and a wide range of use cases. As this evolutionary process continues, broader participation in EIP deliberations-by opinion leaders with heterogeneous perspectives and problem framings-may further enrich the development of a digital-native economic paradigm.

This article presents a high-level examination of EIP trends by reviewing proposals newly accepted into the Draft stage on a monthly basis, alongside proposals that have undergone meaningful status transitions. Through this analysis, we aim to provide builders and business stakeholders with a more structured understanding of the evolving EIP landscape and to offer a conceptual foundation for identifying and developing new value propositions within their respective areas of activity.

The EIP-related data referenced in this article was collected and analyzed using the official GitHub repositories for EIP, ERC, and RIP.

1. This Month's Ethereum Discussion Summary

September saw new EIP proposals hold steady, while fewer existing EIPs advanced. Ten new EIPs were introduced, matching August, but the number advancing to the next stage fell from 25 to 10. None were withdrawn.

Among new Core proposals, EIP-8355 introduced precompiles for verifying quantum-resistant ML-DSA signatures in contracts, while EIP-8288 proposed aggregating signatures and proofs from the mempool stage to reduce data and verification costs. EIP-8360 proposed the TCREATE opcode for temporary contracts used within a single transaction, and EIP-8383 sought to shorten the minimum block history consensus clients must serve from roughly five months to 36 days. Together, these proposals aimed to support new authentication methods while reducing repeated verification work and the burden of retaining code and data after execution.

At the application layer, ERC proposals focused on common interfaces for transaction protection and AI agent state management. ERC-8377 calculates acceptable losses using oracle prices at execution, rather than a minimum output fixed when the transaction is created, then checks the actual output against that threshold. ERC-8350 proposed a registry for verifying modification permissions and the order of state changes onchain without revealing an AI agent’s underlying memory.

Existing proposals that advanced addressed validator operational risk, contract module management, and token permissions. EIP-7716 would impose higher penalties when many validators fail simultaneously, encouraging greater diversity in operating environments. ERC-8153 and ERC-8167 standardize diamond contract module management and the mapping and lookup of function implementations, respectively. Also advancing were ERC-5805, covering vote delegation and historical voting power queries, and ERC-7962, which uses public key hashes and signatures to manage ownership and transfers.

While August’s progress centered on longer-term protocol reforms, September brought proposals to make new authentication technologies usable and adjust verification, storage, and management costs for nodes and developers. At the protocol level, these proposals addressed the resources needed to support security features, while ERCs defined more consistent ways to handle transaction conditions and modification permissions.

Source: blog.ethereum.org

Meanwhile, September saw the Ethereum Foundation (EF) align its long-term research agenda with priorities for the next upgrade. On September 7, EF Protocol published its protocol research priorities, setting a target of quantum resistance across the execution, consensus, and data layers by December 2029. Fast finality, privacy, state management, and zkEVM remain key research areas, but meeting that timeline will require research and implementation across multiple upgrades to proceed in parallel.

This direction became clearer in the Hegotá candidate EIP assessment, published the same day. In its first consolidated assessment of 62 candidates, EF Protocol identified FOCIL for censorship resistance and Frame Transactions for native account abstraction as central to the upgrade. Drawing on lessons from Glamsterdam preparations, it weighed each feature’s benefits alongside the complexity and testing burden of combining changes, as well as potential conflicts with later consensus reforms. The announcements thus began to clarify what to defer or exclude, alongside what to add, to keep longer-term transitions on schedule.

The EF also drew boundaries around its authority while setting technical priorities. It did not support including issuance and reward policy changes, such as EIP-8363, in Hegotá, but stopped short of rejecting their merits. Since issuance policy affects stakers, ETH holders, and the network’s long-term security budget, it called for broader ecosystem discussion rather than leaving the direction to EF Protocol or the scope-setting process for a single upgrade. This suggests an effort to distinguish its role in coordinating protocol development from deciding economic questions that affect the wider ecosystem.

2. Newly Drafted EIPs

Ten new EIPs entered Draft status in September, matching August’s total. Most were Core EIPs, which require network-level changes, or ERCs, which define standards implemented at the application layer.

Below, we group these proposals by category and examine those worth highlighting.

2.1 Core / Networking Layer

2.1.1 EIP-8355: Precompiles for ML-DSA Verification

Blockchain account security depends in part on how long signatures remain trustworthy while assets are held. Preparing for quantum threats therefore requires onchain verification of authorizations made with new signature schemes. EIP-8355 proposes precompiles for verifying ML-DSA signatures - Standardized by the US National Institute of Standards and Technology (NIST), ML-DSA is a digital signature algorithm considered resistant to attacks by large-scale quantum computers.

Precompiles let execution clients handle complex computations directly, while contracts access them through designated addresses. An earlier proposal, EIP-8051, also proposed ML-DSA verification precompiles, but supported only ML-DSA-44, one of three security levels, and limited messages to 32 bytes. EIP-8355 broadens their use by adding the higher-security ML-DSA-65 and ML-DSA-87 variants and removing the message length limit.

Calls pass pubkey ++ signature ++ message, concatenating the public key, signature, and message in that order. Public key and signature lengths are fixed for each security level, so the remaining data is read as the message. This allows long messages to be verified without first reducing them to a hash. By accepting standard key and signature formats, the proposal also lets compatible key management services and hardware security modules produce signatures for onchain authentication without exporting private keys.

The cost design reflects a trade-off between data transmission and computation. EIP-8051 accepts a “large” public key with some verification work already performed, while EIP-8355 accepts a “small” standard key and leaves the additional computation to the client. For ML-DSA-44, the public key shrinks from 20,512 bytes to 1,312 bytes, while base verification gas increases. This reduces the data sent repeatedly and charges for verification work instead, though the proposed gas costs still need to be finalized through benchmarking.

Developers must distinguish call success from signature validity, since an invalid signature still returns normally, with a 32-byte value of 1 or 0 indicating the result. Applications must also include chain, contract, and nonce information in the message to prevent the same authorization from being reused elsewhere. The proposal does not automatically make existing accounts quantum-resistant. It provides a shared verification foundation for wallets and custodians designing ML-DSA authentication.

2.1.2 EIP-8360: TCREATE Opcode

Smart contracts deployed on Ethereum are typically used across many transactions. Some code, however, is needed only for a single transaction and has no reason to remain afterward. Developers previously created contracts and removed them with SELFDESTRUCT, but the removal of deletion-related gas refunds and tighter deletion rules left costs and implementation work unresolved. EIP-8360 proposes TCREATE, a new deployment opcode that lets one-off code run briefly and then be cleared automatically.

A contract created with TCREATE runs like an ordinary contract during the transaction, then loses its code and storage when the transaction ends. Any ETH at the address remains, so the balance must also be emptied to remove the account entirely. Its address can be calculated in advance from the deployer, a developer-specified salt, and the initialization code. The calculation uses a different prefix from CREATE2 to prevent address collisions with contracts deployed through that opcode.

This structure separates the cost of running code from the cost of retaining it after execution. Initialization, computation, and memory use still consume gas, but code that disappears at the end of the transaction incurs no permanent storage charge. Under the current public specification, SLOAD and SSTORE also use temporary storage, allowing values to be recorded during execution without carrying them into the next transaction. Information that persists, such as ETH balances, remains subject to state storage costs.

Smart accounts could use this to create temporary functionality for individual transactions. Code supplied in transaction data, for example, could be deployed as a temporary contract and executed without permanently installing that functionality in the account. Temporary contracts could also serve as deployment intermediaries, since child contracts they create with CREATE remain after the transaction. This would allow the intermediary used to derive an address in the existing CREATE3 deployment pattern to be cleared afterward.

A temporary contract’s lifetime must still be distinguished from the effects it leaves behind. Token approvals or permissions recorded in other contracts can persist after its code disappears, and code later deployed at the same address may behave differently. Developers should therefore avoid trusting unchanged behavior or granting lasting permissions based on the address alone. Storage instructions and gas handling remain under discussion in this Draft proposal, but having the EVM handle the costs and cleanup of one-off execution could reduce developers’ workload.

2.1.3 EIP-8383: Reduce CL Block Retention Window

The cost of running an Ethereum node extends beyond verifying the latest blocks. Operators also store and serve historical blocks to help other nodes synchronize. Even with checkpoint sync, which starts from a recent finalized state, fulfilling this role requires downloading almost five months of additional blocks. EIP-8383 distinguishes the data needed for current consensus participation from the history served to peers, and seeks to reduce the latter burden.

Understanding this distinction starts with why checkpoints are needed. In proof of stake, validators that have already withdrawn their stake could use old keys to build an alternative chain and mislead a newly connected node through a long-range attack. Nodes therefore start from a trusted recent checkpoint and verify subsequent blocks themselves. The period during which a checkpoint remains a safe starting point is called the Weak Subjectivity Period, and downloading more historical blocks does not make an overly old checkpoint safe.

The proposal sets MIN_EPOCHS_FOR_BLOCK_REQUESTS = 8192, reducing the minimum block range consensus clients must serve from 33,024 epochs to 8,192 epochs. An epoch is a unit of Ethereum consensus, and 8,192 epochs is approximately 36.4 days. The existing window assumes the maximum safety decay in the weak subjectivity calculation, whereas the upper bound under current mainnet policy is 3,532 epochs. A fixed window of 8,192 epochs leaves a comfortable margin above that bound and makes retention and pruning requirements more predictable.

Operationally, this reduces backfill, the process of downloading blocks from before the checkpoint. Less historical data needs to be downloaded separately from synchronization to the latest state, saving bandwidth, disk space, and write operations. Some consensus clients retrieve historical execution payloads from execution clients, so the change could also ease execution-layer retention requirements. For infrastructure operators setting up new nodes, it makes the resources needed for current consensus participation and historical data service easier to distinguish.

A shorter retention window must still preserve the relevant safety conditions. If future protocol changes extend the Weak Subjectivity Period, 8,192 epochs must remain above its upper bound, while all unfinalized blocks should be retained during prolonged periods without finality. No hard fork is required, and nodes may keep longer histories, but the minimum history ordinary nodes must serve would shrink. EIP-8383 thus seeks to align baseline retention obligations with the data actually needed for safe synchronization.

2.1.4 Other(s)

• EIP-8365: Disallow new 0x00 validators
• EIP-8379: Top-up Sync

2.2 Data / Messaging / Transaction

2.2.1 EIP-8288: In-mempool signature and proof aggregation

Adopting new security technologies on Ethereum also means accounting for the data and computation each transaction requires. Quantum-resistant signatures and privacy proofs can be large, so including and verifying them individually in every block quickly drives up costs. EIP-8288 proposes aggregating signatures and proofs across transactions to reduce this burden. By combining their verification results into a single proof, it reduces work repeated across the network.

The proposal builds on EIP-8141’s frame structure, which divides transactions into stages such as validation and execution. A new DEP_VERIFY_FRAME_MODE specifies which key’s signature must be verified against which data. Declaring these requirements upfront lets nodes identify and aggregate the required signatures before executing transaction code.

Each verification requirement is expressed as (scheme, data_hash, verification_key_hash). These values identify the cryptographic scheme, the data to verify, and the verification key, while the actual signature or proof is supplied separately alongside the transaction. Contracts read this information through FRAMEPARAM and FRAMEDATACOPY, then check that the specified data and key meet their authentication requirements. The aggregate proof handles cryptographic verification, while the contract determines whether that verification satisfies the transaction’s authorization conditions.

Aggregation begins in the mempool, where transactions wait for inclusion in a block. Nodes generate recursive STARKs that combine multiple signatures or existing aggregate proofs, and builders use them to complete a proof for the transactions in the final block. Other nodes verify the block header’s recursive_stark to confirm that all required signature checks have been performed. Builders can therefore perform the verification work without requiring other nodes to trust their results.

The practical benefit is a shared way to lower costs for transactions using large signatures and proofs. However, the current draft supports only the quantum-resistant leanSPHINCS signature scheme, with a path for general STARK proof aggregation reserved for future use. Adoption would also require a network upgrade and add proof-generation work for mempool nodes and builders. The key question is how far savings in block data and verification costs would offset the added cost and operational burden of generating proofs.

2.2.2 Other(s)

• EIP-8369: VOPS Profiles for FOCIL Eligibility

2.3 Account / Contract / Token Standard / Wallet

2.3.1 Other(s)

• ERC-8410: Portable Execution Plan Artifact

2.4 Application

2.4.1 ERC-8377: Reference-Relative Slippage Bounds

When swapping tokens, the price can change between receiving a quote and executing the transaction. Users account for this by setting minAmountOut, the minimum amount they will accept before the transaction reverts. Lowering that threshold to avoid failed transactions, however, gives attackers more room to place orders around the user’s trade and worsen its execution price through a sandwich attack. ERC-8377 proposes tying the minimum output to the market price at execution.

Instead of specifying a fixed amount such as “receive at least 990 tokens,” the proposal sets a limit on acceptable losses relative to the market price at execution. Users submit a SlippagePolicy specifying a price provider, expected trading costs, and an allowance for additional losses. The execution contract calls getQuote() through ERC-7726 on an oracle that supplies external prices onchain, obtaining a reference output amount for the input tokens.

This reference amount excludes fees and the trade’s own price impact. The contract first deducts these normal costs using expectedCostBps, then applies maxDeviationBps to the remaining expected output as an additional loss allowance. Separating normal costs from adverse execution makes the protection more precise. A hardFloor also sets an absolute minimum output that applies regardless of the market price.

After execution, the contract checks the recipient’s actual token balance increase and reverts the entire transaction if it falls below the calculated minimum. This prevents undelivered tokens from being counted as received simply because a trading route reports a particular output. Wallets and aggregators comparing multiple routes can use the common interface to pass these protection conditions. A deadline also limits how long a transaction remains valid, preventing an old trading instruction from executing much later even if it still meets current price conditions.

The protection depends on the oracle’s reliability and the freshness of its prices. The specification prohibits using the traded pool’s spot price as the reference, since an attacker could manipulate both the execution price and the protection threshold. Sandwich attacks remain possible within the permitted bounds, and legitimate differences between oracle and market prices can still cause transactions to fail. Currently in Draft, ERC-8377 offers a common standard for separating expected trading costs from additional losses and enforcing those limits against the amount actually received.

2.4.2 Other(s)

• ERC-8350: Agent Memory State Registry

3. Progression of Existing EIPs

Beyond the 10 new EIPs introduced in September, 10 existing proposals changed status. All advanced toward final adoption through stages such as Draft, Review, Last Call, and Final, with none moving to Withdrawn.

Notable ERCs that advanced include ERC-5805 for token vote delegation and historical voting power queries, ERC-7962 for managing token ownership and transfers through public key hashes and signatures, ERC-8153 for simplifying diamond contract module management and upgrades, and ERC-8167, a proxy standard for mapping functions to implementation modules and querying those mappings.

Among non-ERC proposals, EIP-7716 stood out for proposing higher penalties when validators fail simultaneously.

Other proposals worth noting include the following.

3.1 Core / Networking Layer

• EIP-7784: GETCONTRACT opcode
• EIP-8246: Remove SELFDESTRUCT Burn

3.2 Data / Messaging / Transaction

• ERC-7562: Account Abstraction Validation Scope Rules

3.3 Account / Contract / Token Standard / Wallet

• ERC-7813: Store, Table-Based Introspectable Storage

3.4 Application

• ERC-8107: ENS Trust Registry for Agent Coordination

4. Making Ethereum’s Ideals Work

Ethereum has expanded blockchain’s possibilities through decentralization, censorship resistance, and systems that do not require trust in any single party. As financial services grow and more institutions participate, however, pressure is mounting to demonstrate usability, commercial viability, and ETH’s economic value. This helps connect Ethereum with real demand, but a focus on immediate results can also create tension with its founding design principles.

Source: Ethereum Blog

Against this backdrop, the foundation stated during its June restructuring that its protocol organization does not exist to make Ethereum easier to sell or serve short-term interests. This can be read as a commitment to preserving an open network’s principles rather than changing them to suit individual companies. For those principles to benefit more users, though, Ethereum must also reflect their needs in its design.

The recent debate over EIP-8363, which proposed adjusting ETH issuance, shows how difficult this can be. Supporters sought to curb staking concentration and preserve ETH’s monetary properties, while opponents warned that lower rewards could push independent operators out first. Both sides argued for decentralization, yet reached different conclusions about how to achieve it and how the market would respond.

Source: X(@dankrad)

A similar divide appears in the debate over business development (BD). Some see a need for a dedicated team to drive institutional adoption, while others argue that Ethereum should focus on technology compelling enough to attract users without BD. External organizations such as Etherealize already support institutional solutions and adoption, so the foundation need not perform every function itself. Still, clearer channels are needed for these organizations to connect institutions with technology and operating partners, then relay common adoption barriers to the foundation and development teams.

A smaller foundation and a larger role for external organizations are only the beginning of this division of responsibilities. Adoption teams must define institutions’ problems clearly, while developers determine whether existing tools can address them or changes to standards or the protocol are needed. Commercial progress should be assessed beyond partnerships and transaction volume, including how well it meets institutional needs for reliability, predictable costs, and integration with existing systems. It is also necessary to examine whether adoption translates into L1 usage and economic demand for ETH, since wider use of the technology alone does not guarantee growth for the network and its asset.

Making this division of responsibilities work requires a more coordinated process that brings operational evidence into development discussions. The foundation could, for example, support joint reviews of major proposals such as issuance changes by researchers, developers, and business operators. Researchers would present expected effects and assumptions, while operators would provide costs and profitability at different scales, helping identify when operators might exit and informing EIP and core developer discussions. For institutional adoption, support teams could document use cases and requirements, while developers specify what they can address and who will take responsibility for follow-up.

Not every request needs to be accepted, but decisions to incorporate or reject feedback, and the reasons behind them, should be public. This would allow researchers to test whether their designs sustain a diverse set of participants, while businesses substantiate adoption challenges and results with concrete evidence. Neither dismissing practical difficulties in the name of ideals nor treating transaction volume as proof of success will help the two sides persuade each other. Before debating which principles to compromise, each side should consider what it must change to make those principles work in practice.