Monthly EIP - Feb 2026 (ft. ETH's Roadmap Is Accelerated by Governance, Not AI)

Key Takeaways

• In February, a number of new EIPs emerged across the contract and core/networking layers aimed at strengthening Ethereum ecosystem’s scalability, while existing proposals continued to evolve with a focus on blob mechanism optimizations and improvements to user experience. Together, these developments signal Ethereum’s ongoing effort to preserve its rollup-centric scaling architecture while simultaneously enhancing L1 efficiency and developer experience.

• For Hegota, the upgrade planned after Glamsterdam, FOCIL (EIP-7805) has been selected as the consensus-layer headliner, while Frame Transactions (EIP-8141) are increasingly discussed as the most likely candidate for the execution-layer headliner. At the same time, Justin Drake’s Strawmap roadmap was unveiled, outlining a long-term development path toward Fast L1, Gigagas L1, Teragas L2, post-quantum security, and L1 privacy through seven forks leading up to 2029.

• Meanwhile, the rapid emergence of AI-driven agentic development stacks has sparked discussion around the potential acceleration of Ethereum’s roadmap. Yet the primary bottleneck shaping the pace of protocol evolution remains community governance. As such, the continued evolution of Ethereum’s governance framework—alongside the onboarding of participants who deeply understand its vision, context, and core technologies—will be the key variable in determining how quickly the roadmap can advance.

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. Author’s Note

One of the most notable aspects of the EIP landscape in February was the emergence of numerous new proposals across the contract and core/networking layers aimed at strengthening Ethereum ecosystem’s scalability. In particular, a variety of designs were discussed to make the execution environment and protocol architecture more flexible, while progress on existing EIPs largely centered on optimizing the blob mechanism and improving user experience (UX). Taken together, these developments highlight Ethereum’s continued effort to maintain its rollup-centric scaling architecture while simultaneously improving L1 efficiency and developer experience.

Meanwhile, discussions surrounding the headliner of Hegota, the upgrade scheduled to follow Glamsterdam, also became a major topic throughout February. FOCIL (Fork-choice Enforced Inclusion Lists, EIP-7805)* has been selected as the consensus-layer headliner, while several options were debated for the execution-layer headliner. At present, however, Frame Transaction (EIP-8141)** appears to be the most likely candidate.

*FOCIL proposes a protocol rule in which a validator committee specifies a list of transactions that must be included in a block, preventing block builders from arbitrarily excluding transactions. In effect, EIP-7805 is widely viewed as a mechanism that strengthens two of Ethereum’s core values—censorship resistance and credible neutrality—at the protocol level.

**For a detailed explanation of Frame Transaction, please refer to the previous post.

Source: Strawmap | Justin Drake

Alongside these discussions, Justin Drake’s long-term roadmap proposal, “Strawmap,” also emerged as an important topic. The proposal proposes a sequence of seven forks occurring at roughly six-month intervals, aiming to implement Fast L1 (1-second slots), Gigagas L1 (~10K TPS), Teragas L2 (~10M TPS), post-quantum security, and L1 privacy transactions by 2029. While previous roadmaps primarily outlined the technological direction Ethereum aims to pursue, Strawmap is notable for presenting a more concrete execution path, specifying which technologies are expected to be implemented in which forks, and in what sequence.

2. Newly Drafted EIPs

In February, a total of 22 EIPs were newly adopted into Draft status, representing a decrease of two compared to the previous month. The majority of these newly drafted proposals were concentrated in the Core and ERC categories, while a notable number of EIPs also emerged in the Networking and Meta categories.

Below, we take a closer look at these newly drafted EIPs by breaking them down into more detailed categories, followed by a deeper examination of several proposals that warrant particular attention.

2.1 Core / Networking Layer

2.1.1 EIP-8105: Universal Enshrined Encrypted Mempool

Ethereum’s public mempool has long served as a core feature symbolizing the network’s openness and transparency. At the same time, however, it also means that transactions are visible to anyone before they are included in a block, and characteristic has increasingly been recognized as a structural vulnerability, enabling malicious MEV strategies such as front-running and sandwich attacks.

As DeFi activity and transaction volume have grown, these attacks have become progressively more sophisticated, emerging as a major factor undermining both user experience and market fairness. The rapid adoption of private order flow and MEV relays over the past few years can largely be interpreted as the market’s organic attempt to mitigate these issues. Yet these approaches have also introduced new trade-offs, concentrating transaction flow in the hands of a limited set of infrastructure providers and raising concerns about potential erosion of Ethereum’s decentralization and neutrality. EIP-8105 proposes a protocol-level solution to this problem by introducing a new transaction propagation architecture called the “Universal Enshrined Encrypted Mempool (EEM)”.

The central idea behind EIP-8105 is to propagate transaction payloads in encrypted form within the mempool, ensuring that their contents remain hidden until the ordering of the block is finalized. In this model, users submit an “envelope” containing an encrypted transaction payload along with only minimal metadata. Block builders therefore include these transactions without having access to their economic details.

A key property of this design is that the payload remains encrypted while residing in the mempool. Builders construct blocks based solely on the envelope data, while the information required for execution is revealed only during the subsequent decryption stage.

As a result, the transaction lifecycle differs meaningfully from that of the current Ethereum architecture. Today, once a transaction reaches the mempool its contents become publicly visible, allowing searchers and builders to reorder or pre-empt transactions for strategic gain. Under an encrypted mempool design, however, the flow would operate as follows:

1. A user submits an encrypted transaction.

2. The network propagates the encrypted payload.

3. Builders include the encrypted transaction in a block.

4. The transaction ordering becomes finalized.

5. The payload is decrypted and the transaction is executed.

The critical property here is that no participant can observe the transaction contents before ordering is finalized. This effectively removes the informational advantage required for strategies such as front-running or intentional transaction reordering, structurally preventing a large class of malicious MEV behaviors.

More importantly, the implications of this design extend beyond simply reducing MEV attacks - by lowering reliance on private relays, the encrypted mempool attempts to restore the public mempool as a trustworthy coordination layer within Ethereum’s transaction pipeline. When combined with mechanisms such as proposer-builder separation (PBS) and FOCIL, an encrypted mempool could evolve into a foundational infrastructure component that simultaneously strengthens block production architecture, transaction ordering fairness, and censorship resistance within the Ethereum network.

2.1.2 EIP-8130: Account Abstraction by Account Configuration

One of the most important pillars in Ethereum’s long-term roadmap for improving user experience is Account Abstraction*. EIP-8130 emerges within this broader trajectory, proposing a framework in which an account’s authentication method is declaratively defined through a structured “Account Configuration”, which the protocol can directly interpret.

Ethereum’s account model has long maintained a relatively simple structure based on a single-signature scheme. A typical EOA authorizes transactions through secp256k1-based signature verification, and the verification logic itself is effectively fixed at the protocol level. EIP-8130 aims to expand this structural limitation by allowing accounts to declare their authentication model through an Account Configuration, enabling the protocol to interpret and enforce it directly. In doing so, accounts are no longer restricted to a single-key authentication scheme and instead gain the flexibility to support a broader range of authentication models.

*This article does not attempt to cover the wide range of standards related to account abstraction. In our previous article, however, we discussed Frame Transactions (EIP-8141), which attempt to implement scalable account abstraction through a new transaction structure. As mentioned earlier, Frame Transactions are currently considered a strong candidate for inclusion in the upcoming Hegota upgrade.

Source: Reference Implementation | EIP-8130

At the core of EIP-8130 is a structure that allows accounts to manage authentication keys and policies as structured data. The proposed IAccountConfig interface defines several structs associated with authentication management, most notably InitialKey and AuthKey. The InitialKey represents the default authentication key configured when an account is created, while AuthKey represents the keys actually used to sign transactions. Each key is identified through a combination of a verifier contract and a keyId, with signature validation delegated to the specified verifier contract.

Beyond expanding authentication methods, EIP-8130 also introduces mechanisms for account-level policy and security management. The AccountOperation struct defines operations related to modifying account policies or managing lock states, while KeyOperation handles key management tasks such as adding or revoking authentication keys. Notably, mechanisms such as requestUnlock and unlockDelay introduce a timelock-based security model for sensitive policy changes, preventing critical permission updates from being executed immediately. This design suggests that accounts may evolve beyond simple signing entities into environments capable of embedding their own policy and security logic.

Ultimately, the long-term direction of account abstraction is about ensuring flexibility in the evolution of authentication mechanisms. In this regard, EIP-8130’s configuration-based verification logic allows new signature schemes or authentication models to be integrated with relative ease. Within the same structural framework, accounts could support features such as multisig policies, passkey-based authentication, key rotation, and gas sponsorship, while also remaining adaptable to future cryptographic authentication methods that may emerge.

2.1.3 EIP-8142: Block-in-Blobs (BiB)

Over the past several years, Ethereum’s scaling roadmap has steadily evolved toward separating the roles of execution and data availability. A representative example is EIP-4844, which introduced blobs*—a dedicated data space for rollups—significantly reducing the cost of publishing L2 data and signaling Ethereum’s gradual shift from an execution-centric architecture toward a data-availability–centric design.

Within this broader trajectory, EIP-8142 takes the concept one step further by proposing a new block structure in which the execution payload itself is moved into blob-based data structures. Instead of embedding the transaction list and related execution data directly in the block body, the execution payload is packed into blobs, while the block header simply references them - the header includes metadata indicating how many blobs compose the payload—specifically the payload_blob_count field—while data integrity is verified through blob commitments and KZG proofs during the validation process.

*Blobs are not inherently limited to rollup data; in principle, any data type that benefits from compression or cryptographic commitment could utilize the blob structure.

Source: bytes_to_blobs | EIP-8142

At its core, this design separates execution data from the block body and delegates it to the blob-based data availability layer. As a result, the consensus layer only needs to verify the block header and blob commitments, while execution clients retrieve the blob data when necessary in order to perform transaction execution.

The implications of this architecture extend beyond a simple change in data formatting. By moving execution payloads into blobs, the structure of data propagated during block dissemination becomes simpler, while the scalability of execution data can be expanded more flexibly. In particular, within a proposer-builder separation (PBS) environment, builders could supply execution payloads in blob form while proposers reference them only at the header level - this approach naturally aligns with the danksharding-based data availability architecture that Ethereum ultimately aims to achieve.

Another reason EIP-8142 deserves attention is that this structure aligns well with proof-based execution models such as zkEVM. zkEVM provers must read both transaction data and execution traces from blocks in order to generate proofs, yet in Ethereum’s current block structure these data elements are deeply embedded within execution client internals, limiting accessibility. If execution payloads are provided as blobs, however, provers could retrieve the required data directly from the data availability layer, significantly simplifying the proof-generation pipeline. While zkEVM support is not the explicit objective of EIP-8142, the proposal nonetheless moves Ethereum’s block data architecture in a direction that is inherently more zk-friendly, making it an important development in the protocol’s longer-term evolution.

2.1.4 EIP-8148: Custom sweep threshold for validators*

*This topic was previously discussed in our earlier piece here.

With the Pectra upgrade, Ethereum is moving toward expanding the Max Effective Balance to 2,048 ETH through EIP-7251, thereby reducing the number of validators and easing bandwidth pressure on the consensus layer. This is not simply an adjustment of the upper bound; rather, its significance lies in structurally securing network scalability through validator consolidation.

Such a transition presupposes execution-layer–based compounding withdrawal credentials, and in doing so, further reinforces an operational model in which a validator’s ETH balance remains within the protocol for extended periods of time.

However, in a structure where automatic sweeps effectively depend on a fixed threshold(i.e., 2,048 ETH), rewards may not be transmitted externally for a considerable duration. This can introduce rigidity for validators, particularly in terms of capital turnover and reward visibility. EIP-8148 is a proposal that seeks to transition this structure into a more flexible, policy-based framework.

At its core, EIP-8148 allows validators to directly configure the automatic sweep threshold (; sweep_threshold) - in other words, a validator’s balance may compound up to the specified limit, and only the portion exceeding that threshold would be automatically transferred to the withdrawal destination.

This design constitutes a relatively small change—a minimal state extension—that adjusts only the timing of reward routing without compromising consensus safety - it does not modify slashing conditions or effective balance calculations; instead, it introduces a policy variable into the flow of capital.

From a more strategic perspective, this proposal can shift staking toward a more “policy-designable yield infrastructure.” For example, large LST protocols such as Lido Finance pursue operational efficiency through validator consolidation, while also seeking to fine-tune the timing of yield distribution within strategic vault structures like stVaults.

If the sweep threshold can be set dynamically, validators may allow rewards to compound up to a certain level in order to maximize capital efficiency, and thereafter deploy the excess at the execution layer—whether through redepositing, restaking, or allocating into DeFi strategies. In this sense, staking rewards are no longer confined to being merely accrued yield, but can instead be redefined as “routable liquidity.” Ultimately, while EIP-8148 may appear, on the surface, to be a UX-oriented refinement, its implications are structurally significant across stakeholders.

For the macro-level design of MaxEB expansion and validator consolidation to remain sustainable, the micro-level dynamics of capital rotation and reward visibility must also be carefully calibrated. In this regard, the proposal can be understood as a micro-adjustment that bridges this gap, and as part of the broader transition toward making staking rewards a more programmable yield primitive.

2.1.5 EIP-8159: eth/71 - Block Access List Exchange

One of the key research directions in Ethereum’s execution layer today is improving parallelization in the execution pipeline and increasing the predictability of state access. Within this context, EIP-7928 introduces the concept of a Block-level Access List (BAL), which records every state location accessed during block execution. By explicitly specifying which accounts and storage slots are accessed within a block, BAL provides a foundation for clients to perform various optimizations, including parallel disk reads, parallel transaction execution, and executionless state updates.

However, for such a structure to function effectively in a real network environment, simply embedding BAL data within newly produced blocks is not sufficient. In particular, when a new node joins the network and performs historical block synchronization, it must also be able to access BAL data through the existing P2P protocol. Addressing precisely this gap is the motivation behind EIP-8159.

EIP-8159 introduces a BAL exchange mechanism into the devp2p eth protocol, allowing block execution metadata to propagate naturally at the network layer. Concretely, the proposal adds a new field, block-access-list-hash, to the block header and defines new P2P messages that allow nodes to exchange BAL data. Through this mechanism, execution clients can request or provide the BAL corresponding to a particular block from their peers.

Source: EIP-8159

At the protocol level, the proposal introduces the following message types: GetBlockAccessLists(0x12), BlockAccessLists(0x13)

This design is notable because it introduces a dedicated synchronization channel for execution metadata without fundamentally altering the existing block propagation structure. Since BAL data serves as auxiliary information for execution optimization rather than essential block data, exchanging it through a separate message layer reflects a pragmatic design choice—one that carefully balances network efficiency with backward compatibility.

2.1.6 Others

• EIP-8131: Add Auth Data to EIP-7623 Floor

• EIP-8134, 8135, 8138: Hardfork Meta - BPO

• EIP-8136: Cell-Level Deltas for Data Column Broadcast

• EIP-8149: Multi KZG Point Evaluation Precompile

2.2 Data / Messaging / Transaction

2.2.1 EIP-8151: Private Key Deactivation Aware ecRecover

Ethereum’s account model has long relied on a single private-key–based EOA signature scheme. Recently, however, a new wave of account evolution—particularly the combination of EIP-7702, which introduces delegated EOAs, and EIP-7851, which proposes private key deactivation—is gradually shifting the security model toward a more dynamic architecture.

However, the challenge arises from the fact that Ethereum’s core signature verification primitive, ecrecover, operates in a completely stateless manner. The function simply recovers an address from a signature and does not consider the account’s state—such as whether the associated private key has already been deactivated. As Ethereum’s account security model evolves toward a policy-driven authentication layer, this limitation creates a structural gap between legacy signature verification mechanisms and newer account management frameworks.

This issue is not merely theoretical; it directly affects the signature-based authorization patterns widely used across DeFi. A prominent example is the permit mechanism introduced in EIP-2612. EIP-2612 allows ERC-20 tokens to support off-chain signatures for setting allowance , enabling users to authorize token spending without submitting an on-chain approve transaction. As a result, the traditional two-step flow (approve → transferFrom) can be replaced with a single signature that both grants approval and triggers execution. Major DeFi protocols—including Uniswap, Aave, and Curve—have widely adopted this pattern. However, most of these systems rely on immutable contracts that internally use ecrecover to verify signers, meaning they cannot recognize changes in an account’s key status or newly introduced security policies.

Consequently, even if a private key is later deactivated, the legacy ecrecover logic would still treat signatures generated by that key as valid. In other words, even if an account declares that a key should no longer be used under EIP-7851, existing DeFi contracts and permit-based systems would remain unaware of that change. This creates a structural inconsistency in which signatures produced by a previously valid key could still generate token allowances, despite the key having been explicitly disabled.

EIP-8151 proposes addressing this issue by modifying ecrecover so that it becomes aware of private key deactivation states. The core idea is straightforward: after recovering the address from a signature, the protocol checks whether the corresponding private key has been marked as deactivated under EIP-7851. If so, the function returns address(0) instead of the recovered address. This approach preserves a critical security invariant—that a deactivated key should never be considered a valid signer—while avoiding the need to modify existing immutable contracts at the application level.

In this sense, EIP-8151 represents more than a minor adjustment to a precompile. Ethereum is gradually moving toward a future defined by programmable accounts, key rotation, delegated execution, and eventually post-quantum migration. Within this broader evolution, signature verification itself must become state-aware, reflecting the security policies embedded within the account model. By enabling new security guarantees without requiring changes to the existing DeFi ecosystem, EIP-8151 could serve as an important compatibility bridge as Ethereum transitions from a traditional EOA-centric model toward a more flexible and programmable authentication framework.

2.2.2 Others

• EIP-8146: Block Access List Sidecars

2.3 Account / Contract / Token Standard / Wallet

2.3.1 ERC-8153: Facet-Based Diamonds

As Ethereum’s ecosystem matures, the structure of smart contracts has gradually evolved from simple single-contract designs toward more modular system architectures. Complex applications—such as DeFi protocols, on-chain governance frameworks, account abstraction systems, and intent-based interaction layers—often require dozens of functional modules. Implementing all of these capabilities within a single contract, however, quickly runs into structural limitations, including the contract size limit imposed by EIP-170 as well as increased upgrade and maintenance risks.

Source: EIP-8153

One of the most widely adopted approaches to addressing this challenge is the EIP-2535 Diamond Standard. In a diamond architecture, a single entry contract routes function calls to multiple logic contracts known as facets, enabling systems to scale functionality far beyond the size constraints of a single contract.

Source: EIP-8153

However, existing diamond implementations lack a standardized way to discover which functionalities are implemented in which facets, or which interfaces a contract supports. In practice, different projects rely on their own custom mechanisms to expose this information. This fragmentation has made it difficult for the broader Ethereum tooling ecosystem—including Hardhat, Foundry, indexers, wallets, and block explorers—to integrate consistently with diamond-based systems.

ERC-8153 addresses this limitation by defining a standardized interface that allows facet information and function selectors to be queried on-chain. Through this mechanism, external systems can programmatically determine which functional modules a contract contains and which interfaces it supports, in a machine-readable format.

Source: The Core Idea of ERC-8153 | ERC-8153

The significance of ERC-8153 lies in its attempt to standardize smart contract composability at the structural layer. Historically, Ethereum’s composability has largely been driven by ABI conventions and token interface standards such as ERC-20 and ERC-721. As protocols grow in complexity, however, functionality is increasingly distributed across multiple modules, making it difficult to understand a system’s architecture through ABI definitions alone.

Ultimately, ERC-8153 can be seen as an effort to extend the modular smart contract paradigm introduced by the Diamond Standard beyond developer convenience and toward an ecosystem-wide coordination layer. In this sense, it represents a natural evolution as Ethereum continues to accommodate increasingly complex on-chain systems.

2.3.2 Others

• ERC-8041: Fixed-Supply Agent NFT Collections

• ERC-8048: Onchain Metadata for Token Registries

• ERC-8049: Contract-Level Onchain Metadata

• ERC-8122: Minimal Agent Registry

• ERC-8126: AI Agent Registration and Verification

• ERC-8127: Human Readable Token Identifiers

• ERC-8152: Content-Addressable Logic Modules (CALM)

2.4 Application

2.4.1 Others

• ERC-8161: Transferable Tokenized Vault Requests

3. Progression of Existing EIPs

Meanwhile, excluding the 24 EIPs newly adopted into Draft status, a total of 15 existing EIPs experienced status changes during February. Among them, 10 proposals were promoted to the next stage in the standardization pipeline—such as Final, Last Call, Review, or Draft—bringing them closer to final adoption. The remaining five EIPs did not progress further: four proposals moved into the Stagnant stage (EIP-3540, EIP-7762, EIP-7956, EIP-7957), while one proposal, ERC-8109, transitioned from Draft to Withdrawn.

The EIPs that advanced this month were broadly distributed across several areas, ranging from L2-related proposals previously under discussion to signature-related improvements and application-level ERC standards.

Among EIPs (among non-ERC proposals), several are particularly noteworthy. These include EIP-7594, a protocol that allows nodes to verify the availability of blob data introduced in EIP-4844 through sampling and KZG proofs without requiring full data downloads, being considered as an intermediate scaling mechanism toward Danksharding. Another notable proposal is EIP-7851, which introduces a mechanism enabling delegated EOAs under EIP-7702 to deactivate existing private-key authority and restore it when necessary. Also noteworthy is EIP-7918, which proposes establishing a minimum price linked to L1 gas costs in order to prevent the blob base fee from dropping excessively low.

On the ERC side, several proposals also merit attention. These include ERC-8019, a wallet-local auto-login standard that allows wallets to automatically sign the same Sign-In with Ethereum (SIWE, EIP-4361) login message based on user-defined permission policies. Another is ERC-8034*, an extended royalty standard designed for rNFT-based DAG structures, enabling fine-grained control over royalty distribution and propagation across multiple NFTs. Finally, ERC-8063 introduces a standard that interprets ERC-20 token balances as “membership levels,” allowing on-chain representation of group membership and permission structures.

*This proposal was discussed in greater detail in our previous article.

Additional EIPs of interest are listed below.

3.1 Core / Networking Layer

• EIP-7607: Hardfork Meta - Fusaka

3.2 Data / Messaging / Transaction

• ERC-8111: Bound Signatures

3.3 Account / Contract / Token Standard / Wallet

• ERC-7656: Generalized Contract-Linked Services

3.4 Application

• ERC-7893: DeFi Protocol Solvency Proof Mechanism

4. “Food for Thought” - Ethereum’s Roadmap Is Accelerated by Governance, Not AI

Over the past few months, the very way software is developed has begun to shift rapidly. Agentic coding tools such as Claude Code, Cursor, and Cline, alongside AI-native application generation platforms like v0 (Vercel), Lovable, and Bolt.new, are becoming increasingly widespread. As a result, even non-developers can now build services or automate workflows using little more than natural language prompts. This trend goes beyond simple code assistance and is evolving into a broader agentic development stack, in which multiple AI agents coordinate tasks by interacting with IDEs, databases, and APIs. Consequently, the speed at which individuals can transform ideas into working services—often by orchestrating multiple AI agents—has increased dramatically.

Within this context, a natural question emerges:

“If software development productivity increases exponentially, could Ethereum—whose evolution follows a long-term technical roadmap—also advance faster than expected?”

Source: Twitter (@yq_acc)

In fact, Yaoqi Jia (YQ), co-founder of AltLayer, recently demonstrated an experiment in which AI was used to prototype an Ethereum protocol implementation reflecting elements of the 2030 roadmap within just a few weeks. Vitalik Buterin also expressed significant interest in the experiment, noting that while such AI-generated implementations may contain many bugs, AI is already dramatically accelerating coding speed and could potentially shorten the execution cycle of Ethereum’s long-term roadmap. The fact that experiments which seemed unrealistic only a few months ago are now feasible highlights how AI-driven development paradigms could serve as a catalyst for shortening the research-to-implementation cycle in blockchain protocols.

Yet Ethereum’s evolution differs fundamentally from that of conventional software projects. The network has been developed—and will continue to evolve—through long-term consensus among diverse stakeholders, including client developers, researchers, infrastructure operators, and application builders. Particularly at the core and networking layers, even a single design change can have far-reaching implications across the entire protocol. As a result, security validation and community consensus remain far more critical than raw implementation speed. In other words, even if AI dramatically accelerates code generation, the true bottleneck determining the pace of protocol evolution remains community governance. Under such a structure, Ethereum infrastructure may indeed develop “somewhat faster” in the coming years, but the surrounding discussions are likely to remain “deliberate and conservative by design”.

In contrast, application-level standards such as ERCs often require less deep protocol-level deliberation. As a result, experimentation and iteration can proceed far more rapidly atop Ethereum’s robust and conservative infrastructure. As AI-driven development environments continue to mature, the speed at which new proposals and implementations emerge at the application layer is likely to accelerate significantly. In other words, the most immediate impact of AI may not appear in the protocol’s fundamental architecture, but rather in the diversity of proposals and experiments at the application layer. Whether those experiments ultimately reach widespread adoption, however, will depend on when the underlying Ethereum infrastructure becomes mature enough to support them safely.

Then, the most important questions are therefore twofold at this moment: (1) how Ethereum’s governance framework and technical deliberation structures will evolve in response to these changes, and (2) how effectively the ecosystem can onboard participants who deeply understand Ethereum’s vision, context, and core technologies. As AI accelerates the pace of experimentation and implementation, the importance of deep protocol understanding—necessary to evaluate interdependencies among proposals and maintain system stability—will only grow. In this sense, it becomes increasingly clear why the Ethereum Foundation and the broader community must continue strengthening alignment around Ethereum’s long-term vision while investing in initiatives that onboard new R&D talent into the ecosystem.