Monthly EIP - May 2026 (ft. The Staking Issuance Debate and the Responsibility of Scale)

Key Takeaways

• The EIP landscape in May saw a wave of core and ERC proposals aimed at redefining long-held assumptions around transaction, asset, and authorization models, highlighting Ethereum’s continued evolution toward expanding and reshaping its design space.
• In May 2026, amid key personnel departures and growing external coordination efforts, Vitalik argued that the Ethereum Foundation should be viewed not as the center of Ethereum but as a purpose-driven node within a broader ecosystem, underscoring the need to redefine its role around long-term sustainability and core values.
• Meanwhile, the debate over Ethereum’s staking issuance policy, reignited by accelerating institutional capital inflows, ultimately raises a deeper question: how can Ethereum preserve its credible neutrality while managing the growing influence of large-scale staking infrastructure through voluntary norms and self-imposed constraints?

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

The most distinctive feature of May's EIP flow is the continued accumulation of Core EIPs, extending the pattern seen in March and April, alongside a surge of new proposals on the ERC side. Notably, attempts to decompose the constituent elements of the transaction body emerged in parallel with efforts to elevate semantics that have until now been handled indirectly outside the protocol, such as privacy and expiry, to the standard level; as a result, the broader current is less about the breadth of individual changes than about reconfiguring the design space itself.

More specifically, over the course of the month we observed movements that explicitly redefine the existing grammar of the transaction, asset, and approval domains (fixed signature schemes, indefinite approvals, single nonces, and the like): a cryptographically agile model that separates a transaction's signature algorithm from its body, a keyed nonce structure enabling multiple parties under a single sender to issue transactions in parallel, and dual-mode tokens that reconcile transparency and anonymity at the asset-standard level.

ERC standards implemented at the application layer, which can also be read as a reflection of broader industry trends, likewise saw meaningful progress. As we will examine in later sections, standards from distinct domains were adopted in parallel: one for circulating verified identities as non-transferable tokens (ERC-7574), one redefining the indefinite semantics of ERC-20 approvals on a time basis (ERC-8255), and one defining the delegation of authority to AI agents on top of regulated real-world assets (ERC-8226). Particularly noteworthy is the fact that all six existing EIPs that underwent status changes in May were promoted to the next step toward adoption, which suggests that, separate from new proposals, standards in the later stages of the pipeline are likewise maintaining a stable progression cycle.

Meanwhile, apart from these technical currents, organizational developments around the Ethereum Foundation (EF) also moved quickly over the course of May. At least nine senior contributors have left or signaled their departure from the EF since the start of 2026, and five of those announcements were concentrated in May. In particular, with all three Protocol Cluster co-leads, Barnabé Monnot, Tim Beiko, and Trent Van Epps, stepping down in May, the existing lead line of the core protocol research organization was effectively vacated; on May 18, seven-year veteran Carl Beek and four-year veteran Julian Ma announced their departures back to back. A few days later, on May 21, Dankrad Feist, a former EF researcher who had left in 2025 to join Tempo, proposed raising one billion dollars for a separate organization that would more actively champion ETH as an asset, bringing alternative organizing efforts outside the EF to the surface.

Source: X (@VitalikButerin)

Against this backdrop, on May 24, Vitalik Buterin published a long post on X, making clear that it represented his personal view rather than the board's official position. The crux of the post is that the EF will no longer be treated as "the center of Ethereum" but as "one node, with a defined purpose"; choosing longevity over breadth, it will reduce the scale of ETH selling and concentrate resources on areas directly tied to censorship resistance, openness, privacy, and security (CROPS), namely provable integrity through AI-based formal verification, available chain consensus that functions even in asynchronous environments, and intermediary minimization spanning FOCIL, EIP-8141, and Kohaku. The post also explicitly lays out a division of labor in which external organizations (some of which hold more ETH than the EF itself) collectively fill the gap left by the EF's narrowing scope, which can be read as a timely response to the broader pattern of EF-external initiatives, exemplified by Dankrad Feist's proposal just days earlier, establishing themselves as a separate track. How the EF ultimately settles into its new form is likely to become clearer over the coming months.

2. Newly Drafted EIPs

A total of 19 new EIPs were adopted over the course of May, an increase of eight from the previous month. May's new EIPs were dominated by Core EIPs, which call for improvements at the network layer, and ERCs, the standards implemented at the application layer.

Below, we break down the EIPs newly adopted as "Draft" in greater detail and take a closer look at those most worth examining.

2.1 Core & Networking Layer

2.1.1 EIP-8164: Native Key Delegation for EOAs

Ethereum full nodes have long faced the constraint of having to hold the entire full state. Verifying a single line of an account's balance required the entire state trie to be reproduced locally, which has been inefficient both in terms of node operating costs and synchronization time. Initiatives such as stateless clients, state expiry, and partial state were approaches aimed at easing this burden; even so, the data format itself, that is, what nodes should exchange between verification and execution, had never been addressed in earnest. Against this backdrop, EIP-7928 (BAL, Block-Level Access Lists) emerged, bundling information about which accounts and slots were touched during block execution and in what way alongside the block itself, thereby enabling tasks such as parallel execution and pre-validation to be handled on top of the same data.

The problem, however, lies in the scope of information BAL carries. BAL includes the post-value of changed slots, balance, nonce, and code, but the post-block storage trie root of the changed account is missing. Because a state trie leaf is composed of four fields, balance | nonce | code_hash | storage_root, the absence of the storage root alone leaves the leaf itself incomplete and breaks the chain of verification against the post-block state root. Put differently, from the perspective of a partial stateful node, BAL was a tool that assisted execution but could not see verification through to the end.

The crux of EIP-8268 is to add that single missing field to BAL. For each AccountChanges entry in which at least one state change has occurred, storage_root is appended as a trailing field, directly committing the post-block storage trie root of that account. Since balance, nonce, and code can already be reconstructed from the BAL diff, the addition of this one field is enough to populate all four fields of the state trie leaf, allowing anyone to assemble the leaf of a changed account regardless of their own state partition. Entries that were not changed retain the six-field form of EIP-7928 as is.

Although only a single field has been added, the very nature of the information BAL handles changes. The original BAL remained, at most, metadata for parallel execution, that is, a way of signaling in advance which locations were touched and how. The moment storage_root enters the picture, however, BAL also begins to serve as a verification-grade data structure, one through which a partial state node can directly assemble leaves for accounts outside its own partition and verify the post-block state root. There are implications for synchronization scenarios as well: a node coming back online within the weak subjectivity period can directly confirm the integrity of its partition simply by replaying the BAL sequence. In this sense, EIP-8268 can be assessed as more than just a change that appends a single 32-byte field to the BAL format; it is an attempt to narrow the asymmetry between verification and retention on top of the stateless and partial-state roadmap.

2.1.2 Others

• EIP-8246: Remove SELFDESTRUCT Burn
• EIP-8252: Execution-Layer Reorg State Retention Window
• EIP-8254: Cap Deposit Requests Per Block
• EIP-8261: Gas Limit Schedule

2.2 Data / Messaging / Transaction

2.2.1 EIP-8197: Cryptographically Agile Transactions

Ethereum's transaction structure has been locked to ECDSA-secp256k1 as its single signature scheme for over a decade. While EIP-2718 opened room to extend the transaction format by introducing the typed envelope, the fact that accepting a new signature algorithm requires defining a new transaction type each time has continued to weigh on the system. With discussions around the transition to post-quantum cryptography (PQC), multi-signature payloads such as paymasters and frame transactions (EIP-8141), and ZK signature aggregation all advancing in parallel, the practice of minting a new transaction type for every algorithm is gradually approaching its scalability limits.

Account abstraction and attempts to extend the transaction model have partially circumvented this problem. ERC-4337 made it possible to construct arbitrary signature verification logic inside smart contract accounts; even so, protocol-level transactions still had to be signed with ECDSA. Even after EIP-7702 allowed EOAs to delegate code, the outer signature itself remained unchanged, and efforts such as EIP-7932, which addresses the introduction of post-quantum cryptographic algorithms, defined a signature type registry but stopped short of touching the underlying structure of the transaction format.

Against this backdrop, EIP-8197's CATX (Cryptographically Agile Transactions) proposes a model that decouples the transaction body and signature into a flat structure rather than binding them within the same container. The encoding takes the form CA_TX_TYPE || rlp([payload_type, payload_body, (sig_type, sig_body)+]), in which payload_type determines the transaction's behavior (EIP-1559, EIP-4844, EIP-7702, and so on), followed by one or more trailing (sig_type, sig_body) pairs. Because the transaction's semantic component and signature algorithm are handled independently of each other in this structure, swapping signature schemes or requiring multi-signature no longer demands defining a new transaction type.

Moreover, the chained signature hash for multi-signature forces each signer to bind not only the payload but also every preceding (sig_type, sig_body) into their own hash input, structurally foreclosing key substitution attacks that would attempt to alter authorization semantics by replacing only a subset of the signatures. For signature types other than ECDSA, sig_type is included in the hash input during address derivation (keccak256(sig_type || public_key)[12:32]), keeping different algorithms from producing the same address.

The significance of CATX lies in its standardization of a path that allows algorithm transitions without changes to the transaction model. From the builder's perspective, a new signature scheme can be accepted as soon as a PQC algorithm is added to the sig_type registry, with no need to rewrite mempool or verification logic. In scenarios such as paymasters or frame transactions, in which the sender and the sponsor sign the same body for different purposes, the chained hash eliminates the possibility that the sponsor's signature could be substituted for a sender other than the intended one. The trailing-signature structure also provides an interface in which signatures can be separated out and processed in aggregate, giving future ZK-based signature aggregation or batch verification infrastructure a standardized entry point.

2.2.2 EIP-8250: Keyed Nonces for Frame Transactions

Ethereum's sender address has long been treated as an identity that points to a single user or, more precisely, a single actor bound to one EOA. Increasingly, however, designs have emerged in which a single address is meant to represent multiple independent users or usage contexts: the shared withdrawal contract of a privacy mixer, a relayer account entrusted with a smart wallet's session keys, or a paymaster-style sponsor. In such designs, the sender's nonce no longer expresses the transaction ordering of a single user but becomes a common resource over which unrelated parties contend, at times even bottlenecking one another's transactions. The frame transaction introduced by EIP-8141 likewise broadened the scope of transaction abstraction by decomposing verification, payment, and execution into a frame sequence; even so, because the sender continues to operate under a linear, single-nonce structure regardless of who the substantive actor is, the same limitation persists.

To resolve this, EIP-8250 replaces the frame transaction's single linear nonce structure with a (nonce_key, nonce_seq) pair. nonce_key == 0 is reserved as an alias pointing directly to the sender's legacy account nonce, preserving existing replay behavior; all other keys are assigned independent sequences managed directly by the protocol within the storage of a system contract named NONCE_MANAGER. Put differently, transactions sitting on different non-zero keys are independent on the nonce axis, so parties sharing the same sender no longer share a single sequence. Crucially, the moment of nonce consumption is repositioned to align with the payment-approval transition of EIP-8141, with the result that the atomic spent-once guarantee, that a given key can be used only once, is provided directly at the protocol layer.

Through this standard, a privacy protocol's shared withdrawal contract can take 32-byte keys derived from distinct nullifiers and use them directly as the nonce domain, receiving from the protocol layer itself a processing model in which one withdrawal does not invalidate another. Smart wallet session keys, paymaster-style sponsors, and relayer accounts can likewise express concurrent transaction flows that do not interfere with one another under the same sender address; and because key consumption is bound to payment-approval, single-use-key applications are guaranteed atomic protection against double-spending without the need for a separate contract-side nullifier table.

In sum, EIP-8250 does more than merely extend the nonce model of frame transactions; it elevates the "keyed nonce pattern," which ERC-4337 had formalized at the application layer, to the protocol layer, opening up a new concurrency design space across the privacy, session, and sponsor domains.

2.2.3 EIP-8266: Expiring Nonces for Frame Transactions

If EIP-8250, examined earlier, decomposed the legacy nonce structure inherited by frame transactions into a key domain so that multiple parties could issue transactions in parallel under a single sender, EIP-8266 takes on another limitation of the nonce structure, namely that "every transaction must queue up in order, and once a record is written it stays on-chain in perpetuity," and unwinds it along the temporal axis.

Transactions with tight time constraints, such as atomic intents or time-boxed sponsorships, need to eliminate the risk of resubmission within a short window. Ordinarily, a transaction blocks resubmission simply by incrementing a per-sender counter by one; in an expiring mode that leaves the nonce empty, however, the fact that "this transaction has been seen" must be recorded somewhere separately. The simplest alternative is to permanently record the transaction's signature hash (sig-hash) and its deadline in storage, which produces a paradox: as expiring transactions multiply, state accumulates indefinitely, and once the SSTORE cost of writing the first value into an empty slot is added on top, short-lived transactions end up more expensive than ordinary ones. In the end, any attempt to design resubmission protection without a nonce had to shoulder both unbounded state growth and a gas cost explosion at the same time.

EIP-8266 leaves the outer payload structure of the transaction intact and switches into expiring-nonce mode simply by placing the sentinel value EXPIRING_NONCE_SENTINEL = 2**64 - 1 into the existing nonce field. In this mode, the sender's account nonce is no longer read or updated; instead, resubmission validity is delegated to the deadline check of the expiry_verify frame already defined by EIP-8141, and the transaction's signature hash is recorded in a ring buffer within the system contract NONCE_RING. The core logic, when writing a new hash into the ring, first checks whether the prior entry sitting in the same slot has yet to expire.

If the prior entry's deadline has not yet passed (oldDeadline >= now), the transaction itself fails with BufferFull to avoid overwriting a still-valid entry; if the entry has already expired, the slot is cleared and the new entry is recorded in its place. The combination of MAX_EXPIRY_SECS = 60 seconds and RING_CAPACITY = 2**18 is sized to operate up to a sustained throughput of roughly 4,369 TPS without pushing out still-live entries, and EXPIRING_NONCE_GAS = 13000 charges only the read and write cost of the ring, without the additional SSTORE_SET cost that would otherwise accompany opening a new slot, since there is no permanent state growth.

These structural changes show up most directly at the mempool layer. The one-pending-frame-transaction-per-sender constraint recommended by EIP-8141 is lifted in expiring-nonce mode, so a single EOA can have multiple atomic intents or time-boxed sponsorship transactions in flight at once; and because transaction ordering is determined not by the nonce but by the deadline and inclusion timing, intent solvers and paymasters gain room to issue transactions alongside the user's other activity. The permanently occupied state is bounded by 2 × RING_CAPACITY slots regardless of transaction count, and the design naturally converges with the earlier EIP-8250 on top of a reserved key, nonce_key == 2**256 - 1, leaving open the possibility of combining key-domain decomposition and temporal-axis decomposition within a single model. In sum, EIP-8266 does not merely tidy up the resubmission-protection mechanism for short-lived transactions; it can be assessed as a move that repositions the cost of extending nonce abstraction from a problem of permanent state growth into a problem of capacity sizing.

2.2.4 Others

• EIP-8253: Bump nonce of zero-nonce storage accounts

2.3 Account / Contract / Token Standard / Wallet

2.3.1 ERC-7574: Authentication SBT using Credential

Digital space is free of physical constraints, yet the scope and depth of interaction within it still fall short of the real world. The reason is that personal data is locked exclusively into specific platforms, with even the right of control handed over to the platform itself. The individual, as the data subject, has little assurance that sensitive information will be preserved in a trustworthy manner, and so is reluctant to hand it over except where strictly necessary; even data already provided cannot be recomposed and reused across platforms. Decentralized Identity (DID) emerged as a standard in which identifiers are owned and controlled directly by the user rather than the platform, allowing the user to hold and present issued credentials themselves. Even so, putting credentials directly on chain exposes their contents and breaks privacy, and because each service handles credential verification in its own way, DID has not fully taken root on chain.

ERC-7574 proposes an approach in which, rather than placing credentials directly on chain, only the fact that verification succeeded is recorded as a non-transferable Soul Bound Token (SBT). Ownership of the credential is confirmed through a zero-knowledge proof, and the contract issues only the result as a token. The standard refrains from specifying any particular proof system; in its place, it standardizes the format of the result. As a result, service developers no longer need to handle the credential formats and proof systems specific to each issuer; they can identify verified users simply by checking SBT holdings through the ERC-721 interface.

The interface is organized around three functions. verify(bytes verificationData) validates the proof of credential ownership; on success, issueSBT(address to, string tokenURI) issues the SBT; and updateTokenURI(uint256 tokenId, string tokenURI) reflects changes in token state. What stands out is that the specification mandates, at the MUST level, that issued tokens implement ERC-5192 (Locked SBT). Metadata carries only the Issuer and credentialNumber fields, referencing the verification context without any user information; should an issue arise, traceability is handled by requesting a lookup from the issuer using credentialNumber, while the token itself holds no identifiable data. Revocation is likewise handled by updating metadata rather than burning the token, preserving the token's existence and changing only its state, so as to distinguish "never verified" from "verified but subsequently revoked."

What this design changes is the working model of the service developer. Without implementing custom credential-verification logic, a developer can build gating for "participation by verified users only" through the familiar ERC-721 token interface. Put differently, applications that presuppose authenticated users, such as gated DeFi participation, verified metaverse avatars, and reputation systems, can handle access control through a single token-holding check; the user, in turn, can reuse a verification status earned once across multiple platforms. In this sense, ERC-7574 is more than a way of moving KYC procedures on chain; it can be assessed as a primitive that circulates verified identity as a token without compromising privacy.

2.3.2 ERC-8086: Privacy Token

The way privacy assets have been handled on Ethereum has shown a consistent pattern of fragmentation over the past several years. Protocols that emerged after Tornado Cash, such as Aztec and Railgun, all operated on top of what were effectively the same primitives, namely commitments, nullifiers, Merkle trees, and encrypted notes; yet circuit design, proof system, and note encryption scheme differed across each one. As a result, even within the category of zk-based privacy tokens, wallets had to undertake a custom integration for every protocol, and new builders had to reimplement the same cryptographic foundations from scratch each time.

In the meantime, account abstraction standards such as ERC-4337 and EIP-7702 secured flexibility at the transaction layer, and ERC-4626 simplified DeFi integration by standardizing yield-bearing vaults. This wave of standardization, however, did not reach privacy assets. Individual privacy projects opted for either a wrapper model (DAI → zDAI → DAI) or a dual-mode model (a single token holding both transparent and private states); even so, the fact that both rest on the same commitment-nullifier primitive underneath was never surfaced at the interface level. Security audits had to re-verify the same territory each time, and the wallet-side user experience forked along protocol lines.

ERC-8086 takes the approach of constructing these shared primitives as an interface called IZRC20, with implementation details split off into an off-chain Privacy Configuration File. The interface itself exposes only the actions of adding commitments to a Merkle tree, consuming nullifiers, and emitting encrypted notes; which proof system is used, which curves and hash functions are chosen, and which note encryption algorithm is applied are all specified by an external JSON file. This structure borrows the Agent Registration File pattern from ERC-8004, aiming at once for stability of the on-chain interface and accommodation of implementation diversity. As a result, whether the implementation uses Groth16, PLONK, or STARK, or a single tree or a dual-layer tree, the same client can handle it as long as it implements the same IZRC20.

The core interface is centered on two functions, in which proofType plays the role of a dispatcher that allows an implementation to register and route multiple verifiers in parallel. For instance, a dual-layer tree implementation can separate proofs for the active subtree and proofs for the finalized root tree under different proofType values, and should new proof systems be added down the line, a new type can simply be appended without any change to the interface. When a transaction occurs, a Transaction(...) event is emitted, in which viewTag is a one-byte identifier that allows the recipient's client to pre-filter its own notes quickly without having to trial-decrypt every transaction.

This structure stands to reshape the scope of work for developers handling privacy assets. A wallet vendor can support every token implementing IZRC20 through a single integration, dynamically configuring the proof-generation environment by pulling circuit artifacts and public signal schemas from each token's privacyConfigURI(). Wrapper-protocol builders can focus on their asset's deposit-withdrawal logic and governance without reinventing privacy primitives, and those designing dual-mode tokens can implement both the ERC-20 and IZRC20 interfaces in a single contract, allowing the transparent (that is, the standard public token) DeFi path and the privacy path to coexist within one asset. In sum, ERC-8086 can be assessed less as another EIP adding yet another privacy protocol and more as an attempt to standardize, at the interface level, the point at which existing privacy protocols integrate with the wallet and DeFi ecosystem.

2.3.3 ERC-8085: Dual-Mode Fungible Tokens

On Ethereum, privacy has long existed as a "trailing layer" appended outside the base asset. Tornado Cash placed a mixer contract on top of ERC-20, and subsequent efforts, including Privacy Pools, never moved beyond a structure in which existing assets are deposited into a wrapper and then withdrawn in a new anonymous form. Because ERC-20 compatibility was so pervasive and so firmly entrenched, privacy could be tacked on only in a way that left the standard untouched; a "dual-mode" option, in which both modes are designed together from the moment of issuance, was, in practice, never on the table.

The most common workaround, exemplified by Privacy Pools, was to place an existing token inside a wrapper and convert it into an anonymous balance. The approach had the merit of leaving ERC-20 untouched and being attachable anywhere; even so, it produced the side effect of creating two contract addresses, a public version and a wrapped version, for the same token. As a result, DEX liquidity for what was effectively the same asset split into two pools, and market prices drifted apart at the margin. Since balances in the anonymous state could not interact directly with DeFi, the user had to unwrap the wrapped token every time they wanted to trade or post collateral, an ongoing source of friction.

ERC-8085 inverts this premise, starting from the proposition that "privacy is not a separate token but another mode of the same token." A single contract simultaneously inherits ERC-20 and IZRC20 (the zk-SNARK-based privacy interface defined in ERC-8086, discussed earlier) and exposes conversion functions that move between the two modes. Public-mode balances continue to be queried through balanceOf() exactly as before and operate as is, without any additional integration on the part of DEXs or lending protocols. Anonymous-mode balances are held in a separate state tree composed of commitments and nullifiers, but because the same contract address owns both states, token economics and liquidity are unified from the outset.

The interface centers on a pair of conversion functions and a supply invariant:

toPrivate burns the caller's ERC-20 balance while adding a commitment of the same value to the anonymous tree via a zk-SNARK proof; toPublic nullifies an anonymous note and issues a public balance to a specified address. Because both conversions also emit a standard ERC-20 event of the form Transfer(account, address(0), amount), they appear to existing indexers and accounting tools in exactly the same shape as an ordinary burn or mint. The contract enforces the invariant totalSupply() == sum(balanceOf) + totalPrivacySupply() on every call, and the total in anonymous mode is not computed from the tree but tracked solely through additions and subtractions at the moment of conversion. Notably, on the toPublic path, one output note is force-routed to an unspendable BURN_ADDRESS so that the value flowing out through conversion cannot remain inside the anonymous tree, blocking double-spending across modes.

This structure lets issuers treat privacy as part of the issuance design itself, rather than as something appended after the fact. A DAO can keep its treasury and grant distributions in public mode in an auditable state while placing voting-power delegations or private holding positions in anonymous mode to reduce strategy exposure. A business issuer can handle investor reporting and exchange listings in public mode, splitting off competitively sensitive transactions, such as payroll or supplier settlements, into the anonymous mode of the same token. Protocol tokens, likewise, can route DeFi integrations such as staking and liquidity provision through public mode, while activities with large price impact, such as long-term holding or OTC, are routed through anonymous mode. Ultimately, ERC-8085 can be assessed as a new standard through which the Ethereum token standard itself evolves its own utility into a unit that reconciles transparency and anonymity.

2.3.4 ERC-8255: Expiring Token Approvals

On the surface, ERC-20's approve is a simple authorization function. Yet the semantics in which an issued allowance remains valid indefinitely until explicitly changed allow allowance rights over an asset to persist with applications the user approved long ago and has since forgotten, with upgrade contracts whose logic has changed, or even with front-ends that have ceased operating. Reported cumulative losses from approval-based asset theft have reached the hundreds of millions of dollars over the years, and the current reality, in which dedicated approval-cleanup tools such as Revoke.cash have effectively become part of routine wallet management, most directly reveals how pervasive this risk has become across the Web3 ecosystem. Application-side patterns such as ERC-2612's permit, bundled transactions on ERC-4337, and resetting the allowance with safeApprove immediately before a spend are all attempts to work around the problem; even so, the structural limitation that the lifetime of an approval depends on caller-side discipline rather than on the token itself remains in place.

What ERC-8255 proposes is to leave the ABI of ERC-20's approve untouched and redefine only its semantics. Specifically, an existing approve(spender, amount) call is made to expire automatically, with validity limited to the constant maxApprovalDuration() defined by the token contract; should a shorter window be required, it can be specified explicitly through the newly introduced approveForDuration(spender, amount, duration). Because allowanceAndExpiration(owner, spender) returns the current remaining allowance and the expiration timestamp in a single call, a spender contract has no need to issue two view calls, and storage can express the expiration in a single slot as uint256(expiration) << 192) | allowance. The ERC-2612 permit inherits the same default-duration rule while preserving its signature format and nonce behavior; the permit deadline parameter is preserved as a deadline for signature submission rather than for approval expiration.

This change creates room to fundamentally rework approval UX at the wallet and application layers. Even when a user explicitly grants an unlimited approval, the authorization automatically expires within a bounded window, so the responsibility previously borne by post-hoc cleanup tools such as Revoke.cash moves to the token contract itself. On the application side, a pattern of issuing a short-duration approval immediately before completing a transaction and letting it expire naturally after use stands to take hold as the standard flow. The EIP also opens an opt-in path for preserving the existing indefinite semantics, but only for legacy-compatible spenders explicitly registered by the token admin or by the spender itself, leaving a route for gradual migration that does not break earlier integrations built on the premise of perpetual approvals.

2.3.5 Others

• ERC-8040: ESG Tokenization Protocol
• ERC-8084: Zero-knowledge proof metadata
• ERC-8179: Blob Space Segments
• ERC-8180: Blob Authenticated Messaging

2.4 Application

2.4.1 ERC-8226: Regulated Agent Mandate

The tokenized real-world asset (RWA) market has, through investor-eligibility standards such as ERC-3643 and ERC-7943, built up a reasonable measure of compliance infrastructure at the issuance stage. In parallel, standards such as ERC-8004, which address the identity and trust level of AI agents that autonomously execute trades, are likewise settling into place on a separate track. What has been missing, however, is the standard that bridges the two, that is, a means of expressing on-chain which verified entity has delegated which powers to which agent and within what limits. ERC-8226 defines this delegation relationship itself as an independent contract layer.

ERC-8226 separates into distinct contracts the IComplianceProvider, which verifies the eligibility of the principal (the party delegating authority), and the IAgentMandate (the RAMS registry), which manages the issuance, extension, revocation, and enforcement of mandates. The scope of delegation is bifurcated into an IPFS-hosted JSON scope document and MandateScopeParams, the subset of that document enforced on chain, with the human-readable agreement and the chain-enforced limits bound together under a shared scopeHash.

A regulated token, inside its existing pre-transfer hook (for example, ERC-7943's canTransfer), dereferences the principal from the agent wallet via getActivePrincipal(agentId), then doubly verifies principal eligibility and isActiveForAmount(agentId, principal, amount), updating the cumulative usage through recordExecution. Freezing authority explicitly distinguishes between PLATFORM and REGULATORY through EnforcerTier, with global freezing reserved for the regulatory tier alone.

The significance of this structure lies in its capacity to allow institutional RWA platforms to operationalize AI-agent-driven portfolio management in a legally defensible form. The constraint of one active mandate per agentId is, in effect, a direct on-chain transposition of the traditional finance convention in which a portfolio manager segregates accounts by client to guarantee audit traceability; an asset manager satisfies this requirement by deploying a separate agent wallet for each principal via CREATE2.

Fixing the value limit in the token's base unit, thereby removing dependence on FX oracles, and designing cumulativeUsed so that it is not reset even on extendMandate are likewise choices that prioritize the integrity of the delegation contract as a unit. With the issuer's eligibility determination (who may hold the asset) and the principal's grant of authority (whom may be instructed to do what) separated into distinct layers, agent operations can now be standardized without encroaching on the sovereignty of the token issuer. In this sense, ERC-8226 is more than a standard codifying the trading authority of autonomous agents; it can be assessed as the first outline of the legal and technical interface required for an autonomous-agent economy to operate on top of regulated digital assets.

2.4.2 Others

• ERC-8257: Agent Tool Registry

3. Progression of Existing EIPs

Meanwhile, separately from the 19 newly adopted EIPs, six existing EIPs underwent status changes over the course of May. What stands out is that all six were promoted to the next step toward final adoption (that is, to stages such as 'Final,' 'Last Call,' 'Review,' or 'Draft').

Among the ERCs, those particularly worth noting include: ERC-4337, the account abstraction standard that, without any change to the consensus layer, allows users to use a smart contract account with its own verification logic as their primary account in place of an EOA, through a separate mempool and a UserOperation, bundler, and EntryPoint structure; ERC-7943, an interface standard that overlays minimal compliance functions such as transfer-eligibility checks, freezing, and forced transfers onto existing token standards, thereby standardizing real-world asset (RWA) tokens in a regulation-friendly manner; ERC-8126, a verification and risk-scoring standard for assessing the trustworthiness of AI agents registered under ERC-8004; and ERC-8063, a standard that interprets an ERC-20 token's balance as a "level of membership," allowing group membership and permissions to be expressed on chain.

Among the non-ERC EIPs, those worth noting include: EIP-8163, a standard that reserves a single opcode slot (0xae), which will not be used on Ethereum L1, so that other EVM chains can experiment with new instructions.*

*This was covered in our previous article.

3.1 Core / Networking Layer

• EIP-8013: Static relative jumps and calls for the EVM

3.2 Account / Contract / Token Standard / Wallet

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

4. The Staking Issuance Debate and the Responsibility of Scale

Ethereum's staking demand is accelerating at an unprecedented pace. As of May 2026, the staking ratio reached an all-time high, nearing 33% for the first time ever, with roughly 2.8 million ETH stacked up in the staking queue, equivalent to 48 days of inflow. The primary driver of this trend is not so much new inflows from retail solo stakers as institutional capital channeled through ETFs, DATs (Digital Asset Treasuries), and institutional staking products. With institutions holding ETH rapidly shifting their asset management model away from simply holding the asset toward one that captures staking yield as well, the pace at which ETH flows into the staking layer has entered a markedly faster phase.

This trend, however, has pushed a scenario long worried over by Ethereum Foundation researchers back to the front of the policy debate. Ethereum's staking reward curve is designed such that, as the total amount of staked ETH grows, the yield per validator declines in inverse proportion to its square root; even so, the central concern has been that once staking crosses a certain threshold, more ETH is issued as rewards than the level appropriate for network security, diluting ETH holders, while LSTs such as stETH simultaneously threaten the moneyness of ETH itself.

Ansgar Dietrichs and Caspar Schwarz-Schilling introduced the staking-ratio-targeting frame in their endgame staking economics discussion, and Mike Neuder and others formally proposed a reward-curve adjustment, building on this work, to be applied at the Pectra (then known as Electra) upgrade. In April of the same year, Anders Elowsson laid out the tempered issuance reward curve in an EIP research post, and in the second half of the year he followed up with an extended endgame reward curve proposal. At the time, the discussion was drowned out by pushback from the staking industry and controversy over the Foundation's influence; in 2026, however, with the acceleration of institutional staking becoming visible, the same discussion has resurfaced.

On the surface, the policy debate is a monetary-policy trade-off framed as "how should the dilution of ETH holders be handled, or should the current issuance policy be preserved to protect other values?" The proponents argue that staking beyond a certain threshold enters a region in which the cost of ETH dilution for holders and erosion of LST moneyness outweighs the marginal contribution to security; Justin Drake's estimate that "roughly one-quarter of circulating ETH represents the optimal security budget" sits on the same line of reasoning.

By contrast, opponents argue that Ethereum, still well short of the market-cap scale befitting a global settlement layer, is in no position to declare that it has "enough security" at this point, and that issued ETH should be viewed less as a cost than as reinvestment aimed at building out a broader validator base. They also note that, with the introduction of Lido's Dual Governance, concerns over LST dominance are gradually being addressed at the governance layer; in their view, altering monetary policy to address a specific market structure risks subordinating Ethereum's long-term roadmap to short-term concerns. Both sides argue their case consistently, and the difficulty of declaring either side plainly correct is itself part of why the policy debate has run in parallel lines for years.

That said, whichever direction the conclusion takes, from a validator-economics perspective it appears relatively clear that the relative standing of large staking infrastructure will be reinforced. In the first scenario, in which issuance is maintained, the current accumulation of staking demand carries on as is. Should the inflow of ETF and DAT capital into the staked-ETH layer through LSTs and institutional staking products continue, the AUM of large LSTs, including Lido, and institutional staking providers will expand naturally in step with the rising staking ratio. Since fee revenue is the product of AUM and yield, absolute earnings rise in tandem. LSTs such as stETH, which have already secured collateral and composability network effects across DeFi, will see their lead over later entrants widen with time; as a result, large staking infrastructure is likely to settle in as the default option of the staking layer.

Paradoxically, even in the second scenario, in which issuance is reduced, the relative advantage of large staking infrastructure is reinforced. Because much of the solo staker's operating-cost structure consists of items that cannot be trimmed, a decline in yield translates directly into margin compression; large operators, by contrast, can pass that shock through to delegators by adjusting the fee rate they charge. As yields fall, solo stakers are the first pushed below break-even, and the gap left behind is absorbed by large CEXs, LSTs, and institutional staking products that hold bargaining power. From the user's perspective, delegated options that bundle convenience and liquidity become more attractive than running a validator directly.

The fact that the share of large staking infrastructure structurally expands under both scenarios means that their governance decisions, operator selection, slashing-risk management, and influence over ETH governance become core variables of Ethereum's security model in their own right. Because such organic influence is difficult to check through external regulation or protocol-level constraints alone, the establishment of self-imposed standards by large staking infrastructure itself, including caps on market share, diversification of the validator set, and delegation of governance authority, becomes the most realistic mechanism for preserving Ethereum's credible neutrality.

This sits well beyond simple profit maximization; it belongs to the heavier domain of responsibility in which large operators must recognize the scale of their own share as a systemic risk and reflect that recognition in their operating principles. Lido's introduction of Dual Governance, despite the overwhelming dominance it held early on, granting stETH holders a veto over dangerous protocol decisions and a path to redeem into ETH; its provision, through stVaults, of independently operated validator sets and customized operating options for institutional participants; and its sustained expansion of the operator base through DVT-based distributed validators and a variety of modules all sit along the same line.

In the end, as the set of stakeholders grows more diverse, protocol change inevitably slows and conflicts of opinion grow more frequent. The greater the diversity, the more Ethereum's principal participants must keep returning to the direction and principles that have long been shared across the ecosystem. And perhaps the question worth asking is how to design mechanisms that uphold those principles through voluntary discipline rather than coercion.