The Prysm team has internally discussed Pectra Retro. Here is a summary of our thoughts 
Key Learnings and Observations
- Underestimating complexity of EIP
EIPs can often appear simple at first glance, but their true complexity surfaces more during implementation (Example: **EIP-7549)**. This experience has taught us the importance of evaluating EIPs and client changes with greater care before making decisions on what to include. This also relates to formalizing specs earlier and having ready-testing infra would help avoid delays caused by misevaluation in spec interpretation.
- EIP prioritization did not address community need
Some EIPs accepted in Pectra, in hindsight, did not address the most urgent need today—scaling. Scaling-focused EIPs like PeerDAS should have taken priority over current Pectra EIPs. Every fork may want to have a north-star theme. Reflecting on Pectra, it’s clear how crucial it is to establish a strong and focused theme for each upgrade. Clear thematic goals will help prioritize features and reduce scope creep. Each fork should have a stable scope early in the cycle.
- More streamlined decision making process
Certain decisions during Pectra took longer than necessary. Relying solely on ACD calls slowed progress due to their weekly cadence. We should move towards more frequent, open discussions via breakout rooms and Discord async to keep all stakeholders informed. ACD calls should focus on final decision-making rather than being the primary discussion forum. Meanwhile, having a unified call structure for ACDE and ACDC would improve efficiency.
- Testing limitations
The primary bottleneck to shipping isn’t building—it’s testing. Multiple client implementation combos and limited testing entropies make finding critical consensus bugs late in the stage. EthPandaOps is simply legendary—there’s no other way to put it—but the reality is they can’t support the testing needs of 11 + more client teams. Kurtosis has proven to be a really useful tool for devnet testing. Greater investment in testing infrastructure within client teams is crucial. Early devnets and parallel streams for layer-specific upgrades could help reduce bottlenecks, allowing testing to happen earlier and more frequently.
- Sustaining client development while shipping new features
Balancing research ambitions with practical implementation limits is critical. Client teams not only develop new features but must also maintain code health. Having a known and more visible schedule - planning forks well in advance and locking down the N+1 fork scope when N ships can help reduce the burden on client teams.
Path Forward and Process Improvements
• Incorporate More Community Feedback
Client teams and community members should have stronger avenues for sharing input, with greater transparency in how decisions are made. Anyone that wants to participate in a certain topic can be informed but there exists a deadline, it’s on you if you miss the deadline and didn’t provide your input. Creating a structured dashboard for EIP reviews and feedback could improve the process compared to scattered forum threads. Based on this feedback, as a collective we can better weigh EIP priorities.
• Shift ACD Focus
Use ACD calls for final decisions while encouraging more efficient offline discussions and asynchronous reviews before calls. This will help avoid long presentations and in-depth technical debates during meetings.
• Improve Testing Infrastructure
Prioritize expanding testing capacity and recruiting more qualified testers on individual client teams level to reduce bottlenecks. Define clear requirements for EIP inclusion, including passing necessary Hive tests and running interop tests with other clients.
• Smaller and More Frequent Forks
Target a cadence of one hard fork every six months, alternating large feature forks with smaller UX and quality-of-life improvements. This schedule would reduce social pressure on each fork and provide more time for testing complex features.
• Parallel Devnet Strategy
Start devnets for future forks earlier in the process. While testing one fork, begin preparing a rolling devnet for the next fork to explore and spec target EIPs early. This approach would minimize delays caused by late scope discussions.
• Emphasize EIP Champion Responsibility
EIP champions should take on greater responsibility for ensuring the readiness of their specifications with sufficient spec tests, coordinating with testing teams, and justifying how their proposals advance the roadmap or improve network security.