Solana works by splitting up the jobs other blockchains bundle together. A cryptographic clock called Proof of History puts transactions in order. Tower BFT consensus votes them final. The Sealevel runtime then runs non-overlapping transactions in parallel. No stage waits on the others, so the network confirms transactions in under a second for a fraction of a cent.
Picture an assembly line with four stations. A clock called Proof of History stamps each transaction with its place in line. A voting system called Tower BFT makes the result official. An engine called Sealevel does many jobs at once. A delivery crew, Gulf Stream and Turbine, moves the work between stations. Each station does one job and hands the work on, so the line never stops to argue about whose turn it is.
There is an honest chapter too. The same design explains why Solana went down again and again in its early years. This guide covers that history straight, including what changed by 2026. If you want the one-line version first, start with Blofin's overview of what Solana is. This article opens up the machine behind it.
The big design bet: one fast chain, no shortcuts
Solana's founding choice is to keep every account and app on one shared chain, and to make that one chain fast enough for the whole load. Most rivals split the work across shards or push it out to Layer-2 networks. Solana bet that a line of stages, each doing one job, could carry it all inside a single chain.
Most blockchains behave like a workshop where one worker handles every step of every order. Each transaction waits for the one before it to be ordered, agreed on, run, and delivered. That serial habit is safe, but it caps how much the chain can do. So networks like Ethereum have moved work off the main chain to Layer-2 networks. Others split the chain itself into shards. Both paths give something up. Your assets and apps end up living in different places, and moving between them takes bridges and extra steps.
Solana refused that trade. It keeps one global state. That means every wallet balance, token, and app lives on the same chain and can interact inside a single transaction. To make that workable, the design splits the work into stages that run at the same time instead of waiting on each other. That is the assembly line this guide walks station by station. How this single-chain path compares with Ethereum's modular one is a topic of its own, covered in Blofin's guide to Solana versus Ethereum.
The first station on the line is the strangest one: a clock.
A clock before consensus: where Proof of History fits
Proof of History is Solana's verifiable clock, not its consensus mechanism. It gives every transaction a cryptographic timestamp that proves the order of events. Validators can then agree on that order without debating timing first. The "when" is settled before voting starts, so consensus has far less work to do.
Think of a photo-finish camera at a race. The camera does not decide who ran a fair race. It settles the order of finishers, so the judges only rule on validity. Proof of History plays the camera's role. A continuous stream of hashes acts like the ticks of a clock. Each transaction gets folded into that stream at a specific tick, and anyone can check its position afterward. The mechanics of that hash chain deserve their own walkthrough, along with why the clock is so often mislabeled as a consensus mechanism. Both live in Blofin's guide to how Proof of History works. For this tour, what matters is narrower. By the time the next stations see a transaction, its place in line is already fixed.
A trustworthy order still needs a final vote, though, and that vote is consensus.
Tower BFT: how validators agree without endless voting
Tower BFT is the voting layer that makes Solana's ordered transactions final. Validators stake SOL and vote on the state of the chain. Each vote locks them in for longer, doubling every time. So the network settles on one history fast instead of re-debating blocks it has already accepted.
The scheme works like a committee with rising commitments. Each member says "aye" to a decision, and the first aye binds them for one round. The next aye on the same branch doubles that commitment. The one after doubles it again. Validators face the same curve. With every vote on a fork, the lockout doubles, and after roughly 32 straight votes the commitment is permanent in practice. That is why finality arrives within seconds on Solana. The cost of changing a vote grows so fast that honest validators fall in line almost at once rather than keeping options open.
Votes carry weight in proportion to staked SOL. That is what makes Solana a proof-of-stake network: influence comes from money at risk, not computing power. The basics of staking, and how it compares with mining, are covered in Blofin's guide to Proof of Work vs Proof of Stake, so this article will not re-teach them. Solana's twist is simple. The Proof of History clock removes most of the timing debate that other proof-of-stake chains still vote about.
Agreement settles what is final. The next station explains how so much can happen at once in the first place.
Sealevel: thousands of transactions at the same time
Sealevel is Solana's execution engine. Its trick is running every non-conflicting transaction at the same time across a machine's CPU cores. It can schedule work safely because each Solana transaction declares, up front, exactly which accounts it will read and which it will write. Conflicts are known before any work starts.
That declaration works because of how Solana stores data. Programs, Solana's word for smart contracts, are pure code. All the things they act on, from your wallet balance to a token's supply, live in separate storage boxes called accounts. A transaction is a note that says "run this program against these named accounts." The runtime reads the note before doing anything. So it can sort thousands of notes into groups that touch different boxes, then run each group at the same time (source: Helius on the Solana Virtual Machine). Ethereum's virtual machine takes the opposite approach. Its transactions do not declare their state in advance, so the chain plays it safe and processes them one at a time.
A supermarket checkout makes the difference concrete. Say you send a friend $20 of SOL at the same moment a stranger swaps 500 USDC for SOL on a decentralized exchange. Your transfer touches your account and your friend's. The swap touches the stranger's accounts and a trading pool's. Nothing overlaps, so the two go through different lanes at the same instant, like shoppers at separate registers. Now imagine 10,000 people minting the same hot memecoin in the same minute. Every one of those transactions writes to the same accounts, so they cannot run in parallel. They queue in one lane while the rest of the store keeps moving. Keep that picture. It is exactly how Solana prices congestion, and it returns in the fee section below.
But parallel lanes only help if transactions reach the registers quickly. That part is the delivery system's job.
The delivery system: Gulf Stream, Turbine, and the leader
Solana knows in advance who will produce each block. The network publishes a leader schedule before validators take their turns. Gulf Stream uses that schedule to forward transactions straight to the next leaders, skipping the public waiting room other chains use. Turbine then spreads finished blocks through the network in small pieces.
On most blockchains, a submitted transaction sits in a mempool. That is a public waiting room where it stays until some future block producer picks it up. Solana skips the room. The leader schedule is public, so nodes route your transaction straight to the leader whose turn is coming, like a courier that ships every package to the depot that dispatches next (source: Anza's Agave validator documentation). Turbine solves the opposite problem. Once a block exists, sending it whole to thousands of validators would choke the leader's connection. So the block is sliced into small pieces called shreds. The shreds pass neighbor to neighbor through layers of validators, the way a parcel network relays packages between local hubs.
Here is the whole line, following one transaction from your wallet to finality:
- You hit send in your wallet. An RPC node (the network's front desk) receives the signed transaction.
- Gulf Stream forwards it to the current leader and the next few leaders in the schedule.
- The leader folds it into the Proof of History stream, fixing its place in line.
- Sealevel runs it, in parallel with every other transaction that touches different accounts.
- Turbine slices the resulting block into shreds and fans them out across the validator network.
- Validators rebuild the block and vote through Tower BFT. Within seconds the transaction is final.
The payoff of all this machinery lands somewhere you can feel it: what you pay.
What the machinery means for your fees
Solana's base fee is 0.000005 SOL per transaction signature. That stays under a cent at any price SOL has traded at. You can add an optional priority fee to move up the queue. And because fee markets are local, congestion raises prices only for the accounts being fought over.
The units are worth thirty seconds. Solana keeps its books in lamports. One SOL equals 1,000,000,000 lamports, so the base fee of 5,000 lamports per signature works out to 0.000005 SOL (source: Solana core documentation). Send a friend $100 of SOL and the network's cut is well under one cent. At SOL prices through mid-2026 it comes to a small fraction of a cent.
The more interesting part is what happens when the network gets busy. Remember the supermarket: 10,000 mints of one memecoin queue in a single lane. Solana prices that queue locally. The people fighting for the hot accounts bid priority fees against each other, while your unrelated transfer keeps paying the quiet-lane price. On a chain with one global fee market, a popular mint raises costs for everyone. On Solana, congestion mostly stays in its lane.
| Lane | What is happening | What you pay (as of mid-2026) |
|---|---|---|
| Quiet lane: a routine SOL transfer | Your transaction touches accounts nobody else is competing for | Base fee only: 0.000005 SOL per signature, a small fraction of a cent |
| Hot lane: a memecoin thousands are minting at once | Transactions compete to write to the same few accounts | Base fee plus a priority fee that can climb to several cents or more while the rush lasts |
How to set priority fees, and when they are worth paying, is a practical topic of its own, covered in Blofin's guide to Solana's fees and priority fees.
Cheap and fast mean little if the network is down. Here Solana has a history to own.
If the design is this clever, why did Solana keep going down?
Solana kept going down in its early years because the choices that make it fast removed the network's shock absorbers. With no mempool to buffer demand, spam floods could bury block producers. And with nearly every validator running one software client, a single bug could halt the whole chain.
The record is real. Between September 2021 and February 2024 the network suffered repeated full or partial halts. The worst early incidents were demand-driven. Bots chasing token launches fired transactions at upcoming leaders at rates reported in the hundreds of thousands per second. With no waiting room to absorb the flood, leaders simply drowned. The final full outage had a different cause. On February 6, 2024, a bug in the dominant validator client stalled block production for about five hours. Nearly the whole network ran that one codebase, so there was no healthy minority to keep the chain moving. That halt remains the last full outage as of mid-2026, and the network has posted roughly 100% uptime over recent trailing 90-day windows. The full incident list, causes included, lives in Blofin's review of Solana's outage history.
Each failure produced a specific fix. QUIC, a modern connection protocol, let leaders manage and throttle incoming traffic instead of drinking from an open firehose. Stake-weighted quality of service gave known validators guaranteed bandwidth, so junk traffic from unknown senders could no longer crowd out honest use. Local fee markets, covered above, made hot-account congestion costly for the people causing it. The deepest fix was client diversity. The Firedancer client is an independent validator client rebuilt from scratch by Jump Crypto. It went fully live on mainnet in December 2025 and runs on roughly 20-26% of validators, depending on the dashboard you read (source: Firedancer GitHub repository).
From Blofin's operational view as an exchange running live SOL markets through the 2024 to 2026 transition, the change that mattered most was client diversity, not a bigger throughput number. We watched the network's failure math shift once Firedancer reached mainnet. A bug in one validator codebase no longer means the whole chain halts, and that is the property we weight most when we assess the network our users' SOL deposits and withdrawals depend on.
Which brings the tour to what the stack looks like now.
The 2026 stack: many clients, and a rewrite in testing
Solana's 2026 mainnet is a multi-client network. Most validators run Agave while a growing share runs Firedancer, two independently built codebases speaking one protocol. The next planned change is Alpenglow, a consensus rewrite in testing with a late-2026 mainnet target. It would retire Proof of History as the network's clock.
Alpenglow would rebuild two stations at once. Votor, a new voting and finalization system, replaces the Proof of History clock and the Tower BFT vote, while Rotor, a new block propagation system, takes over Turbine's delivery job (source: SIMD-0326 Alpenglow proposal). It targets finality in roughly 150 milliseconds, quick enough to feel instant. The proposal passed a validator governance vote in September 2025 with 98.27% of participating stake in favor (source: CoinDesk on the Alpenglow vote). To be clear about status: as of mid-2026 Alpenglow is in testing, targeting mainnet in late 2026, and it is not live. What it would change, and what it would keep, is mapped in Blofin's guide to the Alpenglow upgrade.
What survives every rewrite is the identity of the machine: one global state, work split into stages, and non-conflicting transactions running in parallel. Here is the whole line at a glance.
| Component | Its job | On the assembly line |
|---|---|---|
| Proof of History | Orders transactions with a verifiable clock | The timestamp camera at the start of the line |
| Tower BFT | Validators vote the ordered state final | The sign-off station |
| Sealevel | Executes non-conflicting transactions in parallel | The parallel work stations |
| Gulf Stream | Forwards transactions straight to upcoming leaders | The courier routing packages to the next depot |
| Turbine | Splits blocks into shreds and fans them out | The parcel network delivering finished work |
| Agave and Firedancer | Independent software clients that run all of the above | Two separately built engines for the same line |
| Alpenglow (in testing) | Planned consensus rewrite targeting faster finality | A redesign of the clock and sign-off stations, not the line itself |
Read the table top to bottom and you have re-walked the tour. The clock orders, the vote finalizes, the engine runs work in parallel, and the delivery system keeps it all moving. That is how Solana works.
Frequently asked questions
Is Solana a Layer-1 or a Layer-2?
Solana is a Layer-1: a base blockchain that handles its own ordering, consensus, execution, and data, with SOL as its native asset. The difference matters because Layer-2 networks inherit security from a base chain and add extra trust points, such as bridges and sequencers. Everything on Solana settles on Solana itself. The design in this guide is a bet that a Layer-1 can be fast enough that most users never need a Layer-2.
Does Solana use sharding?
No. Sharding splits a blockchain into pieces that each handle a slice of the traffic. Solana's design is the deliberate opposite: one global state on one chain, made fast through parallel execution and a pipelined delivery system. That is why apps on Solana can interact inside a single transaction without bridges. It is also why the network leans so heavily on validator hardware and software performance.
Is Proof of History Solana's consensus mechanism?
No, and the mislabel is common because early marketing described Solana's breakthrough as a new consensus design. Proof of History only orders events. The agreement that an ordered state is final comes from Tower BFT, the proof-of-stake voting layer. A useful test: a clock cannot be bribed or outvoted, but a voting system can be attacked. That is why the two jobs are built, and should be judged, separately.
How many transactions per second can Solana actually handle?
It depends on what you count. Public dashboards often show several thousand transactions per second, but a large share of those are validator vote transactions. Real user throughput usually runs lower and rises during events like popular mints. Headline figures of 65,000 TPS describe theory or test conditions rather than everyday load. Treat any single number with caution and check a live dashboard, since throughput moves with demand, client software, and upgrades.
What language are Solana apps written in?
Mostly Rust. Solana programs, its version of smart contracts, are compiled down to a low-level format the runtime runs. Rust is the main source language, C and C++ are also supported, and newer toolkits open the door to others. Whatever the language, every program follows the pattern from this guide. The code itself is stateless, and all the data it acts on lives in accounts that transactions must name up front.
Will Alpenglow change how Solana works?
It would change the first half of the machine and keep the second. Alpenglow is in testing with a late-2026 mainnet target. It would replace Proof of History and Tower BFT with a new voting and finalization system called Votor, add a new block propagation system called Rotor in Turbine's place, and aim for finality around 150 milliseconds. Sealevel's parallel execution, the account model, and the single global state would stay. If it ships, the assembly line keeps its stations; the clock and sign-off machinery get rebuilt.
Researched and written by the Blofin Academy editorial team with AI-assisted drafting. Primary sources include the Solana core documentation, Anza's Agave validator documentation, the Firedancer GitHub repository, the SIMD-0326 Alpenglow proposal in the Solana Improvement Documents repository, CoinDesk's report on the Alpenglow governance vote, and Helius engineering research on the Solana Virtual Machine. All facts independently verified against cited documentation current as of July 2026.
This article is for informational purposes only and does not constitute financial advice, investment guidance, or a recommendation to buy, sell, or hold any digital asset. Cryptocurrency markets involve significant risk and you should conduct your own research and consult qualified professionals before making investment decisions. Blofin Academy content reflects the state of public information at time of publication; protocol parameters, fees, and ecosystem data change frequently.