What Fields to Monitor in Contract Upgrade Events

When monitoring upgrade events for proxy contracts, focus on four core fields: the new implementation address (implementation), the old implementation address (previousImplementation), the upgrader (upgrader/triggeredBy), and the transaction hash (transactionHash). These four fields tell you "who replaced the contract logic with what and when." In March 2026, Etherscan launched a "Historical Proxy" tab specifically designed to aggregate this information.

Step 1: Identify the standardized upgrade event format — EIP-1967

What to do: Determine which upgrade standard the contract follows so you know which events to capture.

How to do it:

• Most proxy contracts follow the EIP-1967 standard, uniformly emitting an Upgraded(address indexed implementation) event.

• Transparent Proxy contracts also emit an AdminChanged(address previousAdmin, address newAdmin) event, recording admin changes. If the admin changes, someone may use the new admin privileges to perform an upgrade later.

• If the project uses the Beacon proxy pattern, the event is BeaconUpgraded(address indexed beacon), which records the beacon address change, not the implementation address itself.

When you're done: You have confirmed the proxy type of the target contract (Transparent Proxy / Beacon Proxy / others) and know which event to monitor.

Step 2: Monitor the four core fields of upgrade events

What to do: Extract and record key fields from upgrade event logs.

How to do it: The following four fields from an upgrade event must be recorded and analyzed:

Range Docs lists rules for proxy upgrade monitoring: trigger on detecting an ERC-1967 proxy upgrade event, recording the new implementation code pointed to by the proxy.

When you're done: You can accurately extract these four fields from a single upgrade event.

Key Reminder: The Upgraded event includes only the "new address", not the "old address". To get the old address, you need to look back at the proxy contract's implementation() storage slot, or record a state snapshot before the event. Some advanced monitoring systems read the storage slot before and after the upgrade to compare.

Step 3: Use Etherscan's "Historical Proxy" feature for bulk viewing

What to do: In March 2026, Etherscan launched a new feature that lets you directly view the complete upgrade history of a proxy contract without manually browsing logs.

How to do it:

• Open the detail page of the target proxy contract on Etherscan.

• Find the new "Historical Proxy" tab and click into it.

• The page automatically summarizes all upgrade records for that contract, including the implementation address and transaction hash for each upgrade.

• Etherscan already supports automatic proxy contract identification, so manual confirmation is usually not needed.

When you're done: You have obtained the complete upgrade history list for the contract from Etherscan's summary view.

Step 4: Monitor Admin changes as an early warning

What to do: The prerequisite for an upgrade is a change in admin privileges. Monitoring admin address changes can detect risk earlier than monitoring the upgrade itself.

How to do it:

• The AdminChanged event of a Transparent Proxy records who the admin changed from and to.

• If the admin address changes from a multi-sig wallet to a regular EOA, or to 0x00..., that's a high-risk signal.

• For ProxyAdmin contracts, you need to monitor the OwnershipTransferred event, which records who has the right to call the upgrade method.

• Range Docs also lists "proxy admin change" as an independent monitoring rule, equally important as "proxy upgrade".

When you're done: You have confirmed the current admin address and established a monitoring rule for admin changes.

Prerequisites

Before you start monitoring, make sure you have the target proxy contract address. If you use Etherscan's "Historical Proxy" feature, no additional tools are needed — just access it via a browser. If you use on-chain monitoring tools (like Range, Dune, etc.), ensure that event listening has been configured for the corresponding chain.

Common Failure Reasons

• Ignoring AdminChanged while only monitoring Upgraded: After the admin changes, the new admin may upgrade at some point. Admin changes are not upgrades themselves but are often a precursor to upgrades, with the same high priority.

• Confusing proxy implementation upgrades with contract parameter changes: Many projects change parameters by calling contract methods, which is different from "upgrading the logic code." Parameter changes do not trigger the Upgraded event and need to be monitored with separate rules.

• Not handling Beacon proxy upgrade logic: The upgrade event for Beacon proxies is BeaconUpgraded, which records the beacon address change, not the implementation address itself. You need to read the current implementation address from the beacon contract afterward.

Risk Reminders

• Fund risk: If contract upgrade events are not monitored in a timely manner, the project party may replace the logic with a malicious version without users' knowledge, leading to asset theft or freezing. Range Docs lists this as one of the "most relevant events for takeovers and rug-pulls."

• Account risk: No direct account risk, but if you are an authorized user of the contract, the upgraded logic may change your permission status.

• Compliance risk: None.

Signs that you have completed this correctly: You have successfully extracted the implementation, transaction_hash, and timestamp from the upgrade event. If using Etherscan's "Historical Proxy" tab, you can see the complete upgrade history list of the contract. Next step: It is advisable to also set up a monitoring rule for admin changes — a new admin changing is more alarming than the upgrade itself, because that's the person controlling the upgrade permission changing.