Smart Contract Change Management for Live Protocols

Video transcript

Every upgrade replaces audited code, often in a single multisig transaction. The process around it has to catch what code review misses.

An upgrade can fail in three places: the code, the transaction that installs it, as at Ronin, and the keys that sign it, as at Bybit.

New code breaks old assumptions. Across 49 update reviews in Guardian's published portfolio, sixty-two point five percent of Criticals and Highs were labeled Logical Error.

Run every change through one pipeline: a written change record, a diff review against the audited commit, and a fork simulation of the exact batch.

Then queue it behind a timelock. The Security Alliance framework suggests seven to fourteen days or more for protocol upgrades, and three days by default.

Signers decode calldata on their own devices. Execute in stages with caps, then monitor closely, with a pause trigger agreed in advance.

Every step needs an owner who can stop it. As the Security Alliance puts it, timelocks and review windows are intentional controls, not friction to bypass.

Vanguard includes six months of update review after production, at audit standard, and leaves you a reusable invariant suite. With Managed Security, Guardian reviews every multisig transaction before it is signed.

Read the full article for sign-off roles, the fast path and a process template. Or put your next upgrade through review with Vanguard at guardian.security.

Live protocols keep shipping. Each upgrade replaces audited code, often through a single multisig transaction.

Code review catches bugs in the new code. The process around the upgrade has to catch the rest.

Below is that process, with a template at the end. For how proxies work, see upgradeable smart contracts explained.

Why Upgrades Break Audited Code

An upgrade can fail in three places: the code, the transaction that installs it, and the keys that sign it.

The code

New code breaks assumptions the old code made. Across 49 update reviews in Guardian's published portfolio, 62.5% of Criticals and Highs were labeled Logical Error.

Examples include shares converted twice and a feature that could block liquidations. See smart contract upgrade bugs.

The transaction

In August 2024, a Ronin bridge upgrade ran initializeV4 but skipped initializeV3, Rekt reported. The operator weight stayed at zero, which disabled the vote threshold.

About $12M was withdrawn the same day, in what CoinDesk called a whitehat hack. The funds were returned.

The keys

In February 2025, Bybit's signers approved what their screens showed as a routine transfer. They had signed a wallet implementation upgrade, and $1.43B was taken, per Rekt.

The Change Pipeline

Run every change through the same six steps. Skipping one should be a recorded decision, not a habit.

1. Propose

Write a change record before the code. It should state:

• What changes, why, and on which contracts and chains.
• The audited commit it builds on, and the target commit.
• Storage layout changes, new roles and new parameters.
• The exact transactions, in order, with decoded calldata.
• How to pause or roll back if it goes wrong.

Review the design here, while it is cheap to change. GMX brought Guardian its V2.3 plan before writing it, and the review produced the questions the design had to answer first.

2. Review

• Diff against the audited commit, not the last release.
• Rerun the invariant suite, and add invariants for what the change introduces.
• Check storage layout and initializers against the live version.
• Size the external review to the change: see when you need a re-audit.
• Review the fixes too.

OpenZeppelin's Upgrades Plugins validate "that the new implementation is upgrade safe and is compatible with the previous one".

3. Simulate

Run the exact transaction batch against a fork of live state. Foundry's fork testing "lets you run tests against real chain state without deploying to a live network".

Pin the block, execute as the multisig would, then rerun the invariants and key user flows on the upgraded state.

Test the result, not just the new code. Ronin's bug lived in an initializer that never ran.

Before anyone signs, confirm the new implementation's bytecode matches the reviewed commit.

4. Queue behind a timelock

As ethereum.org puts it, timelocks "give users some time to exit the system if they disagree with a proposed change".

The Security Alliance (SEAL) multisig framework suggests thresholds and delays by type of change:

Its default minimum is three days. It adds that "even a short delay (e.g., 1 hour) with active monitoring is significantly better than no delay at all".

Rollups face a public bar. ETHBEAT (formerly L2BEAT) rates a rollup Stage 1 only if upgrades from outside its Security Council allow "at least a 7 days exit window".

OpenZeppelin's TimelockController splits proposer, executor and canceller roles. Its optional admin "should be subsequently renounced in favor of administration through timelocked proposals".

5. Execute in stages

Ship to the smallest blast radius first:

• One chain or market before the rest.
• Caps on new markets, collateral and deposits, raised over time.
• New features off, or at zero allocation, until monitoring is live.
• Steps that depend on each other in one atomic batch.

Each signer decodes the calldata on their own device. SEAL's framework says to verify calldata, not just hashes. Bybit shows why.

6. Monitor after the upgrade

Watch the first days closely:

• Implementation and admin slots, checked against the change record.
• The roles and parameters the change set.
• The invariants the change touches, on live state.
• Unusual flows: large withdrawals, failed liquidations, reverts on key paths.
• New timelock operations, so nothing ships unannounced.

Agree in advance what triggers a pause and who pulls it. To automate these checks, compare smart contract monitoring tools.

Who Signs Off

Give every step an owner who can stop the change. No one approves their own work.

Write down who may shorten a step, and how that is recorded. SEAL is blunt: "Timelocks and review windows are intentional controls, not friction to bypass."

Plan the fast path

Decide in advance how an urgent fix ships. After an update to Compound's Comptroller in 2021, about $80M in excess COMP was wrongly distributed.

The fix, Proposal 64, had to pass before it took effect. While the team waited, another $68.8M was sent to the vulnerable contract, Rekt reported.

Keep the fast path narrow. SEAL: "Bypass paths should do the minimum necessary and nothing more."

A Process Template

Copy this into your release checklist:

1. Change record filed, with audited base commit and target commit.
2. Design reviewed if core flows or the trust model change.
3. Diff reviewed internally and externally; fixes reviewed too.
4. Storage layout validated; every initializer listed and called.
5. Invariants and fork simulation pass on the exact batch.
6. Implementation bytecode matched to the reviewed commit.
7. Calldata decoded by each signer on their own device.
8. Timelock queued; users and monitors notified.
9. Executed in stages, with caps and a tested pause.
10. Monitoring window complete; change record closed.

Procedures are changes too. Guardian reviewed GMX's procedures for delisting a market and an index token, where "a step in the wrong place is a vulnerability no contract audit will find".

How Guardian Supports Upgrades

Vanguard includes six months of update review after production, at the same standard as the audit. Its invariant suite stays with your team as a reusable harness for every later change.

With Managed Security, Guardian's security operations team reviews every multisig transaction before it is signed, and every deployment and configuration change as it lands.

For GMX's new risk oracle role, Guardian reviewed the change under a deployment freeze. That meant checking it was "as isolated as it claimed to be", not only that it was safe. See the GMX client story.

Frequently Asked Questions

How should a live protocol manage smart contract upgrades safely?

Put every upgrade through one pipeline: a change record, a diff review against the audited commit, a fork simulation, a timelock, a staged rollout and monitoring. Give each step an owner who can stop it.

How long should an upgrade timelock be?

SEAL's framework suggests 7 to 14+ days for protocol upgrades, 48 to 72 hours for operational parameters and three days by default. ETHBEAT's Stage 1 requires at least a 7-day exit window for upgrades from outside a rollup's Security Council.

Who should be able to bypass a timelock?

Ideally only a narrow emergency role that can pause and nothing else. SEAL's framework reserves no-delay actions for tightly scoped emergencies, such as pause-only capability, and says bypass paths should do the minimum necessary.

What should you monitor after an upgrade?

The implementation and admin slots, the roles and parameters the change set, the invariants it touches, new timelock operations, and unusual flows like large withdrawals or failed liquidations. Agree beforehand what triggers a pause and who pulls it.

Sources

• Guardian: Smart Contract Upgrade Bugs: What 49 Update Reviews Found (November 2026)
• Rekt: Ronin Network, Rekt II (August 7, 2024)
• CoinDesk: Ronin Bridge Paused, Restarted After $12M Drained in Whitehat Hack (August 6, 2024)
• Rekt: ByBit, Rekt (February 22, 2025)
• Rekt: Compound, REKT (October 4, 2021)
• OpenZeppelin Docs: Upgrades Plugins
• OpenZeppelin Docs: Governance, TimelockController
• Foundry: Fork Testing
• ethereum.org: Upgrading smart contracts (updated October 21, 2025)
• SEAL Frameworks: Multisig Use Case Requirements
• SEAL Frameworks: Multisig Security Framework
• ETHBEAT (formerly L2BEAT): Stages
• Guardian: GMX client story
• Guardian: Vanguard, including six months of update review
• Guardian: Managed Security