Monthly EIP - Jun 2026 (ft. Ethereum at a Multipolar Turning Point)

Key Takeaways

• In June, ERC proposals continued to expand their scope, addressing regulatory compliance, asset transfers between privacy pools, and mechanisms for carrying token balances at a specific snapshot into a newly issued token. At the core layer, meanwhile, discussions explored separate design paths for more specialized requirements, including staking privacy, pre-distribution of blob data, and account validation based on shared state.
• At the same time, the Ethereum Foundation’s workforce and budget cuts, its broader organizational restructuring, and the launch of Ethlabs began to reveal a more distinct division of roles: the EF would focus on preserving Ethereum’s neutrality and self-sovereign properties, while external organizations would work to accelerate institutional adoption and broaden the utility of ETH.
• The shift from an EF-centered model toward a more multipolar development ecosystem may therefore become a new experiment in decentralization: one that tests whether multiple organizations can balance the interests of their backers with the independence of their research, while maintaining a shared sense of direction and responsibility without a single center.

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 notable feature of June’s EIP activity was a modest decline in the adoption of new Core EIPs compared with the previous three months, alongside the emergence of several new ERC proposals, particularly around token standards. These proposals sought to broaden the scope of asset standards in several directions: introducing functions such as freezing and tracing to accommodate regulatory requirements, extending existing ERC-20 functionality to migrate historical ownership structures into newly issued tokens, and transferring private asset states between separate privacy pools. At the core layer, proposals likewise explored dedicated design paths for specialized use cases, including privacy-preserving deposits and withdrawals, blob transmission that allows data to be committed in advance, and account validation that must reference shared state within a frame transaction context.

Progress among existing EIPs also reflected emerging application-level demand. Standards addressing regulatory asset controls(ERC-1450), explicit transaction execution conditions(ERC-7796), and the verification and permission management of AI agents(ERC-8196), were particularly notable. Meanwhile, ERC-4337 and a range of other account abstraction and ERC-related standards continued to advance in status, while ERC-2770, EIP-7701, and ERC-7766 were moved to “Withdrawn.”

Taken together, June was not only a month in which new design approaches emerged, but also one in which existing standards supporting regulated assets, conditional execution, and agent-based applications moved closer to practical adoption.

Meanwhile, the wave of senior contributor departures that stood out in May began to take clearer form in June as a broader reorganization of Ethereum’s research and execution landscape. On June 18, Hsiao-Wei Wang announced that, following the end of her sabbatical, she would step down as co-executive director of the Ethereum Foundation and leave its board. Five days later, the EF announced the completion of a months-long restructuring process and the departure of 54 employees, representing roughly 20% of its workforce. Vitalik Buterin also stated that the EF’s annual budget would be reduced by approximately 40%, while the organization itself was reorganized into five layer-based clusters (i.e., Protocol, Access, User, Community, and Institution) alongside dedicated operations and management functions. This can be viewed as the first concrete reflection, across staffing, budget, and organizational structure, of the direction outlined in May: the EF would no longer position itself as the center of Ethereum, but as one node with a clearly defined purpose.

Source: X(@ethlabs_org)

Importantly, the contraction of the EF did not simply translate into a corresponding decline in Ethereum’s overall research capacity. On June 22, one day before the restructuring was formally announced, five former senior EF researchers (i.e., Ansgar Dietrichs, Barnabé Monnot, Caspar Schwarz-Schilling, Josh Rudolf, and Julian Ma) launched Ethlabs, an independent nonprofit research organization. Backed by BitMine, SharpLink, Joe Lubin, Anchorage, Octant, SNZ, and others, Ethlabs stated that it would pursue a separate research track focused on areas critical to institutional onchain adoption, including payment finality, mainnet scaling, data availability, interoperability, and the economic properties of ETH. As the EF narrows its role toward that of a protocol steward protecting Ethereum’s self-sovereign properties such as censorship and capture resistance, privacy, and security, research more directly tied to institutional adoption and the economic value of ETH is beginning to shift toward specialized external organizations.

These developments are therefore better understood not simply as a weakening of the EF’s influence, but as a process through which responsibilities that had previously coexisted within a single organization (protocol neutrality, ecosystem growth, institutional adoption, and ETH advocacy) are being distributed across a broader set of actors. The creation of an Institution layer within the EF, however, suggests that institution-facing work has not been outsourced entirely. The EF is likely to focus on standards and reference architectures that allow institutions to adopt Ethereum without compromising privacy, data portability, verifiability, or the ability to exit, while external organizations such as Ethlabs and Etherealize may take a more direct role in connecting performance, real-world deployment, capital, and industry demand.

Ultimately, the significance of June’s restructuring lies less in what the EF has given up than in the fact that responsibility for different objectives within the Ethereum ecosystem is beginning to be divided more explicitly.

2. Newly Drafted EIPs

A total of 10 new EIPs were adopted as Drafts in June, nine fewer than in the previous month. This month’s additions were largely split between Core EIPs, which propose changes at the network level, and ERCs, which define standards implemented at the application layer.

The following section provides a more detailed breakdown of the newly drafted EIPs and takes a closer look at several proposals that warrant particular attention.

2.1 Core / Networking Layer

2.1.1 EIP-8222: Lean Staking

Staking is one of the activities on Ethereum in which identity and capital remain publicly linked for the longest period of time. As institutional demand for Ethereum staking continues to grow, the persistent connection between deposit addresses and validator keys has therefore become an increasingly visible privacy concern. Public deposit records alone can reveal the size of an institution’s position and aspects of its operating patterns, while also making it easier to associate individual operators with their offchain identities. Until now, users have had to rely on mixers or separate privacy contracts to break this connection, but because liquidity is fragmented across individual contracts, these solutions have struggled to form sufficiently large anonymity sets. Moreover, as the sanctions against Tornado Cash demonstrated, dependence on external mixers introduces not only technical friction, but also legal and political risk.

EIP-6110 created the foundation for a different approach by moving deposit verification into the execution layer, making it possible to separate deposits from validator registration within the staking contract itself. Building on this change, EIP-8222 proposes decoupling the moment funds are deposited from the moment a specific validator is registered, thereby breaking the public onchain link between the two actions.

Rather than immediately submitting a validator public key and withdrawal credentials, a depositor places at least 1 ETH, together with a commitment of the form hash(nullifier_preimage | validator_key | withdrawal_cred | amount), into a Pending Deposit Tree. The deposit and its amount remain public, but the validator to which the funds will eventually be assigned is not revealed. At a later point, a relayer or account abstraction bundler submits a zero-knowledge proof showing that a valid commitment exists in the tree, after which the deposit is transferred into the validator activation queue. The contract records the corresponding nullifier to prevent the same deposit from being claimed twice, while binding the validator key and deposit amount to the proof prevents an attacker from intercepting or redirecting the claim.

The proposal extends the same structure to withdrawals. Under the new 0x03 withdrawal credential, validator funds are not transferred directly to a designated address, but are instead placed into a Pending Withdrawal Tree, from which the recipient later claims them by submitting a separate proof. This weakens not only the link between the deposit address and the validator key, but also the connection between the validator and the final withdrawal address. For institutions and staking providers, this could reduce the extent to which treasury wallets, active validators, and fund-recovery addresses are exposed as part of a single, publicly traceable flow of capital.

EIP-8222 does not, however, make validators fully anonymous. Distinctive deposit amounts, the time interval between deposit and claim, and other behavioral patterns may still provide clues for tracing, while validator IP addresses and network activity require protection through separate mechanisms. The proposal also introduces new operational requirements, including zero-knowledge proof generation, secure storage of secret values, and relayer infrastructure, meaning that complexity is not eliminated so much as shifted elsewhere. Even so, EIP-8222 represents the first concrete attempt to bring staking privacy, previously delegated to external mixers, directly into Ethereum’s native deposit and withdrawal flow.

2.1.2 EIP-8256: Blob Streaming

Discussions around blob scaling on Ethereum have so far focused largely on how much data each node can process and verify; EIP-4844 introduced a separate data space for blobs, while PeerDAS reduced the amount of data each node must download. Yet the data still needs to reach the network within the narrow window in which a block is proposed. Increasing throughput under this constraint requires either transmitting more data within the same period or extending the time allowed for block propagation, but the latter gives builders more time to observe market conditions before deciding whether to publish a block. EIP-8256 instead proposes reserving transmission capacity in advance and distributing data before the relevant slot, spreading the propagation burden over time and making delivery more reliable.

The proposal divides blob delivery into two paths: Ahead-Of-Time(AOT) and Just-In-Time(JIT). AOT users purchase tickets from a system contract to reserve transmission capacity for a future slot, then propagate the actual blob data in advance through dedicated consensus-layer subnets. Rollup sequencers that need to finalize batch contents immediately before block production, by contrast, can continue using the JIT path and transmit their data at block time. Under the current specification, transactions with max_fee_per_blob_gas == 0 are classified as AOT, while those offering at least the current blob_base_fee are treated as JIT. Demand from both paths is then reflected in a single shared blob base fee.

A ticket is, in effect, a reservation for the right to propagate a certain amount of blob data in a designated future slot. A user registers (blob_count, bls_pubkey) and prepays the associated cost, with the usable slot set TICKET_LOOKAHEAD slots after the purchase. The user later signs the data with the registered BLS key, after which nodes verify the ticket, the signature, and the KZG proof before accepting and forwarding the data. Because tickets are non-refundable, participants that reserve capacity without transmitting data incur the same cost as genuine users. At the same time, the network can cap in advance the total amount of data eligible for propagation in each slot.

In essence, EIP-8256 changes how blob data is delivered before block production. Blobs already included in a block are currently propagated through consensus-layer objects such as BlobSidecar, or DataColumnSidecar under PeerDAS. Before inclusion, however, the execution-layer blobpool still distributes the blob contents and KZG verification data alongside the transaction body. EIP-8256 removes the raw blob data from the blobpool and instead allows AOT data to spread through dedicated consensus-layer subnets before the relevant slot. To coordinate this process, the execution and consensus layers exchange activeTickets and availableAotBlobCommitments, reconciling reserved capacity, data that has actually arrived, and the transactions eligible for block inclusion.

Source: EIP-8256

The practical significance of EIP-8256 lies in its use of the time before a slot to increase blob throughput, rather than simply extending the block propagation window. Rollups that can finalize their batches early may reserve capacity through AOT, while those whose data remains mutable until the last moment can continue using JIT, allowing different propagation strategies for different operational needs. A ticket, however, only grants the right to propagate data and does not guarantee block inclusion. Because ticket purchases reveal future demand in advance, the design may also introduce front-running opportunities and leave some dependence on builders intact. With several major blob-related constants still marked TBD, and with changes required across the execution layer, consensus layer, and Engine API, EIP-8256 is better understood not as a complete scaling solution, but as a new propagation architecture intended to translate PeerDAS’s verification efficiencies into higher practical throughput.

2.1.3 Other(s)

• EIP-8279: Block Access List Byte Floor

2.2 Data / Messaging / Transaction

2.2.1 EIP-8272: Recent Roots for Frame Transactions

Under account abstraction, the rules that determine whether a transaction is valid can be defined directly by each account’s contract code. The difficulty arises when validation depends on the latest state of an external contract shared by many users. If a transaction that changes that state is included first, a large number of transactions already sitting in the mempool may suddenly become invalid because they were validated against an earlier state. To prevent nodes from repeatedly revalidating and clearing such transactions, Frame Transactions, introduced in EIP-8141, place strict limits on directly referencing mutable state belonging to other accounts during validation.

These restrictions help protect the public mempool, but they also narrow the range of functions that accounts can support. Privacy applications, for example, may aggregate commitments from many users into a single tree, while wallet services may maintain authorization keys or security policies shared across multiple accounts. In such cases, the latest permissions or proofs cannot easily be verified using only an account’s internal state. Account abstraction therefore faces a persistent trade-off: greater validation flexibility can weaken mempool stability, while tighter mempool protections make shared state harder to use.

As a compromise, EIP-8272 does not allow validation code to read external state freely. Instead, it requires applications to publish a 32-byte root that compresses the relevant state at a specific point in time. When submitting a transaction, the user specifies the slot containing the root against which validation should be performed, and the node first checks that the root was indeed published recently. Rather than reading the constantly changing current state of an external contract, the validation code relies on a fixed snapshot bound to the transaction. Even after a newer root is published, the transaction can continue to be validated under the same conditions until its designated root expires or disappears because of a chain reorganization.

This structure would allow shared state, such as privacy trees, collective authorization lists, and common security policies, to be used in a limited and predictable manner within the public mempool. Rather than expanding validation freedom without constraints, it introduces shared state in a form that allows nodes to identify dependencies and validity windows in advance. Applications must still publish roots on time and ensure that each proof is bound precisely to the relevant application, slot, and root, while nodes must track both expiration and chain reorganizations. In this sense, EIP-8272 complements EIP-8141 by creating a controlled middle ground between the expressiveness of account abstraction and the stability of the public mempool.

2.3 Account / Contract / Token Standard / Wallet

2.3.1 ERC-8047: Forensic Token (Forest)

For onchain assets that require freezing and tracing capabilities—such as stablecoins, tokenized deposits, and securities—the more difficult problem is often not whether suspicious transactions can be prevented in advance, but whether illicit and legitimate funds can be separated precisely after an incident occurs. In account-based models such as ERC-20 and ERC-3643, funds arriving through different paths are combined into a single balance, making it difficult to isolate only the portion associated with a particular transaction. Controlling suspicious funds may therefore require freezing an entire address or a specified amount, potentially restricting legitimate assets held in the same account. ERC-8047 proposes lowering the unit of post-incident enforcement from the account level to the transaction lineage of individual token units, represented as a directed acyclic graph(DAG).

To achieve this, ERC-8047 represents money not as a single aggregated balance, but as a collection of individual Token nodes, each containing a root, parent, value, level, and owner. A newly issued token uses its own ID as its root. When a transfer occurs, the value of the existing token is reduced or set to zero, and a new child ID is created for the recipient. In a partial transfer, the remaining value stays with the parent token, while a new token equal to the transferred amount is created at the next level. A transfer, therefore, is less an update to the owner of an existing balance than the spending of one node and the creation of another that continues its lineage.

This lineage can, in turn, serve as an index for regulatory or enforcement actions. Tokens originating from the same issuance unit share a common root, while level indicates how many transfers have occurred since issuance. This allows an implementation to isolate not only a specific token ID, but also an entire lineage or tokens located before or after a particular level. The reference implementation, TPEn, or Token Policy Enforcement, uses bucket := shr(8, level) and bitIndex := and(level, 0xFF) to compress the freeze status of 256 levels into a single bitmap, checking only the relevant bit during a transfer. The specification’s claim of O(1) complexity means that policies can be set and checked without iterating through every descendant token; it does not imply that tracing the full transaction lineage or calculating the total spendable balance can always be completed in constant time.

Were this standard to be adopted, the most substantial operational changes would emerge at the wallet and indexer layers. A single address could hold multiple IDs belonging to the same nominal asset but associated with different root values and freeze statuses. Wallets would therefore need coin-selection logic to determine which tokens to spend, as well as support for batch transfers, rather than simply deducting an amount from an aggregate balance. ERC-8047 similarly proposes that spendable balances be calculated by offchain services subscribing to events such as TokenCreated, TokenSpent, and TokenMerged. Although the standard inherits from ERC-1155 and ERC-5615, allowing existing interfaces and event tooling to be reused, its operating model differs substantially from that of conventional tokens because a single fungible asset is divided into multiple serialized fragments.

The trade-offs are equally clear. Spent tokens are retained to preserve their lineage, meaning that state continues to accumulate as transactions are repeated, while high decimal precision and frequent micropayments could increase ID fragmentation and batch-transfer costs. Because parent-child relationships are public, transaction privacy is weakened, and combining legitimate tokens with sanctioned ones in a single transfer may blur the risk profile of both. Most importantly, ERC-8047 defines a traceable data structure, but leaves questions of authority and procedure—including who may freeze assets and how errors or reversals should be handled—to individual implementations. It is therefore better understood not as a general-purpose monetary standard, but as an architecture for regulated assets that trades away some privacy, state efficiency, and straightforward fungibility in exchange for more precise post-incident enforcement.

2.3.2 ERC-8054: Forkable ERC-20 Token

ERC-20 is sufficient for recording current balances, but it does not define how the ownership structure at a particular point in time should be carried over into a new token. As a result, protocols that migrate an existing token to a new contract—or distribute governance or reward tokens to holders at a given snapshot—typically need to build a separate snapshot, Merkle tree, and claim contract. In practice, ownership records that already exist onchain must be reprocessed into an external dataset, while protocols bear the cost of distribution and proof generation and users must claim their allocations themselves. ERC-8054 seeks to standardize this process onchain by adding checkpoint-based balance histories to ERC-20 and allowing a new ERC-20 token to inherit the ownership structure recorded at a specific checkpoint.

The existing ERC20Snapshot mechanism can also retrieve balances at a particular point, but the contract operator determines when each snapshot is created, and the mechanism does not standardize how those balances should be used to create a new token. By contrast, an ERC-8054 source token records checkpoints for balances and total supply whenever a transfer, mint, or burn occurs, producing a continuous history without a separate snapshot-generation process. Because checkpoints are identified by nonces rather than block numbers or timestamps, the design also reduces ambiguity over the precise fork point when multiple transactions occur within the same block.

The source token implements the IERC20Checkpointed interface, including totalSupplyAt(checkpoint), balanceOfAt(account, checkpoint), and checkpointNonce(). Each transfer, mint, or burn creates a new checkpoint, while queries for checkpoints that do not yet exist must revert with ERC20FutureCheckpoint. The creator of a fork can therefore reference balances directly attested by the source contract, rather than submitting an independently compiled holder list or Merkle root. Maintaining this history, however, requires additional storage operations whenever the source token’s state changes, meaning that the ongoing cost of preserving future forkability is shared by users conducting ordinary transfers.

When a forked token is deployed, it specifies a checkpointedToken and checkpointedNonce, then derives its initial supply and account balances from totalSupplyAt() and balanceOfAt() at that checkpoint. This does not mean that every holder’s balance is copied into the new contract at once. Instead, the forked token uses lazy loading, referring back to the source token’s historical balance until an account undergoes its first state change. Once that account sends or receives tokens, its balance is materialized within the forked token and evolves independently from the source thereafter. In this sense, “gasless distribution” does not mean that creating the token is free; rather, it eliminates the need for transfers to every holder or separate claim transactions from individual users.

The structure can support not only token migrations and reward distributions, but also the creation of separate governance rights or distinct risk-and-return profiles while preserving an existing ownership structure. Because the forked asset continues to behave as a standard ERC-20 token, existing wallets and applications should require relatively little adaptation. Allowances and permit nonces, however, are not inherited, so users must approve the new token separately. Moreover, tokens with rebasing mechanics, transfer fees, or other balance changes that do not follow standard ERC-20 transfer semantics may produce a mismatch between the recorded checkpoints and the underlying economic rights.

In short, ERC-8054 is less a general-purpose mechanism for “forking” an entire protocol than a standard for reusing a verifiable onchain ownership structure at a chosen point in time. Its design is therefore best suited to tokens for which the convenience of future migrations, distributions, or rights separation justifies the continuous storage overhead required to preserve that history.

2.3.3 Other(s)

• ERC-8100: Representable Contract State
• ERC-8273: Attestation-Gated Agentic Actions

2.4 Application

2.4.1 ERC-8290: Shielded Note Teleportation

The limitations of privacy protocols become most apparent not in how effectively they conceal activity within an individual pool, but at the moment users move between separate pools. If assets are withdrawn publicly from one pool and then deposited into another, the two transactions may be linked by combining their amounts, timing, asset types, and source and destination addresses. As a result, even when each protocol has built a sufficiently large anonymity set, users must leave that protected environment whenever they switch protocols. ERC-8290 proposes replacing this publicly observable flow of assets with the transfer of a proof that a valid asset existed within the source privacy pool.

The proposal builds on the “ZK Wormhole” introduced in EIP-7503, which sends assets to an address with no identifiable owner and later uses a zero-knowledge proof to demonstrate that they were burned. EIP-7503, however, concerns a core protocol change that would allow ETH to be privately burned and reissued, whereas ERC-8290 extends the concept into an application-layer interoperability standard for UTXO-based privacy protocols. An existing pool can serve as a source without changing its native format, provided that an adapter can express its note commitments and prove their inclusion under a recognized root. Still, proving that assets were locked in the source pool is distinct from ensuring that equivalent assets are available at the destination, so the proposal does not by itself replace bridges or liquidity infrastructure.

burnAddress = H(chainId, dstPoolAddress, receiver, burnSecret, "ZKTELEPORT")

The user first derives a burnAddress by binding together the destination chain, destination pool, recipient, and a secret value called burnSecret, then assigns that address to the note in the source pool in place of its previous owner. Because the address is derived for a specific destination, the same note cannot be reused on another chain or against another contract. A subsequent teleport proof demonstrates that the note genuinely exists in the source pool, that the pool’s root is included in a canonicalRoot trusted by the destination, and that asset information such as the token and amount is preserved. Protocols with different note structures or hash functions can connect their own verification logic to this common flow through adapters.

The destination contract first verifies that the source pool’s root is trusted, then checks the proof and records a nullifier to prevent the same note from being used twice. A zero-knowledge proof, however, establishes only that a valid asset existed in the source pool; it does not guarantee that the destination can actually deliver the corresponding asset. Separate backing arrangements—such as escrowed liquidity, new issuance, protocol-owned reserves, or bridge settlement—are therefore still required.

If adopted, this structure could connect the anonymity sets of otherwise distinct privacy protocols without forcing them to converge on a single format, allowing smaller pools to inherit some of the privacy benefits of larger ones. At the same time, faulty adapter or root-registry implementations could result in double-spending or asset inflation, while the timing of a transfer may remain observable. ERC-8290 is therefore best understood not as an attempt to merge privacy pools, but as a common interface for transferring private asset states while allowing each protocol to retain its own rules and architecture.

2.4.2 Other(s)

• ERC-8217: Agent NFT Identity Bindings

3. Progression of Existing EIPs

Alongside the 10 newly drafted EIPs, 12 existing proposals changed status over the course of June. Nine advanced to the next stage toward final adoption, including Draft, Review, Last Call, and Final, while three (i.e., ERC-2770, EIP-7701, and ERC-7766) were moved to Withdrawn.

Several of the advancing standards are particularly noteworthy; ERC-1450 defines a security-token standard designed for compliance with Regulations CF, D, and A by preventing token holders from directly calling transfer or approve and allowing only an SEC-registered transfer agent, or RTA, to issue, burn, and transfer tokens. ERC-7796 introduces the eth_sendRawTransactionConditional RPC, which allows a transaction to specify preconditions tied to the state of particular accounts. This enables builders to determine whether a transaction is eligible for inclusion without running a full simulation, while handling cross-transaction dependencies at lower cost. ERC-8196, meanwhile, proposes a wallet standard that constrains the actions AI agents may perform through onchain policies and records an auditable signed log for every execution, allowing owners to retain control over autonomous agents without handing over their private keys.

Other advanced EIPs are listed below.

3.1 Core / Networking Layer

• EIP-8133: Network Upgrade Naming

3.2 Data / Messaging / Transaction

• None

3.3 Account / Contract / Token Standard / Wallet

• ERC-4337: Account Abstraction Using Alt Mempool
• ERC-5516: Soulbound Multi-owner Tokens
• ERC-7813: Store, Table-Based Introspectable Storage

3.4 Application

• ERC-8126: AI Agent Verification
• ERC-8161: Transferable Tokenized Vault Requests

4. Ethereum at a Multipolar Turning Point

Source: Twitter(@trent_vanepps)

In June, Trent Van Epps drew considerable attention by warning that funding for Ethereum core development could run short within the next three to nine months. More important than the possibility of development actually coming to a halt, however, is the question of who will lead Ethereum as the ecosystem works to address that risk. Until now, the Ethereum Foundation has supported long-term research and core development through the capital, talent, and institutional trust it has accumulated over time. The debate over funding shortages is therefore also a debate over which organizations and stakeholders will take on the responsibilities that the EF has gradually begun to relinquish.

The greatest strength of the EF-centered model was its ability to support work that the protocol required, even when that work offered no immediate path to revenue. It could fund public goods such as client development, security research, and upgrade coordination over long periods, largely independent of any single company’s performance, token price, or prevailing market narrative. At the same time, the concentration of funding and talent within one organization meant that the EF’s judgments were often treated as priorities for Ethereum as a whole, giving it influence well beyond its formal authority. The EF’s decision to reduce its role can be understood as an attempt to lower this dependence, but the space it leaves behind will not necessarily be filled automatically by healthy markets or capable new institutions.

Going forward, organizations that aggregate ecosystem funding, such as Protocol Guild, independent research institutions such as Ethlabs, client teams, and application businesses are all likely to support protocol development in different ways. A structure in which no single organization controls the entire research agenda or budget clearly creates more room for experimentation and competition. Yet as funding becomes more fragmented, responsibility may become less clear: who is accountable for which areas of development, how priorities are set, and who bears the consequences when initiatives fail. Ethereum’s transition toward a multipolar ecosystem is therefore not simply a matter of distributing the EF’s influence across more organizations. It is a process of developing new forms of coordination among institutions with different interests, sources of legitimacy, and responsibilities, all while advancing the same protocol.

The way core development is funded may itself become a new layer of governance. If exchanges, L2s, stablecoin issuers, staking providers, and other businesses that have accumulated significant value on Ethereum begin contributing to development costs, the free-rider problem surrounding public goods could be reduced. At the same time, the commercial priorities of the largest funders may increasingly shape research and development agendas. Yet insulating those agendas too aggressively from donor influence would leave the ecosystem more dependent on voluntary contributions through mechanisms such as Protocol Guild, potentially weakening the foundations of long-term research and development whenever market conditions deteriorate. What ultimately matters, then, is not merely the amount of funding available, but how clearly the interests of sponsors can be separated from research and technical decision-making.

Ethereum after the EF is unlikely to be defined by the rise of a single successor organization. It will more likely consist of several institutions, each with its own area of expertise and accumulated trust, cooperating through a looser network of relationships. Such a structure may reduce the risk that the failure of one organization or leadership group spreads across the entire ecosystem, but it could also slow coordination and make disagreement a permanent feature of protocol development. New organizations will therefore need to do more than secure funding and talent; they will need to demonstrate, continuously, what they exist to protect and from which interests they remain independent. Ethereum’s next experiment in decentralization may depend less on the number or diversity stuffs of its nodes and validators than on whether the organizations building the protocol can preserve a shared direction without relying on a single center.