When a network brags about throughput, it’s really bragging about how much chaos it can swallow before it chokes. That’s why the most interesting part of Solana’s latest “stress test” is that there’s no story at all.
A delivery network called Pipe published data that put a recent barrage against Solana at roughly 6 terabits per second, and Solana’s co-founders backed the broad thrust of it in public posts. If the number is right, it’s the kind of traffic volume usually reserved for the internet’s biggest targets, the sort of thing Cloudflare writes long blog posts about because it isn’t supposed to be normal.
And yet Solana kept producing blocks. There was no coordinated restart or validator-wide group chat turning into a late-night disaster movie.
CryptoSlate’s own reporting on the incident said block production remained steady and confirmations kept moving, with no meaningful jump in user fees. There was even a counterpoint tucked into the chatter: SolanaFloor noted that an Anza contributor argued the 6 Tbps number was a short peak burst rather than a constant week-long wall of traffic, which matters because “peak” can be both true and slightly theatrical.
That kind of nuance is fine. In real-world denial-of-service, the peak is often the point, because a short punch can still knock over a system tuned for a steady state.
Cloudflare’s threat reporting points out how many large attacks end quickly, sometimes too quickly for humans to react, which is why modern defense is supposed to be automatic. Solana’s latest incident now shows a network that learned how to make spam boring.
What kind of attack was this, and what do attackers actually want?
A DDoS is the internet’s crudest but most effective weapon: overwhelm a target’s normal traffic by flooding it with junk traffic from many machines at once. Cloudflare’s definition is blunt; it’s a malicious attempt to disrupt normal traffic by overwhelming the target or nearby infrastructure with a flood of internet traffic, typically sourced from compromised systems.
That’s the web2 version, and it’s the version Pipe is gesturing at with a terabits-per-second chart. Crypto networks add a second, more crypto-native flavor on top: spam that isn’t “junk packets at a website” so much as “endless transactions at a chain,” often because there’s money on the other side of congestion.
Solana’s own outage history is like a handbook for that incentive problem. In September 2021, the chain went offline for more than 17 hours, and Solana’s early postmortem framed the flood of bot-driven transactions as, in effect, a denial-of-service event tied to a Raydium-hosted IDO.
In April 2022, Solana’s official outage report described an even more intense wall of inbound transactions, 6 million per second, with individual nodes seeing more than 100 Gbps. The report said there was no evidence of a classic denial-of-service campaign, and that the fingerprints looked like bots trying to win an NFT mint where the first caller gets the prize.
The network stopped producing blocks that day and had to coordinate a restart.
So what do attackers want, besides attention and the joy of ruining everyone’s Sunday? Sometimes it’s straightforward extortion: pay us, or we keep the firehose on.
Sometimes it’s reputational damage, because a chain that can’t stay live can’t credibly host the kind of apps people want to build. Sometimes it’s market gamesmanship, where broken UX creates odd pricing, delayed liquidations, and forced reroutes that reward people positioned for disorder.
In the on-chain spam version, the goal can be direct: win the mint, win the trade, win the liquidation, win the block space.
What’s different now is that Solana has built more ways to refuse the invitation.
The design changes that kept Solana running
Solana became better at staying online by changing where the pain shows up. In 2022, failures had a familiar shape: too many inbound requests, too much node-level resource strain, too little ability to slow bad actors, and knock-on effects that turned congestion into liveness problems.
The upgrades that matter most sit at the edge of the network, where traffic hits validators and leaders. One is the transition to QUIC for network communication, which Solana later listed as part of its stability work, alongside local fee markets and stake-weighted quality of service.
QUIC isn’t magic, but it’s built for controlled, multiplexed connections rather than the older connection patterns that make abuse cheap.
More importantly, Solana’s validator-side documentation describes how QUIC is used inside the Transaction Processing Unit path: limits on concurrent QUIC connections per client identity, limits on concurrent streams per connection, and limits that scale with the sender’s stake. It also describes packets-per-second rate limiting applied based on stake, and notes the server can drop streams with a throttling code, with clients expected to back off.
That turns “spam” into “spam that gets shoved into the slow lane.” It’s no longer enough to have bandwidth and a botnet, because now you need privileged access to leader capacity, or you’re competing for a narrower slice of it.
Solana’s developer guide for stake-weighted QoS spells this out: with the feature enabled, a validator holding 1% of stake has the right to transmit up to 1% of the packets to the leader. That stops low-stake senders from flooding out everyone else and raises Sybil resistance.
In other words, stake becomes a kind of bandwidth claim, not just voting weight.
Then there’s the fee side, which is where Solana tries to avoid “one noisy app ruins the whole city.” Local fee markets and priority fees give users a way to compete for execution without turning every busy moment into a chain-wide auction.
Solana’s fee documentation explains how priority fees work through compute units, with users able to set a compute unit limit and an optional compute unit price, which acts like a tip to encourage prioritization. It also notes a practical gotcha: the priority fee is based on the requested compute unit limit, not the compute actually used, so sloppy settings can mean paying for unused headroom.
That prices computationally heavy behavior and gives the network a knob to make abuse more expensive where it hurts.
Put those pieces together, and you get a different failure mode. Instead of a flood of inbound noise pushing nodes into memory death spirals, the network has more ways to throttle, prioritize, and contain.
Solana itself, looking back at the 2022 era, framed QUIC, local fee markets, and stake-weighted QoS as concrete steps taken to keep reliability from being sacrificed for speed.
That’s why a terabit-scale weekend can pass without real repercussions: the chain has more automatic “no’s” at the front door and more ways to keep the line moving for users who aren’t trying to break it.
None of this means Solana is immune to ugly days. Even people cheering the 6 Tbps anecdote argue about what the number means and how long it lasted, which is a polite way of saying internet measurements are messy and bragging rights don’t come with an audit report.
And the trade-offs don’t vanish. A system that ties better traffic treatment to stake is, by design, friendlier to well-capitalized operators than hobbyist validators. A system that stays fast under load can still become a venue for bots that are willing to pay.
Still, the fact that the network was quiet matters. Solana’s earlier outages weren’t “people noticed a little latency.” Block production ceased completely, followed by public restarts and long coordination windows, including the April 2022 halt that took hours to resolve.
In contrast, this week’s story is that the chain remained live while traffic allegedly hit a scale more at home in Cloudflare’s threat reports than in crypto lore.
Solana is behaving like a network that expects to be attacked and has decided the attacker should be the one who gets tired first.
The post How Solana neutralized a 6 Tbps attack using a specific traffic-shaping protocol that makes spam impossible to scale appeared first on CryptoSlate.
