Author: Ethereum Foundation Protocol Support Team; Translation: Jinse Finance xiaozou
The Ethereum Pectra upgrade is scheduled to be activated on May 7, 2025 at Ethereum mainnet epoch 364032 (UTC time 10:05:11).
1. Introduction to Pectra
Pectra is a major update following last year's Dencun upgrade. It introduces new features to enhance the Ethereum account system, improve the validator experience, support L2 expansion, and more!
This article will explore these three major improvements in detail. For a comprehensive understanding of the upgrade content, please refer to the upgrade guide on ethereum.org.
(1) From External Accounts (EOA) to Smart Accounts
EIP-7702 marks an important step in the process of account abstraction, allowing users to add smart contract functions to external accounts (EOA).
This hybrid solution combines the simplicity of EOA with the programmability of contract accounts. Specifically, it enables wallets to support features such as:
• Transaction batching:Multiple operations can be atomically executed in a single transaction. No need to initiate separate transactions for "authorization" and "redemption"!
• Gas proxy:Allows third parties to pay transaction fees. This is particularly useful for transactions initiated without an ETH account.
• Alternative authentication:This means that many hardware security modules (HSMs) in current mobile phones can authorize account operations through technologies such as pass keys.
• Spending controls:You can limit the number of tokens that a specific application can consume, or set a daily transfer limit on the wallet for increased security.
• Recovery mechanisms:Provide users with multiple asset protection options without migrating to a new account.
When using EIP-7702, the EOA needs to sign an authorization pointing to a specific delegate address (which contains the code to be executed). Once set up, the account will gain the new code features (such as batching, proxy payment, verification logic, etc.). Since choosing a delegation target means handing over a lot of control, EIP-7702 enforces multiple security checks:
• Chain-specific delegation:By default, delegation is only valid for a specific chain ID, preventing the same authorization from being used across networks.
• Nonce-bound delegation:Authorization can be bound to the account's current nonce, and automatically expires after the nonce increases. • Revocability: EOA owners can always create new EIP-7702 authorizations to revoke or replace existing delegation codes, avoiding permanent lockouts due to erroneous operations.
(2) Validator experience optimization
Pectra includes three EIPs to improve the validator experience: 7251, 7002, and 6110.
First, EIP-7251 increases the maximum balance that a validator can receive rewards from 32 ETH to 2048 ETH by voluntarily updating the withdrawal certificate type.
For stakers, this achieves compound interest on returns. Previously, validators’ stakes above 32 ETH were not counted towards active stake. Users who want to stake more than 32 ETH can only do so in increments of 32 ETH, with intermediate values dependent on the staking pool. EIP-7251 allows both new and old validators to be configured to receive rewards based on actual stake (up to 2048 ETH).
This EIP also allows large operators to merge multiple 32 ETH validators, reducing bandwidth requirements across the network.
EIP-7002 expands validator capabilities by introducing execution-layer-triggered withdrawals. Previously, only the validator’s active signing key could trigger an exit. Now, if an Ethereum address is set as a withdrawal credential, that address can also force an exit. This reduces the trust assumption in the delegation setup, as the owner of the funds (whether it is an individual controlling the EOA or a smart contract managed by the DAO) can always initiate an exit without trust.
Finally, EIP-6110 eliminates a legacy issue from pre-merger Ethereum: the delay between a validator depositing and joining the deposit queue. Before the Ethereum merge, the beacon chain had to wait 2048 blocks before processing validator deposits to prepare for a potential proof-of-work reorganization. Now this is no longer necessary!
EIP-6110 reduces deposit processing latency from about 9 hours to 13 minutes.
(3) Blob expansion
The last major change to Pectra is EIP-7691, which doubles Ethereum's blob throughput!
The blobs introduced by the Dencun upgrade are a temporary storage solution used by L2 to submit compressed transaction data and proofs to Ethereum L1. Once enabled, L2's L1 fees are reduced by 10-100 times, significantly reducing L2 user transaction costs.
The current Ethereum mainnet supports an average of 3 blobs per block, with a peak capacity of 6. EIP-7691 will increase the average support to 6 and the peak to 9, respectively.
Unlike CALLDATA, which is permanently stored by nodes, blobs are cleared after 4096 epochs (about 18 days). This limits their space usage. The actual constraint on blobs comes from bandwidth, as they need to be propagated on the Ethereum peer-to-peer layer. To offset the bandwidth increase brought by EIP-7691, Pectra also introduced EIP-7623 to limit the upper limit of block size.
To continue to expand Ethereum data throughput without increasing bandwidth requirements, we must move from "each node stores all blobs" to "nodes only store a subset and verify the rest of the data through network sampling". The good news is: related work is already underway! Francesco from the Ethereum Foundation Research Team roughly described this expansion roadmap in his Devcon keynote.
2. Pectra Specifications
For specific updates to Pectra, please see EIP-7600. Specifically including:
• EIP-2537: Precompilation of BLS12-381 curve operations
• EIP-2935: Saving historical block hashes in the state
• EIP-6110: On-chain supply validator deposits
• EIP-7002: Execution layer-triggered exit
• EIP-7251: Increase the MAX_EFFECTIVE_BALANCE limit
• EIP-7549: Move the committee index field out of Attestation
• EIP-7623: Increase calldata cost
• EIP-7685: General execution layer request
• EIP-7691: Blob throughput improvement
• EIP-7702: Set EOA account code
• EIP-7840: Add blobs to the EL configuration file schedule
Full Python versions of the execution and consensus layer specifications can be found in the following versions:
• Execution layer: v1.17.0rc6
• Consensus layer: v1.5.0-beta.5
In addition, Pectra has also updated the Engine API used for communication between the consensus and execution layer nodes.
3. Pectra Activation
The Pectra network upgrade will be activated on the Ethereum mainnet at 10:05:11 UTC on May 7, 2025 (starting from epoch 364032).
It has been activated on the Hoodi, Holesky and Sepolia testnets.
4. Client Versions
The following client versions are suitable for Pectra upgrades on the Ethereum mainnet.
Consensus Layer Versions
When running a validator, both the consensus layer beacon node and the validator client need to be updated.

Execution layer version

5. Frequently Asked Questions
Q: How does the Ethereum network upgrade work?
A: Ethereum network upgrades require node operators to explicitly opt in. Although client developers reach consensus on the EIPs included in the upgrade, they are not the final decision makers.
For the upgrade to take effect, validators and non-staking nodes must manually update their software to support the new protocol.
If the Ethereum client used is not updated to the latest version (see above), it will lose connection with the upgraded node when the fork block occurs, causing the network to fork. In this case, each subset of nodes will only maintain connections with nodes that maintain the same (un)upgraded state.
While most Ethereum upgrades are non-contentious and forks are rare, the ability of node operators to decide whether to support an upgrade is a core feature of Ethereum governance.
Q: As an Ethereum mainnet user or ETH holder, what do I need to do?
A: In a word: No.
If you use an exchange, digital wallet, or hardware wallet, no action is required unless the service provider specifically notifies you.
Q: As a non-staking node operator, what do I need to do?
A:To ensure compatibility, please update your execution and consensus clients to the versions listed in the table above.
Q: As a staker, what do I need to do?
A:To ensure compatibility, please update your execution and consensus clients to the versions listed in the table above. Please also update your beacon node and validator clients.
Q: As an application or tool developer, what should I do?
A:Review the EIPs included in Pectra and assess their impact on your project - this upgrade introduces many exciting new features in both the execution and consensus layers!
Q: Why is it named "Pectra"?
A:The execution layer upgrade uses the Devcon city name, and the consensus layer upgrade uses the Constellation name. "Pectra" is a combination of Prague, the venue of Devcon IV, and Electra, a blue-white giant star in the constellation Taurus.