Guide · facts checked Oct 25, 2026

Monitor an upgradeable proxy contract

An upgradeable proxy can get entirely new code in one transaction. Users audited, or at least trusted, the code behind it. A silent upgrade replaces that code, and an attacker who gets the upgrade key does not need a bug at all.

Upgrade monitoring answers three questions: did the code change, who can change it, and can we hear about a change before it lands.

Address

Which address to add

Add the proxy address, not the implementation. The proxy holds the state and the funds, and it is the contract that emits the upgrade events. The implementation address changes with every upgrade.

For verified proxies, SmartAlert recognises the ERC-1967 pattern and offers the upgrade template automatically.

Depending on the pattern, add one or two more addresses:

Transparent proxy
Who can upgrade
The owner of a separate ProxyAdmin contract
Also add
The ProxyAdmin contract, to alert on OwnershipTransferred
UUPS
Who can upgrade
Whoever passes the check in the implementation, usually an owner or a role
Also add
Nothing extra: watch OwnershipTransferred or RoleGranted on the proxy itself
Upgrade through a multisig
Who can upgrade
The Safe signers
Also add
The Safe, to alert on owner and threshold changes
Upgrade through a timelock
Who can upgrade
Whoever can schedule on the timelock
Also add
The TimelockController, to alert on CallScheduled
Alerts

The alerts

Watch
Upgraded(implementation) on the proxy
Fire when
Any event
Severity
Critical
Proxy admin changed
Watch
AdminChanged(previousAdmin, newAdmin) on the proxy
Fire when
Any event
Severity
Critical
Watch
OwnershipTransferred on the proxy or the ProxyAdmin
Fire when
Any event
Severity
Critical
Watch
RoleGranted, RoleRevoked
Fire when
Any event
Severity
Critical
Watch
AddedOwner, RemovedOwner, ChangedThreshold on the Safe
Fire when
Any event
Severity
Critical

The upgrade alert names the new implementation address. The admin alert names the new admin. Check them against what your team planned to deploy.

These are "any event" rules, not thresholds. In a normal month, upgrades are rare and planned, so every one is worth a message. The check on history before you enable the rule shows how many upgrades the contract really had in the last 30 days.

Timelock

Hear about the upgrade before it executes

If upgrades go through an OpenZeppelin TimelockController, the upgrade is announced first and executed after the delay. Add the timelock address and alert on CallScheduled: the alert comes when the upgrade is queued, hours or days before the code changes. That is the window in which users can exit and the team can cancel with Cancelled.

Without a timelock, the Upgraded alert comes after the fact. It still matters: the sooner the team knows, the sooner it can pause or warn users.

Honestly

Limits

  • SmartAlert watches events and view functions. A proxy that changes its implementation slot without emitting Upgraded is non-standard; the alert will not see it.
  • An unverified proxy has no ABI. Upload the ABI by hand or the template will not be offered.
  • Alerts tell you fast. They do not undo an upgrade. Undoing it needs a pause or an admin action, planned in advance.
FAQ

FAQ

I added the implementation and see no events. Why?

Events are emitted by the proxy. Add the proxy address instead.

Do I need to change the contract?

No. Everything here reads public events. No redeploy, no code.

Which networks?

Ethereum, BNB Chain, Base and Arbitrum.

Try it on your own contract

An address is enough. The first 14 days get Pro limits, and rules are checked on history before they go live.