Event‑Based Detection or Storage‑Slot Check: Choosing a Recovery Path for Failed Proxy Upgrades

Question

Recovery from Failed Proxy UpgradeThe goal is to determine a reliable strategy to detect and recover when a proxy upgrade transaction fails in a web3.js‑driven dApp. The upgrade is performed through a ProxyAdmin contract that writes a new implementation address into the proxy’s EIP‑1967 storage slot. A failed transaction (receipt status 0) leaves the proxy pointing to the old implementation, but the client must confirm this state before continuing operation.Unresolved DecisionTwo documented approaches exist: 1) Event‑Based Detection, where the client listens for the ProxyAdmin’s Upgraded event and treats its absence within a configurable block window as a failure; and 2) Storage‑Slot Verification, where the client explicitly reads the proxy’s storage slot after the transaction to confirm the implementation address has not changed. Each method has trade‑offs regarding node reliability, support for chain reorganizations, and the risk of false positives.Which approach offers stronger guarantees against chain reorganizations that could invalidate a seemingly successful upgrade?What timeout or block‑window should be used when relying on event logs to decide that an upgrade has failed, especially in networks with high latency or censorship risk?How can a dApp combine both mechanisms to provide a fault‑tolerant recovery path without duplicating logic or incurring excessive on‑chain reads?

Siddharth · Answer

Answer
Storage‑slot verification provides the stronger guarantee against chain reorganizations.
Confirmed Facts

The proxy’s implementation address is stored in EIP‑1967 slot 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc.
A transaction receipt with status 0 guarantees the upgrade call reverted, so the proxy still points to the old implementation.
Reading the slot with eth_getStorageAt returns the actual on‑chain state at the queried block.
Event logs (ProxyAdmin Upgraded) are only as final as the block they appear in; a reorg can remove or re‑emit them.

Likely Explanation
Because a reorg can drop the upgrade transaction, the slot will still hold the old address immediately after the reorg, whereas the Upgraded log may disappear, giving a false impression of success. Therefore, verifying the slot after a confirmation depth reflects the true state even if the block containing the transaction is later reverted.
Recommended Combined Recovery Path

Send the upgrade transaction via ProxyAdmin.upgrade and wait for the receipt.
If receipt.status === 0, treat the upgrade as failed; read the implementation slot at the latest confirmed block (see step 4) and continue with the old implementation.
If receipt.status === 1, wait for a confirmation depth of N blocks (e.g., N = 2 on Ethereum mainnet, higher on fast‑reorg chains).
After N blocks, call web3.eth.getStorageAt(proxyAddress, EIP1967_IMPL_SLOT, confirmedBlockNumber) and compare the returned address to the new implementation address.
If the slot matches, the upgrade is considered successful; otherwise, re‑read the slot at 'latest' to verify the current state before deciding to retry or abort.

Missing Diagnostic Detail
To rely on event‑based detection as a fast signal, you must know which contract emits the Upgrade event in your proxy stack (ProxyAdmin vs the proxy itself). Please confirm the emitter contract address so that log filtering can be set up correctly.

Event‑Based Detection or Storage‑Slot Check: Choosing a Recovery Path for Failed Proxy Upgrades

Recovery from Failed Proxy Upgrade

Unresolved Decision

1 answer

Answer

Confirmed Facts

Likely Explanation

Recommended Combined Recovery Path

Missing Diagnostic Detail

Your perspective belongs here.

0 question comments