Upgradeability is where protocols quietly die

Everyone markets the audit of v1.

Incidents often come from v1.4, shipped on a Friday, by a Safe that still has a developer EOA from testnet.

Upgradeability is not automatically wrong. Unexamined upgradeability is how otherwise competent teams lose years of work without a single novel Solidity bug.

This note is for founders, protocol security leads, and anyone writing an RFP who still treats “UUPS + Timelock” as a checkbox.

The uncomfortable baseline

In 2026 most serious systems are upgradeable somewhere:

• Proxy implementations
• Parameter setters
• Module registries
• Bridge validators / guardian sets
• Offchain keepers that effectively change economic behavior

If your threat model stops at “can an attacker reenter withdraw?”, you are protecting last year’s story.

Where designs actually break

### 1. The timelock that is not in the path

Diagrams show: proposal → timelock → upgrade.

Production often has a second path: UPGRADER_ROLE still on a Safe, or an emergency pause that can also swap implementations, or a factory that deploys new “instances” without touching the timelocked proxy.

We ask one question early: list every call that can change code, parameters, or who can change either. Then we match that list to chain state. Gaps between the two are where “we thought it was timelocked” lives.

### 2. Governance that cannot actually govern

Token voting looks decentralized until you notice:

• Quorum is unreachable under normal turnout, so a small active set always wins
• The same team runs the proposer Safe and the largest delegate cluster
• Emergency powers can cancel the timelock or execute with a shorter delay

That is not a moral judgment. It is a blast-radius number. If five people can ship bytecode next week, write that down. Auditors and users deserve the same sentence.

### 3. Storage and initialization debt

Upgrade bugs are boring and lethal:

• Uninitialized implementations
• Storage layout collisions after a “small” refactor
• Initializers that can be front-run on new proxies
• Missing disableInitializers on logic contracts

These do not need a clever economic exploit. They need a rushed merge and a missing diff review against the previous implementation’s storage.

If you upgrade often, treat storage layouts as a release artifact—versioned, reviewed, and tested with the same seriousness as the feature branch.

### 4. Offchain upgrades that skip the ceremony

Keepers, price adapters, allowlists, and “config services” change risk without an upgradeTo.

If a bot can retarget a router or a multisig can flip a feature flag that enables a new external call, that is an upgrade. Call it one. Scope it like one.

A review checklist we actually use

When AN3 scopes upgrade risk, we force answers on paper before we open Remappings:

1. Actors — EOAs, Safes, governors, guardians: who can propose, cancel, execute, pause, or upgrade?
2. Delays — real minimum time from intent to effect, including cancel windows and admin overrides
3. Atomicity — can upgrade and parameter change land in one transaction that users cannot exit before?
4. Verification — is the new implementation verified, and do users get a human-readable diff of what changed?
5. Rollback — is rollback safer than forward-fix, or does rollback reintroduce a known hole?

If any answer is “we’ll figure it out during the incident,” you are not upgradeable. You are editable.

What good looks like without cosplay

You do not need to go fully immutable to be serious.

You do need:

• One inventory of privileged paths that matches the chain
• No silent owner keys left from launch
• Timelocks that sit on the actual upgrade path
• Clear public notes when bytecode or critical parameters change
• A practice run of “malicious upgrade proposed—what do users do?”

Users have gotten better at reading explorers. They have not gotten better at guessing which Safe still has DEFAULT_ADMIN_ROLE.

Closing

Smart contract bugs still matter. So do economic designs. In 2026, a large share of quiet deaths sit between them: the ability to replace the rules after users opted in.

If you are buying an audit this year, put the upgrade and admin graph in the first scope call—not the appendix.

---

AN3 Intel · for teams who ship systems that can still change.