The Pectra network upgrade is scheduled to activate on the Ethereum mainnet on May 07, 2025 at epoch 364032 (10:05:11 UTC)! Mainnet client releases are listed below.

Pectra Overview

Pectra follows last year's Dencun upgrade. It introduces features to augment Ethereum accounts, improve the validator experience, support L2 scaling and more!

This post explores these three major improvements in detail. For a more comprehensive overview, see ethereum.org's guide to the upgrade.

From EOAs to Smart Accounts

EIP-7702 represents a major step toward widespread account abstraction, enabling users to enhance their Externally Owned Accounts (EOAs) with smart contract functionality.

This hybrid approach combines the simplicity of EOAs with the programmability of contract-based accounts. In practice, it enables wallets to support:

• Transaction batching, where multiple operations execute atomically within a single transaction. No more separate transactions for "approve" and "swap"!
• Gas sponsorship, which allows others to pay for transaction fees. This is especially useful when wanting to transact from an account that doesn't have ETH in it.
• Alternative authentication, which means many hardware security modules (HSMs) in phones today can be used to authorize operations for the account via technologies like passkeys.
• Spending controls, which can limit how many tokens a specific application can spend, or cap daily outflows from a wallet, improving security.
• Recovery mechanisms, which provide different options for users to safeguard their assets, without migrating to a new account.

To use EIP-7702, an EOA signs an authorization pointing to a specific delegation address whose code it wants to execute. Once set, the account gains the new code’s capabilities (e.g., batching, sponsorship, authentication logic, etc.). Because choosing a delegation target hands over a great deal of control, EIP-7702 enforces several safety checks:

• Chain-specific delegations: by default, a delegation is only valid on a specific chain ID, preventing the same authorization from being used on different networks.
• Nonce-bound delegations: authorizations can be tied to the account's current nonce, automatically invalidating them once the nonce increases.
• Revocability: the owner of the EOA can always create another EIP-7702 authorization that revokes or replaces the existing delegation code, preventing a permanent lock-in if something goes wrong.

For best practice on using EIP-7702, see this page.

Validator UX Improvements

Three new EIPs within Pectra improve the validator experience: 7251, 7002 and 6110.

The first, EIP-7251, raises the maximum balance a validator can receive rewards on from 32 ETH to 2048 ETH, through an opt-in update of withdrawal credential type.

For stakers, this enables reward compounding. Previously, any rewards earned beyond a validator's 32 ETH deposit would not count towards their active stake. Stakers who wanted to stake more than 32 ETH could only do so in fixed 32 ETH increments, relying on staking pools for anything 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 allows larger operators to consolidate multiple validators, by merging multiple 32 ETH validators. This reduces the bandwidth requirement for the network as a whole. To understand the mechanics in detail, see this page.

EIP-7002 also extends validators' abilities, this time by introducing execution layer triggerable withdrawals. Prior to this EIP, only a validator's active signing key could trigger an exit. Now, if an Ethereum address is set as a withdrawal credential, that too can force an exit. This reduces trust assumptions in delegation settings, as the owner of the funds -- be they a human in control of an EOA or a DAO-managed smart contract -- can always trustlessly initiate an exit.

Lastly, EIP-6110 removes a lingering vestige of pre-merge Ethereum: the delay between validator deposits and their addition to the deposit queue. Pre-merge, the Beacon Chain had to wait 2048 blocks before processing validator deposits to account for potential proof-of-work re-orgs. This is no longer necessary!

With EIP-6110, deposit processing delays now drop from around 9 hours to roughly 13 minutes. Teku engineers Lucas Saldanha and Stefan Bratanov covered the details of EIP-7002 and EIP-6110 in their joint Devcon SEA talk.

Blob Scaling .oO

The final major change in Pectra is EIP-7691, which doubles Ethereum’s blob throughput!

Blobs, introduced in the Dencun upgrade, are ephemeral data storage that L2s can use to submit compressed transaction data and proofs to Ethereum L1. Since going live, they've reduced L1 fees for L2s by 10-100x, resulting in far cheaper L2 user transactions.

The Ethereum mainnet currently supports an average of 3 blobs per block, with a maximum of 6 to accommodate periods of high demand. With EIP-7691, these numbers will increase to an average of 6 and maximum of 9.

Unlike CALLDATA, which nodes store indefinitely, blobs are pruned from the network after 4096 epochs (~18 days). This bounds the amount of disk space they can use. The binding constraint for blobs is instead bandwidth, as blobs need to be gossiped over Ethereum's peer-to-peer layer. To offset the bandwidth increase caused by EIP-7691, Pectra also introduces EIP-7623, which caps the worst-case size of a block.

To continue scaling Ethereum’s data throughput without a corresponding rise in bandwidth requirements, we must shift from a world where every node stores every blob to one where nodes store only a subset and sample the network to verify the remaining blob data. Good news: work to support this is already underway! Francesco from the Ethereum Foundation Research team outlined this scaling roadmap in his Devcon keynote.

Pectra Specifications

The list of changes introduced in Pectra can be found in EIP-7600. For reference, they are:

• EIP-2537: Precompile for BLS12-381 curve operations
• EIP-2935: Save historical block hashes in state
• EIP-6110: Supply validator deposits on chain
• EIP-7002: Execution layer triggerable exits
• EIP-7251: Increase the MAX_EFFECTIVE_BALANCE
• EIP-7549: Move committee index outside Attestation
• EIP-7623: Increase calldata cost
• EIP-7685: General purpose execution layer requests
• EIP-7691: Blob throughput increase
• EIP-7702: Set EOA account code
• EIP-7840: Add blob schedule to EL config files

Additionally, full python specification for the changes to the execution and consensus layer specifications can be found in the following releases:

• Execution layer: v1.17.0rc6
• Consensus layer: v1.5.0-beta.5

Lastly, Pectra also introduces changes to the Engine API used for communication between the consensus and execution layer nodes. These are specified in the prague.md file of the repository.

Pectra Activation

The Pectra network upgrade will activate on the Ethereum mainnet at the start of epoch364032, happening on May 07, 2025 at 10:05:11 UTC.

It was previously activated on the Hoodi, Holesky and Sepolia testnets.

Client Releases

The following client releases are suitable for the Pectra upgrade on the Ethereum mainnet.

Consensus Layer Releases

When running a validator, both the Consensus Layer Beacon Node and Validator Client must be updated.

• Note: the recommended Nimbus version was changed from v25.4.0 to v25.4.1 on April 26.

Execution Layer Releases

FAQ

How do Ethereum network upgrades work?

Ethereum network upgrades require explicit opt-in from node operators on the network. While client developers come to consensus on what EIPs are included in an upgrade, they are not the ultimate deciders of its adoption.

For the upgrade to go live, validators and non-staking nodes must manually update their software to support the protocol changes being introduced.

If they use an Ethereum client that is not updated to the latest version (listed above), at the fork block, it will disconnect from upgraded peers, leading to a fork on the network. In this scenario, each subset of the network nodes will only stay connected with those who share their (un)upgraded status.

While most Ethereum upgrades are non-contentious and cases leading to forks have been rare, the option for node operators to coordinate on whether to support an upgrade or not is a key feature of Ethereum's governance.

For a more exhaustive overview of Ethereum's governance process, see this talk by Tim Beiko.

As an Ethereum mainnet user or $ETH holder, is there anything I need to do?

In short, no.

If you use an exchange, digital wallet or hardware wallet you do not need to do anything unless you are informed to take additional steps by your exchange or wallet provider.

If you'd like to watch the upgrade go live, you can join the online viewing party!

As a non-staking node operator, what do I need to do?

To be compatible with the upgrade, update your node's execution and consensus layer clients to the versions listed in the table above.

As a staker, what do I need to do?

To be compatible with the upgrade, update your node's execution and consensus layer clients to the versions listed in the table above. Make sure both your beacon node and validator client are updated.

As an application or tooling developer, what should I do?

Review the EIPs included in Pectra to determine if and how they affect your project --- there are many new exciting features being introduced across both the execution and consensus layers!

Why "Pectra"?

Upgrades to the execution layer follow Devcon city names, and those to the consensus layer use star names. "Pectra" is the combination of Prague, the location of Devcon IV, and Electra, a blue-white giant star in the constellation of Taurus.

Original cover image by Julia Solonina, with modifications by Tomo Saito.