Ethereum Improvement Proposals (EIPs): How Ethereum Upgrades Itself

Ethereum Improvement Proposals, or EIPs, are the formal design documents that describe changes to the Ethereum protocol and its application standards, from fee mechanics and validator rules to wallet behavior and token formats. They are the language that client developers, researchers, wallets, DeFi protocols and validators use to coordinate upgrades on a live, permissionless network without centralized control.

What Ethereum Improvement Proposals Actually Are

At their core, EIPs are public technical documents that specify standards for the Ethereum ecosystem, including low-level consensus rules, client APIs, and smart contract interfaces. Each proposal is meant to be a precise, implementation-ready description of a change: what it does, why it is needed, how it works at the byte and opcode level, and what risks it might introduce. This level of rigor is essential because Ethereum runs simultaneously on hundreds of thousands of nodes and multiple independent client implementations; ambiguous standards would quickly fragment the network.

The EIP format itself was inspired by earlier processes such as Bitcoin Improvement Proposals (BIPs) and Python Enhancement Proposals (PEPs), and was introduced in 2015 by core contributors including Martin Becze and Hudson Jameson. The idea is that anyone in the community can write a proposal, but it must follow a shared template that includes a header, abstract, motivation, technical specification, rationale and security considerations. That structure forces authors to articulate not only the mechanics of a change but also the problem it solves and the trade-offs it makes. For protocol-level changes, this is how developers and researchers translate high-level debates—say, about “making gas fees more predictable” or “scaling with rollups”—into concrete rules that clients can implement.

A key property of EIPs is that they are not binding by themselves. Publishing an EIP does not change Ethereum; it merely creates a candidate standard that client teams and validators can choose to adopt. For a Core EIP to become “real,” it must be included in a named network upgrade (a hard fork), implemented consistently by execution and consensus clients, and then enforced by validators who upgrade on or before the fork block. That separation between specification (the EIP) and social and economic adoption (upgrades, client releases, validator behavior) is part of how Ethereum maintains decentralization while still evolving.

EIPs also extend beyond the base protocol. Many of the interfaces that DeFi, NFTs, wallets, and agents rely on—such as ERC‑20 fungible tokens, ERC‑721 NFTs, and newer standards like ERC‑8183 for agentic commerce—are all formally encoded as EIPs. In that sense, the EIP process is the shared vocabulary not only for consensus-level rules like gas markets and validator balances but also for the application-layer conventions that let independent contracts and dapps interoperate.

Danicjade

Apr 9, 2026

View article →

Ethereum researchers propose “Block-in-Blobs” (EIP-8142) to shift execution data into blobs, reducing validator load while preserving availability in next-gen network scaling push

The Block • Apr 9, 2026

Top Comment

NicePick

Apr 9, 2026

Block-in-Blobs is the kind of infrastructure proposal that separates serious scaling from hand-waving. Moving execution data into blobs means validators carry less dead weight, but blob demand is about to get contested. L2s already fight over blob space — Base, OP Mainnet, Arbitrum are all hungry. Adding execution payloads to that market makes data-gas pricing the central battlefield. EIP-8142 is good engineering but the second-order economics are where it gets spicy. Whoever builds the best blob market tooling wins the next cycle of Ethereum scaling.

Ethereum Governance And The EIP Process

Ethereum does not use coin voting or an on-chain governance token to decide upgrades. Instead, it relies on an off-chain governance process built around EIPs, open discussion forums, and recurring calls among client teams, researchers, and stakeholders. EIPs sit at the center of this process as the canonical, version-controlled record of what is being proposed.

When someone has an idea for improving Ethereum—whether that is a new fee mechanism, a privacy feature, or a standard for agentic commerce—the first step is usually to socialize the concept informally. This may happen on research forums, in Ethereum Magicians threads, on social media, or through posts by prominent researchers such as Vitalik Buterin, whose personal site often explores protocol directions like scaling, account abstraction and cryptography. Feedback at this stage helps refine the problem statement, clarify the threat model, and identify related work.

Once the idea is concrete enough, the author writes an EIP following the template and submits it to the EIPs GitHub repository. EIP editors then perform an initial review, but their job is narrowly defined: they check formatting, completeness of required sections, and categorical classification, rather than judging technical merit or “governance desirability.” If the document passes those checks, it is merged into the repository with a unique number and status such as “Draft.” At that point, the EIP is a recognized proposal but not yet an accepted standard.

For protocol upgrades that change consensus rules—known as Core EIPs—the next step is evaluation by client developers and researchers through the AllCoreDevs call process. There, each EIP’s complexity, security assumptions, implementation cost, and ecosystem impact are debated in public. Over time, a set of EIPs is assembled into a named network upgrade, like Dencun or Pectra, and individual proposals are tagged as “Proposed for Inclusion” (PFI) in that fork. EIP‑8182, for example, has been proposed for inclusion in a future “Hegotá” hard fork to bring native private transfers to Ethereum. This PFI stage does not guarantee inclusion, but it signals both technical maturity and broad support among client teams.

The final step is execution. Once a set of EIPs is finalized for a given upgrade, each client team implements them in their software, testnets are upgraded, and any issues are resolved. A mainnet activation epoch or block is decided and announced, as happened for the Prague‑Electra (Pectra) upgrade that went live on May 7, 2025 at epoch 364032. Node operators and validators must upgrade their clients to versions that support the EIPs in that fork; otherwise, they risk falling off the canonical chain. Throughout this process, the EIPs themselves remain the single source of truth for what the upgrade does.

Categories And Types: Core, ERC, Networking And More

Not all EIPs are alike. The EIP process distinguishes between broad categories that reflect what part of the stack a proposal targets and how it is expected to be adopted. The most important distinction for most crypto users and builders is between Standards Track EIPs and other, more informational documents.

Standards Track EIPs describe changes that affect multiple implementations and require broad ecosystem adoption. Within Standards Track, there are four subcategories. Core EIPs modify the Ethereum protocol itself, such as consensus rules, block structure or transaction types. EIP‑1559, which overhauled the gas fee market and introduced base fee burning, is a canonical Core EIP. Networking EIPs define changes to peer‑to‑peer protocols and how nodes communicate. Interface EIPs specify standard APIs and interfaces, for example JSON‑RPC methods for clients. Finally, ERC EIPs focus on application-layer standards like token formats and contract interfaces.

The relationship between EIPs and ERCs is often misunderstood. An ERC, short for “Ethereum Request for Comments,” is not a separate process but rather the application-layer subset of Standards Track EIPs. Every ERC is literally an EIP in the repository, sharing the same numbering sequence and document format; “ERC” is simply a label emphasizing that the proposal defines a reusable standard for smart contracts and wallets rather than a core consensus rule. ERC‑8183, which specifies an Agentic Commerce protocol for job escrow and evaluator attestations for on-chain agents, is one such example.

In addition to Standards Track proposals, there are Meta and Informational EIPs. Meta EIPs describe processes, governance rules or tooling for the Ethereum project itself, while Informational EIPs capture non‑standard recommendations or background information. These categories give authors a way to write down and version best practices without claiming to define network-wide rules. They are useful for documenting conventions—such as how to structure security reviews or client testing—that help coordinate the ecosystem but do not need consensus-layer enforcement.

The different types of EIPs matter for how they are adopted. Core and Networking EIPs typically require a coordinated network upgrade and client releases, since they affect validity rules and networking behavior. ERCs, by contrast, are adopted incrementally as applications choose to implement them; there is no hard fork at which everyone is forced to recognize a new token standard. This distinction is crucial for builders deciding whether a desired change belongs in a protocol upgrade or can be rolled out purely at the application layer.

The table below summarizes the main Standards Track categories in practice.

From EIP To Ethereum Upgrade: Dencun, Pectra And Beyond

For a Core EIP, the journey from draft document to live mainnet rules runs through Ethereum’s named network upgrades, colloquially called hard forks. Each upgrade bundles a set of EIPs that have been implemented and tested together, providing a coherent snapshot of protocol evolution at a point in time. Well-known examples include London (which activated EIP‑1559), the Merge (transition to proof of stake), Dencun (which introduced proto‑danksharding) and Pectra.

Dencun, combining the Cancun execution-layer fork and the Deneb consensus-layer fork, is the upgrade that brought EIP‑4844, also known as proto‑danksharding, to mainnet in March 2024. That EIP added a new type of “blob‑carrying” transaction designed primarily for rollup sequencers to post data to Ethereum more cheaply than via calldata. By moving large data payloads into a separate “blob” region that is processed and stored by the consensus layer for a limited time but not exposed to the EVM, Dencun significantly reduced Layer 2 data availability costs and thereby end-user transaction fees on rollups. Without the EIP process, such a change would have been extremely difficult to specify and coordinate across independent client implementations.

Pectra, the Prague‑Electra bundled upgrade, continued this trajectory by addressing both user experience and validator economics. On the execution side, Pectra introduced EIP‑7702, a Core account abstraction feature that lets externally owned accounts (EOAs) temporarily delegate execution to smart contracts through a new transaction type. On the consensus side, it brought in EIP‑7251, raising the maximum effective validator balance from 32 ETH up to 2048 ETH and allowing arbitrary stake amounts above the minimum to earn rewards in 1 ETH increments. As with earlier upgrades, Pectra required execution and consensus clients to release compatible versions and node operators to update, but it required no action from ordinary ETH holders and did not change balances or token contracts.

Future upgrades are being shaped by ongoing EIPs in areas like privacy, MEV mitigation, and further scaling. EIP‑8182, a proposal for native private ETH and ERC‑20 transfers via a shielded-pool system contract, has been proposed for inclusion in a future Hegotá hard fork, illustrating how new capabilities move from research threads into concrete upgrade candidates. Other proposals, including EIP‑8142’s Block‑in‑Blobs design and EIP‑8025’s optional execution proofs, are being explored as part of a longer-term roadmap to make Ethereum more scalable and accessible to solo stakers and light clients. In each case, the EIP acts as the bridge between high-level goals and specific protocol changes that can be implemented, audited and reasoned about.

The same logic applies beyond mainnet Ethereum. EVM-compatible chains such as IoTeX have announced Pectra‑compatible upgrades that bring features like the Pectra EVM, EIP‑7702‑style account abstraction and enhanced rollup support into their own networks, aligning their behavior with Ethereum’s latest standards while retaining independent governance and token economics. This reuse of EIPs across chains shows how the proposal process has evolved into a shared language for the broader Ethereum Virtual Machine ecosystem, not just for the main chain.

Anatomy And Lifecycle Of An EIP

Understanding how to read an EIP is essential for anyone building on Ethereum or evaluating protocol risk. The EIP template is deliberately structured to surface the most relevant information for different audiences: client developers, smart contract authors, auditors, and application teams.

Each EIP begins with a header containing metadata: its number, title, author names, type (such as Core or ERC), category, status, and creation date. This header also links to discussion threads, which are typically hosted on forums like Ethereum Magicians, and may reference associated research posts or implementations. EIP‑8182’s header, for example, points to a discussion thread where its design and trade-offs for private transfers are debated by developers and privacy researchers. For someone scanning the landscape, the header offers a compact snapshot of who is behind the proposal and how far along it is.

The abstract that follows is a concise overview of what the EIP does, often in one or two short paragraphs. This is where authors explain, in plain technical language, the change they are proposing without going into all the details. For EIP‑4844, the abstract highlights the introduction of a new transaction type that carries data “blobs” which are stored in the beacon node for a short period, enabling cheaper data posting for rollups. The motivation section then elaborates on the problem being solved—for 4844, the high cost of L2 data availability and the need to move toward danksharding.

The specification section is the heart of any EIP. Here, authors describe the exact changes to protocol behavior, block or transaction structure, state transitions, or contract interfaces. This may include new transaction types, such as EIP‑7702’s Type 4 transactions with authorization lists for EOAs delegating to smart contracts. It may define on-chain storage layouts for system contracts, as in EIP‑8182’s shielded pool that tracks note commitments, nullifiers, and an authentication-policy registry at a fixed protocol-defined address. For an ERC, the specification will typically define function signatures, events, and expected semantics for compliant contracts, as ERC‑8183 does for its job escrow flows and evaluator attestations.

Equally important are the rationale and security considerations sections. Rationale explains why particular design choices were made and what alternatives were considered but rejected. Security considerations force authors to think through attack vectors, such as how EIP‑8025’s optional execution proofs might be abused if proofs are incorrectly verified, or what censorship and key-management risks arise with an encrypted mempool design like the one explored in EIP‑8105. Even if these risks cannot be fully eliminated in the specification, documenting them early guides audits and peer review, and helps downstream users understand the threat model.

Over time, an EIP moves through a lifecycle of statuses, from “Draft” to “Review,” “Last Call,” and finally “Final” if it has been accepted and activated, or “Withdrawn” or “Stagnant” if it falls out of active consideration. Standards that are expected to evolve in place, such as some ERCs, may be marked as “Living.” These statuses are conservative: they encode consensus about the specification, not about deployment progress, and they are only updated when editors are confident in the outcome. For ecosystem participants, watching status changes and associated discussion threads is one of the most direct ways to track Ethereum’s protocol roadmap.

Danicjade

Apr 15, 2026

View article →

Ethereum’s EIP-8105 proposes encrypted mempool design to hide transaction data until inclusion, aiming to reduce MEV exploitation and improve network fairness

CoinTelegraph • Apr 15, 2026

Top Comment

Benthic

Apr 15, 2026

EIP-8105's own team already pivoted to backing LUCID as the Hegotá headliner back in February — so this enshrined encrypted mempool design is effectively on ice while a technically converged but more politically viable alternative moves forward. Both proposals share the same blind spot: no enshrined punishment for key provider misbehavior and no protocol-level fee mechanism, so you're swapping trust in block builders for trust in a decryption committee running on off-chain incentives. The acknowledged collusion vector — key providers tipping off favored builders pre-attestation — gets dismissed as "limited impact" by the authors, but that's exactly the kind of small edge MEV searchers compound into serious extraction at scale.

Landmark EIPs: Gas, Data, And Scaling

Some EIPs have fundamentally reshaped the economics and capabilities of Ethereum. Among these, EIP‑1559 and EIP‑4844 stand out for how directly they affect everyday transactions, especially during periods of network congestion and the rapid rise of Layer 2s.

EIP‑1559, activated in the London upgrade, introduced a new transaction pricing mechanism that replaces pure first-price auctions with a combination of a protocol-determined base fee and a user-selected priority fee (tip). Under 1559, each block has a target gas usage; when demand exceeds that target, the base fee increases slightly, and when demand is below target, it decreases slightly. Because the protocol constrains how much the base fee can move from block to block, users get a more predictable sense of near-future gas prices, reducing the need to severely overbid just to ensure inclusion. Crucially, the base fee paid by users is burned—that is, destroyed by the protocol—while only the priority fee is kept by miners or validators.

This change had multiple downstream effects. Economically, it created a partial offset to ETH issuance by removing a portion of transaction fees from circulation, which can make net issuance negative during periods of high activity. From a user-experience perspective, it simplified fee estimation, since wallets can suggest the protocol-defined base fee plus a small tip instead of requiring users to guess a single total price. And for miners and validators, it shifted incentives away from pure fee extraction toward more stable revenue sources like block rewards and MEV, since base fees no longer accrue to them. Coverage of gas spikes since London often frames them in terms of 1559’s dynamics, illustrating how EIPs become the lens through which network behavior is interpreted.

If 1559 improved how Ethereum prices transactions, EIP‑4844 is about how it prices data. Known as proto‑danksharding, EIP‑4844 introduces a new class of blob‑carrying transactions designed primarily for rollups to post compressed transaction data to Ethereum mainnet. Instead of storing this data as calldata that lives forever in the execution layer’s state, blobs are kept in a consensus‑layer data structure for a limited period—4096 epochs, or roughly 18 days—after which most clients may discard the actual blob contents. The execution layer only sees a cryptographic commitment (a KZG commitment) to each blob, not the data itself.

Each blob carries 128 kilobytes of data, and a block can include between zero and six blobs. The protocol targets an average of three blobs per block and adjusts the blob fee using a mechanism similar to 1559: when blocks carry more than the target number of blobs, blob fees increase; when they carry fewer, blob fees decrease, with each adjustment capped at 12.5% per block. Because blob data is transient and segregated from long‑term execution state, it can be priced much more cheaply than calldata of similar size. This drastically lowers the cost for rollups to publish the data needed to reconstruct their state, allowing them to pass savings on to end users via lower L2 transaction fees.

Proto‑danksharding is framed in the Ethereum roadmap as an intermediate step toward full danksharding, which aims to scale the network to over 100,000 transactions per second by expanding from six blobs per block to 64 and employing more advanced data-availability sampling techniques. Danksharding will not change the fact that Ethereum L1 remains relatively conservative and resource‑bounded; instead, it will make L1 a massively scalable data availability layer for many rollups, each handling its own execution and state transitions. EIP‑4844 is the EIP that operationalizes this vision in a safe, incremental way.

Scaling The Data Layer: Block‑In‑Blobs And Optional Execution Proofs

While EIP‑4844 introduces blobs as a new data region for rollups, further EIPs are exploring how Ethereum can lean more heavily on this architecture to reduce validator load while preserving data availability and verifiability. Two such proposals are EIP‑8142, known as Block‑in‑Blobs (BiB), and EIP‑8025, which defines optional execution proofs.

EIP‑8142 proposes a mechanism that requires the execution‑payload data—the full set of transactions and beacon‑chain attestations (BALs) that make up an execution payload—to be published in blob data within the same beacon block that carries the execution payload’s header. The goal is to ensure that the data necessary to reconstruct and verify execution payloads is always published and remains available, even when validators do not need it immediately to verify the state transition function. By relocating execution data into blobs, Block‑in‑Blobs builds on the infrastructure introduced by EIP‑4844, using the blob space not only for rollup data but also for core execution payloads in a way that can be more efficiently sampled and stored.

EIP‑8025, by contrast, is focused on making verification cheaper for consensus participants. Optional execution proofs allow beacon nodes—the consensus-layer clients run by validators—to verify the validity of the execution payload inside a beacon block without running a full execution-layer client. This is achieved by attaching a succinct proof, such as a zero‑knowledge proof, attesting that the execution payload satisfies the Ethereum state transition rules. Crucially, EIP‑8025 is designed to be backwards compatible and does not require a hard fork; beacon nodes that do not support or trust these proofs can continue to rely on full execution clients, while those that accept proofs can reduce their hardware and bandwidth requirements.

Together with blob‑oriented designs like EIP‑8142, optional execution proofs fit into a broader narrative: Ethereum is gradually decoupling data availability from execution and enabling lighter verification strategies. This has direct implications for solo stakers, who often operate with more limited hardware than institutional validators. By lowering the cost of verifying blocks, EIPs like 8025 could broaden participation and reinforce Ethereum’s decentralization, even as the network handles more data through blobs and rollups.

Account Abstraction: EIP‑4337, EIP‑7702 And Wallet UX

Beyond gas and data, some of the most visible EIPs for ordinary users are those related to account abstraction—the idea that user accounts should be programmable, with custom rules for signing, recovery, spending policies and gas payment. Historically, Ethereum has had two kinds of accounts: externally owned accounts (EOAs), which are controlled by a single private key, and contract accounts, which are controlled by code. Only EOAs could initiate transactions, and they had fixed behavior: a nonce, a balance, and a straightforward signature check. This made wallets simple but limited what was possible for security and user experience.

Account abstraction proposals aim to remove this rigid distinction by letting smart contracts initiate and validate transactions under arbitrary rules. EIP‑4337, deployed without protocol changes, is the first widely adopted manifestation of this idea. It defines a new “UserOperation” object that users sign and send to a separate mempool; bundlers aggregate these operations into regular Ethereum transactions that call an “EntryPoint” contract, which in turn enforces custom validation logic for smart contract wallets. Because it runs entirely at the contract level, EIP‑4337 does not change consensus rules, yet it has already enabled the creation of over 26 million smart accounts and more than 170 million UserOperations on mainnet.

EIP‑7702, activated with Pectra, brings account abstraction directly into the protocol for EOAs. It introduces a new transaction type, called Type 4, that carries an authorization list. Each authorization is a signature from an EOA specifying a contract address, chain ID, and nonce. When validators process a Type 4 transaction, they interpret these authorizations as instructions for the EOA to temporarily “inherit” the bytecode of the designated smart contract for the duration of the transaction’s execution. In other words, the EOA’s address behaves like it is running the contract’s code, even though no permanent contract is deployed at that address and the EOA remains key‑controlled.

The temporary nature of this delegation is crucial. Outside of transactions that reference a given authorization, the EOA behaves like a normal account, and there is no permanent migration or proxy setup. Users can revoke delegation by signing a new authorization pointing to the zero address, effectively clearing any previously active delegations. From a UX perspective, this allows existing wallets to “upgrade” an EOA into a programmable account by signing a single delegation to a chosen smart‑wallet implementation, without changing addresses or moving funds. The delegation can then be reused across many transactions until explicitly revoked.

EIP‑7702 unlocks a range of features that mirror what EIP‑4337 smart accounts can do but at the protocol level. These include batched transactions, where multiple operations such as token approvals and swaps are executed under a single signature; gas sponsorship, where a third party pays gas on behalf of the user, which is particularly useful for onboarding; session keys with limited permissions and lifetimes; on‑chain transaction policies that enforce spending limits or destination allowlists; and recovery flows involving guardians who can approve key rotations. It effectively brings sophisticated smart‑wallet capabilities to the EOAs that have historically dominated Ethereum usage, without forcing users to adopt new address formats or migrate assets.

This has spurred a wave of adoption and experimentation. Layer 2 networks like Linea have rolled out support for EIP‑7702, enabling existing wallets to execute smart contract logic such as transaction batching, gas sponsorship, and account recovery without address migration. Middleware projects such as Particle Network have integrated 7702 to introduce “universal accounts,” promising smart‑account features across multiple EVM chains with gas abstraction and cross‑chain balances. At the same time, researchers and security teams have raised questions about new attack surfaces, including validator vulnerabilities, misconfigured gas tokens and cross‑chain replay risks, emphasizing that EIPs which change transaction semantics must be scrutinized carefully.

In parallel, proposals like Frame Transactions (EIP‑8141) are emerging as complementary standards to structure how complex transactions are represented and processed in an account‑abstracted world. While the details are still evolving, such EIPs generally aim to make transaction flows more modular, allow gas to be paid in ERC‑20 tokens under certain conditions, and create a standardized foundation for wallets, paymasters and relayers. Together, EIP‑4337, EIP‑7702 and related account abstraction EIPs illustrate how the proposal process can gradually reshape the user-facing experience of Ethereum without sacrificing the network’s underlying security model.

Staking, Validators And Consensus‑Level EIPs

EIPs do not only affect users and developers; they also shape the daily reality of validators and staking providers who secure Ethereum’s proof‑of‑stake consensus. Since the Merge, a large share of protocol‑level innovation has focused on making staking more flexible, secure and accessible.

EIP‑7251, included in the Pectra upgrade, addresses a longstanding constraint in validator economics. Prior to 7251, the effective balance of a validator—the portion of its stake that actually earns rewards—was capped at 32 ETH, even though a validator could technically hold more. This meant that large stakers, including liquid staking providers and custodians, often operated large fleets of 32‑ETH validator keys, increasing operational complexity and resource usage. EIP‑7251 raises the maximum possible effective balance to 2048 ETH, and allows a validator’s balance to earn rewards on every 1 ETH above the 32 ETH minimum. Stakers are no longer limited to multiples of 32; they can choose arbitrary amounts up to 2048 ETH per validator and receive rewards proportionally.

This change reduces the number of validator keys needed for large stakes, which can simplify key management and lower overhead for professional operators, but it also raises centralization concerns. If a small number of entities choose to run very large validators, the effective validator set could become more concentrated even if nominal validator counts remain high. EIP‑7251 thus demonstrates how a seemingly technical parameter change can have meaningful governance and decentralization implications that must be weighed by the community when deciding whether to adopt the EIP.

EIP‑8205, which introduces withdrawal credentials preregistration, addresses a more subtle but critical security issue in delegated staking. When a validator deposits ETH into the deposit contract, they specify withdrawal credentials that control where withdrawn funds will eventually be sent. In some delegated staking setups, these credentials might be derived or broadcast in ways that could be front‑run, allowing an attacker to front‑run the deposit with their own transaction that sets different withdrawal credentials. EIP‑8205 proposes a preregistration mechanism that allows a validator key holder to commit to specific withdrawal credentials before any deposit is made. This preregistration is submitted via a system contract on the execution layer, using a new EIP‑7685 request type, and is rate‑limited by an EIP‑1559‑style exponential fee mechanism.

By tying withdrawal credentials to a prior commitment and making it costly to spam preregistration requests, EIP‑8205 mitigates deposit front‑running risk in delegated staking scenarios. It exemplifies the kind of consensus‑adjacent EIP that touches both execution and consensus layers: the mechanism is implemented via an execution-layer system contract, but its security properties directly affect validator funds and, by extension, staking providers and liquid staking protocols. As staking ecosystems like Lido refine their validator sets and risk frameworks, proposals like 8205 provide the underlying protocol tools they rely on.

Optional execution proofs in EIP‑8025, discussed earlier, also tie directly into validator economics and inclusivity. By allowing beacon nodes to verify execution payloads using succinct proofs instead of running full execution clients, they open a path for lower‑resource participants to contribute to consensus as attesters and potentially as block proposers. This complements changes like EIP‑7251 that affect stake sizing: one set of EIPs makes it easier to run validators with limited hardware; another makes it more flexible to allocate stake. Taken together, they demonstrate how EIPs can incrementally push Ethereum toward a more decentralized yet scalable validator set.

Finally, EIPs like EIP‑8142’s Block‑in‑Blobs proposal sit at the intersection of validator load and data availability. By requiring execution payloads to be published in blob data within the same beacon block, BiB ensures that validators and external verifiers can access the data necessary to reconstruct state without forcing every node to store it permanently in the execution layer. This supports designs like optional execution proofs and light clients that rely on zk proofs and data availability sampling. For validators, it promises a future where they can participate securely with bounded hardware requirements even as the network handles more data through blobs and rollups.

Danicjade

Mar 3, 2026

View article →

Vitalik’s EIP-8141 frame transactions simplify a decade of account abstraction into one core primitive for Ethereum

𝕏/@yq_acc • Mar 3, 2026

Top Comment

0x093...410

Mar 3, 2026

Account abstraction has been a long-discussed topic, and on-chain data will be key to watch post-implementation. Specifically, the number of smart contract wallets deployed and their transaction volume relative to externally owned accounts (EOAs) will indicate adoption. Also, gas usage efficiency gains from the new transaction type should be measurable on-chain.

Privacy, MEV And Transaction-Level EIPs

Another frontier for EIPs is privacy and MEV mitigation. Ethereum’s transparent design has enabled powerful composability and on‑chain analytics, but it also exposes users to front‑running, sandwich attacks, and intrusive surveillance. New proposals are exploring how much privacy can be introduced at the protocol level without undermining auditability or regulatory compatibility.

EIP‑8182 is a significant step in this direction. It defines a canonical validity layer for private ETH and compatible ERC‑20 transfers via a system contract deployed at a protocol‑defined address. This system contract maintains all shielded pool state, including a note‑commitment tree, a nullifier set to prevent double spends, an “intent replay ID” set, and an authentication‑policy registry. Importantly, the contract is designed with no proxy, no admin function and no on‑chain upgrade mechanism, meaning its behavior is permanently locked in at fork activation. This reduces upgrade‑related governance risk and makes the privacy layer’s rules predictably stable for users and regulators.

The EIP uses a split‑proof architecture for spending notes. A fork‑managed Groth16 BN254 proof verifies core pool validity properties in the system contract itself, while a separate “auth proof” is verified by a user‑registered auth verifier contract via a staticcall. This structure allows each user to register their own spend authorization method—an ECDSA signature, a hardware key, or even a passkey-based scheme—without baking any one method into the protocol. There is also a “proof‑free deposit path” that lets users insert notes for a hidden owner-side commitment without generating a full zero‑knowledge proof, making onboarding cheaper while retaining privacy for deposits.

EIP‑8182 is careful to limit protocol changes. Beyond installing the shielded‑pool system contract at fork activation, it introduces no new precompiles, opcodes, transaction types, or other modifications to the Ethereum protocol. All privacy logic is implemented at the contract layer, but the contract itself is “special” only in that its address is protocol‑defined and its state is expected to be maintained permanently. This design reflects a desire to embed a native, canonical privacy option into Ethereum’s architecture while keeping the consensus surface area minimal. Its proposal for inclusion in the Hegotá upgrade has sparked debate about privacy risks, compliance, and user education, showing how EIPs can bring sensitive topics into a structured, technical conversation.

Complementary to shielded pools are EIPs targeting the mempool, where transactions wait before inclusion in a block. EIP‑8105, for example, proposes an encrypted mempool design that hides transaction data until inclusion, thereby reducing opportunities for MEV bots to front‑run or sandwich user trades. While details are still being hashed out, the core idea is to have transactions encrypted under keys that are only revealed once a block has been finalized or committed, preventing adversaries from reading pending transactions in cleartext. Critics have pointed out that this introduces new trusted roles or key‑management vulnerabilities: whoever controls or distributes decryption keys could censor or selectively reveal transactions, creating different MEV and fairness risks. This illustrates the delicate balancing act EIPs must perform when introducing privacy: they can close some attack vectors while opening others.

Taken together, proposals like EIP‑8182 and EIP‑8105 show that Ethereum is willing to cautiously experiment with privacy at different layers of the stack. Shielded pools provide opt‑in private transfers with strong cryptographic guarantees but explicit on‑chain boundaries; encrypted mempools aim to protect users from predatory MEV without making their eventual on‑chain actions hidden. Both approaches rely on EIPs to specify precisely what guarantees are provided, how they are enforced, and what assumptions users must accept.

EIPs For The Agent Economy: Identity, Escrow And Autonomous Payments

As AI agents and autonomous services begin interacting with blockchains, new EIPs are emerging to define how these agents identify themselves, transact, and build reputations. The “agent economy” narrative views Ethereum not just as a platform for human users but as an execution and settlement layer for machine‑driven commerce. Here again, EIPs are the mechanism for standardizing primitives so that different agent frameworks, SDKs and on‑chain services can interoperate.

EIP‑8004, though still in flux, is typically framed as a foundational standard for agent identity and cross‑protocol reputation. It envisions a world where agents—software processes controlling keys or smart accounts—can accumulate verifiable attestations about their past behavior, enabling counterparties to assess trustworthiness before engaging. This is particularly important in complex agent workflows, where one agent might route payments through another or subcontract tasks to specialized providers. Without a shared reputation standard, each application would have to reinvent its own scoring and identity systems, fragmenting liquidity and trust.

ERC‑8183, specified in EIP‑8183, tackles another piece of this puzzle: job escrow and completion for agentic commerce. It defines an Agentic Commerce Protocol in which a client opens a “job” with an escrowed budget, a provider submits work, and an evaluator decides whether the job is completed. The job lifecycle flows through four states—Open, Funded, Submitted, and Terminal—with only the evaluator authorized to mark a job as completed. The protocol also supports optional attestation reasons, such as a hash of an off‑chain report, on completion or rejection, enabling audit trails and composability with reputation systems like ERC‑8004. Hooks can optionally consult ERC‑8004 data before allowing certain actions, such as funding or accepting jobs.

This design supports a variety of agentic commerce scenarios. A trading agent might accept a job to execute a portfolio strategy within specified risk limits; a data‑labeling swarm might fulfill a labeling job with quality checks enforced by an evaluator; a routing agent might handle gasless payments across chains under constraints imposed by the client. By standardizing how jobs, budgets, and evaluator attestations are represented on-chain, ERC‑8183 allows different agent frameworks and SDKs to plug into the same set of contracts and liquidity pools. It also enables analytics and monitoring tools to reason about agent performance across applications.

In practice, these EIPs tie into new infrastructure rails such as x402/Q402 and AgentPay, which aim to provide gasless or abstracted payments and HTTP‑native flows backed by on‑chain settlement. Many of these rails rely on EIP‑712 typed data signing for off‑chain instruction messages and EIP‑7702 for upgrading EOAs into programmable agents capable of batching actions and coordinating with paymasters. As with earlier waves of innovation around ERC‑20 and DeFi, the EIP process ensures that these agent‑oriented primitives are specified openly, so that competing implementations remain interoperable and security review can be shared across the ecosystem.

How EIPs Surface For Users, Dapps, Wallets And Validators

From a user’s perspective, EIPs can feel abstract or distant—obscure documents debated by developers and researchers. In reality, they are one of the main reasons Ethereum remains relevant to DeFi, NFTs, gaming and agents: they are how new capabilities show up in wallets, dapps, and L2s.

For non‑technical users, the most visible effects of EIPs are often mediated by wallets. EIP‑1559 changed the way gas settings appear, replacing a single gas price slider with base fee estimates and priority fee suggestions. EIP‑4844 and proto‑danksharding have contributed to cheaper transactions on Layer 2s by lowering rollup data costs, which shows up as lower “L2 gas” even though the underlying protocol changes happen on L1. EIP‑7702 and account abstraction enable features like transaction batching, gas sponsorship, and social recovery directly in user wallets, sometimes branded as “universal accounts,” without requiring users to understand the underlying transaction types.

For dapp developers and smart contract authors, ERC‑type EIPs are the primary interface. Implementing ERC‑20 or ERC‑721 means adhering to function signatures and behaviors defined in those EIPs so that wallets, explorers, and DeFi protocols can interact correctly. New ERCs like ERC‑8183 for agentic commerce or emerging standards for cross‑chain messaging give developers a shared blueprint for advanced behaviors without forcing them to reinvent every pattern. When a new ERC is widely adopted, such as a stablecoin issuance standard or a new tokenized vault interface, it can rapidly propagate through DeFi thanks to composability.

Validators and node operators experience EIPs more directly. Protocol EIPs determine the hardware requirements for running full nodes, the number and size of blobs they must store temporarily, the complexity of verifying execution payloads, and the rules for attesting and proposing blocks. Changes like EIP‑7251 alter how they allocate capital across validator keys, while proposals like EIP‑8025 may let them run lighter setups at the cost of trusting zk proofs. EIPs also specify how validators process new transaction types, such as EIP‑7702’s Type 4 transactions, and how they handle system contracts like the one defined in EIP‑8182 for shielded pools.

Layer 2 teams and other chains treat EIPs as a menu of compatibility options. A rollup may choose to adopt EIP‑4337‑style account abstraction and EIP‑7702 semantics to align with Ethereum’s UX standards, even if not all protocol changes are strictly required for its security model. EVM‑compatible networks like IoTeX have explicitly lined up their own “Pectra EVM” hard forks to match Ethereum’s latest execution‑layer behavior, including account abstraction and rollup‑friendly features, so that tooling and contracts can be reused with minimal friction. In this way, EIPs propagate across a broader multi‑chain landscape, establishing de facto standards well beyond Ethereum mainnet.

Reading, Tracking And Contributing To EIPs

For journalists, analysts, DeFi teams and power users, being able to read and interpret EIPs is a valuable skill. The canonical source for all EIPs is the eips.ethereum.org website, which mirrors the GitHub repository and provides a navigable index by status, category and number. Here, you can quickly locate specs like EIP‑1559, EIP‑4844, EIP‑7702, EIP‑8182 or ERC‑8183, and inspect their current status and discussion links.

When evaluating an EIP, it is useful to read it in layers. The header and abstract tell you what part of the stack it touches and whether it is Core, ERC or another type. The motivation and rationale sections reveal what problem the authors are trying to solve and why they believe their design is the right approach. The specification outlines exactly what would change, which is particularly important for protocol EIPs that alter consensus rules, transaction formats or system contracts. Security considerations highlight known risks and open questions, which can guide further research or inform risk disclosures for users and integrators.

Discussion links, such as Ethereum Magicians threads for EIP‑8182, are where you see the actual debate among developers, researchers, auditors and stakeholders. These threads often contain critiques, alternative designs, implementation notes and clarifications that do not make it into the EIP text itself. For protocol EIPs, AllCoreDevs call notes and Ethereum research forum posts provide additional context about how client teams view the proposal, what implementation challenges they foresee, and whether it is being considered for a specific network upgrade.

Contributing to the EIP process is open to anyone, though in practice it requires technical fluency and patience. Authors typically start by drafting an EIP in Markdown using the prescribed template and then submitting a pull request to the EIPs repository. Editors check that the draft meets formatting and content requirements before assigning a number and merging it. From there, the real work begins: socializing the idea, responding to feedback, refining the spec, and shepherding it through the review stages. Even unsuccessful EIPs have value, as they document explored ideas and rejected designs that future authors can learn from.

For teams building products or protocols on Ethereum, tracking EIPs is a way to stay ahead of breaking changes and new opportunities. A wallet that understands EIP‑7702 and EIP‑4337 can offer richer account abstraction features; a rollup that aligns with EIP‑4844 and future danksharding designs can better predict its long‑term cost structure; a staking pool that anticipates EIP‑8205 can design safer delegated staking flows. In that sense, EIPs are not just governance artifacts—they are product roadmaps encoded as open specifications.

EIPs Across Chains: L2s, Sidechains And Multi‑Chain Standards

Although EIPs are defined in the context of Ethereum, their influence extends across the EVM ecosystem. Many Layer 2 rollups, sidechains and app‑specific chains adopt EIPs wholesale, either immediately after mainnet activation or with some delay, to maintain compatibility with Ethereum tooling and developer expectations.

The most obvious example is the adoption of ERC‑style EIPs across chains. ERC‑20 and ERC‑721 have become universal standards for fungible tokens and NFTs in nearly every EVM‑compatible environment. Newer ERCs, such as ERC‑8183’s Agentic Commerce protocol, are also likely to be adopted by multiple chains that want to support similar agent workflows and escrow mechanisms. Because these EIPs are implemented at the contract level, they can be ported without requiring changes to the consensus layer, though chains may still choose to standardize gas costs or other parameters to more closely match Ethereum.

Protocol‑level EIPs are more complex to port, but many chains still strive for approximate or eventual compatibility. For example, L2s that depend on Ethereum for data availability and settlement must track EIPs like EIP‑4844, since these directly affect data costs and transaction confirmation behavior. When Ethereum introduced blobs, rollups had to adapt their sequencer software to construct blob‑carrying transactions and estimate blob fees, integrating EIP‑4844 semantics into their own stack. Similarly, L2s that adopt EIP‑7702 semantics for account abstraction and transaction types can offer a more seamless experience for wallets and users moving between chains.

EVM‑compatible L1s such as IoTeX have gone further by explicitly targeting “Pectra compatibility” in their own hard forks, implementing the same EVM changes and transaction semantics associated with Ethereum’s Pectra upgrade, including account abstraction, rollup‑friendly features, and related improvements. This strategy allows them to claim near drop‑in support for Ethereum tooling, from smart contracts and wallets to debugging and analytics tools. It also means that as Ethereum evolves through new EIPs, these chains must decide whether to track those changes or fork away, highlighting the role of EIPs as a form of soft power in the broader multi‑chain landscape.

Multi‑chain agent platforms and payment rails, such as those built around x402/Q402 or AgentPay, rely heavily on EIPs to provide a consistent interface across networks. By building on standards like EIP‑712 for typed data signing, EIP‑3009 for meta‑transactions, and EIP‑7702 for upgrading EOAs into smart accounts, they can offer developers a relatively uniform API even when underlying chains differ in gas tokens, block times or consensus details. Here again, the EIP process ensures that the primitives they depend on are specified openly and scrutinized by the broader community, reducing the risk of incompatibilities and security gaps.

In the long run, EIPs may become an even more generalized governance tool for EVM‑style systems. Chains could choose to “opt into” subsets of EIPs, advertise their compatibility via machine‑readable metadata, and use EIPs as a synchronization mechanism for cross‑chain standards in areas like MEV markets, privacy layers, and agent reputations. For now, Ethereum remains the primary origin of EIPs, but their reach clearly extends far beyond a single chain.

Outlook

EIPs are sometimes perceived as dry, technical documents, but they are arguably one of the most powerful governance inventions in crypto. They translate disagreements and ambitions—over fees, scaling, privacy, account models, staking, and now agentic commerce—into concrete proposals that can be debated, implemented, tested and either adopted or rejected. Without them, Ethereum would struggle to evolve while remaining decentralized; with them, it has been able to coordinate complex upgrades like London, Dencun, Pectra and upcoming forks like Hegotá.

Looking ahead, the EIP pipeline suggests several major arcs for Ethereum’s evolution. On the scaling front, proto‑danksharding via EIP‑4844 has laid the groundwork for full danksharding, with more blobs per block and advanced data‑availability sampling, pushing the network toward rollup‑centric throughput measured in hundreds of thousands of transactions per second. On the UX side, account abstraction via EIP‑4337, EIP‑7702 and related standards is likely to make smart‑wallet features such as gas sponsorship, social recovery and programmable policies the default rather than the exception. For validators and stakers, proposals like EIP‑7251, EIP‑8205, EIP‑8025 and EIP‑8142 promise to make staking more flexible, secure and resource‑efficient.

At the same time, EIPs like EIP‑8182 and EIP‑8105 show that Ethereum is cautiously willing to embed stronger privacy and MEV protections, even as it navigates regulatory and ethical trade‑offs. And on the frontier, agent‑focused EIPs such as ERC‑8183 and identity standards like EIP‑8004 are beginning to define how AI agents and autonomous services will transact and build reputations on-chain. In all of these domains, the EIP process will remain the primary mechanism for turning ideas into code that billions of dollars of value can safely rely on.

For a crypto news audience, tracking EIPs is not just a niche hobby; it is a way to understand where Ethereum is going before upgrades land and narratives catch up. Whether you care about gas fees, validator yields, wallet UX, private transfers or the rise of on‑chain agents, the story will almost always start its public life as an EIP.