A Clock Was Only the Beginning: Solana’s Idea and Its Test After FTX
A Qualcomm engineer turned a timing problem into Proof of History. Solana’s next challenge was surviving failures that a cryptographic clock could not solve.
3-Minute Fast Briefing
- The ParadoxProof of History records a verifiable sequence of computation; validators still communicate and use consensus to choose the accepted history.
- The Turning PointSolana’s early 50,000-plus TPS claim described a GPU-assisted testnet benchmark, not guaranteed mainnet throughput or finality.
- The LegacyAfter FTX’s collapse, application recovery and work on alternative validator clients showed why operational resilience mattered alongside speed.
Chronological Timeline
Solana’s later published origin account places the whitepaper in November 2017, following Yakovenko’s recollected late-night insight.
The published origin account dates the change from Loom to Solana to March, after prototype work by former Qualcomm colleagues.
The Foundation’s June newsletter identifies March 16 as the launch date. Earlier testnet speed measurements were not a mainnet service guarantee.
The Foundation disclosed assets and transactions connected to FTX/Alameda while reporting that the network continued operating during that week.
The Foundation reported a first Firedancer version on testnet at Breakpoint 2023. Test results and 2024 delivery goals do not establish a full-client mainnet launch.
1. A wireless engineer encounters a different timing problem
Before Solana had a token, Anatoly Yakovenko had spent years making computers do more with the hardware available. In a first-person interview published by Phantom, he described almost fourteen years at Qualcomm, from operating-system work for phones to augmented-reality performance. When he began exploring crypto in 2017, he brought that experience with him: communication and computation were engineering costs to examine, not simply accept.[5]
The familiar origin scene comes from a later telling. In a sponsored profile republished by the Solana Foundation, Packy McCormick relayed Yakovenko’s account of being awake at 4 AM after coffee and beer. The profile places the insight in October 2017 and the whitepaper in November. It is a recollection, not a contemporaneous record of the room, his movements, or his thoughts.[6]
The engineering question was whether computers could check evidence of elapsed computation instead of repeatedly asking one another about time. In a later a16z crypto conversation, the origin is again presented as a late-night discovery. Turning that idea into a network meant separating a useful mechanism from the much larger problem of getting independent computers to operate together.[4]
2. A sequence that can be checked, not a replacement for consensus
Proof of History runs a hash function repeatedly, feeding each result into the next step. Recording outputs and their positions creates a sequence whose construction requires successive computation. Data can be incorporated into that sequence, giving verifiable evidence about its placement relative to other entries. The work of constructing the sequence and the work of checking it need not take the same amount of time.[1]
A useful distinction is between ordering evidence and a trusted wall clock. PoH does not put a GPS receiver inside a blockchain, nor does it make every timestamp an independently certified civil time. Its security rests on assumptions about the hash function and computation. The whitepaper also describes leaders, verification, and stake-based voting. Validators still exchange information to settle on an accepted history.[1]
The celebrated speed figure had conditions. Solana’s early technical explainer reported more than 50,000 transactions per second on a testnet of 200 distinct nodes using GPUs. That was a measurement of a particular setup. It was not a promise that every application would receive that throughput, and it did not turn block production time into a guarantee of final settlement. The same explainer presents PoH alongside other components, rather than as a complete system by itself.[7]
3. From a prototype to a network other people had to run
The published origin profile describes Greg Fitzgerald and Stephen Akridge joining the effort after their Qualcomm years. Fitzgerald worked on a Rust prototype; Akridge identified signature verification on GPUs as a way to increase throughput. The project first used the name Loom, then changed it to avoid confusion with Loom Network. In March 2018 it took the name Solana, after the beach where the colleagues had surfed.[6]
Mainnet Beta arrived on March 16, 2020, according to the Foundation’s subsequent June newsletter. Launch changed the nature of the test. An architecture could now be used by people outside the founding team, with applications, validators, and balances depending on its behavior. The milestone establishes that the network launched; it does not retrospectively certify every earlier performance ambition.[8]
In his Phantom interview, Yakovenko described why production was harder than a laboratory. Bot traffic and memory pressure could interact with the conditions needed for validators to reach quorum. Developers could test components, yet still encounter workloads they had not anticipated. For users, the important question was no longer only how quickly a machine could execute instructions. It was whether the network could keep making progress when demand became hostile.[5]
4. FTX exposed a dependency the clock could not remove
November 2022 brought a different kind of stress. FTX and Alameda entered bankruptcy proceedings, and the Solana Foundation published details of its connections to them. Its update listed earlier SOL transactions as well as exposure to FTX equity, FTT, and SRM. These were concrete financial relationships, not evidence that an exchange controlled every validator or that its failure mechanically stopped Solana.[9]
The Foundation reported no notable network uptime or performance problems during the preceding week. Applications still faced consequences: its update described uncertainty around assets behind the Sollet custodial bridge and a community-organized new build of Serum. A functioning base network did not make affected claims whole. Recovery could require replacing an application’s infrastructure while unresolved financial losses remained.[9]
That distinction is the harder part of the survival story. Ordering transactions cannot resolve a bankrupt counterparty’s obligations. A counterparty’s collapse, in turn, need not stop a distributed network. Applications and their users could face unresolved losses even while the chain continued producing blocks.[9]
5. A second implementation, and a less tidy ending
By January 2024, the Foundation was pointing to continued building through the downturn. It reported that a first Firedancer version had been announced on testnet at Breakpoint 2023. Its cited million-plus-transactions-per-second figure was an early test-environment benchmark per core. That result described an engineering experiment, not live network traffic or a completed recovery for token holders.[10]
Firedancer’s own guide describes a validator implementation written in C, rather than C++. It also explains the staged approach: Frankendancer combines new networking components with Agave’s runtime and consensus. The guide’s targets for mainnet in the second quarter of 2024 and a fully independent validator by year-end are stated as goals. Those sentences cannot be used as evidence that either deadline was met.[11]
The purpose of another implementation is broader than a faster headline. Separately written clients can reduce exposure to a defect shared by one codebase, provided operators adopt them and the implementations remain compatible. That is an engineering strategy with work left to do, not proof that outages have become impossible. Solana’s clock addressed one coordination problem. The story after FTX shows why a network’s survival also depends on the people and software around that clock.[11]
Key Takeaways for Investors & Builders
A clock has a limited job
A clock can reduce coordination overhead without removing consensus, software defects, or economic dependencies.
Measure the conditions, not just the headline
Read performance numbers with their conditions: a testnet benchmark, a block interval, and irreversible settlement answer different questions.
Resilience takes continuing work
Resilience depends on applications, operators, and independent implementations. Continuing development after a crisis is evidence of work, not a guarantee of recovery.
Continue reading
Explore the topic through other cases and contexts.
Sources & References
- [1]Source 1: Solana: A New Architecture for a High Performance Blockchain (current PDF v0.8.13)Anatoly YakovenkoAccessed 2026-09-06
- [2]Source 2: Solana Labs repository (legacy code context)Solana Labs
- [3]Source 3: Solana encyclopedia overview (supplementary background)Wikipedia contributors
- [4]Source 4: Inside the Solana story: Near-death brushes and a need for speeda16z crypto · 2025-06-05Accessed 2026-09-06
- [5]Source 5: Anatoly Yakovenko interview: career and production engineering (transcript)PhantomAccessed 2026-09-06
- [6]Source 6: Solana Summer: sponsored origin profile, republished with permissionPacky McCormick / Not Boring; republished by Solana Foundation · 2021-08-23Accessed 2026-09-06
- [7]Source 7: Proof of History: A Clock for Blockchain — testnet setup and mechanismSolana Foundation · 2018-04-18Accessed 2026-09-06
- [8]Source 8: June Newsletter — Mainnet Beta launch dateSolana Foundation · 2020-07-05Accessed 2026-09-06
- [9]Source 9: Solana Ecosystem Facts Related To FTX Bankruptcy (updated November 21)Solana Foundation · 2022-11-09Accessed 2026-09-06
- [10]Source 10: What Solana Devs Can Look Forward to in 2024 — testnet and benchmark reportSolana Foundation · 2024-01-11Accessed 2026-09-06
- [11]Source 11: Firedancer guide — C implementation, Frankendancer, and stated delivery goalsFiredancerAccessed 2026-09-06