Monthly EIP - Apr 2026 (ft. Staked Assets at Work, The Prepared Win)

Key Takeaways

• April's EIP activity, much like the first quarter, saw active new proposals at the core layer, with EIPs aimed at supporting a range of use cases at the signature scheme and application layers standing out in particular.
• Community discussions unfolded along two axes: "the safe structuring of the Glamsterdam and Hegota upgrades" and "strengthening the trusted network foundation for native applications.”
• Meanwhile, as the center of gravity in the staking asset market shifts toward solutions with high on-chain utilization, the protocols that will lead this market will be those that have quickly attained both Web3 scalability and Web2 accountability at once.

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

April's EIP activity continued the trend set in the first quarter, with a meaningful number of new EIPs proposed at the Core layer. As we'll explore below, most of these new EIPs were aimed at extending support for a range of use cases at the signature scheme and application layers in a scalable manner. Among existing EIPs that advanced, the majority were ERC standards implemented at the application layer. What stands out is that several ERCs which had progressed over the past few months continued to move forward, and as in the previous month, four EIPs were downgraded to Stagnant status.

Meanwhile, Ethereum community discussions in April unfolded along two broad tracks. On the protocol core side, the central question was how to safely structure the upcoming Glamsterdam upgrade and the subsequent Hegota upgrade. Tightly interdependent proposals such as ePBS, BAL, gas repricing, and the contract size limit are being sorted out slowly but carefully; in particular, with FOCIL selected as the consensus-layer headliner for Hegota, censorship resistance has emerged as a core agenda item for the following upgrade. EIP-8141 Frame Transactions, by contrast, drew attention as a proposal addressing account abstraction, signature agility, and post-quantum readiness all at once, but it remains at the CFI stage as developers have yet to converge on its implementation direction and scope.

On the application side, the verifiability of AI agents and the Ethereum Foundation's ecosystem support initiatives rose to the forefront. On Ethereum Magicians, a series of proposals(e.g., ERC-8126, ERC-8210, ERC-8203, and ERC-8239) sought to standardize agent identity, verification, collateral, skills, and settlement processes. In parallel, the Solidity Survey revealed that while AI tool usage has become widespread, trust in their outputs remains low. Alongside this, initiatives such as the launch of the Ethereum Applications Guild (EAG) to support stable operations of ecosystem applications, the Ethereum Foundation's Ecosystem Support Program (ESP) backing research in cryptography, zero-knowledge proofs, and security protocols, and a 500 ETH security funding round point to a shift in the Ethereum Foundation's direction toward building the foundations needed to safely verify and support real-world applications across the ecosystem.

2. Newly Drafted EIPs

A total of 11 EIPs were newly adopted as "Draft" status over the course of April - one fewer than the previous month. As in March, the majority of this month's new drafts were Core EIPs targeting improvements at the network layer.

Below, we break down the newly drafted EIPs in more detail and take a closer look at those most worth highlighting.

2.1 Core & Networking Layer

2.1.1 EIP-8164: Native Key Delegation for EOAs

Since Ethereum's launch, externally owned accounts (EOAs) have relied on a single signature scheme, secp256k1 ECDSA, for authentication. The simple model in which the transaction signer is also the account owner has long been a foundational element of the protocol, but it has also exposed a limitation: EOA authentication is permanently bound to a single curve and a single algorithm. For instance, any EOA that has ever signed a transaction has its secp256k1 public key exposed on-chain, meaning that the private key could be recovered via Shor's algorithm or similar techniques once a sufficiently powerful quantum computer emerges. In other words, ECDSA dependence is more than a lack of algorithmic diversity; it has accumulated as a creeping risk that leaves every active EOA exposed to quantum threats.

The closest prior attempt to address this concern was EIP-7702. EIP-7702 allows an EOA to delegate contract code to its own code field, enabling arbitrary verification logic to run on each transaction. This gave EOAs functionality similar to ERC-4337 accounts, but with a critical limitation: the authority to approve the delegation itself still rests on an ECDSA signature. As a result, exposure to quantum threats remains intact. Moreover, verifying alternative signature schemes through EVM execution incurs additional gas costs on every transaction.

EIP-8164 recognizes these limitations and introduces a protocol-level path for permanently replacing the authentication algorithm of an EOA itself. The core idea is to extend the delegation designator scheme defined by EIP-7702, enabling native key delegation rather than code delegation. Put differently, an EOA can, through a single migration, permanently transition its authentication key from ECDSA to a quantum-resistant signature scheme, and when this transition takes place, the original ECDSA key is permanently invalidated at the protocol level. The first native key scheme adopted is ML-DSA-44, the NIST FIPS 204 standard; ML-DSA-44 is a NIST Level 1 (~128-bit post-quantum) signature scheme based on the module lattice problem (Module-LWE / Module-SIS), and it is quantum-resistant.

Concretely, EIP-8164 defines a new delegation designator, 0xef0101 || pubkey.* Of the 1,315 bytes in the code field, the first 3 bytes form a prefix identifying an ML-DSA-44 native-key account, while the following 1,312 bytes are the ML-DSA-44 public key itself. This is fundamentally different from EIP-7702's "pointer to a code address" structure, in that the key used for authentication is embedded directly in the code field.

*This proposal reserves the 0xef01XX prefix to accommodate a variety of schemes in subsequent extensions.

The new transaction type 0x06, introduced alongside, supports two modes within a single type.

First, ECDSA mode is used once at migration time: the sender field is left empty, and the existing ECDSA signature authorizes the native-key delegation.

Second, ML-DSA-44 mode is intended for native-signature transactions after migration, carrying a 20-byte address in the sender field along with a 2,420-byte ML-DSA-44 signature. Unlike ECDSA, ML-DSA-44 does not allow public key recovery from the signature, so the sender must be specified explicitly; in return, elliptic curve operations are eliminated from the transaction decoding stage, a useful side benefit.

In parallel, the key lifecycle is managed through two types of tuples within native_key_authorization_list:

The migration tuple is signed with ECDSA and is used exactly once, whereas the rotation tuple is signed with the currently installed ML-DSA-44 key to install a new ML-DSA-44 public key. Once an account has transitioned to a native key, both ECDSA-based transactions (types 0x00 to 0x04 and the ECDSA mode of 0x06) and EIP-7702 delegations are rejected. To eliminate the risk of consensus divergence between verifying clients, the verification procedure rigorously specifies encoding canonicalization, signature coefficient norm checks, and hint vector ordering. On the gas side, ML-DSA-44 verification carries an intrinsic cost of 50,000 gas, replacing the existing ecrecover cost.

In sum, EIP-8164 can be read as the first formal migration path that Ethereum is laying down at the authentication layer to prepare for the quantum threat era. For wallet builders and custody infrastructure providers, it represents the first formalization of a new primitive: a permanent migration from ECDSA to a quantum-resistant scheme. This is particularly meaningful for institutionally held assets as well, where key infrastructure tied to a single curve and classical security assumptions has increasingly been viewed as a creeping risk. The ability to prove at the protocol level that "the original ECDSA key is no longer valid" carries clear implications for compliance and audit. Moreover, the reservation of the 0xef01XX designator space for future signature schemes means that EIP-8164 functions not as the introduction of a single algorithm, but as an extensible authentication framework into which post-quantum (PQ) signature schemes can be added slot by slot.

2.1.2 EIP-8188: State Tiering by Write Age

Ethereum's state persists indefinitely once written, unless explicitly removed, and state written long ago is processed under the same write cost structure as state that is repeatedly updated. EIP-8188 frames this as a "renewal age is unpriced" problem.

Recently updated state is likely to reside in a client's mutable working set. By contrast, state that has not been updated for a long time can trigger deeper database lookups and larger write overhead. Yet under the current flat write cost structure, actively used state in the active set is overcharged, while rewrites to long-dormant state are undercharged. EIP-8188 starts not from the size of state itself, but from the observation that repeatedly rewritten state and long-untouched state have fundamentally different resource profiles.

The existing gas model already includes a warm/cold distinction that charges a higher cost for the first access to an address or slot within a transaction (EIP-2929). But this only looks at "was this the first access within this transaction?" (transaction-local first-touch). What EIP-8188 seeks to capture, by contrast, is "how long has it been since this state was last written?" In short, EIP-2929 looks at the order of access, while EIP-8188 looks at the age of writes. Access lists, introduced via EIP-2930, can also pre-warm addresses and storage keys, but this only reduces the first-touch cost of read access; it does not erase the fact that the state in question was last written long ago. Accordingly, even a storage slot pre-warmed via an access list must, when later written to via SSTORE, still pay the tiered write cost based on its last_written_period.

Concretely, EIP-8188 adds a last_written_period field to the RLP encoding of accounts and storage slots. The account structure expands from the existing account = RLP([nonce, balance, storageRoot, codeHash]) to account = RLP([..., last_written_period]), and storage slots change from slot_value = RLP(value) to slot_value = RLP([value, last_written_period]).

The global current_period is computed as current_period = max(0, (block_number - PERIOD_START_BLOCK) // PERIOD_LENGTH), and a state's tier is determined as ACTIVE or INACTIVE depending on whether period_age = current_period - last_written_period is less than INACTIVE_MIN_AGE.

Write costs are split into sub-components such as ACTIVE_ACCOUNT_WRITE, INACTIVE_ACCOUNT_WRITE, ACTIVE_STORAGE_WRITE, and INACTIVE_STORAGE_WRITE, with the specification mandating the condition INACTIVE > ACTIVE. The key point here is that the tier is evaluated before the write takes place. A transaction writing to inactive state pays the inactive write cost first, even though the write itself refreshes that state back to active.

The implication of this EIP is that clients can use the write-age metadata to split state storage paths. That is, while EIP-8188 does not mandate any particular storage architecture, it opens the door for clients to place active state in a small mutable store optimized for repeated writes, and inactive state in a stable store optimized for throughput. That said, this proposal does not, like state expiry, remove inactive state at the consensus level, nor does it directly bound the total state size. In this sense, EIP-8188 can be read not as a heavy-handed intervention that deletes state, but as a middle-ground state management mechanism that inserts a cost signal for rewriting old state into the protocol, separating the mutable working set from the broader state.

2.1.3 EIP-8205: Withdrawal credentials preregistration

In Ethereum's validator creation process, the first deposit effectively finalizes the withdrawal credentials tied to a given public key. This structure poses little issue in solo staking, where the entity providing the funds is the same as the BLS key generator. In delegated staking services, however, a clear trust boundary emerges.

For instance, in models that separate the operator from the capital, such as liquid staking protocols or staking-as-a-service providers, the key holder can deposit using their own withdrawal credentials before the capital provider does. In that case, the capital provider has no on-chain guarantee of withdrawal rights. EIP-8205 is a proposal to handle precisely this "pre-first-deposit window" directly at the protocol level.

Until now, this problem has been handled at the application layer rather than at the protocol layer. The EIP-8205 specification notes that at least one-third of staked ETH flows through such delegated architectures, and that individual applications have built their own defenses in the form of bond-based pre-deposits, guardian committees, and similar mechanisms. These defenses have so far succeeded in preventing exploits, but the burden of design, audit, and operation has fallen entirely on each application.

The core of EIP-8205 is to have validator key holders preregister the binding between pubkey and withdrawal_credentials via a BLS signature before deposit, and to have the consensus layer enforce this during subsequent deposit ingestion. On the Execution Layer (EL), a new system contract queues an EIP-7685 request corresponding to VALIDATOR_PREREGISTRATION_REQUEST_TYPE, composed of four fields: source_address, pubkey, withdrawal_credentials, and signature. On the Consensus Layer (CL), StoredPreregistration stores pubkey, withdrawal_credentials, and inclusion_slot, while a preregistrations list is added to ExecutionRequests. Deposits for a pubkey without preregistration are processed exactly as before, so the mechanism adds an optional safety layer needed for delegated staking structures rather than overhauling the existing staking flow.

The practical implications become clearer when we look at the deposit security structure of Lido's various modules. As shown in the table above, Lido has used the Deposit Security Module (DSM) since 2021, allowing deposit batches only after a guardian committee signs a depositRoot snapshot. The current configuration relies on operational devices such as a 4-of-6 quorum, a 1-of-N pause threshold, and a per-block deposit rate limit to prevent withdrawal credential frontrunning. As the operator set grows, however, as with Staking Router and the Community Staking Module (CSM), guardian-based monitoring becomes increasingly complex; and in structures like stVaults, where each vault carries its own withdrawal credentials, a fixed committee struggles to monitor every deposit queue. For this reason, Lido built a separate Predeposit Guarantee for stVaults, requiring a 1 ETH bond per validator upfront and verifying withdrawal credentials via an EIP-4788 Merkle proof. As a result, Lido now runs two parallel deposit protection systems, DSM and PDG. With the introduction of EIP-8205, much of this architecture could be replaced by protocol guarantees, or substantially simplified.

In this respect, EIP-8205 can be read not merely as a proposal to improve validator deposit UX, but as an attempt to absorb the deposit security infrastructure that LSTs and many staking-as-a-service providers have each maintained on their own into Ethereum's shared security properties, broadening the base of staking participation in the process.

2.1.4 Others

• EIP-8133: Upgrade Nomenclature
• EIP-8173: Foundations of EVM Control Flow
• EIP-8200: EVMification
• EIP-8237: Independent CL/EL Sync

2.2 Data / Messaging / Transaction

2.2.1 EIP-8202: Scheme-Agile Transactions

Through EIP-2718, Ethereum has evolved by issuing a new transaction type whenever new functionality is added. EIP-1559 introduced 0x02 to separate the base fee from the priority fee; EIP-4844 introduced 0x03 to attach blob data; and EIP-7702 introduced 0x04 for per-transaction code delegation by EOAs, each establishing its own distinct EIP-2718 transaction type. The payloads of these types, however, cannot be combined with one another within a single transaction. Put differently, if one wants to send a blob and perform a set-code delegation in the same transaction, an entirely new top-level type for that combination has to be created. As more features are added, the number of possible combinations grows exponentially, and issuing a new envelope for each one is not sustainable.

EIP-8202 addresses this problem not by continuing to multiply transaction types, but by attaching authentication methods and extension features inside a single common transaction envelope. The fee and execution payload are kept in a shared form, while the remaining features are combined selectively as needed.

Concretely, EIP-8202 introduces SchemedTransaction with transaction type 0x05. The type takes the form 0x05 || rlp([..., authorizations, extensions]), where the front portion contains a common EIP-1559 fee header and a standard call/create execution payload, while the latter two lists, authorizations and extensions, specify how the sender is authenticated and which additional features (such as blobs or set-code) are attached. The key point is that the signature scheme is no longer implicitly determined by the transaction type, but is explicitly determined by the authorization field inside the transaction. Under this structure, the existing secp256k1 ECDSA is supported as before, while alternative approaches such as ephemeral secp256k1, which reduces long-term public key exposure, as well as future passkey or quantum-resistant signature schemes, can be added within the same envelope.

From a practical perspective, this EIP can reduce the breadth of transaction combinations that wallet, client, and application developers have to handle. Wallets, for example, can implement "blob transactions," "EIP-7702 set-code transactions," and "new-signature-scheme transactions" not as separate top-level formats, but by attaching the relevant features linearly on top of a common envelope. For clients and block builders, validating an authorization and extension list within a single transaction is simpler than interpreting several transaction types in combination. This can lower implementation complexity, particularly in environments that demand multiple protocol features at once, such as rollups, smart wallets, and data-heavy applications.

2.3 Application

2.3.1 ERC-8196: AI Agent Authenticated Wallet

Discussion and development around agent commerce, in which AI agents autonomously execute on-chain transactions on behalf of users, continue at a steady pace. With the x402 payment protocol pushed by Coinbase and Cloudflare, ERC-8183 standardizing task delegation and settlement between agents, and ERC-8004 defining agent identity all taking shape quickly, agents are now being incorporated as economic actors that move actual capital, not just entities that retrieve information.

For an agent to genuinely move funds on-chain, however, it must be granted some form of key or signing authority, and the current delegation model sits at one of two extremes. If the agent holds a private key directly, the hosting environment can extract that key at any time; if the user signs every transaction themselves, autonomy disappears. In other words, payment infrastructure is being standardized first, without a delegation structure that guarantees both autonomy and control.

With these limitations, efforts to build a dedicated agent stack began to take shape in earnest in late 2025. ERC-8004 grants on-chain identity to agents through an Identity Registry inheriting from ERC-721, and ERC-8126 computes a unified risk score in the range of 0 to 100 by running five categories of verification on that identity, including contract, media, web endpoint, and wallet history checks.

That said, these two standards only answer the question "who is this agent, and how trustworthy is it." They do not provide a clear answer to the execution-time question of "does this agent have the authority to perform this transaction right now." Smart contract accounts based on ERC-4337 and EOA code delegation under EIP-7702 likewise only provide a container for delegation, leaving the policy model that enforces the contents of that delegation undefined. ERC-8196 starts from this gap, explicitly positioning itself as the execution layer within the agentic commerce stack.

The core idea of ERC-8196 is to shift the unit of delegation from a key to a policy hash. Instead of handing the agent a key, the asset owner registers a policy on-chain specifying which actions are permitted (allowedActions), against which contracts (allowedContracts, blockedContracts), up to what value (maxValuePerTx, maxValuePerDay), within what time bounds (validAfter, validUntil), and under what verification conditions (minVerificationScore, per EIP-8126). This policy is hashed as ERC-712 structured data, and every action performed by the agent is signed bound to that policyHash. In parallel, each action includes an entropy commit-reveal (entropyCommitment) to guard against host manipulation, and a hash-chained audit entry (previousHash) for tamper detection. As a result, the agent can execute autonomously without holding a key, and the user can verify every action after the fact, even post-delegation.

In turn, ERC-8196 looks set to ripple across a range of domains, including agent builders, wallet infrastructure, payment protocols, and compliance tooling. For builders, it opens a standard interface in which agents can execute autonomously without holding keys; for wallet infrastructure, it offers a path to be introduced as an ERC-4337 module that enforces policy. Payment protocols such as x402 and ERC-8183 can offload the assumption they have so far made, namely the "legitimacy of the agent's key," to an external standard. Compliance tools, in turn, gain a world in which every agent action is standardized as an auditable unit bound by a hash chain.

In short, ERC-8196 defines how the identity recorded by ERC-8004 and the trust score assigned by ERC-8126 are actually enforced in real fund flows, and can therefore be seen as a key piece in completing the stack needed for the agent economy to move from information exchange into the stage of managing capital.

2.3.2 Others

• ERC-8199: Sandboxed Smart Wallet

3. Progression of Existing EIPs

Meanwhile, beyond the 11 EIPs newly adopted as "Draft" in April, the status of 14 existing EIPs changed over the course of the month. Of these, 10 advanced to the next stage toward final adoption (i.e., "Final," "Last Call," "Review," or "Draft"), and 3 of those reached the “Final” status. The remaining 4 EIPs failed to progress further and were instead moved to "Stagnant" status (i.e., EIP-7919, EIP-8012, EIP-8015, and EIP-8025).

Notably, among the 10 EIPs that progressed this month, all are ERCs implemented at the application layer, with the exception of EIP-8134 and EIP-8135, the “Meta” EIPs that formally record Ethereum's step-by-step increases in blob capacity parameters.

Among the ERCs, the ones most worth highlighting include ERC-7828, a standard for expressing human-readable per-chain addresses and ENS in multi-chain environments; ERC-7945, an ERC-20 interface that supports confidential transactions hiding both balances and transfer amounts; ERC-8063, a standard that interprets ERC-20 token balances as "membership levels," enabling on-chain expression of group membership and permissions; ERC-8126, a verification and risk scoring standard for validating the trustworthiness of AI agents registered under ERC-8004; and ERC-8167*, a proposal to standardize a modular proxy structure that dynamically routes logic modules based on function selectors.

*This was covered in a previous article.

Other EIPs worth referencing are listed below.

3.1 Core / Networking Layer

• EIP-8134: Hardfork Meta - BPO1
• EIP-8135: Hardfork Meta - BPO2

4. “Food for Thought” - Staked Assets at Work, The Prepared Win

Amid active core-layer discussions and substantive EIP proposals, Ethereum's staking ratio reached an all-time high on April. Behind this trend lie two factors: growing institutional investment interest in ETH as a digital infrastructure asset, and a push to capture additional value-creation opportunities by actively deploying staked ETH on-chain.

Source: Korean Blockchain Guidebook for Institutions 2026 | Four Pillars & Pantera Capital

In particular, the roles played by participants in the institutional staking asset market are rapidly evolving from simple staking service providers into comprehensive financial infrastructure providers. As a result, staked assets are no longer defined as a single category called "staking service," but are evolving into a “structured product stack” that combines multiple functional layers. Global players are actively entering each layer of this stack in line with the regulatory environment of their respective jurisdictions, and from the perspective of institutions considering new entry, this means the options for assembling the right partners across each layer to build their own yield generation solution have expanded considerably.

What, then, should be the most important judgment criteria for new institutional entrants navigating this wide array of options? The first is accountability. This encompasses components such as accounting and tax reporting, risk management, liquidity planning, and regulatory compliance, with specialized players, as noted above, in each of these areas. The second is where to position oneself on the spectrum between asset control and on-chain utilization, building on top of that accountability foundation. Put differently, on the basis of above five components, institutions must assess "how much control over their asset a given protocol guarantees, while at the same time leaving room for them to deploy that asset on-chain.”

Source: Korean Blockchain Guidebook for Institutions 2026 | Four Pillars & Pantera Capital

For example, delegating both ETH custody and staking to a licensed staking provider is the most operationally intuitive structure, but it comes with the trade-off of limited on-chain utilization. By contrast, non-custodial staking, white-labeling, or approaches that leverage LSTs preserve control over the asset while substantially expanding the scope for on-chain deployment. That said, the stronger the appetite for on-chain utilization, the more exposure to the operational risk of the protocols being used has to be considered. As a result, how technically cleanly the protocol aligns with the underlying network, and how robust the safeguards it has built for actual users are, become the decisive variables.

For most on-chain solutions, however, the way services are delivered and operated is fundamentally different from traditional Web2 services, which makes it difficult to advance Web3-native operational sophistication while simultaneously meeting Web2 standards of accountability. Even so, at this point, with institutional capital inflows clearly on the horizon, neither side can be set aside.

Protocols like Lido offer an exemplary case along both of these axes. On accountability, Lido recently obtained Web3SOC certification from Cantina, which, combined with its existing stETH Staking Rewards risk assessment and Credora DeFi evaluation, makes it a DeFi protocol backed by external evaluation across all three dimensions of asset, protocol, and organization. On alignment, Lido, despite being the largest LST provider, has aligned itself quickly with Ethereum's technical direction and has actively pushed core initiatives such as validator consolidation, migration aligned with EIP-7251, and the EIP-8205 proposal. In doing so, it has achieved technical robustness while positioning itself as a collaborator that extends its role as a trusted layer for Ethereum.

Institutional adoption and the capture of diverse yield generation pipeline opportunities are already accelerating quickly, and the center of gravity will gradually shift toward solutions with high on-chain utilization. Not everyone, however, will be able to absorb this flow. The market is full of protocols, but those that have first attained the maturity to robustly scale Web3-native operations while rapidly adopting the grammar of Web2, enough to support institutional capital, will be the ones to claim the next stage of on-chain infrastructure.