# pectra scheduling into two forks

On ACDE #196 the concern around the size of the [currently scheduled Pectra fork](https://eips.ethereum.org/EIPS/eip-7600) (along with some possible CFI'd EIPs) came up and a potential resolution was to split the Pectra scope into two forks.

I'd like to suggest one way to break the EIP set into two hard forks:

## Pectra

Essentially `pectra-devnet-3` today, along with some polish:

* 6110
* some outstanding work to resolve this feature along with other CL EIPs, but all of this would be in Pectra
* 7002
* 7251
* 7549
* 2537
* some outstanding work to finalize gas schedule
* 2935
* 7685
* the work to move to "flat hash requests and Engine API changes" is included here
* 7702
* some outstanding work to polish, see ACDE #196 for latest here

## Fusaka

Essentially the "blob suite" and EOF:

* 7594
* 7623
* 7742
* One "EIP slot" for adjusting blob parameters (target/max)
* final numbers will depend on PeerDAS details and other network analysis
* Possibly 7762
* but see note about scope creep below
* EOF EIPs listed [here](https://eips.ethereum.org/EIPS/eip-7600)

## Notes

Pectra as-is presents one of the biggest hard forks we have had in Ethereum history. The size demands a correspondingly large development, testing, and security burden. Breaking a big fork into two smaller forks is a clear win around risk of protocol upgrades and this clearly justifies this change. Smaller forks also mean faster delivery so we either have a "big" Pectra that ships much later, or two smaller forks that ship much faster. Along with the security burden concerns, getting more features faster is another clear win that justifies this change.

An immediate question is around "what goes into Fusaka?" if we make the split. I'd argue the scope of current Pectra is already two hard forks and so we have already made the scoping decision. This suggestion is now **not about scope** but **scheduling**.

That means Pectra and Fusaka as proposed above are **not open** for inclusion of other EIPs. To speak to the delivery point I made above, if we open Fusaka for inclusion of new EIPs, it will definitely add delays and defeat the aim to ship two forks sooner than one big fork.

The future is uncertain and so it is hard to make predictions around timing. I would like to ship Pectra as scoped above in H1'25 and Fusaka as scoped above in H2'25. Obviously, the sooner the better, and there could be unexpected delays as we actually turn to production implementation and testing. To derisk a potential delay, we should all be aligned around keeping the scope as tight as possible.

As a concrete process note, I will call out Danno's suggestion from ACDE #196 to start spining out `pectra-devnet-3` to the testnet phase of protocol delivery, and turn what we have discussed for `pectra-devnet-4` into `fusaka-devnet-0`. This aligns with the scope suggestion above and I think will keep momentum high.