Taking contracts offline is not just a matter of documentation; it is an essential part of security control.
Written by: Gino Matos
Compiled by: Luffy, Foresight News
TL;DR:
- Hackers stole approximately $1.34 million from Raydium’s long-discontinued V3 automated market maker pool.
- This incident exposes a common problem: old contracts of DeFi projects that have been decommissioned are still running normally on the chain. These forgotten underlying facilities have become easy targets for attacks.
- Public reports indicate that since March 2025, there have been at least eight similar cases of old contracts being stolen in the industry, meaning that a large amount of old code remains unattended and can still be accessed externally.
Recently, a vulnerability in Raydium AMM V3 caused a loss of $1.34 million. The project was related to five pools outside the current product system. These pools were not supported by Raydium's UI or SDK and were inaccessible to ordinary users, but were ultimately exploited by hackers.
This attack targeted outdated contracts and underlying infrastructure that were neglected in the industry, exposing a major vulnerability in the full lifecycle management of smart contracts. Such problems are not limited to this one decentralized exchange in the Solana ecosystem.
Neglected risk categories
According to publicly available security incident reports, since March 2025, there have been at least eight cases of attacks caused by obsolete, outdated, or obsolete contracts, with a total loss of approximately US$10.8 million.
If security incidents caused by outdated fund pools and old-version supporting products are included in the statistics, the number of related incidents reaches 10 (including the Raydium theft this time), with a total loss of approximately US$22.5 million.
Currently, most security incident tracking platforms in the industry classify attack types according to their technical causes. Common classifications include: smart contract code vulnerabilities, access control failures, oracle tampering, private key leaks, and cross-chain bridge defects.
Zombie contracts (i.e. old contracts that a project has announced are no longer in use, but can still be called normally on the blockchain) belong to a completely different risk dimension. They are security incidents caused by problems in contract lifecycle management, but they are always buried in the statistics of various conventional vulnerabilities and are not classified separately.
The reason why Raydium's V3 Automated Market Maker liquidity pool was abandoned is that the Serum project it relied on was officially shut down, causing this old contract to completely lose its original function, and the corresponding liquidity assets have been idle on the chain.
Raydium's current new contract uses a dual verification mechanism to check two key pieces of information: first, it verifies the asset percentage through a total supply verification mechanism, and second, it verifies the minting address of liquidity tokens and various associated account information.
However, this outdated V3 contract completely omits these two verification processes. Hackers exploited this vulnerability to forge new liquidity tokens and impersonate legitimate credentials, directly bypassing all risk control rules.
In this incident, a total of approximately 150,177 RAY, 5,603 SOL, and 893,700 USDC were stolen. These assets had been stored in the platform's old liquidity pool for a long time. Although they were no longer part of the mainstream business, their on-chain access permissions were never closed.
Eight cases expose common problems
Since 2025, several well-known DeFi projects have stumbled on old contracts. All of these incidents share the same characteristics: the project team claims that the current version of the product and active users are unaffected, but because the old contracts were not completely shut down, the project's treasury ultimately bears all the losses.
Why are the risks of old contracts overlooked?
Currently, most security incident classification systems in the industry focus on attack methods, tampered targets, and code failures, which is an analytical perspective that "starts from technical vulnerabilities." This has led to the concealment of zombie contract incidents. The core of these problems is never a coding error, but rather that the project should have completely shut down the old contracts, but failed to do so.
A 2025 industry research paper analyzed 50 major global crypto security incidents between 2022 and 2025, with cumulative losses exceeding $1 billion. The study pointed out that high-risk on-chain attacks are often the result of a chain of risks, involving multiple levels including human operation, daily maintenance, economic models, contract lifecycles, and community governance.
The paper proposes a four-layer root cause analysis framework, explicitly classifying contract lifecycle management vulnerabilities, community governance vulnerabilities, and code writing vulnerabilities as independent risk categories. The zombie contract problem is a typical lifecycle management vulnerability. However, in the existing security statistics system, such incidents are all categorized as "code vulnerabilities," and the corresponding loss data is obscured by other classifications, failing to attract sufficient attention from the industry.
Beware of "contract graveyards": Outdated facilities have become new hotspots for attacks.
If DeFi projects consistently treat "contract shutdown" as a trivial matter, merely noting "this contract is deactivated" in their product documentation without transferring idle assets, disabling call functions, or continuously monitoring the status, then hackers will continue to target this "contract graveyard."
The historical deployment records of every large DeFi project have now become searchable and exploitable targets for hackers. The currently estimated $22.5 million in losses only represents publicly disclosed cases; the true risk is far higher.
Those outdated fund pools, historical authorized interfaces, and early cooperation modules that contain assets but are detached from the mainstream user process are subject to far less operational and monitoring efforts than the current business systems, making them prime targets for hackers.
To change the current situation, firstly, "zombie contracts" should be classified as an independent risk category and their incidents should be statistically analyzed separately; secondly, the contract decommissioning process should be incorporated into standardized security procedures and given equal importance to code auditing. Only by implementing comprehensive lifecycle maintenance can the attack scope be effectively reduced.
The current handling methods in the industry are largely similar. Raydium used its project treasury to pay out $1.34 million in losses, while Transit Finance and Huma Finance also had their project teams bear the user losses.
This also means that taking contracts offline is no longer just a documentation task, but an essential security control step.
Seven security control standards for contract decommissioning
For the closure of old contracts, the industry can establish standardized management and control procedures, the specific requirements and functions of which are as follows:
Simply marking the contract as "discontinued" in the documentation only shifts the security risk to the project's vault; the vulnerability to attack remains. Only announcing its decommissioning at the product level, without completely shutting it down technically, allows old contracts to remain accessible: the project team is negligent in its oversight, while hackers are always lurking.
The value of DeFi projects lies not only in their current asset lock-up size, but also in their historical code and underlying architecture. This forgotten history has now become a new security vulnerability.
