The recent failed forks on Sepolia and Holesky left Ethereum app developers without a stable, finalizing testnet, effectively halting most development progress for nearly three weeks. This disruption underscored a critical issue: the lack of reliable testnet infrastructure for developers.
With the Ethereum Foundation’s leadership transition, there is now a renewed focus on app developers. This shift presents an opportunity to reassess the goals and priorities of Ethereum’s testnets to better support the broader development community.
SSV.Network, like many other projects, was heavily reliant on Holesky. The network instability significantly delayed our development, reinforcing the need for more dependable testing environments. Frustrated by the situation, I tweeted the following:
Moving forward, the Ethereum community must prioritize testnet stability to ensure continuous innovation and prevent future bottlenecks in protocol and application development.
What Are Testnets For?
“A testnet is an encapsulation of some Ethereum fork, with next to zero cost of testing and experimentation”
And boy did we have a lot of them… 26 to be exact (see table below)
Despite their differences, all testnets share common traits:
- Critical dependencies – Developers rely on them for QA testing, transaction validation, contract interactions, and more.
- Operational overhead – Running nodes, coordinating upgrades, and maintaining tooling introduce significant costs and complexity.
- Finite lifespan – Unlike mainnet, all testnets are eventually deprecated, forcing migrations and disrupting workflows.
Historically, some testnets enjoyed longer lifespans (Ropsten, Kovan, Rinkeby, Goerli), but recent years have brought instability, introducing frequent changes to testing environments. While no testnet has ever been designated as “everlasting,” the consequences of their deprecation are far from trivial—especially for app developers with limited DevOps and cloud resources.
The Need for a Persistent Testnet
We tend to accept that mainnet is the only stable network, but that assumption is flawed when building consumer-facing applications. Developers need a testnet that mirrors mainnet as closely as possible.
As dApp complexity grows, so does dependency on external services. Expecting developers to self-replicate critical Ethereum infrastructure (e.g., ENS, Etherscan, builders/relays) for local testing is neither practical nor scalable.
Case Studies: Why Stability Matters
-
Dex Aggregator
A DEX aggregator relies on multiple on-chain services like oracles, DEX pools, and bridges, which are difficult to replicate. While open-source contracts can be redeployed, the effort and cost involved are prohibitive. -
Staking Service
Staking services must interact with third-party components such as relays, builders, and deposit contracts. These dependencies are nearly impossible to replicate in a local test environment.
Testnet Successions
| Terminated Testnet | Successor | Reason for Transition |
|---|---|---|
| Morden (July 2015 – Nov 2016) | Ropsten (Nov 2016) | Morden was deprecated due to accumulated junk data and client consensus issues. Ropsten replaced it as the primary PoW testnet. |
| Ropsten (Nov 2016 – Dec 2022) | Sepolia (Oct 2021 – Active) | Ropsten was transitioned to PoS during Merge testing, then deprecated in favor of Sepolia, which is lighter and easier to maintain. |
| Kovan (March 2017 – 2021) | Sepolia (Oct 2021 – Active) | Kovan was a PoA testnet maintained by OpenEthereum (Parity), which was deprecated. Sepolia became the main Ethereum execution-layer testnet. |
| Rinkeby (April 2017 – Q3 2023) | Sepolia (Oct 2021 – Active) | Rinkeby did not undergo The Merge, so it was deprecated. Sepolia took over as the main lightweight testnet. |
| Goerli (Jan 2019 – Active, planned EOL 2024) | Holesky (Sep 2023 – Active) | Goerli faced issues with test-ETH supply and staking limitations. Holesky was launched as a large-scale staking testnet to replace it. |
| Prater (June 2021 – Aug 2022) | Merged with Goerli (Aug 2022) | Prater was an Ethereum 2.0 beacon chain testnet. It was merged into Goerli to simulate The Merge. |
| Pyrmont (Nov 2020 – Q4 2021) | Prater (June 2021 – Aug 2022) | Pyrmont was an early staking testnet, but Prater replaced it as the long-term beacon chain testnet. |
| Kiln (Feb 2022 – Sep 2022) | No direct successor (transition to Merge) | Kiln was the final Merge testnet. It was decommissioned after The Merge successfully went live on mainnet. |
| Shandong (Oct 2022 – Jan 2023) | Shanghai Public Testnets (Zhejiang, etc.) | Shandong was an early testnet for Shanghai/EOF, but EOF was postponed, so it was replaced by final Shanghai testnets. |
| Zhejiang (Feb 2023 – April 2023) | Mainnet Shanghai Upgrade | Zhejiang was a short-lived testnet to simulate ETH withdrawals. Once Shanghai went live, it was deprecated. |
In A Perfect World
To solve the issues outlined above, we need to rethink what a testnet should be. A perfect testnet for app developers should embody the following key properties:
1. Continuity: A Testnet That Lasts
A truly effective testnet must be long-lasting—ideally indefinite—evolving alongside the Ethereum mainnet. It should serve as a permanent point of reference for developers, ensuring stability in testing environments.
Continuity enables the broader developer community to build an entire ecosystem around it, including:
- Tooling (e.g., monitoring, debugging, and deployment frameworks)
- Faucets (ensuring easy access to test ETH)
- Builders & Relays (for a realistic block-building environment)
- Explorers (to track test transactions just like on mainnet)
- Interoperable dApps (for seamless integration testing)
2. Isomorphism: A True Mainnet Replica
The ideal testnet should mirror mainnet as closely as possible. This means:
- Protocol stability – The testnet should not fail due to forks, misconfigurations, or protocol changes.
- Identical properties – Everything from gas mechanics to validator behavior should be an accurate reflection of mainnet, except for the use of “funny money” instead of real ETH.
- Full-feature parity – It must support the same infrastructure services as mainnet, ensuring realistic testing conditions.
3. Accessibility: Open & Scalable for Developers
Past testnets have often suffered from artificial scarcity—whether through limited access to test ETH, restricted validator sets, or bureaucratic hurdles. This led to instability, slow adoption, and even premature deprecation.
A developer-friendly testnet should be:
- Permissionless – Anyone should be able to access it and spin up validators if needed.
- Scalable – Designed to handle high transaction volumes and large-scale app testing.
- Easy to onboard – With simple mechanisms for obtaining test ETH and deploying smart contracts at scale.
Methodology for Ethereum Networks
To address the current issues with Ethereum testnets, we propose a structured testnet methodology that categorizes networks based on their purpose, stability, and governance. This approach ensures continuity, isomorphism, and accessibility while providing dedicated environments for different use cases.
1. Mainnet (Ethereum Main Network)
Purpose: The primary Ethereum network for production use.
- Ever-lasting – The final, canonical Ethereum chain.
- Minimal risk tolerance – Any protocol change must be fully vetted and proven.
- The ultimate point of reference – All testnets should align with its behavior.
Why it matters:
- Ensures a secure and stable environment for users and dApps.
- Provides a source of truth for developers and researchers.
- Maintains Ethereum’s economic and security integrity.
2. aTestnet (App Developer Testnet)
Purpose: A stable, long-term testnet designed specifically for app developers.
- Ever-lasting – A permanent testnet that remains operational indefinitely.
- Minimal risk tolerance – Only perfectly vetted changes are introduced.
- Forks with or after mainnet – Maintains high parity with the main Ethereum chain.
- Similar ETH supply as mainnet – Mimics real-world economic conditions.
- Community faucets – Provides open access to test ETH for developers.
Why it matters:
- Ensures uninterrupted testing for dApps, wallets, and smart contracts.
- Supports a full ecosystem of tooling, explorers, relays, and infrastructure.
- Eliminates sudden deprecations that disrupt developer workflows.
3. ceTestnet (Consensus + Execution Testnet for Core Developers)
Purpose: A structured environment for testing protocol upgrades before mainnet deployment.
- Forks before mainnet – A successful fork here means a mainnet upgrade is imminent.
- Could be terminated – Exists only as needed for upgrade validation.
- Validator set controlled by the Ethereum Foundation and partners – Ensures structured testing and reliability.
Why it matters:
- Serves as a proving ground for protocol upgrades before they go live.
- Allows Ethereum core developers to test and validate changes under realistic conditions.
- Reduces risks by ensuring only battle-tested forks reach mainnet.
4. uceTestnet (Unstable Consensus + Execution Testnet)
Purpose: An experimental testnet for early-stage consensus and execution changes.
- Forks before ceTestnet – The first testing environment for new protocol changes.
- Unstable by design – Encourages experimentation and rapid iteration.
- Easier to experiment with – No long-term support guarantees.
- Validator set controlled by the Ethereum Foundation – Managed for structured chaos.
Why it matters:
- Serves as Ethereum’s sandbox for bleeding-edge research.
- Allows core developers to test radical changes without breaking stable testnets.
- Reduces failure risks before upgrades reach ceTestnet or mainnet.
5. dsTestnet (Domain-Specific Testnets)
Purpose: Custom testnets for non-canonical Ethereum forks and niche use cases.
- Unstable by design – Built for targeted experimentation.
- Supports domain-specific Ethereum adaptations – Used for specific research, such as rollup testing, execution sharding, or staking experiments.
- Validator set controlled by the Ethereum Foundation – Ensures controlled experimentation.
Why it matters:
- Enables custom Ethereum forks to test innovations without impacting global testnets.
- Supports specialized research in scalability, security, and execution environments.
- Prevents fragmentation of core testnets by offloading experimental work.
Conclusion: A Testnet Framework That Works for Everyone
By implementing this methodology, Ethereum can provide:
- App developers with a stable, long-term testing environment (aTestnet).
- Core developers with structured, risk-tolerant testnets for protocol upgrades (ceTestnet and uceTestnet).
- Domain-specific innovators with dedicated experimental spaces (dsTestnet).
This structured approach ensures Ethereum remains developer-friendly while maintaining high security, stability, and innovation velocity.
The next step is rallying the community around this vision and pushing for implementation.
Past & Present Testnets
| Name | Launch Date | Termination Date | Duration | Purpose | Consensus Mechanism | Type | Special Notes |
|---|---|---|---|---|---|---|---|
| Olympic | Early 2015 | Jul-15 | 6 months | Final pre-launch testnet (stress test for Frontier release) | PoW | Public Testnet | Ethereum 0.9, incentivized stress test |
| Morden | Jul-15 | Nov-16 | 16 months | First long-lived testnet | PoW | Public Testnet | Replaced due to consensus issues, continued as Morden Classic for ETC |
| Ropsten | Nov-16 | Dec-22 | 6 years | Final Ethereum PoW testnet, later merged to PoS | PoW ‚Üí PoS | Public Testnet | DoS attack in 2017, transitioned to PoS before deprecation |
| Kovan | Mar-17 | 2021 | 4 years | Parity PoA testnet, aimed at stability for dApps | PoA (Aura) | Public Testnet | Only supported by OpenEthereum, not Geth |
| Rinkeby | Apr-17 | Q3 2023 | 6 years | Geth PoA testnet | PoA (Clique) | Public Testnet | Did not undergo The Merge |
| Goerli | Jan-19 | Q1 2024 | 5 Years | Cross-client PoA testnet, later transitioned to PoS | PoA ‚Üí PoS | Public Testnet | Merged with Prater Beacon Chain for Merge testing |
| Sepolia | Oct-21 | Active | Ongoing | Main post-Merge testnet | PoW ‚Üí PoS | Public Testnet | Minimal cross-client execution layer testnet |
| Holesky | Sep-23 | Active | Ongoing | Largest Ethereum testnet, replacing Goerli | PoS | Public Testnet | 10× mainnet validators, resolves Goerli’s test-ETH issues |
| Schlesi | Apr-20 | May-20 | 1 month | First multi-client Beacon Chain testnet | PoS (Beacon) | Beacon Chain Testnet | Tested Eth2 clients for Phase 0 |
| Witti | May-20 | Jun-20 | 1 month | Second Beacon Chain testnet | PoS (Beacon) | Beacon Chain Testnet | Expanded client diversity |
| Altona | Jun-20 | Aug-20 | 2 months | Limited multi-client testnet before Medalla | PoS (Beacon) | Beacon Chain Testnet | Early Eth2 validator coordination |
| Medalla | Aug-20 | Dec-20 | 4 months | Final Beacon Chain testnet before mainnet | PoS (Beacon) | Beacon Chain Testnet | Time sync bug caused network halt |
| Spadina | Sep-20 | Oct-20 | 3 days | Dress rehearsal for Eth2 launch | PoS (Beacon) | Beacon Chain Testnet | Failed due to low validator participation |
| Zinken | Oct-20 | Oct-20 | 1 week | Second genesis rehearsal | PoS (Beacon) | Beacon Chain Testnet | Final pre-launch rehearsal before Beacon Chain mainnet |
| Pyrmont | Nov-20 | Q4 2021 | 1 year | Public staking testnet post-Eth2 launch | PoS (Beacon) | Beacon Chain Testnet | Large-scale staking testnet |
| Prater | Jun-21 | Aug-22 | 1 year | Successor to Pyrmont, merged with Goerli | PoS (Beacon) | Beacon Chain Testnet | Used for The Merge testing |
| YOLO v1 | Jun-20 | Jun-20 | 1 month | Early Berlin upgrade testnet | PoW | Ephemeral Devnet | Crashed due to disk usage issues |
| YOLO v2 | Oct-20 | Late 2020 | 1 month | Berlin upgrade EIP testing | PoW | Ephemeral Devnet | Follow-up after YOLO v1 crash |
| YOLO v3 | Feb-21 | Q1 2021 | 2 months | Final Berlin upgrade testing | PoW | Ephemeral Devnet | Concluded Berlin test cycle |
| Aleut | Apr-21 | May-21 | 1 month | First London upgrade testnet | PoW | Ephemeral Devnet | Tested EIP-1559 fee market changes |
| Baikal | May-21 | Late May 2021 | 2 weeks | Second London upgrade testnet | PoW | Ephemeral Devnet | Ensured client compatibility |
| Calaveras | May-21 | Jun-21 | 1 month | Final London upgrade testnet | PoW | Ephemeral Devnet | EIP-1559, 3198, 3529, 3541 tested |
| Kintsugi | Dec-21 | Q1 2022 | 3 months | First Merge testnet | Hybrid (PoW ‚Üí PoS) | Ephemeral Devnet | Exposed client bugs, leading to Kiln |
| Kiln | Feb-22 | Sep-22 | 7 months | Final Merge testnet | Hybrid (PoW ‚Üí PoS) | Ephemeral Devnet | Successfully simulated The Merge |
| Shandong | Oct-22 | Jan-23 | 3 months | Experimental pre-Shanghai testnet | PoS | Ephemeral Devnet | Ran EOF and PUSH0 EIPs, later removed |
| Zhejiang | Feb-23 | Apr-23 | 2 months | Staked ETH withdrawals (Shanghai/Capella) | PoS | Ephemeral Devnet | Allowed early withdrawal testing |
Sometimes there’s value in getting community input so we polish them a bit, like with