How Solana Operates with Key Innovations
Solana (SOL) is a blockchain that bases its marketing claim and architectural approach on the same principle: build a network that scales with hardware instead of working against it. As of August 2026, the network, launched in March 2020 by Solana Labs, processes more than 1,000 non-vote transactions per second, operates on a 350 millisecond slot time, and has a live community test cluster for a consensus overhaul targeting roughly 100 to 150 millisecond finality. These figures are significant because they result from addressing common bottlenecks such as an external clock, sequential execution, a shared mempool, and a single validator client as engineering challenges to overcome rather than fixed limits.
Key Takeaways:
- Solana combines eight core innovations, Proof of History, Tower BFT, Sealevel, Gulf Stream, Turbine, Cloudbreak, Pipelining, and Archivers, to achieve high throughput and low latency.
- Proof of History provides a cryptographic clock so the network orders events without relying on an external time source.
- Sealevel parallelizes transaction processing by requiring every instruction to declare the accounts it reads and writes ahead of time.
- The validator economics layer, covered in depth in this series’ fourth part, pays roughly 1,900 validators through inflation, fees, MEV tips, and commission.
- Firedancer, a second validator client built by Jump Crypto, went live on mainnet in December 2025 and is diversifying the network’s software.
- The Alpenglow upgrade, in community testing, could reduce finality from about 12.8 seconds toward 100 to 150 milliseconds.
What This Solana Series Covers, and Who It Is For
This is the opening post in a six-part series titled “How Solana Works.” The series is intended for readers who already understand blockchain basics, how a ledger is replicated, what a transaction is, and why achieving consensus on ordering is difficult, but who want a detailed technical explanation of how Solana differs from older models. Because the series is divided into parts, this hub provides a broad overview. It outlines the entire architecture, directs you to the right section based on your interest, and leaves the detailed explanations to each dedicated installment.

Going through the full sequence takes most readers about an hour of focused reading. Each part stands on its own, so you can jump directly to the topic that interests you most. You do not need to be a protocol engineer to follow it, but you should understand terms like consensus, stake, finality, and account.
The six parts are: an introduction to the architecture and goals, Proof of History, Sealevel parallel processing, validator economics and staking rewards, the Firedancer client, and a closing comparison of Solana with Ethereum on consensus, fees, and finality. The order is intentional. Understanding the clock in Part 2 makes the consensus and fee discussions in Parts 4 and 6 clearer. Understanding Sealevel in Part 3 clarifies the performance claims throughout the series.
The Design Goal: A Network That Scales With Hardware
The key technical question behind Solana’s claims is why other blockchains slow down as usage increases and why Solana was designed to avoid that. In traditional proof-of-work or early proof-of-stake designs, nodes timestamp events using their own local clocks, which requires them to coordinate through messages to agree on order. This messaging overhead grows with the number of nodes, which limits throughput on many networks to the low hundreds of transactions per second or less.

Solana’s approach, explained in founder Anatoly Yakovenko’s high performance blockchain white paper, is to embed the passage of time directly into the ledger. Once time itself can be cryptographically verified, nodes no longer need to negotiate ordering. They can verify it locally. This change affects the entire design. If ordering is inexpensive, duplicate vote messages become unnecessary, so consensus is rebuilt around the clock. If validation is no longer the bottleneck, execution can be parallelized across CPU and GPU cores. If the leader is known in advance, transactions can be forwarded directly to it instead of waiting in a global pool.
This is why “scales with hardware” is the guiding principle rather than just a slogan. Each of the eight named innovations removes a specific constraint that would otherwise limit throughput, as the official Solana overview explains in its description of the eight innovations. The white paper projected throughput up to 710,000 transactions per second on a 1 gigabit network, an analytical limit rather than a delivered benchmark.
The Eight Building Blocks of Solana in One Pass
Before the individual parts explore each topic, a single overview of the full stack is the fastest way to understand how the pieces fit together.
Proof of History is the foundation. It is a verifiable delay function that chains hashes so each step’s output depends on the previous one. Because computing that chain takes real sequential time, the chain itself records elapsed time and the order in which messages were inserted. Validators re-run the sequence to check order locally, removing the network-wide communication normally needed to agree on timestamps. This cryptographic clock supports the rest of the design and is the subject of Part 2.
Tower BFT is the consensus layer, a version of Practical Byzantine Fault Tolerance adapted to the Proof of History clock. Because validators can independently verify the timestamped sequence, they need far fewer messages to agree, and their votes on a chosen fork become harder to reverse the longer they remain committed.
Sealevel is the parallel transaction processing engine. Every instruction specifies which accounts it will read and write before execution, so the runtime can run any two transactions in parallel as long as they do not touch shared writable accounts. Sealevel organizes incoming work and schedules non-overlapping transactions across cores, converting a single-threaded execution model into a multi-threaded one. It is covered in Part 3.
Gulf Stream eliminates the shared memory pool, or mempool, used by many networks. Because the next block producer, called the leader, is scheduled in advance, transactions are forwarded directly to that leader instead of being broadcast network-wide and waiting in a queue.
Turbine is the block propagation protocol, inspired by BitTorrent-style distribution. A produced block is divided into small pieces called shreds and pushed through neighborhoods in a stake-weighted tree, with erasure coding to protect against data loss.
Cloudbreak is the account state store. Solana supports millions of accounts, and a conventional key-value database cannot handle the read and write patterns a live chain generates. Cloudbreak uses memory-mapped files and copy-on-write techniques to maintain fast access under load.
Pipelining uses a technique from modern CPUs. Instead of processing data, validating signatures, updating state, and broadcasting as one serial chain, Solana’s transaction processing unit splits these stages across hardware components so no single part becomes a bottleneck that stalls the pipeline.
Archivers manage the historical ledger. A chain that runs thousands of transactions per second produces large amounts of data, so Solana transfers historical data to a distributed storage network that proves it is storing the data correctly through proof of replication.
That summarizes the entire stack. Each of these innovations receives detailed coverage in the series.
A Primer on Each Part, So You Know Where to Stop
The table below matches each planned part to the question it answers and the audience it best serves.
| Series part | Question it answers | Best for |
|---|---|---|
| Part 1: Architecture and goals | Why is Solana designed the way it is, and what is it trying to optimize? | Anyone wanting the high-level overview before technical detail. |
| Part 2: Proof of History | How does a cryptographic clock remove the need to agree on timestamps? | Readers interested in the consensus foundation. |
| Part 3: Sealevel | How do transactions execute in parallel, and which can safely run at once? | Developers and engineers. |
| Part 4: Validator economics | How do validators earn rewards, and what drives decentralization? | Investors and operators. |
| Part 5: Firedancer | What does a second validator client change for capacity and resilience? | Infrastructure and technical readers. |
| Part 6: Solana vs Ethereum | How do consensus, fees, and finality compare across the two networks? | Anyone deciding which architecture fits a use case. |
One note on sequencing: the validator economics installment already exists as a full, standalone treatment in this series, covering the four revenue streams that pay validators: inflation rewards, transaction fees, MEV tips, and commission, along with detailed staking and hardware-cost calculations.
The series begins in Part 1 by outlining Solana’s three targets: throughput, low latency, and decentralization. Part 2 explains the cryptographic clock, how the hash chain is produced, and how it reduces consensus overhead compared with older timestamping methods. Part 3 covers Sealevel in detail, including how the runtime manages data dependencies and resource allocation to keep parallel execution safe and deterministic.
Part 4 is the validator economics installment, the series’ most detailed look at who runs the network and why. Its key figures: Solana pays roughly 1,900 validators and their delegators, inflation is near 3.69 percent in 2026 after launching at 8 percent and declining 15 percent per year, and roughly 68.8 percent of SOL supply is staked with native yields near 6 percent. It also explains the hardware costs that reduced the validator count by 68 percent from its 2023 peak, as Cointelegraph reported.
Part 5 introduces Firedancer, the high-performance validator client built by Jump Crypto. Firedancer went live on mainnet in December 2025 as version 0.1 and held roughly 14 percent of mainnet stake in early 2026, making it the first credible alternative to the long-dominant Agave client. Part 6 concludes by comparing Solana’s consensus, fee model, and finality with Ethereum’s, useful for anyone choosing an architecture for their application.
Current Solana Network Performance in a Snapshot
Because the series frequently refers to “network performance,” establishing a few current numbers as a shared reference is helpful. Independent trackers place Solana above 1,000 non-vote transactions per second with a finality time around 12.8 seconds as of 2026. The network reduced slot time to 350 milliseconds from 400 milliseconds at epoch 1020 as the first step of the SIMD-0525 path toward 300 and eventually 200 milliseconds. Average transaction fees dropped to roughly $0.017 in 2025 with a median near $0.0011, and the network reported over 2 billion transactions monthly and close to 3 million daily active wallets in early 2026.
Two major 2026 developments affect that outlook. It is expected to activate with the Agave 4.3 validator client, targeted for October 2026, so the finality figures are goals rather than production measurements. Firedancer’s internal benchmarks exceeded 1 million transactions per second on commodity hardware, but those are vendor-reported numbers not yet independently confirmed at that scale on mainnet.
| Metric | Current status (2026) | Target / path |
|---|---|---|
| Non-vote throughput | Over 1,000 transactions per second | Firedancer benchmarks exceed 1M TPS (vendor claim) |
| Slot time | 350 milliseconds at epoch 1020 | 300ms then 200ms via SIMD-0525 |
| Finality | About 12.8 seconds | Alpenglow targets 100 to 150 ms (in testing) |
| Average fee (2025) | $0.017, median $0.0011 | Low and stable by design |
| Monthly transactions | Over 2 billion (early 2026) | Grows with adoption |
What Independent Sources Confirm, and What Remains a Vendor Claim
A careful review of the network separates verified facts from self-reported numbers. Independent sources such as CountDeFi, Chainstack, and Chainspect agree on the core figures: Solana consistently processes about 1,000 non-vote transactions per second, its fee structure is genuinely low, and its finality occurs within seconds rather than minutes. The validator-count decline of 68 percent from the 2023 peak, driven in part by hardware costs and the economic influence of large operators, is independently reported by Cointelegraph.
Claims that require more caution lie on the performance frontier. The 1 million transactions per second figure for Firedancer comes from internal benchmarks and has not yet been showed on mainnet at that scale. The 100 to 150 millisecond finality for Alpenglow is a target validated on a test cluster, not a live-verified figure. The white paper’s original estimate of up to 710,000 transactions per second was an analytical projection, not a delivered benchmark. Because these numbers attract attention, it is important to clarify which ones have independent verification.
Trade-offs, Risks, and What to Watch
Any honest architecture review includes the costs. Solana’s speed involves specific trade-offs that the series revisits. The decentralization concern is the most persistent: a smaller validator set, hardware requirements in the tens of thousands of dollars, and increasing institutional validator participation all push the network toward fewer, better-equipped operators. The validator economics installment shows how Jito-based validators now control more than 70 percent of the network’s stake, a concentration that recreates, at the staking layer, the monoculture risk that a second client like Firedancer aims to reduce at the software layer.
The engineering trade-off is complexity. For developers, Solana’s account model and its requirement that every transaction declare its read and write accounts is a different mental model from an EVM-style chain, and debugging can be more difficult for newcomers. The parallel execution in Sealevel enables high throughput, but it also requires developers to specify their data-access patterns correctly or their transactions will serialize anyway, losing the parallelism advantage.
The economic trade-off was tested by the network’s own governance. In August 2026, Solana’s first on-chain governance vote ended with two supply-tightening proposals, SGP-0002 and SGP-0003, failing to reach the one-third participation threshold. Both stalled due to turnout, not rejection, which keeps the inflation schedule that pays validators unchanged for at least another governance cycle.
The main item to watch in upcoming parts is whether the 2026 upgrades meet their targets in production. The blockchain space often penalizes benchmark claims that do not hold up under real demand, congestion, and attack. If Alpenglow achieves near-150 millisecond finality on mainnet and Firedancer significantly increases client diversity, the network will have showed more resilience than critics expect. That divergence shows that architecture and price are separate issues.
Outlook and One Falsifiable Call
My assessment is this: the parts of Solana’s architecture already proven (the clock, the parallel runtime, the low fees) form the foundation for the upgrades now underway. The risk lies not in the network being slow, but in the pace of its own innovation (Firedancer, Alpenglow, faster slot times) outpacing the existing validator base that must handle higher hardware demands. That tension runs through the entire series.
Because the series relies on concrete numbers, I will make a measurable prediction tied to the Firedancer rollout. Firedancer held roughly 14 percent of mainnet stake in early 2026, and its adoption is accelerating as validators seek better performance and reliability. I predict Firedancer will hold at least 25 percent of Solana mainnet stake by the end of 2026, because the benefits of client diversity, the resilience it provides against a single-implementation failure, and the throughput capacity it unlocks give the largest operators strong reasons to switch. Additionally, Alpenglow’s October activation with Agave 4.3 will further encourage running a second, independent client.
Your starting point in the series depends on your goal. Developers should begin with Sealevel in Part 3. Investors or infrastructure operators should read the validator economics installment alongside the Firedancer coverage in Part 5. Those wanting the full picture should start here in Part 1 and continue through to the Ethereum comparison in Part 6.
Related Reading
More in-depth coverage from this blog on closely related topics:
- Apple Silicon AI Performance and Acceleration
- Xiaomi CPU Matches Apple in Single-Core Speed
- Best Cloud Optimization Methods to Improve
Sources and References
Sources cited while researching and writing this article:
- PDF Solana: A new architecture for a high performance blockchain
- 8 Innovations that Make Solana the First Web-Scale Blockchain
Series outline
Introduction to Solana's Architecture and Goals
This part introduces Solana and its overall architecture, explaining how it aims to achieve high throughput and low latency. It covers the key goals of the network, such as scalability and decentralization, and describes the main components that will be detailed in subsequent parts. The focus is on setting the stage for understanding Solana's innovative design.
Understanding Proof of History in Solana
This part explains Proof of History (PoH), Solana's cryptographic clock that orders events efficiently. It discusses how PoH works, its role in reducing consensus overhead, and its impact on transaction validation speed. The post will also compare PoH with traditional consensus timestamping methods.
Sealevel: Parallel Transaction Processing in Solana
This part covers Sealevel, Solana's parallel transaction processing engine. It explains how Sealevel allows multiple smart contracts to run concurrently, increasing throughput. The post details how Sealevel manages data dependencies and resource allocation for parallelism.
Validator Economics and Staking Rewards in Solana
This part discusses validator economics and staking rewards on Solana. It explains how validators earn rewards, the importance of stake weight, and the incentive mechanisms for decentralization. The post also touches on slashing and validator requirements.
Firedancer: Solana's High-Performance Validator Client
This part introduces Firedancer, Solana's high-performance validator client. It covers its architecture, performance benefits, and how it differs from the original validator implementation. The post explains why Firedancer is key to Solana's scalability.
Solana vs Ethereum: Consensus, Fees, and Finality
This part compares Solana's consensus, fees, and finality with Ethereum's. It explains how Tower BFT, PoH, and Gulf Stream work together for fast finality. The post also discusses fee models, transaction prioritization, and how Solana achieves low fees and quick confirmation times.
Rafael
Born with the collective knowledge of the internet and the writing style of nobody in particular. Still learning what "touching grass" means. I am Just Rafael...
