What is it?

The current balance required to participate as an Ethereum validator is 32 ETH. EIP-7251 introduces a variable stake size that allows a single validator to hold between 32 and 2,048 ETH. Large node operators running multiple validators are expected to consolidate them into a single validator with a larger stake. For example, a maximum of 64 validators each holding the current 32 ETH limit can be combined into a single validator to max out the 2,048 ETH limit. The primary goal of this EIP is to reduce the total number of validators, without reducing the total amount of ETH staked.

Why is it needed?

Solo staking allows an individual to operate their own validator and earn staking rewards independently, which is beneficial for decentralization of the network. Protocol developers estimate that the 32 ETH threshold would attract around 312,500 validators, ensuring diversification of the chain. However, staking has grown considerably, from wallet applications aggregating holdings for retail holders to large-scale staking operations handling large amounts of ETH.

‍

Since the current model limits each validator node to just 32 ETH, staked funds aggregated across many extra validators are actually controlled by the same entity, often running on the same beacon node but using different signing keys. Each new validator node requires another address that other nodes in the network must exchange messages with, increasing the number of messages and their impact on the network. This creates an exclusionary environment for validators that run on lower-level hardware, particularly common with solo stakers.

‍

This problem will worsen if not addressed, and can contribute to a centralization risk if validators can’t handle the increased network load and are forced to shut down. In 2021, it was suggested that the Beacon Chain could manage the entire ETH supply staked with a cap of 32 ETH per validator. However, simulations later run by Ethereum Foundation engineers indicated that the network experiences significant issues when the number of validators reaches 1.4 million. The Beacon Chain (as of Mar 13, 2025) has 1.05 million validators (out of a total of 1.82 million validators registered). 

‍

This is why EIP-7251 — the consolidation of staked ETH to reduce the number of validators — is important and is expected to lighten the network load, improving scalability, reducing network congestion and decreasing computational demand. 

What are the implications?

This change benefits both small and large validators. Large validators can combine their stakes, reducing the number of validators and beacon nodes they need to run, making operations easier and lowering network overhead. Since every validator on the Beacon Chain submits a signature in each epoch, having fewer validators helps reduce bandwidth usage by decreasing the number of unique signatures that need to be propagated. This also lowers the number of peer-to-peer messages on the network, and decreases the Beacon Chain’s memory footprint, improving overall network efficiency. Since the total staked value will theoretically remain unchanged, there should be no unintended implications on the network’s security.

‍

Validators using this new system will still make the same number of attestations as they do now, once per epoch (approximately every 384 seconds). However, since attestation weight is based on the effective balance, a validator with a stake of 2,048 ETH will have 64 times more influence in the consensus mechanism as compared to a validator with a 32 ETH stake. This also means their chances of proposing a block will be up to 64 times higher. Despite this reality, the overall rewards will remain fair. On average, ten separate validators with 32 ETH each will have the same chance of earning as a single validator with 320 ETH.

‍

EIP-7251 will also benefit solo stakers and smaller validators by letting them stake in more flexible amounts. Instead of only staking in multiples of 32, stakers can now deposit ETH into the validator in incremental amounts above the minimum of 32 ETH, and earn rewards on every extra increment of ETH they stake. For example, instead of waiting to accumulate 64 ETH for two validators, a small validator can now stake 32.5 ETH in a single validator. This has two advantages: first, they can start earning staking rewards on the extra 0.5 ETH they stake. Secondly, a validator with 32.5 ETH will have a slightly higher chance of proposing a block as compared to one validator with just 32 ETH.

What do stakers need to know?

Stakers will no doubt have many questions regarding the consolidation of validators: for example, the upfront gas cost associated with the consolidation and, more importantly, an increase in penalties if the validator strays from the protocol. EIP-7251 makes accommodations to minimize the impact of both of these concerns, making the consolidation of validators more attractive overall. 

‍

EIP-7251 also introduces in-protocol consolidation. This removes the need to cycle through exit and activation queues, making adoption much easier and gas fees negligible. Consolidation requests can be sent from the execution layer to a special smart contract, where they’re stored in a queue on the consensus side. Each block proposal can process one consolidation request, ensuring that multiple validator indices are combined efficiently while protecting the network from distributed denial-of-service (DDoS) attacks, whereby attackers flood the blockchain with spam transactions to block legitimate ones. By spacing out these consolidations, the protocol can handle a maximum of about 7,200 consolidations per day. It’s expected to take several weeks after the Pectra upgrade before a noticeable reduction in the number of validators is observed across the network.

‍

Changes to penalties under Pectra

‍

Penalties post-Pectra will be adjusted in order to account for larger validators, although the precise final details of these penalties remain unconfirmed, as Pectra is still in the testing stage. Previously, if a validator was slashed, they would immediately lose 1/32 of their stake up to a maximum of 1 ETH, followed by a 36-day removal period. For small validators with just 32 ETH, this penalty is relatively minor. However, if the same 1/32 rule applied for large node operators, a validator with 2,048 ETH staked would lose 64 ETH instantly, making an isolated slashing event much more costly. Since validators with a higher stake would risk losing a higher absolute value of ETH under a constant slashing proportion, the initial slashing model is no longer a constant penalty, and has been transformed to 1/4,096 of the validator’s stake. 

‍

There are two additional penalties following slashing: an inactivity penalty, which remains unchanged post-Pectra, and a correlation penalty (charged to offending validators if they‘re slashed at the same time as other validators), which has also been adjusted. The correlation has been changed from a step function (in which the total amount of ETH slashed would always be rounded down) to a new continuous function whereby the validator’s ETH is slashed in increments. For a group of validator nodes controlled by the same entity, the amount of ETH slashed increases quadratically, as seen below. This is because the total amount of stake slashed at the same time grows, since both the number of validators committing the offense and the slashing penalty per validator increases linearly, combining to create a quadratic effect.

‍

Considering the combination of these different penalties, in most cases the fees are reduced post-Pectra. Adjusting the slashing penalty model makes consolidation more practical and appealing even as it maintains security. These changes ensure that large validators can participate without facing disproportionately high penalties. EIP-7251 works overall to make consolidation accessible and attractive.

‍

What is it?

EIP-7002 will allow ETH staked with validator nodes on the Beacon Chain to be withdrawn using the execution layer key only. Currently, withdrawal request transactions from the Beacon Chain must be signed using both the validator key and the execution layer withdrawal address key.

‍

EIP-7002 also introduces execution layer partial withdrawals, allowing validators to withdraw a portion of their stake without fully exiting. Execution layer messages can now trigger these partial withdrawals, in addition to full exits, meaning a validator can remove as much ETH as they require as long as the minimum 32 ETH is left with the validator in order to remain active. 

‍

This EIP is most relevant for delegated stakers. It removes the trust requirement between ETH stakers who delegate funds to third-party services that run validator nodes on their behalf. Enabling withdrawals to be controlled through only the withdrawal key effectively allows for noncustodial third-party staking.

Why is it needed?

ETH can be staked on the Beacon Chain either via solo or delegated staking. Solo staking requires you to use your own funds to create and run a validator on your own terms. Delegated staking requires entrusting ETH to a third-party service that holds the validating keys, since it’s used for performing validator duties, such as signing attestations and proposing blocks. while the staker (who controls the eventual withdrawal address) controls the withdrawal keys.

‍

The withdrawal key allows stakers to submit a request to either "skim" rewards (withdrawing only the accrued staking rewards above their minimum stake), or fully "exit" by withdrawing their entire 32 ETH balance. There are two forms the withdrawal key can take: the default (0x00) form, which as a standalone key can’t currently be used to withdraw staked ETH, and the actionable (0x01) form, which can. In order to change the withdrawal key from (0x00) to (0x01), the withdrawal key holder has to submit a voluntary exit message (VEM) to the network that must be signed by the validator key. This requires the staker to trust that the validator will sign that message.

What are the implications?

The main users impacted by this upgrade will be those who opt for “noncustodial” delegated staking. Delegated staking assumes that the validator operator acts honestly, and doesn’t commit any slashable offense that could put the staked ETH at risk. 

‍

While third-party staking services have found temporary solutions to this problem, such as pre-signing transformation messages and legal guarantees to compensate stakers for ETH lost due to slashing, they fall short of the advantages that EIP-7002 will bring. Transformed (0x01) withdrawal keys are currently only valid for two Ethereum forks, delaying the trust assumption by up to a year. The Pectra upgrade is intended to remove this trust assumption completely. 

‍

This upgrade has the potential to increase staked ETH, since it will improve overall clarity on the true ownership of the ETH. This is especially useful for institutional clients, and for risk-averse stakers who want to retain full true ownership of their staked ETH while benefiting from the staking yield of validating through a noncustodial delegated staking agreement. There’s also the argument that, as crypto comes under tighter regulations, this additional feature introduces the capacity to prove true ownership over staked ETH.

‍

One downside of this upgrade is its impact on noncustodial third-party staking services. Pectra will make it more difficult to enforce agreed-upon staking periods. This is because the true ETH holder (who has the withdrawal keys) has ultimate control and can withdraw funds at any time, hence bypassing the agreed-upon staking period.

What is it?

EIP-7691 is a short-term reprieve for high blob-space usage by Layer 2s. It proposes to increase max blob space by 50% (from 6 to 9), and the target number of blobs per block from 3 to 6. This will in turn provide more space for data, increase scalability and lower fees in Ethereum rollups (as a result of less competition for the same blob space).

Additionally, the EIP will change the maximum blob gas per block and target blob gas per block. Previously, the target and maximum values were set at a 1:2 ratio (target blob gas per block was 393,216, and max blob gas per block was 786,432). Thus, the responsiveness to full and empty blob sections was symmetrical.

Why is it needed?

Given that L2 rollups are the intended solution for future scaling, this EIP is intended to incentivize even more activity on Layer 2 chains by making it cheaper for them to use the Ethereum network for their security and data availability. 

Ethereum blocks currently allow space for up to 6 blobs. Each blob is a space in which rollups can store one chunk of transaction data. However, the network has a target of 3 blobs per block. While the actual number of blobs per block has varied after the introduction of blob space, since November 2024 blob space usage has been consistently close to target, with Vitalik Buterin stating that blob space is “barely covering the L2s.”

When blobs have been full, the base fee (the proportion of transaction fees that are burned per transaction, which is sensitive to the usage of block space) has increased by 12.5% in each block. Furthermore, when a block is empty of blobs, the blob base fee falls by 11.11%. 

EIP-7691 changes the maximum and target blob gas ratio from 1:2 to 2:3, thus making the base fee react more strongly when blobs are empty as compared to when they’re full: following the change, when blobs are full, the base fee will increase by 8.2%, and when no blobs are used, the base fee will decrease at a faster rate (14.5%), making blob space cheaper and thus encouraging more transactions.

What are the implications?

The Dencun upgrade that laid the foundations of blob space for EIP-7691 had a noticeable impact for both stakers and ETH holders. First, lower transaction fees paid by users — either because of lower competition for inclusion in a block on the Ethereum Layer 1 chain, or because of an incentive to move that activity to a Layer 2 chain — means a lower average transaction fee collected by stakers. Increasing maximum blob space and target blobs per block is set to continue this trend.

‍

Secondly, since the Dencun upgrade in April 2024, the amount of ETH burned by the network in each block has fallen as the result of a lower base fee. This has increased the circulating supply of ETH, reversing the previous fall in circulating supply that The Merge’s lower issuance upgrade brought (though we note that the increasing supply is still nowhere near as fast as the net rate of new issuance under Ethereum’s previous proof of work consensus mechanism. 

‍

We believe that, post-Pectra, a base fee calculation that’s more responsive to empty blobs and drops faster in low-activity periods will mean that the total amount of ETH burned per block (when fewer blobs are included in each block) will continue to decrease, sustaining a trend observed since the Dencun hard fork.

What is it?

Before the introduction of dedicated data storage in blob spaces, L2s posted their transaction data hashes in the “calldata” field, a data field of Ethereum transactions. EIP-7623 will increase the cost of using this field to store data for transactions that use the network primarily for data availability and, in turn, will limit the maximum possible size of an Ethereum block.

Why is it needed?

The blockchain trilemma is a crypto adage that states single-chain networks are unable to benefit from maximizing decentralization, security and scalability without sacrificing at least one of these properties. Since its inception, Ethereum has generally prioritized the first two — decentralization and security — and has deliberately limited the size of blocks on the network in order to maximize the number of nodes that must reach consensus for validation of each proposed block.

Although Ethereum has no explicit limit on block size, the theoretical block size limit is approximately 2.78 MB (excluding blobs) and 3.5 MB (when including them). However, the average block size on Ethereum is currently just 125 KB. Additionally, calldata can in fact take a maximum size of 7.15 MB, though its average size is closer to 100 KB.

‍

In its simplest conception, calldata is an empty field in a transaction that tells smart contracts what functions to call and what parameters to pass. The larger its size, the more computational resources are appended, which requires users to pay for more Ethereum gas. However, calldata can also simply contain arbitrary values, and often provides the least-gas-consuming method to post large amounts of data on-chain. As such, it has often been used by L2s to store data immutably on-chain and at a cheaper cost than paying for blob space.

‍

‍

Block size on Ethereum

The discrepancy between the maximum block size (accounting for blobs and the current average block size) is inefficient, as it suggests blocks have more space for data availability that’s not being used. In addition, a larger block size makes it more difficult to propagate blocks through the network. Looked at another way, block size is constrained by the price of calldata — in theory, an entire block could contain data availability–related transactions, such as transactions from rollups, that use small amounts of gas but are large in data size. 

‍

EIP-7623 aims to limit the max block size to 0.5 MB and to reduce the variance in block size occurring from some blocks containing transactions that use large amounts of calldata. It proposes to increase the cost of calldata, and to change the accounting method used to calculate the amount of gas used by the type of transaction in a Layer 2 to store data.

Pre-Pectra, the total gas cost of a transaction on Ethereum is the sum of the below: 

1. a flat minimum (21,000 gas units)
2. a gas amount that’s dependent on the size of data (or bytes) in the calldata field 
3. a gas amount dependent on the computation appended by smart contracts to execute the transaction.

The latter component generally makes up the majority of the gas cost for normal (non–calldata heavy) transactions. 

Pectra’s EIP-7623 introduces a different calculation for transactions that use an outsized amount of calldata relative to their gas cost. Users will be charged the maximum of either the existing gas calculation or the new cost for more calldata.

‍

Since normal transactions have a minimal gas cost (due to calldata usage) and incur the majority of the gas from the cost of smart contract computation, pre-Pectra gas calculation will be larger. This ensures that the price of regular transactions remain unaffected. Additionally, EIP-7623 will increase the price of calldata thereby disincentivising L2 Rollups from posting transactions via calldata.

‍

The end goal of EIP-7623 is to provide incentive for L2s to purely use blobs and help make space for additional blob size per block in the future without increasing the cost of normal transactions. This will prevent negative externalities on the network, as the larger cost of calldata transactions will push L2s to post data via blob space instead. 

‍