This was Grandine’s first hard fork where we fully participated in the process, so it’s difficult for us to compare it with previous forks. However, we have a few key insights to share:
Lack of a Clear Flagship Feature
Pectra ended up being a hard fork with many small improvements but no strong central message, or direction. We believe hard forks should be driven by a single flagship feature, similar to how the upcoming PeerDAS fork is structured. Additional smaller changes should only be included in exceptional cases - ideally, only if they don’t delay the shipment of the flagship feature. This approach would help control scope and accelerate fork releases.
Stronger Requirements for Non-Flagship EIPs
Any non-flagship EIPs should only be included if the proposer has implemented them in a real client and they are significantly integrated into a few ecosystem projects. This ensures that we fully understand the impact and potential friction introduced for users. It would also help prevent seemingly simple “single-line change” EIPs that, in reality, require extensive refactoring in clients and major adjustments in dependent community projects.
Faster Fork Releases Through Parallel Development
Forks need to be shipped faster, and the only viable way to achieve this is through parallel development. PeerDAS is a great example - Pectra hasn’t even been deployed on the testnet yet, and we’ve already had multiple PeerDAS devnets. However, for this model to work, teams need to be large enough to split internally so that dedicated sub-teams can focus on individual forks without key contributors being stretched across multiple efforts.