Solana processes around 2,000 to 4,000 transactions per second on its live network, with fees that rarely exceed a fraction of a cent. Bitcoin handles roughly 7 transactions per second. Ethereum manages around 15 on its base layer. The gap is not a small engineering improvement – it comes from a fundamentally different approach to how a blockchain orders, validates and finalises transactions. This article explains that approach from the ground up: the problem older networks face, the eight technical components Solana uses to solve it, what actually happens when a transaction leaves your wallet, and where the network is heading with its Alpenglow upgrade scheduled for 2026.
The problem Solana was built to solve
Every blockchain needs its nodes to agree on two things: which transactions happened, and in what order. On Bitcoin and Ethereum, nodes reach that agreement by talking to each other constantly. Before a transaction can be added to a block, validators broadcast it across the network, wait for peers to confirm receipt, check timestamps against their own clocks and then vote. Because no two computers share a perfectly synchronised clock, the network cannot simply trust a timestamp – it has to verify the order of events through rounds of communication.
That back-and-forth is the bottleneck. The more validators that need to coordinate, the longer each round takes. The longer each round takes, the fewer transactions the network can process per second. This trade-off sits at the centre of what researchers call the blockchain trilemma: a network can optimise for scalability, security or decentralisation, but achieving all three at once has proven difficult. Bitcoin and Ethereum chose security and decentralisation. Speed was the cost.
Anatoly Yakovenko, a former Qualcomm engineer with a background in distributed systems, published the Solana whitepaper in 2017 with a specific claim: the coordination problem could be solved without sacrificing security, if nodes could agree on the passage of time cryptographically rather than through communication. That idea became Proof of History.
Proof of History: the cryptographic clock that makes Solana fast
Proof of History is not a consensus mechanism in the traditional sense. It is a method for creating a verifiable record of time that every validator on the network can trust without checking with anyone else. Understanding it is the key to understanding how Solana works at every level.
What Proof of History actually does
The standard problem with timestamps on a blockchain is that any node can lie about when a transaction occurred. Without a trusted source of time, the network must agree on order through votes, and votes take time. Proof of History removes the need for those votes by embedding time directly into the data.
The mechanism runs a continuous SHA-256 hash function, where the output of each computation becomes the input of the next. Because SHA-256 is a sequential function – you cannot skip steps or parallelise the computation – the number of iterations completed serves as a verifiable measure of elapsed time. Each hash output carries a counter and a timestamp. Any validator can look at the chain of hashes and confirm, without communicating with anyone, that a specific amount of time passed between two events.
Think of it like a metronome that broadcasts a cryptographic beat. Every node on the network hears the same beat. Because the beat is generated by a hash function that cannot be faked or fast-forwarded, every node can independently verify the order of events without waiting for a consensus round.
How the SHA-256 hash chain creates a timeline
In practical terms, the Solana leader node runs the PoH generator continuously. Transactions are inserted into the hash sequence as they arrive, and their position in the sequence proves when they were received relative to all other events. A transaction inserted at hash 50,000 provably occurred before a transaction inserted at hash 51,000 – and any validator can verify this by replaying the hash sequence from any point.
This is what makes Proof of History a verifiable delay function (VDF). The computation takes real, measurable time, and the output serves as proof that the time was spent. The chain cannot be forged in advance because each step requires completing the previous one.
The PoH sequence produces a tick roughly every 400 milliseconds. Each tick corresponds to one slot, which is the basic unit of time on the Solana network. A slot is the window in which one validator – called the slot leader – collects transactions, produces a block and hands off to the next leader.
Why Solana validators do not need to talk to each other to agree on order
On a conventional blockchain, validators must exchange messages to confirm that they have seen the same transactions in the same order. That messaging adds latency at every step. On Solana, the PoH hash chain does the ordering work before the consensus round begins. By the time validators vote on a block, the order of transactions within it is already cryptographically established and verifiable by all parties independently.
The result is that validators spend far less time on coordination and far more time on actual transaction processing. That shift in how time is used is the primary reason Solana transactions per second are orders of magnitude higher than those of older networks.
Proof of Stake: how validators secure the Solana network
Proof of History handles ordering. Proof of Stake handles security. The two mechanisms work together, and neither is sufficient alone. A verifiable timeline is useless if validators can lie about what transactions they saw, and a voting system is too slow if nodes need to agree on order before they can vote. Together, PoH and PoS give Solana both speed and security.
Who are Solana validators and what do they do
A validator is a computer that participates in the Solana network by verifying transactions and voting on blocks. To become a validator, an operator must stake SOL – Solana native token – as collateral. That stake signals commitment to honest behaviour. If a validator acts against the rules of the network, its staked SOL can be confiscated through a process called slashing.
As of early 2026, the Solana network has approximately 1,900 active validators. The hardware requirements are significant – a competitive validator setup typically requires a high-core-count CPU, 512 GB or more of RAM, fast NVMe storage and a high-bandwidth internet connection. Those requirements are a point of criticism when comparing Solana’s decentralisation to Ethereum’s roughly one million validators, though Solana supporters argue that performance at scale requires capable hardware.
Validators earn rewards in two ways: block rewards paid in newly issued SOL, and a share of the transaction fees collected in the blocks they produce.
How staking and delegation work
SOL holders who do not run a validator can still participate in securing the network through delegation. A holder deposits SOL into a stake account and assigns it to a validator of their choice. The validator’s total stake weight increases, which affects how often it is selected as a leader. In return, the delegator earns a portion of the validator’s staking rewards.
Staking APY on Solana was running at approximately 5 to 6 percent in early 2026, depending on the validator chosen and network inflation at the time. Inflation started at 8 percent annually at launch and falls by 15 percent each year, with a long-term floor of 1.5 percent expected to be reached around 2032. Around 13 percent of staked SOL flows through liquid staking protocols, which allow stakers to retain liquidity while earning rewards.
Unstaking is not instant. SOL locked in a stake account is subject to a cooldown period of one epoch before it becomes available for withdrawal.
Slots, epochs and the leader schedule
Understanding how validators take turns requires understanding two units of time: slots and epochs.
A slot is approximately 400 milliseconds long – the interval between PoH ticks. Each slot is assigned to one validator, called the slot leader, who is responsible for collecting pending transactions, producing a block and broadcasting it to the network. A leader typically holds four consecutive slots (approximately 1.6 seconds) before the role rotates.
An epoch is a longer time unit consisting of 432,000 slots, which works out to roughly two days. At the start of each epoch, the network calculates the leader schedule for the entire epoch based on each validator’s stake weight. Validators with more stake are assigned more slots. Because every validator knows the schedule in advance, they can prepare to receive blocks from the incoming leader rather than waiting for a broadcast announcement. This advance knowledge is part of what allows Gulf Stream – covered below – to skip the mempool entirely.
Tower BFT: how the network agrees that a block is final
Proof of History establishes the order of events. Proof of Stake determines who produces blocks and penalises bad actors. But neither mechanism answers the question of finality: at what point is a block so deeply confirmed that reversing it becomes effectively impossible?
That is the job of Tower BFT, Solana’s implementation of Byzantine Fault Tolerance consensus. It is an adaptation of the Practical BFT algorithm originally published by Miguel Castro and Barbara Liskov in 1999, redesigned to use the PoH clock as a pre-established timeline.
Under Tower BFT, validators cast votes on blocks. Each vote locks the validator into that branch of the chain for a period called a lockout. The lockout doubles with each subsequent vote on the same branch. A validator that has voted on 10 consecutive blocks on the same branch would need to wait 1,024 slots before switching to a different fork – a period long enough that switching becomes economically irrational unless the network has genuinely split.
Because the PoH timeline is already established before voting begins, Tower BFT does not need multiple rounds of messaging to agree on which events preceded which. Validators can vote quickly, confident that the ordering is already cryptographically fixed. The result is deterministic finality – once enough stake has voted on a block, that block is mathematically final. Under normal conditions, optimistic confirmation arrives in roughly 400 milliseconds to 1.5 seconds, while full Tower BFT finality takes approximately 12.8 seconds.
How a Solana transaction actually works, step by step
The technical components above describe the infrastructure. This section describes what happens in practice when a user sends a transaction – from the moment they press confirm in a wallet to the moment the network records it as final.
From wallet to block: the path of a single transaction
When a user sends SOL or interacts with a decentralised application, their wallet software constructs a transaction. A Solana transaction contains the instructions to execute (for example, transfer 1 SOL to address X), the public keys of all accounts involved, the signatures of all required signers, and a recent blockhash.
The recent blockhash is a reference to one of the last 150 blocks on the chain. It serves as a timestamp and an expiry mechanism: if a transaction is not included in a block within approximately 90 seconds of the referenced blockhash, it is considered expired and dropped. This prevents replay attacks and removes the need for a nonce counter on every account.
The signed transaction is sent to an RPC node – a Solana node that accepts external requests but does not necessarily vote or produce blocks. The RPC node forwards the transaction toward the current slot leader.
Why Solana has no mempool: Gulf Stream explained
Most blockchains use a mempool – a waiting room where unconfirmed transactions sit until a validator picks them up and includes them in a block. Under high load, the mempool fills up, fees spike and transactions can wait minutes or hours for confirmation.
Solana replaces the mempool with Gulf Stream, a transaction forwarding protocol that takes advantage of the known leader schedule. Because every validator knows which node will be the leader for the next several slots, transactions can be forwarded directly to that node – and to the validators scheduled to lead the following slots – before the current block is even finished.
The slot leader receives transactions ahead of time, processes them as they arrive and is ready to pack them into a block the moment its slot begins. Transactions that miss the current leader are already in the pipeline for the next one. There is no queue to join and no mempool to drain. Under normal conditions, this is why Solana transaction confirmation feels near-instant to end users.
Transaction fees: base fee, priority fee and the burn
Every Solana transaction pays a fee denominated in lamports, where one lamport equals 0.000000001 SOL (named after computer science pioneer Leslie Lamport). The fee has two components.
The base fee is fixed at 5,000 lamports (0.000005 SOL) per signature. A standard single-signature transaction costs 0.000005 SOL regardless of network conditions. For context, at SOL priced at $100, that is $0.0005 per transaction – less than a tenth of a US cent.
The priority fee is optional and variable. During periods of high demand for specific programs – particularly popular DeFi protocols or NFT mints – users can attach a priority fee denominated in micro-lamports per compute unit to increase the probability that their transaction is included in the current block rather than a future one. Priority fees are set by the user and paid on top of the base fee.
Of the total fee collected, 50 percent is burned – permanently removed from the SOL supply. The remaining 50 percent goes to the validator that produced the block. The burn mechanism creates deflationary pressure on the SOL supply, though whether it offsets inflation in any given period depends on network activity levels.
Parallel processing: how Solana runs thousands of transactions at the same time
Even with a fast leader schedule and no mempool, a blockchain that processes transactions one at a time cannot scale past a certain point. The next layer of Solana’s performance comes from parallel execution.
Sealevel: running smart contracts at the same time
Ethereum executes smart contracts sequentially. Each transaction waits for the one before it to complete before the next one begins – the equivalent of a supermarket with a single checkout lane regardless of how many customers are waiting. Solana’s parallel execution engine, Sealevel, works differently.
Every Solana transaction must declare upfront which accounts it will read from and which it will write to. Sealevel uses this information to identify transactions that touch completely different sets of accounts. Those transactions have no dependency on each other and can be executed simultaneously across multiple CPU cores and GPU threads without any risk of conflicting results.
Two users swapping tokens on different DeFi protocols, for example, have no account overlap. Sealevel runs both swaps at the same time. A token transfer and an NFT mint with no shared accounts run simultaneously. The throughput gains compound quickly: where Ethereum serialises every operation, Solana parallelises everything it safely can.
Turbine: breaking blocks into shreds to reach every validator
Producing a block is only half the work. The block must then reach every validator in the network quickly enough that they can vote on it before the next slot begins. Sending a full block to 1,900 validators directly would require enormous bandwidth from the leader node.
Turbine solves this by splitting each block into small fragments called shreds and distributing them through a layered tree of validator groups. The leader sends shreds to a small set of validators. Each of those validators forwards shreds to the next layer, and so on, until the entire network has received the complete block. The structure reduces the bandwidth burden on any single node and allows the network to propagate large blocks quickly even as validator count grows.
Turbine also applies erasure coding to shreds – a technique borrowed from data transmission engineering that allows any node to reconstruct a complete block even if a portion of shreds are lost or arrive out of order.
Pipelining, Cloudbreak and Archivers
Pipelining is the process by which Solana’s validator software overlaps the four stages of block processing: fetching data, verifying signatures, executing transactions and writing results to the ledger. Rather than completing all four stages for one batch before starting the next, each stage processes a different batch simultaneously – similar to an assembly line where multiple products move through different stations at the same time. This keeps all hardware resources occupied and reduces the time between receiving a block and confirming it.
Cloudbreak is Solana’s account database, designed for horizontal scalability. It allows simultaneous read and write access to account data across multiple solid-state drives, which is necessary for Sealevel to execute thousands of transactions in parallel without creating storage bottlenecks. Cloudbreak distributes data across as many SSDs as the hardware provides, meaning storage performance scales with the machine.
Archivers are lightweight nodes that store historical ledger data. Because Solana’s high throughput generates data at a rate that would quickly overload validator storage if validators were required to keep everything, Archivers handle long-term storage independently. This keeps validator hardware requirements focused on transaction processing rather than historical archiving.
How fast is Solana? TPS, finality and what the numbers mean
Solana’s claimed theoretical maximum is 65,000 transactions per second. That figure comes from lab conditions with optimal hardware, no vote transactions counted and no network overhead. The practical numbers are lower but still far ahead of comparable networks.
| Network | Practical TPS | Finality | Average fee |
|---|---|---|---|
| Bitcoin | ~7 | ~60 minutes | $1-$20+ |
| Ethereum (L1) | ~15-30 | ~12 minutes | $0.50-$50+ |
| Solana (current) | 2,000-4,000 | ~12.8 seconds | $0.0005 or less |
| Solana (post-Alpenglow) | 107,000+ (target) | ~150ms (target) | $0.0005 or less |
The current 2,000 to 4,000 TPS figure includes validator vote transactions, which consume a share of block space. Non-vote user transactions make up a portion of that total. During peak activity in early 2026, the network recorded over 108.8 million daily transactions at its highest points.
Finality deserves a precise definition. Optimistic confirmation – the point at which a transaction is extremely unlikely to be reversed – arrives in 400 milliseconds to 1.5 seconds under normal conditions. Full Tower BFT finality – the point at which reversal is mathematically impossible – takes approximately 12.8 seconds. For comparison, Ethereum’s full finality under its current consensus takes around 12 minutes, and a Bitcoin transaction is typically considered settled after six block confirmations, which takes roughly 60 minutes.
On the Solana vs Ethereum question, the comparison is complicated by the fact that Ethereum has largely shifted its scaling strategy to Layer 2 networks – separate chains that batch transactions and post proofs back to Ethereum’s base layer. Solana’s approach is to scale at Layer 1 directly. Both strategies have trade-offs in terms of composability, decentralisation and the user experience of bridging assets between chains.
Alpenglow: the upgrade that replaces Proof of History in 2026
In August 2025, Solana developers at Anza submitted SIMD-0326, a governance proposal for the most significant infrastructure overhaul in the network’s history. The proposal, nicknamed Alpenglow, passed with 98.27% validator support on September 2, 2025. Mainnet deployment is scheduled for 2026, pending testnet validation. No competing “how does Solana work” article covers this at the level of detail the upgrade deserves.
Alpenglow replaces both Proof of History and Tower BFT with two new components: Votor and Rotor. The combined effect is expected to cut transaction finality from 12.8 seconds to approximately 100 to 150 milliseconds – a reduction of nearly 100 times – and raise theoretical throughput to over 107,000 transactions per second.
Votor: single-round and two-round block finalisation
Votor is a direct-vote consensus protocol that replaces Tower BFT’s on-chain voting with off-chain validator communication. Under Tower BFT, every validator vote is submitted as an on-chain transaction – a design that consumes block space, adds cost and introduces the latency of waiting for votes to be processed like regular user transactions.
Votor removes votes from the chain entirely. Validators exchange votes directly using cryptographic signature aggregation, then submit compact proofs on-chain once consensus is reached. The on-chain footprint is dramatically smaller, and the voting round completes far faster.
Votor operates in two modes depending on network conditions. If 80 percent of staked weight votes in the first round, the block is finalised immediately in a single round. If only 60 percent vote in the first round, a second round runs, and finalisation requires two-thirds majority across both rounds. Under normal network conditions, the single-round path is the default, and finality arrives in approximately 150 milliseconds.
Votor also introduces a 20+20 resilience model: the network maintains safety guarantees with up to 20 percent of stake acting adversarially, and maintains liveness – the ability to keep producing blocks – even if an additional 20 percent of validators go offline simultaneously. That is a stronger fault tolerance profile than Tower BFT provides.
Rotor: replacing Turbine with one-hop broadcasting
Rotor replaces Turbine as Solana’s block propagation mechanism. The core change is moving from Turbine’s multi-hop tree structure – where blocks travel through multiple relay layers before reaching all validators – to a one-hop broadcast model, where the leader sends shreds directly to all validators in a single step.
The bandwidth savings come from Rotor’s use of erasure coding and its elimination of redundant relay nodes. Under Turbine, intermediate relay nodes consume bandwidth receiving and re-transmitting shreds without producing blocks themselves. Rotor removes the relay layer entirely, reducing wasted bandwidth and cutting the time required for full network propagation.
When combined with Votor’s faster voting rounds, Rotor means that blocks reach validators and receive votes faster than under any previous Solana architecture. The Solana Foundation described the combined effect as delivering Web2-level responsiveness with L1 finality – the kind of speed users experience with Google or Visa, but with cryptographic certainty. Testnet deployment was scheduled for December 2025, with mainnet to follow in Q1 2026.
Solana vs Ethereum: how the two blockchains compare
The most common comparison in the Solana vs Ethereum debate involves speed and fees, but the architectural differences go deeper than those numbers suggest.
Ethereum is a single-layer base chain that has moved most of its scaling ambition to Layer 2 networks – rollups like Arbitrum, Optimism and Base that process transactions off the main chain and periodically post batches back to Ethereum for settlement. The base chain handles security and final settlement. The L2 chains handle throughput. This creates a fragmented environment where liquidity and applications are spread across many chains, and users must bridge assets to move between them.
Solana scales at Layer 1 directly. All transactions, all applications and all liquidity exist on one chain. There is no bridging between layers, no liquidity fragmentation and no composability gap between protocols. A DeFi trade, an NFT purchase and a stablecoin transfer can all be bundled into a single atomic transaction. That composability is difficult to replicate across rollups.
On decentralisation, Ethereum holds a clear lead by validator count – roughly one million validators versus Solana’s approximately 1,900. Solana’s validator hardware requirements are substantially higher, which limits who can run one. On the other hand, Solana’s staking delegation system allows SOL holders without expensive hardware to participate in network security, and the introduction of Firedancer – a second independent validator client developed by Jump Crypto – reduces the risk of a single-client bug taking down the network.
On fees, Solana is consistently cheaper. Ethereum gas fees fluctuate with demand and have historically reached tens of dollars per transaction during congested periods. A Solana base fee of 0.000005 SOL does not change with network load in the same way.
Neither chain is strictly better for all use cases. Ethereum’s longer history, larger developer base and more decentralised validator set make it the preferred base layer for high-value settlement and institutional DeFi. Solana’s speed and low fees make it the more practical choice for high-frequency trading, consumer payments, gaming and applications where transaction cost or confirmation time affects the user experience directly.
Solana network outages and the decentralisation debate
Any honest account of how the Solana network works must address its outage history. Between 2021 and 2023, the network experienced several significant disruptions, including a full outage in September 2021 that lasted approximately 17 hours, partial degradation during the Candy Machine NFT launch in January 2022, and instability caused by bot activity during the Stepn memecoin period in 2022.
The causes varied. The September 2021 outage was triggered by an excessive volume of transactions from a single token launch that overwhelmed validator memory. The 2022 bot-driven incidents involved millions of low-value transactions per second that consumed block space intended for legitimate users. The common thread was that Solana’s performance at scale created attack surfaces that had not existed on slower networks.
The responses were concrete. The QUIC transport protocol replaced UDP for transaction ingestion, giving validators more control over which connections they accept and allowing them to shed load from bad actors without dropping legitimate traffic. The introduction of local fee markets – separate priority fee markets for individual programs rather than one network-wide fee market – meant that a congested NFT mint would no longer drive up fees for unrelated DeFi transactions. Firedancer, the second validator client from Jump Crypto, adds client diversity that reduces the risk of a single software bug halting the entire network.
The Solana decentralisation debate centres on validator count and hardware requirements. Running a competitive Solana validator requires hardware costing roughly $10,000 or more to set up, plus ongoing bandwidth and electricity costs. That barrier excludes most individual participants from running validators, concentrating block production among well-funded operators. Proponents argue that this is a deliberate trade-off – consumer-grade hardware cannot process thousands of transactions per second – and that the delegation system distributes economic participation even if not every SOL holder runs a node. Critics argue that a network with 1,900 validators is categorically more centralised than one with one million, and that the concentration of stake among large operators creates governance risk.
Both positions have merit. For a full account of what Solana is and how it positions itself against competing blockchains, the decentralisation trade-off is worth understanding before deciding how to use or invest in the network.
Frequently asked questions
Is Solana proof of stake or proof of work?
Solana uses Proof of Stake combined with Proof of History. It has never used Proof of Work. Validators stake SOL to participate in block production and earn rewards. Proof of History is a separate mechanism that establishes the order of transactions cryptographically, allowing validators to skip the coordination rounds that slow down conventional PoS networks.
How many transactions per second can Solana handle?
The theoretical maximum under optimal lab conditions is approximately 65,000 TPS. In practice, the live network processes 2,000 to 4,000 transactions per second including validator votes. With the Alpenglow upgrade expected in 2026, the target rises to over 107,000 TPS.
How does Proof of History work?
Proof of History runs a continuous SHA-256 hash chain where each output becomes the next input. Because the computation is sequential and cannot be parallelised, the number of completed iterations proves elapsed time. Transactions are inserted into the chain as they arrive, and their position in the hash sequence proves when they were received relative to all other events – without requiring any communication between nodes.
How much does a Solana transaction cost?
The base fee is 5,000 lamports, or 0.000005 SOL, per signature. At SOL priced at $100 that works out to $0.0005 per transaction. Users can optionally attach a priority fee during high demand, but standard transfers and most program interactions cost a fraction of a cent. 50 percent of all fees are burned.
What is a Solana slot?
A slot is a 400-millisecond window assigned to one validator, called the slot leader, who produces a block during that time. One slot equals one PoH tick. Slots are grouped into epochs of 432,000 slots – roughly two days – and the leader schedule for the entire epoch is calculated at the start of each epoch based on stake weights.
What is Gulf Stream on Solana?
Gulf Stream is Solana’s transaction forwarding protocol. Because every validator knows the leader schedule in advance, pending transactions can be forwarded directly to the upcoming slot leader before the current block is finished. This eliminates the mempool – the waiting queue used by Bitcoin and Ethereum – and allows the leader to begin processing transactions before its slot even starts.
What is Sealevel?
Sealevel is Solana’s parallel transaction execution engine. Every transaction on Solana must declare which accounts it reads and writes. Sealevel identifies transactions with no overlapping accounts and runs them simultaneously across multiple CPU cores and GPU threads. This is the primary architectural reason Solana’s throughput exceeds Ethereum’s sequential processing model.
What is Tower BFT?
Tower BFT is Solana’s Byzantine Fault Tolerant consensus mechanism, based on the 1999 Practical BFT algorithm by Castro and Liskov. It uses the Proof of History clock to eliminate the need for multiple communication rounds during voting. Validators cast votes with increasing lockout periods that make switching to a conflicting fork progressively more expensive. Tower BFT provides deterministic finality in approximately 12.8 seconds, with optimistic confirmation in under 1.5 seconds.
What is Alpenglow and when does it deploy?
Alpenglow (SIMD-0326) is a consensus upgrade that replaces Proof of History and Tower BFT with two new components: Votor, a direct off-chain voting protocol, and Rotor, a one-hop block propagation mechanism. It passed a validator governance vote with 98.27% support on September 2, 2025. Testnet deployment was scheduled for December 2025. Mainnet deployment is expected in Q1 2026. The upgrade targets finality of 100 to 150 milliseconds, compared to 12.8 seconds under the current system.
What is the difference between Solana and Ethereum?
Solana scales at Layer 1, processing all transactions on a single chain. Ethereum scales primarily through Layer 2 rollups that batch transactions and post them back to the Ethereum base layer. Solana is faster and cheaper per transaction, but Ethereum has a larger validator set and a longer track record. Solana’s single-chain architecture offers stronger composability across applications, while Ethereum’s rollup model distributes load across many chains with different security assumptions.
Has Solana ever gone down?
Yes. The most significant outage was in September 2021, lasting approximately 17 hours following a transaction flood from a single token launch. Additional disruptions occurred in January 2022, May 2022 and June 2022. Since 2023, the network has run without a full outage, following the introduction of QUIC for transaction ingestion, local fee markets and the ongoing development of Firedancer as a second validator client.
What is Firedancer?
Firedancer is an independent Solana validator client developed by Jump Crypto. Most Solana validators currently run Agave, the client maintained by Anza. Firedancer provides client diversity – if a bug is found in Agave, Firedancer validators continue operating, preventing a single-client failure from halting the network. Firedancer is also designed for higher throughput, with benchmarks showing it capable of processing several hundred thousand transactions per second in controlled testing.
