For those of you who are plugged into the Ethereum world, you would be aware that Pectra has recently shipped. And, like every major fork in the past, this is a good time to look back, not just at what went into this major upgrade but also at how Prysm got here in the first place.
Prysm has existed since 2018. Its initial purpose was to support Ethereum through sharding. This was pre-merge, and back when sharding was still at the center of Ethereum’s scalability roadmap. As priorities shifted toward Proof of Stake, so did Prysm’s direction and the many iterations of its codebase.
Since then, Prysm has grown to become one of the most widely used consensus clients. In 2020, it helped bring the Beacon Chain to life, then later in 2022 (the same year Prysm joined Offchain), it successfully assisted in shipping the Merge. Most recently, with Pectra, the Prysm team helped ship one of the most complex forks since the Merge. This latest upgrade is packed with new features and structural improvements, which the blog will delve into in more detail.
Eight years down the road, Prysm’s mission has remained the same. That is, to help scale Ethereum, improve validator infrastructure, and continue to push the boundaries of possibilities of what blockchains can do.
Bringing the Pectra Hard Fork to Life
As previously mentioned, Pectra was one of the largest forks since the Ethereum Merge. Over a year of development work went into making it happen, and Prysm was right in the middle of it all. So what happened behind the scenes?
Around 37 unique contributors helped bring Pectra to life across 12 different releases, from versions 5.1 to 6.0.2. This effort resulted in over 3,100 file changes, with nearly 700 commits. This was a massive effort, with roughly half of the EIPs included in the fork implemented directly in the Prysm code base.
These weren’t minor features either. The Prysm team handled some significant consensus logic changes, such as onchain validator deposits (EIP-6110), execution triggerable withdrawals (EIP-7002), and raising the validator max balance (EIP-7251). The Prysm team also helped bring in generalized requests from the execution layer (EIP-7685) and boosted blob throughput (EIP-7691). Pectra was rather unique in its breadth, as it touched nearly every part of the system. For the Prysm team, this upgrade was a chance to demonstrate deep technical understanding and deliver meaningful improvements across the board.
The Invisible Work That Made Pectra Possible
Considering the scope of Pectra, the upgrade was relatively seamless, but that isn’t to say everything was clean. Take EIP-7549, for example. This EIP was proposed to make onchain attestations more compact, fitting up to eight slots’ worth of votes into a block instead of just two today and drastically improving Ethereum’s ability to maintain liveness even in scenarios where there was only a small fraction of proposers online. Although this looked like a small change, where all that needed to be done was just reordering some attestation data, in practice, this touched hundreds of files and required a lot of internal rewiring.
That said, Pectra did unlock some real quality-of-life improvements, such as its significant improvement to validator UX. By reducing deposit inclusion time, Prysm could begin the cleanup process of legacy logic from the merge era, which basically translates to less fragile, bug-prone code in the long term. This improvement enabled validators to compound their earnings without having to redeposit manually. And, with EIP-7002 now in place, smart contracts can directly trigger validator actions.
Of course, ample testing is part of any new upgrade. The Prysm team participated in six devnets and three public tenets, Holesky, Sepolia, and Hoodi, in collaboration with over 200 engineers and researchers across the Ethereum ecosystem.
The team also participated in the Nyota interop, Ethereum’s largest coordinated client testnet event for the Pectra upgrade, ran interop suites using Kurtosis Ethereum package from eth pandaops, and helped write and review spec test coverage across more than 16 test versions.
In addition to all this, a lot of time was spent testing edge cases, catching consensus mismatches, and ensuring that external infrastructure such as MEV-boost was compatible with Web3Signer.
So, What’s Next For Prysm?
Although the Pectra days may be over, Ethereum is not planning to slow down. In fact, the next upgrade currently underway is Fusaka, which will ship this same year. Fusaka is notable not only for its technical goals, but also because it will be the first time that Ethereum has attempted to ship two hard forks within the same year.
Fusaka is focused on scaling blob space and improving data availability. The main feature to watch for here is EIP-7594, which will introduce PeerDAS (peer data availability sampling). Today, on Ethereum, every node must download every blob, which isn’t scalable in the long run. PeerDAS is designed to change this by enabling nodes to sample blob data and verify it using erasure coding. This will allow Ethereum to increase blob throughput safely, a necessary step for scaling.
Prysm is also preparing for Blob Parameter Only (BPO) forks, which can safely increase blob count without requiring a massive consensus upgrade. This will make Ethereum much more responsive moving forward.
Eight years following its inception, the Prysm team continues to play a foundational role in its mission to scale Ethereum with Offchain. Prysm is still here, building, and we don’t plan to slow down anytime soon.
Author: James He, 2026
