Solana Risks and Reliability

Introduction

Solana attracts unusually polarised commentary. To its advocates it is the fast, cheap chain that has put its outage era behind it; to its critics it is the network that keeps falling over. Neither caricature helps someone actually deciding whether to hold, stake or build on it. The honest position is that Solana carries real, specific, datable risks — and that most of them have moved over the past two years. Some are receding, some narrowing, and none is mysterious once you read the record rather than the slogans.

This page is written for that reader: not the trader chasing a narrative, but the person weighing whether to hold SOL, to stake it natively or through a liquid-staking token, or to build on the chain. The questions that matter are much the same in each case. How often does the network stop, and what could stop it? What will you pay when it is busy? And what is genuinely at stake when you delegate? Each risk below is dated, sourced and sorted by whether it can merely delay a transaction or actually touch your principal.

A few realities are worth stating before the detail, because they are the ones most often mis-stated. Solana has no live protocol-level slashing today: as of 25 July 2026 a delegator's stake cannot be seized for a validator's misbehaviour, though violations are recorded and penalties remain under governance discussion. Native staking yields roughly 5.5–5.9% all-in before commission, driven mainly by issuance rather than fees. By comparison, Ethereum pays about 2.64% base issuance, or roughly 3–4% all-in once execution-layer tips and MEV are counted.

Client diversity has finally arrived — Firedancer is live on mainnet — yet full Firedancer secures only around 14% of stake, so the majority still runs Agave-lineage software. The page then maps these risks in the order a cautious investor would meet them. It starts with the outage history and what the live uptime figure actually shows, then the single-client concentration that made several of those halts possible and the Firedancer work now narrowing it. From there it turns to what you pay under load, what staking does and does not protect, and the MEV that survives Solana's no-mempool design.

It closes with two risks that are now largely historical: the securities-law allegation that was withdrawn, and the FTX estate's SOL that has been sold. Getting the tense right on those matters as much as getting the live ones right. Throughout, the aim is neither reassurance nor alarm but an accurate register you can act on. Where a figure moves, the page points you to the live source rather than freezing a number that will date.

Solana’s outage and reliability history

Solana’s reliability record is best read from the incidents themselves rather than from either its critics or its advocates. The network has suffered a series of full or near-full halts, each documented with a root cause, and the honest reading of that record is neither “always down” nor “fixed”. The table below lists the confirmed full-network halts through the most recent one, on 6 February 2024.

Two families of failure: load and code

Two patterns run through this list. The first is demand-driven. Several of the earliest outages, including September 2021 and May 2022, began when a burst of automated transactions — bots chasing a token sale or an NFT mint — flooded the network faster than it could schedule the load. The second is software-driven: the June 2022, September 2022, February 2023 and February 2024 halts trace to bugs in consensus, fork choice or block handling rather than to raw traffic. The two categories overlap, because heavy load has a way of surfacing latent bugs, but the distinction matters. Spam-driven halts point to how the network prioritises transactions under pressure; bug-driven halts point to the maturity of the client software that every validator runs.

Why the two families need different cures

The two families call for different cures, which is why the distinction is worth holding onto. A demand-driven halt is, in principle, a problem of admission and prioritisation: decide whose transactions get scheduled when capacity is scarce, and a flood becomes a slowdown rather than a stoppage. That is precisely what QUIC transport, stake-weighted quality of service and local fee markets are built to do, so a load-driven repeat of 2021 or 2022 is the failure mode those mitigations most directly target.

A consensus or client bug is a different animal. It cannot be throttled away, because the fault sits in the code every validator runs, and the only durable defences are the slow ones — more mature software and a second independent implementation to break the shared-code monoculture. Reading a future incident by which family it belongs to therefore tells you something useful. A load halt would suggest the mitigations were overrun; a bug halt would point straight back at the client-diversity gap the next section examines.

The improving trend since 2024

The record also shows a change over time. The clustering of incidents in 2021 and 2022 gave way to single halts in 2023 and 2024, and as of mid-2026 there has been no officially confirmed full network halt since 6 February 2024. For the current status and the live length of that streak, the authoritative source is the network’s own dashboard at status.solana.com. The gap since 2024 followed concrete engineering work. QUIC replaced the older transport layer to give validators finer control over incoming traffic. Stake-weighted quality of service began prioritising transactions from staked validators during congestion, and local fee markets confined fee spikes to the specific programs under demand rather than the whole chain.

None of this warrants calling the problem solved. The 2024 halt was itself a software bug that reached mainnet, which is the same class of failure that caused several earlier outages, and the mitigations above manage load and congestion rather than eliminating the possibility of a consensus or client bug. The reliability story is one of ongoing hardening on a network that has demonstrably reduced the frequency of its worst failures, not one of a network that has ruled them out. A prospective user should weigh the improving trend against a plain fact: the most recent halt is recent enough to remain within living memory of anyone who has used the chain. The sensible reading is to treat any long uptime streak as evidence of progress rather than as a guarantee.

Uptime today and what changed

The single most useful number here is also the one that dates fastest, so treat it as a snapshot rather than a settled verdict. As of July 2026, Solana has recorded no officially confirmed full network halt since 6 February 2024, when the network stopped for roughly five hours. That is the longest clean run in its history, but a streak is a live figure, not a fixed property. Before quoting it anywhere, check the current status directly on status.solana.com, which reports the network's real-time state and its incident history. If a halt has occurred since this page was written, that source will say so before we can.

Reading the status dashboard well

Reading that dashboard well is itself a small skill, and it repays the habit. It answers two distinct questions, and it helps to keep them apart. The first is the live state: is the network producing blocks right now, which is what you want to confirm before relying on any uptime claim quoted second-hand. The second is the incident log: how recent the last disruption was and, more usefully, what kind it was.

The two families set out above give you the lens. A most-recent incident that was load-driven tells you the congestion mitigations were, on that occasion, overrun; one that was a consensus or client bug points instead at the codebase risk the next section examines. So the dashboard is not just a green light to glance at but a short record to interpret: the streak is the headline, and the character of the last incident is the part that actually tells you what to expect.

Measured against a poor record

The run matters because the record behind it was poor. Solana suffered dated, full-network outages across 2020 to 2024 — a Turbine block-propagation bug, transaction floods during high-demand launches, a durable-nonce consensus fault, a fork-choice bug, and an oversized-block failure among them. Several were not congestion in the ordinary sense but the whole validator set losing consensus and needing a coordinated restart. So the improvement is real and worth crediting, but it is measured against a low bar, and the causes were varied enough that no single fix could have addressed all of them.

Three changes that lengthened the streak

Three changes did most of the work in lengthening the streak, each aimed squarely at a failure mode that had caused earlier stoppages:

• QUIC transport replaced the older raw-UDP path for submitting transactions, giving validators connection-level control over who is flooding them.
• Stake-weighted quality of service prioritises transactions from higher-stake sources, so a bot spraying the network cannot as easily crowd out legitimate traffic.
• Local fee markets scoped congestion to the specific programs under load, rather than letting one popular contract price up the entire chain.

Together these target the exact failure modes — flooding and undifferentiated congestion — that produced several of the earliest halts.

The honest framing is that this is hardening in progress, not a problem closed. Each of those mechanisms reduces the likelihood of a repeat of a past outage; none of them proves the next fault cannot come from somewhere new. Consensus software is complex, and the outages that hurt most were the ones nobody had modelled in advance. A longer streak raises confidence incrementally; it does not convert reliability into a guarantee.

Two caveats that keep it in proportion

Two caveats keep this in proportion. First, uptime is a network-level measure: the chain producing blocks does not mean every transaction lands, which is a separate question of fees and congestion covered below. Second, the resilience story is still bound up with client diversity — for most of this period a single client family produced nearly all blocks, so a codebase bug remained a plausible route to another halt. That risk is narrowing rather than resolved. Read the streak as evidence of steady engineering progress, verify it live before you rely on it, and weigh it alongside the other risks on this page rather than as a headline that settles the matter.

Single-client risk and Firedancer

Why one client is a single point of failure

For most of its history, Solana ran on effectively one production client. That software, the Agave client from the Solana Labs lineage, defined how nearly every validator built blocks, gossiped transactions and reached consensus. A network with a single dominant client has a single point of failure: a bug in that one codebase is a bug the whole network shares at the same moment. There is no independent second implementation running in parallel to keep producing blocks while the first is patched, so a fault can stop the entire chain rather than a fraction of it.

This is not a hypothetical. Several of Solana's confirmed full-network halts traced back to defects in that shared code path — a durable-nonce consensus bug in June 2022 and a fork-choice bug later that year among them. When one implementation carries the whole network, a coding error becomes a liveness event for every user, and recovery depends on validators coordinating an out-of-band restart. Client concentration is therefore a structural reliability risk in its own right, separate from the transaction-flood and spam incidents that caused other outages.

The standard mitigation, borrowed from the wider blockchain world, is client diversity: several independently written implementations of the same protocol, so a bug in one does not take down the others. Ethereum has pursued this for years. Solana lacked it for most of its life, which left the concentration risk unaddressed no matter how much the individual client was hardened.

What a second implementation actually buys

It is worth being concrete about what a second independent implementation actually buys. If two clients genuinely share the protocol but not the code, the same latent defect is unlikely to sit in both at once, so a bug that would freeze a monoculture instead sidelines only the validators running the affected client. The others keep building blocks, and a full-network halt degrades into a partial, survivable event — provided the healthy client commands enough stake to carry consensus on its own.

That proviso is the whole game, and it is why a from-scratch client matters more than a fork would. A fork inherits its parent's code paths, and with them the parent's latent bugs, so it can fail in lockstep at the very moment independence is needed most. Diversity only protects the network when the second implementation is both genuinely independent in its code and large enough in stake to keep producing blocks while the first is patched.

Firedancer on mainnet, and where its stake stands

Firedancer is the response to that gap. Built by Jump Crypto as an independent, from-scratch client rather than a fork of the existing code, it is designed to share the protocol but not the implementation — so a defect in one lineage need not be present in the other. It reached full mainnet on 12 December 2025, making Solana a genuinely multi-client network for the first time.

The important caveat is scale. Reaching mainnet is not the same as securing the network, and as of mid-2026 the stake is split three ways:

• Full Firedancer secures only around 14% of stake — genuinely independent code, but a minority share.
• Frankendancer, a hybrid that pairs Firedancer's networking layer with the existing execution engine, runs on roughly a quarter of stake.
• Agave-lineage software — Agave itself and Jito-Solana, the single largest client by stake — still carries the majority.

So while true client diversity now exists, it does not yet dominate.

Narrowing, not resolved

What this means for the risk picture is that the systemic single-client-family exposure is narrowing rather than resolved. A critical bug in the Agave lineage today would still affect the majority of validators, because most stake continues to run that family of code. Client diversity only delivers its full protective benefit once no single implementation commands enough stake to halt or fork the chain by itself, and Solana is not there yet. The trajectory is favourable — an independent client exists, is live, and is gaining share — but the honest reading is a work in progress.

For a reader, the figure that carries the risk is the share of stake concentrated in the single largest client family. While that share stays above the point at which one family could halt or fork the chain on its own, the single-client exposure is materially live, regardless of how encouraging the direction of travel looks. A comforting trend and a present-day vulnerability can be, and here are, true at the same time. The reassurance to resist is the one that reads “Firedancer is live, therefore the problem is solved”. The honest version is that an independent client existing is necessary but not yet sufficient, and it stays insufficient until no one implementation can stop the network by itself.

For anyone weighing Solana's reliability, this is one of the more consequential open variables. The pace at which stake migrates onto genuinely independent clients, and the point at which no single client family can unilaterally stop the network, is a metric worth tracking directly rather than assuming. It sits alongside the network's outage history as evidence that reliability here is being actively engineered, not that it has been settled.

Fees under load

The base fee: 5,000 lamports per signature

Every Solana transaction pays a base fee of 5,000 lamports per signature, a fraction of a cent at typical SOL prices. Half of that base fee is burned and half goes to the validator that processes the block, a mechanism designed to give the network a small deflationary pull while still rewarding block producers. On its own, this base fee is genuinely cheap, and for the large majority of everyday transfers and swaps it is the only fee a user pays.

On top of the base fee sits an optional priority fee, calculated as a compute-unit price multiplied by the compute-unit limit a transaction requests, paid entirely to the validator rather than burned. Priority fees are not a single network-wide auction. Solana runs scoped local fee markets, so demand for compute is priced separately for each program or account a transaction touches. A surge of activity on one popular application does not, by itself, push up the cost of an unrelated transfer elsewhere on the chain.

Local fee markets and the failed-transaction risk

That localisation is the honest nuance most summaries skip. When a specific program becomes hot — a popular mint, a liquidity pool during a volatile move, a high-demand launch — the local fee market around it tightens. Users trying to land a transaction that touches that program need to bid a higher priority fee to get validator attention. If the fee attached is too low, the transaction can simply fail to land. It is either not processed at all, or it loses a race against better-paying transactions and must be resent with a higher bid. This is a real, user-visible failure mode, not a hypothetical one, and it is the mechanism behind most complaints about Solana "fees spiking" during busy periods.

For an ordinary user, the practical consequence is worth stating plainly. Because the base fee is fixed at 5,000 lamports whatever the conditions, none of the extra cost during a spike comes from the protocol charging you more. The whole of it sits in the optional priority fee, which is a bid you set rather than a price the network imposes. Most wallets estimate that bid for you from recent demand around the program you are touching. In a fast-moving spike a stale estimate can leave your transaction under-bidding and stuck behind better-paying ones — landing late, or not landing until you resend.

The lever is narrow and specific: raise the priority fee on that one transaction rather than assume the whole chain has turned expensive. Once the hot program cools, the same swap lands at the ordinary base fee again. An unrelated transfer you send during the same spike is unaffected, because the elevated bidding is scoped to the busy program, not to you.

The fair framing on congestion

The fair framing sits between two extremes. Solana is not immune to congestion, and a specific hot program can become expensive and unreliable to interact with for as long as demand stays elevated. But it is also not chain-wide congestion in the way a single global fee market would produce. Transactions unrelated to the congested program continue to confirm cheaply and quickly, because the local fee markets keep demand for one piece of the network from bidding up the price of using an entirely different piece of it. Any specific number quoted for "average priority fees" or "typical congestion cost" is a snapshot of one period of demand rather than a fixed property of the network. Figures from a single congested week should not be read as Solana's normal operating cost.

Staking risk: no slashing, but not risk-free

No live slashing today

One risk that exists on some proof-of-stake networks is largely absent here. As of July 2026, Solana has no live protocol-level slashing, so a delegator's staked SOL cannot be seized as a penalty for a validator's misbehaviour. If you delegate to a validator that double-signs or otherwise misbehaves, the protocol does not confiscate a portion of your stake. That removes one tail risk that new stakers often worry about, and it is worth being clear about because the fear is common and, in this specific case, misplaced. How Solana's position compares with networks that do enforce economic penalties is covered in the Solana versus Ethereum staking comparison; the point here is only what applies to your staked SOL.

The real downside: underperformance

Absent slashing does not mean staking is free of downside. The likeliest way to lose value is not seizure but underperformance, and it comes from three quiet sources:

• Validator downtime. An operator that is offline or missing its assigned slots earns fewer rewards, and you receive a proportionally smaller share — an unreliable operator quietly costs you yield over time.
• Commission drift. The percentage a validator takes from your rewards is set by the operator and can change, so two delegators staking the same amount to different validators can end up with materially different returns.
• Liquid-staking contract risk. Stake through a token such as jitoSOL or mSOL and you also take on the soundness of the protocol's smart contracts, covered below.

Neither of the first two shows up as a dramatic event. They show up as a lower balance than you expected, which makes validator choice and ongoing monitoring the practical work of staking rather than a one-time decision.

In practice that monitoring is less onerous than it sounds, because you are watching for drift rather than disaster. The signal is not an alert but your realised reward rate slipping below what comparable validators return over the same window. If the rewards landing in your account are quietly lagging the operators around it, the likeliest cause is a validator missing its assigned slots, or one that has raised its commission since you delegated.

Both are checkable. Compare the reward you actually receive against what a well-run validator of the same size is paying, and the commission the operator currently advertises against the figure that applied when you staked. Neither demands constant attention; an occasional look is enough to catch an operator that has drifted from reliable to mediocre, at which point the remedy is simply to redelegate. The work of staking well is this periodic check, not the initial choice.

Liquid staking adds a layer

Liquid staking adds a separate layer of risk. When you stake through a liquid-staking token, you hand your SOL to a staking protocol and receive a token that represents the position and can be used elsewhere while it earns. That token is only as sound as the smart contracts behind it. A bug, an exploit, or a failure in the liquid-staking protocol can affect the value or redeemability of the token independently of anything the underlying validators do. You are taking on the protocol's contract risk on top of the ordinary staking risks above. Native delegation avoids that particular exposure but gives up the liquidity and composability that make liquid-staking tokens attractive in the first place. There is a genuine trade-off here rather than a clearly superior option.

The mechanics of delegating, choosing a validator, comparing commission rates, and deciding between native and liquid staking are set out in the Solana staking guide. Treat the absence of slashing as one fewer thing to fear, not as a signal that staked SOL carries no risk at all. Validator reliability, commission, and — for liquid staking — the soundness of the protocol you use all still bear directly on what you keep.

Execution risk: MEV and sandwiching

The “no MEV” claim, and why it is wrong

A persistent claim in Solana discussions is that the network has "no MEV" because it has no public mempool. That is not accurate. Maximal extractable value — profit a validator or searcher can capture by reordering, inserting, or excluding transactions within a block — is still very much present on Solana. What differs from Ethereum is the mechanism, not the existence of the problem.

Ethereum's classic sandwich attack relies on a public mempool, where pending transactions sit visible before confirmation. A searcher spots a large pending swap, places a buy order ahead of it, lets the victim's trade push the price up, then sells immediately after. Solana has no equivalent open mempool for pending transactions to be scanned and front-run in that specific way. That structural difference is real, and it is the source of the "Solana has no MEV" claim — but it is only half the picture.

How MEV actually works on Solana

Instead, MEV on Solana is organised off-protocol, primarily through Jito's block engine. Validators running Jito-enabled software can accept bundles of transactions from searchers, who bid for favourable ordering within a block via tips rather than gas auctions in an open mempool. This is a different market structure, but it still allows the same underlying behaviour: searchers can identify a profitable swap as it is being submitted and bundle their own trades around it. Sandwiching on Solana happens through this route, and careless or unprotected swaps — particularly on volatile pairs or low-liquidity pools — remain exposed to it.

The reason this reaches an ordinary user is that none of it requires the user to take part. You never see a mempool, never run a searcher, never opt into a bundle — and yet your swap is the very thing a searcher bundles its own trades around. The extraction happens to your transaction, not through any choice you made, which is what makes it easy to miss.

There is no error and no obvious event. The trade confirms, but you receive fewer tokens than the quoted price implied, because a buy was slipped in ahead of yours to push the price up and a sell dropped in behind to capture the difference. The cost of a sandwich is a quietly worse fill. On a volatile pair or a thin pool — exactly the conditions the previous paragraph flags — that gap between the price you were quoted and the price you actually got can be the whole of the harm.

Practical defences for a trade

The practical defence is not assuming the network structure protects a trade by default. Setting a tight slippage tolerance limits how much price movement a transaction will accept before it reverts, which caps the damage a sandwich attempt can extract even if one is attempted. Routing swaps through a reputable aggregator that includes MEV-aware routing or private transaction submission also reduces exposure, since it avoids broadcasting a trade in a way that is easy for searchers to target. Neither measure eliminates MEV outright — no chain has managed that — but together they substantially reduce the practical risk to an individual trade.

Slippage tolerance is worth setting deliberately rather than reflexively, because it cuts both ways. Set it too loose and you leave room for exactly the price movement a sandwich needs. Set it too tight and, during genuine volatility, an honest price move can breach the limit and the transaction reverts — you pay to fail rather than to trade, and then have to resubmit into a market that has already moved.

The right level is not the tightest possible number but the tightest one that still lets a legitimate trade through under the conditions you are trading in. Set it wider for a fast-moving pair where honest volatility is large, and tighter for a deep, stable pool where any big deviation is more likely to be someone acting on your order. That judgement, rather than a single default, is where the practical protection actually lives.

The honest framing sits between the two extremes. Solana is not a mempool-based sandwich free-for-all in the way early Ethereum DeFi was, but it is not immune to extraction either. MEV has simply moved to a different layer of the stack, and the burden of defence still falls on the person making the trade. Set slippage limits deliberately, and treat a swap through an unprotected route on a volatile pair as the same kind of risk it would be on any other chain.

Regulatory history

An allegation, not a ruling

Solana's regulatory record is shaped by an unresolved dispute rather than a settled ruling, and the honest way to describe it is procedural. In June 2023 the United States Securities and Exchange Commission filed civil complaints against two large exchanges, Binance and Coinbase. Within those filings the SEC named a list of tokens it alleged were being traded as unregistered securities, and SOL appeared on that list. It is important to read that precisely: the SEC alleged that SOL had been offered and sold as a security. An allegation in a complaint is a legal argument the agency intended to prove, not a finding that any court had accepted.

That distinction matters because the allegation was never adjudicated. No court held a trial on whether SOL is a security, issued a judgment on the question, or created binding precedent about the token itself. The claim existed as part of wider enforcement actions whose focus was the conduct of the exchanges, and SOL was one item within a broader theory. Anyone who tells you a court “ruled SOL a security” is describing something that did not happen.

Because the allegation was withdrawn rather than tested, it also left no precedent behind it — in either direction. A claim litigated to judgment produces a ruling that later cases must reckon with; a claim that is dropped produces nothing a future court is bound to follow. So the question of SOL's status was not narrowed by the episode so much as returned, unanswered, to the shelf. A later action, under a different agency posture, would begin more or less from scratch rather than inherit a win or a loss.

For a holder, it helps to separate what changed from what did not. What changed is sentiment: a specific allegation that had shadowed the token was lifted, and with it a source of headline risk. What did not change is any formal classification. The withdrawal compelled no exchange to delist SOL, imposed no new obligation on the people who hold it, and did not convert the token into something a court has blessed. The practical position is simply the absence of a live claim, which is a genuinely better place to stand than an open allegation, without being the settled all-clear that the word “cleared” would imply.

How the posture unwound in 2025

During 2025 the posture unwound. The enforcement pressure that had put SOL on those lists eased as the actions themselves were resolved and stepped back from, and the specific security-status allegation lost its live footing. This is best understood as the claim being withdrawn from active contention rather than as a tribunal clearing the token. The practical effect is that, as of mid-2026, there is no active SEC allegation that SOL is an unregistered security, and there is also no court ruling that settles the matter in the other direction.

So the accurate summary is a question that is resolved for now, not closed forever. The particular allegation that overhung SOL from 2023 has been removed, which lifts a specific source of uncertainty that weighed on the token during that period. What has not happened is a definitive legal determination of SOL's status. Regulatory classification of a token can be reopened by a future agency posture, a new administration, or a different set of facts, and nothing about the 2025 unwinding forecloses that. Treating the token as “permanently cleared” would overstate the record just as badly as claiming it was declared a security.

For an investor, the takeaway is modest and specific. The most acute regulatory fear of the 2023–2024 window has receded, the current baseline carries no live securities allegation against SOL, and the underlying question of formal classification remains open rather than answered. Weigh it as an unsettled variable, not as either a proven danger or a guaranteed all-clear.

The FTX-estate overhang, in the past tense

The overhang while it existed

For most of 2023 and 2024, one line item sat over Solana's price like a standing question mark: the FTX estate's bankruptcy proceedings included a SOL holding of roughly 41 million tokens, acquired mostly at deep discounts before the exchange's 2022 collapse. At various points that stash was worth billions of dollars, and because bankruptcy estates exist to return cash to creditors rather than hold a market view, the working assumption was straightforward — sooner or later, most of it would be sold.

That assumption shaped a lot of Solana commentary. Analysts modelled how a multi-billion-dollar unlock schedule might weigh on price, and court filings and distribution timelines were parsed for clues. “The FTX overhang” became shorthand for a risk that any SOL price rally could be capped by an anonymous, motivated seller with a very large bag.

Why it belongs in the past tense

That period is over. The estate wound the position down through 2023–2025 as part of its structured distributions to creditors, and by mid-2025 the bulk of the holding had been sold. The overhang was a real, dated pressure on price during the years it existed — it was not a myth — but it described a specific asset in a specific court process, not a permanent feature of Solana's market structure. Once the estate finished selling, the mechanism that produced the risk stopped operating.

Content that still frames a large FTX-estate SOL position as a live threat is describing a market that no longer exists. It is worth flagging as a factual error rather than a difference of opinion: the estate is not sitting on a fresh multi-billion-dollar stake waiting to be dumped, and there is no comparable single-holder overhang of that size hanging over Solana today. Readers encountering "FTX still holds 41M SOL" style claims in 2026 should treat it as stale information rather than an active risk to price in.

None of this erases the years when the fear was legitimate, and it says nothing about other concentration risks in Solana's holder base. It simply means this particular one has run its course and belongs in the historical record rather than the current risk register.

Conclusion

Put the pieces together and Solana reads as a network that is measurably more reliable than its reputation suggests, without having earned the right to be called solved. The outage record has genuinely improved — no confirmed full halt since February 2024 — but a streak is evidence of progress, not a guarantee against the next novel bug. Client diversity is maturing rather than mature: Firedancer is live in production, yet the majority of stake still runs Agave-lineage software, so a shared-codebase fault remains plausible today.

Much of the network's most frenetic activity still concentrates in speculative memecoin trading, which flatters usage figures without saying much about durable demand. The honest trade-off is between a chain that is fast, cheap and improving on reliability, and one whose worst failures are recent and whose safety net — genuine client diversity — is real but not yet dominant. Neither the booster's “fixed” nor the critic's “broken” survives contact with the dated record.

Which path that suits depends on the reader. If you mainly want exposure to SOL, the live risks that bear on you are reliability and regulation, both of which have improved but neither of which is closed. If you intend to stake, the absence of live slashing removes one fear, but validator choice, commission and — for liquid staking — contract soundness do the real work. If you build, the fee and MEV mechanics are the day-to-day reality, not the headline outage count.

The forward-looking piece is Alpenglow, the consensus redesign proposed by Anza. It has been approved by roughly a 98 per cent governance vote, a strong mandate, but it is not yet live and is moving through a phased pre-activation — so its headline latency numbers describe what it is designed to achieve, not what the network delivers today. Read the whole picture as a trajectory worth watching rather than a verdict to bank, and keep checking the live status over any dated snapshot. For the architecture that produces these trade-offs, see the Solana complete guide; to weigh Solana's yield and slashing model against Ethereum's, see the Solana versus Ethereum staking comparison.

Sources

• Solana network status — uptime and incident history: the live dashboard behind the outage record and the no-confirmed-halt streak since 6 February 2024, to be checked rather than quoted from a snapshot.
• Anza — 6 February 2024 mainnet-beta outage post-mortem: core-developer root-cause writeup of the most recent confirmed full halt and the software fix that followed.
• Anza — SIMD-0212: Slashing on Solana: the proposal-stage record confirming that protocol-level slashing is not yet live, which is why staked SOL cannot currently be seized for validator faults.
• Solana docs — transaction fees: protocol documentation for the fixed 5,000-lamport base fee, the 50% burn, and the compute-unit priority-fee formula behind the fees-under-load section.
• US SEC — June 2023 complaint naming SOL: the primary litigation record for the unregistered-security allegation that was later unwound without any court ruling on SOL's status.

Frequently asked questions

Does Solana still go offline, and when was the last outage?

Solana has a documented history of full-network halts, but they have become rarer. The last officially confirmed full halt was on 6 February 2024 (around five hours). Since then there has been no officially confirmed full network halt — check status.solana.com for the live, current figure rather than trusting a static number here. The reduction follows deliberate hardening: QUIC transport, stake-weighted quality of service, and local fee markets that contain demand spikes. That is genuine progress, not a guarantee. The honest framing is ongoing hardening of a network that has halted before, not a problem that is permanently "fixed".

Can you lose your staked SOL to slashing?

As of July 2026, Solana has no live protocol-level slashing, so a delegator's staked SOL cannot be seized for validator misbehaviour. That removes one tail risk that exists on some other proof-of-stake networks. Staking is still not risk-free, though. Validator downtime lowers your rewards, commission rates vary between validators and can change, and if you stake through a liquid-staking token you take on that protocol's smart-contract risk on top. So the specific "your stake gets slashed" fear does not apply here today, but treating staked SOL as entirely risk-free would be a mistake — the risks are just of a different, softer kind.

What actually caused Solana's past outages?

The causes vary, which is itself informative. The December 2020 halt came from a block-propagation (Turbine) bug. September 2021 was a bot transaction flood during the Grape IDO. In 2022 there were three: bot spam during an NFT mint (May), a durable-nonce consensus bug (June), and a fork-choice bug (September). February 2023 stemmed from an oversized-block bug, and February 2024 from another bug in the client software. Broadly, they split into two families: load-driven congestion from bot activity, and consensus or client software bugs. Several were exactly the single-codebase failures that client diversity is meant to reduce.

Are Solana fees really that cheap, even during congestion?

Mostly, but with an important caveat. The base fee is fixed at 5,000 lamports per signature (half of which is burned), which is genuinely cheap. On top of that you can add an optional priority fee — a compute-unit price bid — that goes to the validator and competes within scoped local fee markets. When demand for one hot program spikes, priority fees for that program rise, and a transaction can fail to land without a high enough bid. So congestion is real, but it is localised to the busy program rather than pricing out the whole network. Any specific average-cost figure is dated and should be checked against current conditions.

Did the SEC rule that SOL is a security?

No court ruled that. In its June 2023 complaints against Binance and Coinbase, the SEC alleged that SOL was an unregistered security. That was an allegation in a civil complaint, not a judicial finding, and it was never adjudicated by a court on the merits. The relevant proceedings were unwound during 2025. The accurate way to describe this is procedural: a claim was made and later dropped. It is wrong to say "a court ruled SOL a security", and equally wrong to say SOL has been "permanently cleared" — neither reflects what actually happened, which is an unresolved allegation that was withdrawn.

Is the FTX estate's SOL still a risk to the price?

This is now a historical, resolved matter rather than a live structural risk. The FTX estate held roughly 41 million SOL, and between 2023 and 2025 the market treated it as an overhang — a large position that could weigh on price if sold. The estate sold that position down by mid-2025. So the specific "FTX dumping SOL" concern that shaped sentiment for a couple of years no longer applies. It is worth understanding as context for past price behaviour, but it should not appear on a current risk checklist as though the overhang were still in place.

Is Solana still a single-client network or single point of failure?

Less so than before, but the risk is narrowing rather than resolved. For most of its history Solana effectively ran one production client family (Agave, the Solana-Labs lineage), meaning a single bug could halt the whole network — and several past outages were exactly that. Firedancer, an independent client from Jump Crypto, reached full mainnet on 12 December 2025, but as of mid-2026 it secures only around 14% of stake. The Frankendancer hybrid runs roughly a quarter, and the majority of stake still runs Agave-lineage clients (Agave and Jito-Solana). Meaningful client diversity is arriving, but a shared-codebase failure remains plausible today.

Financial Disclaimer

This content is not financial advice. All information provided is for educational purposes only. Cryptocurrency investments carry significant investment risk, and past performance does not guarantee future results. Always do your own research and consult a qualified financial advisor before making investment decisions.