The Pectra network enhancement is slated to commence on the Ethereum mainnet on May 07, 2025 at epoch 364032 (10:05:11 UTC)! Mainnet client releases can be found below.
Pectra Overview
Pectra follows the previous year’s Dencun upgrade. It introduces features aimed at enhancing Ethereum accounts, refining the validator experience, facilitating L2 scaling and beyond!
This article delves into these three significant improvements in depth. For a more exhaustive overview, refer to ethereum.org’s guide to the upgrade.
From EOAs to Smart Accounts
EIP-7702 marks a significant advancement toward widespread account abstraction, allowing users to upgrade their Externally Owned Accounts (EOAs) with smart contract capabilities.
This combined strategy merges the ease of EOAs with the flexibility of contract-based accounts. In practice, it empowers wallets to offer:
- Transaction grouping, enabling multiple operations to be executed atomically within a single transaction. No more individual transactions for “approve” and “swap”!
- Gas sponsorship, allowing third parties to cover transaction costs. This is particularly beneficial when seeking to transact from an account that lacks ETH.
- Diverse authentication, meaning that numerous hardware security modules (HSMs) in modern devices may be utilized to authorize operations for the account via technologies such as passkeys.
- Expenditure controls, which can restrict how many tokens a particular application is allowed to spend, or limit daily outflows from a wallet, enhancing security.
- Recovery options, which present various methods for users to protect their assets, without the necessity of transitioning to a new account.
To implement EIP-7702, an EOA signs an authorization directing to a specific delegation address whose code it intends to execute. Once established, the account acquires the new code’s functionalities (e.g., batching, sponsorship, authentication logic, etc.). Since selecting a delegation target assigns a substantial amount of control, EIP-7702 mandates several safety measures:
- Chain-specific delegations: by default, a delegation is exclusively valid on a particular chain ID, preventing the same authorization from being utilized across various networks.
- Nonce-restricted delegations: authorizations can be linked to the account’s current nonce, automatically invalidating them once the nonce rises.
- Revocation capability: the owner of the EOA can always create an alternative EIP-7702 authorization that cancels or replaces the existing delegation code, avoiding a permanent lock-in if an issue arises.
For optimal practices regarding the use of EIP-7702, check out this page.
Validator UX Enhancements
Three new EIPs within Pectra enhance the validator experience: 7251, 7002 and 6110.
The first, EIP-7251, elevates the maximum balance a validator can accrue rewards on from 32 ETH to 2048 ETH, through an opt-in update of withdrawal credential type.
For stakers, this enables the compounding of rewards. Previously, any rewards accrued beyond a validator’s 32 ETH deposit were not considered towards their active stake. Stakers aiming to stake beyond 32 ETH could only do so in fixed increments of 32 ETH, depending on staking pools for amounts in between. With EIP-7251, both existing and new validators can be configured to earn rewards on every ETH staked, up to 2048 ETH per validator.
This EIP also empowers larger operators to consolidate multiple validators by combining several 32 ETH validators. This alleviates the bandwidth requirement for the network as a whole. For a deeper understanding of the mechanics, refer to this page.
EIP-7002 further expands validators’ capabilities by introducing execution layer triggerable withdrawals. Before this EIP, only a validator’s active signing key could initiate an exit. Now, if an Ethereum address is designated as a withdrawal credential, it can also trigger an exit. This reduces trust assumptions in delegation arrangements, as the owner of the funds — whether a person managing an EOA or a DAO-controlled smart contract — can always trustlessly initiate an exit.
Lastly, EIP-6110 eliminates a lingering remnant of pre-merge Ethereum: the delay between validator deposits and their inclusion in the deposit queue. In the pre-merge era, the Beacon Chain had to wait 2048 blocks before processing validator deposits to account for possible proof-of-work re-organizations. This is no longer necessary!
With EIP-6110, deposit processing delays have been reduced from around 9 hours to approximately 13 minutes. Teku engineers Lucas Saldanha and Stefan Bratanov presented the details of EIP-7002 and EIP-6110 in their joint Devcon SEA presentation.
Blob Scaling .oO
The final significant alteration inPectra is EIP-7691, which enhances Ethereum’s blob handling capacity twofold!
Blobs, which were unveiled in the Dencun upgrade, serve as temporary data storage that L2s can utilize to submit compressed transaction details and proofs to Ethereum L1. Since their implementation, they’ve significantly decreased L1 costs for L2s by 10-100 times, leading to drastically lower transaction costs for L2 users.
Presently, the Ethereum mainnet allows an average of 3 blobs per block, with a peak of 6 to manage spikes in demand. Following EIP-7691, these figures will rise to an average of 6 and a ceiling of 9.
In contrast to CALLDATA, which nodes keep permanently, blobs are removed from the network following 4096 epochs (~18 days). This limits the storage space they can occupy. The limiting factor for blobs is bandwidth, as they must be disseminated throughout Ethereum’s peer-to-peer network. To mitigate the bandwidth increase that EIP-7691 could bring, Pectra also introduces EIP-7623, which places a cap on the maximum size of a block.
To sustain Ethereum’s data handling growth without a proportional rise in bandwidth demands, we must transition from a scenario where every node holds every blob to one where nodes keep only a fraction and sample the network to verify the remaining blob information. The good news is that efforts to facilitate this transition are already in motion! Francesco from the Ethereum Foundation Research team detailed this scaling strategy in his Devcon keynote.
Pectra Specifications
The detailed alterations brought by Pectra are documented in EIP-7600. For reference, they include:
In addition, comprehensive Python specifications for the updates to the execution and consensus layer specifications are available in the subsequent releases:
Lastly, Pectra also brings modifications to the Engine API utilized for interaction between the consensus and execution layer nodes. These are detailed in the prague.md file of the repository.
Pectra Activation
The Pectra network upgrade is set to go live on the Ethereum mainnet at the commencement of epoch364032, occurring on May 07, 2025 at 10:05:11 UTC.
It was previously activated on the Hoodi, Holesky and Sepolia test networks.
Client Releases
The subsequent client versions are appropriate for the Pectra upgrade on the Ethereum mainnet.
Consensus Layer Releases
When operating as a validator, both the Consensus Layer Beacon Node and Validator Client must be updated.
Execution Layer Releases
FAQ
How do Ethereum network upgrades function?
Ethereum network upgrades necessitate explicit consent from node operators on the network. While client developers reach a consensus on the EIPs that will be part of an upgrade, they do not possess the ultimate authority for its implementation.
For the upgrade to be enacted, both validators and non-staking nodes must manually refresh their software to accommodate the protocol alterations being introduced.
If they utilize an Ethereum client that hasn’t been updated to the latest iteration (as listed above), at the fork block, it will disconnect from upgraded peers, resulting in a fork within the network. In this situation, each subset of the network nodes will only remain connected to those with the same (un)upgraded status.
While the majority of Ethereum upgrades are non-contentious and instances leading to forks have been infrequent, allowing node operators to coordinate on whether to adopt an upgrade or not is a crucial aspect of Ethereum’s governance.
For a more comprehensive overview of Ethereum’s governance framework, consult this presentation by Tim Beiko.
As an Ethereum mainnet user or $ETH holder, is there anything required of me?
In summary, no.
If you utilize an exchange, digital wallet, or hardware wallet, you do not need to take any action unless you receive instructions for additional steps from your exchange or wallet provider.
If you’d like to witness the upgrade go live, feel free to join the online viewing event!
As a non-staking node operator, what actions should I take?
To comply with the upgrade, refresh your node’s execution and consensus layer clients to the versions outlined in the table above.
As a staker, what should I do?
To ensure compatibility with the upgrade, update your node’s execution and consensus layer clients to the versions identified in the table above. Ensure that both your beacon node and validator client are updated.
As an application or tooling developer, what steps should I take?
Examine the EIPs incorporated in Pectra to assess if and how they influence your project — numerous intriguing new features are being launched across both the execution and consensus layers!
What’s the origin of the name “Pectra”?
Upgrades for the execution layer follow the names of Devcon cities, while those for the consensus layer utilize star names. “Pectra” is derived from the names Prague, the location of Devcon IV, and Electra, a blue-white giant star within the Taurus constellation.
Original cover image by Julia Solonina, with adjustments by Tomo Saito.
