How to Confirm Whether a Contract Can Still Be Upgraded

The most critical step in confirming whether a contract can be upgraded is to see whether it carries a "Proxy" label on a block explorer such as Etherscan. If a contract is a proxy contract and its upgradeTo or upgrade function has not been removed or disabled, then theoretically it can still be upgraded.

Below we introduce several investigation methods, from simple block explorer operations to deeper code analysis. You can follow them in order depending on the information you have at hand.

Prerequisites

Before you start, first determine what kind of contract information you have:

• You have the contract address: You can look it up directly on a block explorer (such as Etherscan). Most of the investigation steps are based on this.

• You have the contract source code: You can check whether the code contains upgrade‑related functions or modifiers.

Step‑by‑Step Instructions

Step 1: Check whether a "Proxy" label appears on the block explorer

This is the most direct and commonly used method. Taking Etherscan as an example, starting from March 2026 the explorer can automatically recognize most proxy contracts and supports viewing historical upgrade records.

1. Enter the contract address in the Etherscan search box and go to the contract details page.

2. Look at the tabs at the top of the page:

   • Case A: The page shows Read as Proxy or Write as Proxy tabs — this indicates it is a proxy contract and very likely retains the ability to be upgraded.

   • Case B: An "Is this a proxy?" button appears at the bottom of the page — this means the explorer may not have recognized it automatically yet; you can click this button to let the system verify. After a successful verification, the page usually refreshes and displays the "as Proxy" tab.

3. Check the upgrade history: If it is confirmed to be a proxy contract, click the Historical Proxy tab on the page. This lists all historical implementation contract addresses that the proxy has pointed to, as well as the corresponding upgrade transaction records. If upgrade records exist, it is clear proof that the contract has upgrade capability.

What counts as complete: You can see tabs such as Read as Proxy on the contract page, and the Historical Proxy page shows at least one upgrade record, or the page explicitly identifies the contract as a proxy contract.

Step 2: Check the contract source code for upgrade functions (advanced)

If the block explorer did not automatically recognize the proxy but you can obtain the contract's source code, you can confirm directly at the code level.

1. Search the contract code for keywords such as upgradeTo, upgradeToAndCall, or upgrade. These are the core functions that perform upgrade operations.

2. Check whether these functions have access control (for example onlyOwner, onlyAdmin, or onlyRole modifiers). The existence of these functions means the contract has upgrade capability, while the presence of access control indicates that upgrading requires specific permissions.

3. Check whether the contract inherits official upgradeable contract templates from OpenZeppelin such as UUPSUpgradeable or TransparentUpgradeableProxy. If it does, then it can definitely be upgraded.

What counts as complete: You found upgrade functions in the source code and understand what permissions are required to trigger an upgrade.

Step 3: Analyze the proxy pattern (only when the above methods are ineffective)

In rare cases, a contract may use a non‑standard proxy pattern, causing the usual methods to fail. In such situations you can turn to specialized detection tools, such as the UPC Sentinel algorithm proposed in academic research, which can detect multiple proxy patterns — including inactive contracts — through static bytecode analysis. For regular users, mastering the first two steps is usually sufficient.

Common Causes and Risk Reminders

• The contract is not a proxy pattern: If it is just an ordinary, non‑upgradeable contract, you will not see a "Proxy" label on any page, and there will be no upgrade functions in the code.

• Upgrade permissions are locked: Even if upgrade functions exist, if their permissions are restricted to a special address (such as a multi‑sig wallet or a burn address), then ordinary users or developers cannot perform an upgrade.

• Risks of proxy pattern upgrades: The upgrade feature of a proxy contract is a developer's "back door." While it brings flexibility, it also introduces security risks — if the permissions fall into an attacker's hands, the entire contract logic can be replaced.

How to Confirm That You Have Correctly Completed the Check

Regardless of which method you use, to finally confirm that a contract can still be upgraded, two conditions must be met at the same time:

1. Technical aspect: It is identified as a proxy contract, or its code contains callable upgrade functions.

2. Permission aspect: The right to call the upgrade function is held by an active address or by a multi‑sig wallet controlled by multiple parties.

You can enter the contract address into Etherscan. If it automatically displays "Proxy" information and you can see upgrade history on the Historical Proxy page, then you can confirm that it is an upgradeable contract.