Abandoned DeFi protocol leaves zombie smart contracts

Zombie smart contract: Survival and risk of legacy code on the chain

Zombie smart contract refers to contract code that the project team has abandoned or stopped maintaining, but can still run on the chain, hold funds, accept calls, or execute logic. Public deprecation notices or closing the front-end interface will not disable the contract itself. Bytecode remains active at its address, and the interaction continues as long as the caller provides valid input.

In the DeFi space, this leads to the long-term retention of a large number of abandoned contracts that retain economic value and callable entry points on the chain. Attackers probe these endpoints, and bots or unsuspecting users may interact with legacy addresses. Since Ethereum contracts are immutable by default, and their behavior can only be changed through explicit upgrade design, the risk persists.

If the upgrade path or administrator rights are removed or waived, the team may not be able to suspend, patch, or deactivate legacy contracts. This limitation stems from Ethereum's immutable model and the proxy/UUPS/diamond model's reliance on the administrator role.

How zombie smart contracts persist on the chain

Ethereum smart contracts cannot be changed once deployed. Any ability to change behavior must be explicitly designed through patterns such as proxy, UUPS, or diamond that delegate calls to scalable logic. These patterns rely on administrator keys or governance roles. If these roles are misconfigured, leaked, or abandoned, even if the team has publicly abandoned the contract, it may lose the ability to repair or completely deactivate the contract. Abandoning a product or shutting down a website will not affect the bytecode on the chain. The address is still callable, and any residual state or value will persist. Attackers can interact directly through transactions, while integrators still point to legacy addresses may inadvertently direct users to deprecated logic. The zombie contract phenomenon has been observed for many years in academic and empirical research.

How deprecation translates into an attack surface

The risks after deprecation are not theoretical. It stems from several practical mechanisms discovered in event analysis:

Real-time entry points: Even if the project declares deprecation, functions can still be called, making useful actions open to attackers. Residual value: Immutable contracts may still hold funds or liquidity provider positions, making them a honeypot for targeted use or state manipulation. Wrong assumptions about administrators/off-chain participants: If the contract expects operators, repeaters, or sorters to operate in a specific way, these assumptions may fail once the team scales back operations or removes keys. Architectural boundaries: Mismatches between off-chain proof and on-chain settlement boundaries can be exploited without breaking cryptography. The industry summary pointed out that there were multiple fund theft incidents across the chain between 2025 and 2026, which were characterized as operational and lifecycle risks rather than a single vulnerability category.

Case: Aztec Connect's deprecated contract RollupProcessorV3

In June 2026, the deprecated contract RollupProcessorV3 used by Aztec Connect was stolen of approximately US$2.1 - 2.3 million. Analysis pointed out that this is a bypass of the settlement boundary on the abandonment path, rather than a new cryptographic breakthrough. The key is that the contract remains active and callable at its address after retirement. The conclusion is operational: abandoning a product will not deactivate its on-chain contracts. Unless entry points are disabled or funds are migrated, residual value and callable logic can lead to targeted exploitation.

Who is at risk when the agreement is deactivated

End users holding residual balances: Funds left in vaults, pools, or escrow contracts may be locked out or exposed to new attack paths. Integrators and aggregators: Routers or front-ends that still reference legacy addresses may continue to send transactions to deprecated logic. Agreement teams and DAOs: If the administrator role has been waived to indicate decentralization, the team may not be able to pause or patch legacy code when new risks arise. Auditors and monitors: Tools often focus on active deployments and have blind spots for addresses that hold value but have been deprecated.

Disable operating manuals that teams can follow

The best way to prevent zombie contracts is through life cycle planning. Industry guidelines emphasize planning for migrations, using multi-signature management, and implementing a security model. Practical operating manuals are as follows:

Comprehensive inventory. Lists all deployed addresses, upgrade agents, administrator roles, guardians, authorized participants, and dependent services. Publish a deactivation plan. Communicate a clear timetable and specific addresses involved. Provide users with withdrawal windows and repeated reminders. Enable withdrawal only or pause mode if supported by the code. Preference should be given to controllable states that allow exits but prevent new deposits, loans, or complex operations. Clear the residual funds controlled by the reason agreement. Migrate treasury funds and release LP positions in contracts owned by administrators. Revoke authorizations and roles. Remove operator keys, disable repeaters and tighten access control lists in stages and on record. Complete the upgrade path. If an agent is used and upgrades are still feasible, point-to-minimization logic will be implemented, allowing only withdrawals and preventing status changes at entry points. Strengthen management. Transfer any remaining rights to a well-governed multi-signature wallet with clear signers and published policies. Disable off-chain dependencies. Turn off guardians and automation, archive the front-end interface, and record that legacy addresses are deprecated and no longer supported. Monitor and protect tail risks. Maintain alerts, bounty or insurance coverage for some time after deactivation to catch unexpected calls or inflows of funds to old addresses. Complete the closed loop. Publish post-retirement reports with final status and browser links so that users and integrators can verify results on-chain.

Limitations and misunderstandings to be noted

Immutability is a double-edged sword. If the administrator key is abandoned or an upgrade path never exists, the team will not be able to add a pause or withdrawal pattern later. Disuse is not a termination switch. Announcing or shutting down the UI does not make the contract safe or invalid. Audits will become obsolete. Code that has passed censorship may become risky when off-chain participants disappear, economic conditions change, or assumptions no longer hold true. Not all agents are the same. A poorly designed upgrade path can leave unexpected callable paths or storage conflicts, complicating decommissioning. Residual funds attract attention. Even if a small balance in the address has been deprecated, it may trigger a targeted attack.

Where will you encounter a zombie contract in practice

Readers are most likely to encounter a zombie contract when following the tutorial or aggregator guidelines and using an old address from a migrated protocol. You see multiple versions of the same pool, vault, or router on the Block Explorer, and it's unclear which version is the current version. After the front-end goes offline, interact directly through the contract address. I don't know that the function has been deprecated but not disabled. Holding assets after the agreement is announced to be suspended, although there is a withdrawal window, there are no measures on the chain to prevent subsequent risk interactions. Before touching legacy addresses, please check the agent model and current implementation, confirm the administrator role or suspended status, read the latest announcements, and verify that your actions are consistent with the latest migration path of the protocol.

Frequently Asked Questions

How to determine whether a contract has been abandoned or is still active? Check recent on-chain activities, governance or developer announcements, and whether the project lists the address as its current address. Check if the contract is behind the agent and if the implementation has been recently updated. If the administrator role has been abandoned and there is no upgrade path, maintenance options will be limited.

Does giving up the administrator key make the protocol more secure? This reduces certain governance risks, but also eliminates the ability to suspend, patch, or deactivate defective or obsolete contracts. This trade-off stems from Ethereum's immutable and scalable model.

If the contract has been deprecated, is it safe to continue using it? Not safe. Disrupting notifications and shutting down the UI will not disable on-chain code. Contracts can still be invoked and funds can be held.

Are zombie contracts just an issue for Ethereum? No. This pattern can appear on any chain with immutable or semi-immutable smart contracts. 2025-2026 During the year 2000, many incidents of fund theft against abandoned or legacy contracts have been observed across the chain.

What should the integrator do when a dependency is deprecated? Repoint to the new address, remove or block paths to deprecated logic, and conduct targeted integration reviews. Consider adding circuit breakers, stricter license lists and deprecation warnings to prevent users from accidentally interacting with zombie endpoints.