Ethereum’s Spadina testnet launched at 12:00 UTC on September 29, 2020, opening a deliberately short rehearsal for the deposit and genesis procedures intended to start Ethereum’s planned proof-of-stake Beacon Chain.
The network began producing blocks, but its opening validation rounds drew participation from less than 34% of the deposited stake, according to contemporaneous reporting from the launch. That was well below the level needed for the chain to finalize checkpoints. The mixed result mattered because Spadina was designed specifically to test whether validators, independently developed clients and launch tools could coordinate from genesis—not merely whether software could run after a network was already established.
A focused test of deposits and genesis
The Ethereum Foundation described Spadina before launch as a three-day “dress rehearsal.” Its scope was narrower than the longer-running Medalla testnet: prospective validators were asked to practice generating deposit data, using the Launchpad interface, configuring beacon nodes and validator clients, and bringing those systems online for a predetermined genesis.
Prysmatic Labs’ September 25 preparation record set genesis for September 29 at 12:00 UTC, corresponding to Unix timestamp 1601380800. The client team described Spadina as a small-scale network requiring 1,024 validators for genesis, compared with 16,384 in the contemplated mainnet specification.
Those were configured validator thresholds, not counts of distinct people or organizations. One operator could control multiple validators, and the reviewed records do not provide an independently verified distribution of participating entities.
Spadina also tested a multi-client architecture. Ethereum’s proof-of-stake work was being implemented by separate teams whose software needed to follow the same consensus specification and communicate reliably across a peer-to-peer network. Diversity could reduce dependence on one implementation, but only if releases, configuration instructions and networking behavior remained compatible at the launch boundary.
Blocks arrived before finality
Contemporaneous coverage reported that the deposit process produced no major failure and that clients handled blocks. The principal event-day problem was participation: many validators associated with deposits were not actively attesting when genesis arrived.
With insufficient stake voting consistently, the chain could advance without promptly finalizing checkpoints. Finality is the protocol condition under which a supermajority of validator stake confirms history strongly enough that reverting it would require severe protocol violations and penalties. A network producing blocks without finality was therefore operating, but not demonstrating the clean genesis developers wanted to reproduce with real-value deposits.
Ethereum Foundation coordinator Danny Ryan characterized the exercise on September 29 as delivering roughly 90% of what developers wanted. That was an attributed contemporaneous assessment, not a measured reliability score. Reports also identified user difficulties involving client setup, peer connectivity and router-port configuration, while the incomplete participation made it difficult to separate operator indifference from software and documentation problems during the opening hours.
Why the rehearsal mattered
Spadina did not alter the existing Ethereum mainnet on September 29. Ethereum’s proof-of-work chain continued processing user transactions, no production Beacon Chain launched, and no mainnet genesis date had been set. Phase 0 was intended to establish a separate proof-of-stake coordination chain before later phases added broader functionality.
The consequential result was operational rather than transactional. Deposits and genesis represented a one-time coordination problem involving funds, client releases, node configuration and a fixed start time. Discovering friction in a disposable network gave developers evidence that a technically complete specification did not by itself ensure an orderly launch.
No cryptocurrency price, return or trading-volume move is attributed to Spadina here. Continuous markets and competing news on September 29 prevent a defensible causal market claim from the reviewed evidence.
Later clarification
On October 1, 2020, the Ethereum Foundation reported that Spadina required approximately 70 epochs—almost eight hours—to reach the two-thirds participation threshold and begin finalizing. Its postmortem also identified release and configuration errors, including a critical Prysm peering problem, and announced another genesis rehearsal named Zinken. That later account clarifies the launch failure without implying that its full diagnosis was available on September 29.
The complete source packet and revision history are retained with the newsroom record.
Automated systems may have assisted with source organization and drafting. Coinburn is accountable for the published text and maintains a revision record.
This article provides news and analysis, not investment, legal or tax advice. Digital assets are volatile and may result in total loss.