# Holesky path forward ### Issue: While holesky is stable and finalizing now, a large amount of damage has already been done: - ~1M validators have been either slashed or exited from the network. These exits are lined up in the exit queue and would take until June 2026 to completely clear up. - Even with completely full deposit queues, we cannot reach the older validator sizes in a reasonable amount of time. - The consolidation feature in pectra relies on the source validator to completely exit before the balance accures in the target validator. With a full exit queue, we can no longer test consolidations on Holesky until the queue has cleared. ### Implications: - The community and staking pools would not be able to test consolidations on a public network for a long time ### Solutions: 1. We continue as is, consolidation requests can be made but the output would defer to the future. i.e, Status quo 2. We use some hackey fork/fix that empties the queue on Holesky. 3. We spin up a holesky shadowfork with a very centralized validator set. This shadowfork can be live for ~2 months and we push for staking pools to test consolidations on the shadowfork. Due to the presence of the Holesky state, the contracts and deployments would already exist on the state. Clients could make a release with `pectra-holesky-shadowfork` as the network in order to make it easier for users to sync to it. 4. We promote `pectra-devnet-6` to the location everyone goes to test for the short term. We keep the network up until mainnet and client teams can make releases with the configs. This should give all staking pools an easy and stable location for testing. 5. We speed up our testnet lifecycle and replace Holesky with a new, named testnet that would be live for the next 5y. Client teams can continue to run Holesky until we decide to shut it down. The testnet would be the 3rd officially supported testnet. Due to its long term nature, RPC providers/etc would eventually add support as it matures. We could also increase the gas limit on this network and label it as a sort of "limits" testnet. ### ethPandaOps position We are assuming client teams would shoot down 2. due to its hacky nature (Unless they can think of some other workaround). So we have a loose preference for option 4. over option 3. or 5., But are comfortable with all options (especially if staking pools prefer one over the other).