Ethereum’s Pectra upgrade is one of the most ambitious upgrades in the ecosystem to date, introducing major improvements and innovations, such as smart accounts, blob scaling, and validator UX enhancements, among other things.
In this overview, we present the most important and relevant information on the Pectra upgrade and its long-term implications for Ethereum staking.
Pectra in a Nutshell
In line with the pre-established naming tradition of two-part upgrades separated between the execution and consensus layer, Pectra is a portmanteau of Prague+Electra.
It was initially expected to be a small upgrade. Yet, over the course of prolonged discussions between core developers about its scope and the priorities of Ethereum’s long-term progress, it has become clear that a smaller-scale upgrade was not feasible. The decision stemmed from the debate about the improvements required prior to transitioning to the Verkle structure, which was set for the upgrade that would follow Pectra (known as Fusaka, a portmanteau for Fulu+Osaka). In essence, it would imply moving away from a Merkle Patricia tree to a Verkle tree in order to enable nodes to generate more efficient and less bulky proofs, thus ushering in so-called stateless clients (lightweight clients that don’t need to store the full blockchain state).
As the Verkle transition would make Ethereum noticeably more decentralized and scalable, setting the priorities straight was crucial for the developers since, as is normal with large-scale upgrades, minimizing risks was of paramount importance. Thus, in the end, it was decided that having Fusaka focus solely on this particular transition would mitigate them significantly, and most other improvements that had been intended for it were moved to Pectra.
Main Improvements in Pectra
Pectra will include 11 EIPs (Ethereum Improvement Proposals) listed below.
- EIP-2537: Precompile for BLS12-381 curve operations
- EIP-2935: Save historical block hashes in the 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
The table below provides details on all of those proposals.
| # | Title | Authors | Content | Justification |
| 2537 | Precompile for BLS12-381 curve operations | Alex Vlasov, Kelly Olson, Alex Stokes, Antonio Sanso | Enabling efficient and gas-optimized operations for BLS12-381, addressing the limitations of the existing BN254 precompile | The current cryptographic tools in Ethereum, particularly the BN254 precompile, are not robust enough for applications that require enhanced security. The BLS12-381 curve provides stronger cryptographic features and is being more widely adopted across blockchain platforms for improved security. |
| 2935 | Save historical block hashes in state | Vitalik Buterin, Tomasz Stanczak, Guillaume Ballet, Gajinder Singh, Tanishq Jasoria, Ignacio Hagopian, Jochem Brouwer, Sina Mahmoodi | Introducing a system to store the last 8,191 historical block hashes in the state of Ethereum as part of a system contract for enabling more efficient state proofs and interactions. | Ethereum currently depends on clients for recent block hashes, which is not a future-proof approach. This proposal addresses the limitation by embedding block hashes in the state, enhancing accessibility and enabling features like extended proof validation and rollup interaction. |
| 6110 | Supply validator deposits on chain | Mikhail Kalinin, Danny Ryan, Peter Davies | Integrating validator deposits directly into the Ethereum Execution Layer blocks. | The current mechanism relies on the complex deposit voting process in the Consensus Layer. This proposal removes deposit voting from the Consensus Layer, shifting the responsibility for deposit inclusion and validation to the Execution Layer. The goal is toimprove security, simplify client design, and reduce validator deposit processing delays |
| 7002 | Execution layer triggerable exits | Danny Ryan, Mikhail Kalinin, Ansgar Dietrichs, Hsiao-Wei Wang, lightclient | Introducing the mechanism that allows validators to initiate withdrawals and exits directly using their Execution Layer (0x01) withdrawal credentials. | Currently, validators need their active “hot” keys to initiate exits. The proposal addresses the restriction where only the active validator key could trigger withdrawals, ensuring that withdrawal credential holders have full control over their staked ETH securely and independently. |
| 7251 | Increase the MAX_EFFECTIVE_BALANCE | Michael Neuder, Francesco, dapplion, Mikhail Kalinin, Aditya Asgaonkar, Justin Drake, lightclient | Raising the maximum effective staking balance for Ethereum validators up to 2048 ETH while keeping the 32 ETH minimum requirement. | Currently, validators are limited to 32 ETH, which forces large stakers to operate many redundant validators, and that increases network overhead and inefficiencies. This proposal would reduce the validator count, optimize resource use, and improve efficiency for both solo and large-scale stakers. |
| 7549 | Move committee index outside Attestation | dapplion, Mikhail Kalinin | Moving the committee index outside the signed Attestation message in Ethereum’s Consensus Layer to enable vote aggregation. | The current mechanism of attestations in Ethereum’s Beacon Chain leads to increased computational and storage requirements for validators and ZK circuits. The proposal’s goal is to optimize Casper FFG (Friendly Finality Gadget) mechanisms that will enhance gas efficiency, scalability, and cryptographic verification. |
| 7623 | Increase calldata cost | Vitalik Buterin, Toni Wahrstätter | Raising the gas cost of calldata to reduce maximum block size and its variance. | Ethereum’s calldata costs have remained unchanged since EIP-2028, leading to inefficiencies as rollups generate large, data-heavy blocks. This proposal adjusts calldata costs to reduce inefficiencies and align with EIP-4844’s data availability changes. |
| 7685 | General purpose execution layer requests | lightclient | Introducing a framework for managing contract-triggered requests between Ethereum’s Execution Layer and Consensus Layer. | Smart contract-controlled validators often rely on external intermediaries for administrative actions, introducing inefficiencies and risks. This proposal allows direct requests from smart contracts to the CL, streamlining operations and improving safety, scalability, and cross-layer communication for governance automation. |
| 7691 | Blob throughput increase | Parithosh Jayanthi, Toni Wahrstätter, Sam Calder-Mason, Andrew Davis, Ansgar Dietrichs | Raising the maximum and target number of blobs per block in Ethereum to 9 and 6, respectively. | This proposal addresses current data availability limitations, offering a short-term scalability improvement for Layer 2 rollups while long-term solutions like peerDAS are being developed. |
| 7702 | Set EOA account code | Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, lightclient | Introducing a new transaction type that enables Ethereum externally owned accounts (EOAs) to permanently set their account code, creating a mechanism for delegation. | EOAs are less programmable than smart contracts, limiting their efficiency and flexibility. This proposal introduces a mechanism to extend EOAs’ functionality, improving gas optimization, security, and interoperability by bridging the gap between EOAs and contract accounts. |
| 7840 | Add blob schedule to EL config files | lightclient | Adding a blob Schedule object to Ethereum client configuration files to define the target and maximum blob counts per block for each network fork. | Currently, execution clients depend on blob configuration data for some features. Storing this data only in the consensus client leads to inefficiencies and extra API calls between clients for each block. This proposal improves performance by offloading the need for execution and consensus layers to perform excessive data handshakes. |
What Does Pectra Mean for Ethereum Staking
The staking mechanism in Ethereum will experience significant changes after Pectra’s implementation, affecting large and solo stakers alike, as well as the network as a whole. The main changes stem from three Ethereum Improvement Proposals.
Increased Maximum Effective Balance (EIP-7251)
The maximum effective balance per validator will increase from 32 ETH to 2,048 ETH. This would allow large stakers to use a single validator instead of several ones. In turn, it will massively reduce operational complexity.
Solo stakers, therefore, will be able to benefit from compounding benefits provided their stake exceeds 32 ETH. This will also affect those participating in ETH staking pools, such as Everstake’s 0.1+ ETH Staking Pool, with stakes lower than 32 ETH since the compounding option without the need to activate another validator will also become available for their pools.
The network as a whole will benefit from reduced network congestion, which can usher in enhanced scalability performance.
Execution Layer Triggerable Exits (EIP-7002)
Staking services and pools, like those provided by Everstake, will be able to automate validator exit for a more streamlined operation and improved user experience.
At the same time, solo stakers will be able to initiate validator exit directly via the execution layer without engaging in consensus-layer interactions. Thus, the responsiveness of the entire staking ecosystem will significantly improve.
Supply Validator Deposits On-Chain (EIP-6110)
This will accelerate the activation of a new validator from approximately 13 hours to about 13 minutes, which will dramatically enhance staking for large stakers.
Quicker validator activation will also mean that solo stakers can participate and receive their staking benefits much faster than before.
At the end of the day, the overall staking experience will undergo massive optimization, and user experience will dramatically improve. In the long run, this improvement will make Ethereum much friendlier to broader audiences and newcomers to ETH staking.
How Pectra Will Benefit Users and Developers
Regular Ethereum users will enjoy some of the most pronounced improvements upon the full implementation of Pectra.
- Account abstraction will enable users to use tokens like USDC to pay transaction fees without relying solely on ETH. This will make Ethereum way more accessible and convenient by removing a serious hurdle that requires everyone to have ETH to make transactions on the network.
- The transaction cost will also drop, thanks to the optimization of data processing and storage management. Ethereum has long experienced trouble with fluctuating transaction fees that occasionally became unreasonably high to many users. While there have been solutions that mitigated it to an extent, Pectra is set to seriously lower this threshold. In perspective, it can attract even more projects and users to the ecoystem.
- Wallet capabilities will also expand with new functionality like batched transactions and customizable security options, all aimed at ensuring a more seamless interaction with decentralized applications. This is particularly beneficial to users who are not highly skilled at complex technological solutions and processes, making the entire ecosystem more user-friendly.
Similarly, many developers will be able to benefit from the new opportunities that Pectra is set to bring about.
- Pectra will bring about updates to the Ethereum Virtual Machine (EVM), particularly the EOF (object format). This will make the deployment of smart contracts more cost-effective and less time-consuming. In addition to that, developers will be able to enjoy broader coding capabilities.
- The aforementioned increase of the staking limit from 32 ETH to 2,048 ETH will enable developers and major validators to reduce operational costs and complexity.
- Most importantly, Pectra will optimize the data storage and verification process in anticipation of the adoption of Verkle trees. The network is set to become more efficient and resilient, which would simplify the deployment of new decentralized applications.
Testnet Issues
As the upgrade began, the testnets faced noticeable challenges. The Holešky testnet experienced non-finality issues caused by incorrect deposit contract addresses that affected validator deposits. After about two weeks of troubles with excessive state storage for nodes and validators, the issues were finally resolved, and Holešky achieved finalization.
The problems, however, continued with Sepolia. There were unexpected transaction failures and overall network instability mostly caused by certain issues with a custom deposit contract which required quick intervention by devs and node operators. Those two instances brought about an extensive discussion of whether Pectra’s mainnet launch had to be postponed.
The Ethereum developers addressed these concerns by introducing Hoodi, a long-lived testnet tailored specifically for Pectra testing, validator exits, and staking operations. It mimics the mainnet environment exclusively for staking and protocol-level testing and exists in parallel with Sepolia, which remains the primary testnet for dApps, smart contracts, and other EVM functionalities.
Given the effort devs, client teams, and the community at large put into addressing the issues with the testnets, it became apparent that rigorous testing across multiple environments is crucial while preparing for mainnet deployment if the stability and security of Ethereum are to be ensured.
Upgrade Timeline
Pectra went live as scheduled—February 24 on Holešky and March 5 on Sepolia. Its launch on Hoodi is scheduled for March 26, which, if successful, will lead to the mainnet launch tentatively scheduled for late April or early May 2025.
Everstake and Pectra
To stay ahead of all the developments related to the Pectra upgrade, be sure to subscribe to Everstake’s in-house ETH expert on X (formerly Twitter) and always be the first to know about all the most important news in the Ethereum ecosystem.
Stake with Everstake | Follow us on X | Connect with us on Discord
***
Everstake is a software platform that provides infrastructure tools and resources for users but does not offer investment advice or investment opportunities, manage funds, facilitate collective investment schemes, provide financial services or take custody of, or otherwise hold or manage, customer assets. Everstake does not conduct any independent diligence on or substantive review of any blockchain asset, digital currency, cryptocurrency, or associated funds. Everstake’s provision of technology services allowing a user to stake digital assets is not an endorsement or a recommendation of any digital assets by it. Users are fully and solely responsible for evaluating whether to stake digital assets.
