Raydium $1.34M Exploit: Does It Expose Lingering
Published 6/11/2026, 2:51:31 AM
Yes, this exploit definitively exposes lingering risks in deprecated AMM pool infrastructure. The incident demonstrates that "deprecated" does not equal "secure," and that legacy smart contracts—even when inaccessible via UI—remain persistent attack surfaces.
What Happened
On June 10, 2026, a hacker drained approximately $1.34 million from five deprecated AMM V3 liquidity pools on Raydium. These pools had been phased out in 2021 but remained deployed on-chain with real assets.
| Asset | Amount | Approximate Value |
|---|---|---|
| USDC | ~893,700 | ~$900,000 |
| SOL | ~5,603 | ~$357,000 |
| RAY | ~150,177 | ~$86,000 |
The affected pools were RAY-SOL, USDC-RAY, SRM-RAY, Sollet USDT-RAY, and Sollet ETH-RAY. All had been inaccessible via UI since 2021 but remained callable through direct blockchain interaction.
The Vulnerability Mechanism
The root cause was a self-contained logic flaw in the legacy AMM V3 program's LP mint validation—specifically a failure to properly verify LP token mint addresses. The attacker:
- Created a fraudulent LP token mint with a supply of just 1 unit
- Bypassed intended proportion checks using these fake LP tokens
- Impersonated a legitimate liquidity provider
- Redeemed the fabricated LP tokens for the entire pool balance
This vulnerability existed because the 2021-era AMM V3 code lacked modern security checks, including virtual supply mechanisms that current Raydium programs implement.
Lingering Risks Confirmed
The evidence strongly supports that deprecated AMM pools pose ongoing risks across the industry:
| Risk Factor | Evidence |
|---|---|
| Ghost State | Old programs remain on-chain even after deprecation, creating persistent attack surface |
| Insufficient Validation | Legacy code lacks modern security checks (LP mint verification, proportion checks) |
| Reduced Monitoring | Deprecated pools receive less security scrutiny and on-chain monitoring |
| Orphaned Liquidity | The 2021 deprecation of Serum created orphaned liquidity that remained exploitable |
| UI Inaccessibility ≠ Security | Pools inaccessible via UI since 2021 were still exploitable via direct blockchain calls |
This pattern is not unique to Raydium. Multiple 2026 incidents share similar characteristics—KelpDAO ($300M), Drift Protocol ($300M), and Zcash (counterfeiting vulnerability)—all involved legacy infrastructure vulnerabilities.
Scope of Impact
| Component | Status |
|---|---|
| Current AMM programs | Unaffected |
| Active pools | Unaffected |
| Current users | No impact |
| SDK/DApp integrations | Legacy AMM V3 not supported |
Remediation & Protocol Response
Raydium's response has been comprehensive:
- Treasury compensation: Full reimbursement for affected liquidity providers; no user losses
- Security review: Core contributors conducting review of all mainnet programs
- Architecture improvement: Current V3 CLMM implementation uses virtual supply mechanisms preventing similar LP mint validation bypasses
- Market resilience: RAY token traded up ~2% post-incident; protocol maintains ~$797M TVL with ~$1.1B weekly DEX volume
Conclusion
The Raydium $1.34M exploit clearly exposes genuine lingering risks in deprecated AMM pool infrastructure. The core lesson: UI-layer inaccessibility is not a security measure. The DeFi ecosystem needs systematic strategies for complete deprecation of legacy infrastructure—including potential program disabling or asset migration—rather than relying on deprecated contracts remaining passively on-chain.
What remains open: Whether other deprecated pools across Solana and other ecosystems share similar vulnerabilities, and whether industry-wide standards for legacy contract decommissioning will emerge.
Follow-Up Actions
-
Protocol Security Audit — Given this pattern across 2026 exploits, a systematic review of deprecated contract exposure across your portfolio protocols would quantify residual risk.
-
On-Chain Monitoring Setup — Configure alerts for interactions with legacy/deprecated contract addresses to detect potential exploit activity early (the attacker used address
4WnPebowR4HHfumvNPaDjG6Pa5Hi1jxLm6xmmBq33QVk).