Malicious Upgrades and Governance

Every upgradeable protocol carries an implicit trust assumption: whoever can call upgradeTo can replace the entire system with arbitrary code at the existing address. That capability is, by construction, equivalent to ownership of every dollar in the protocol. The question an auditor should ask of every upgrade pathway is not "is the code safe?" but "who can call this, how fast can they act, and what can users do about it?"

This section covers the governance and authorization layer that sits above the proxy mechanics — the part that determines whether a system is meaningfully decentralized, theatrically decentralized, or honestly admin-controlled.

Threat Model

The realistic threats against the upgrade path are:

  • Key compromise. An attacker obtains the private key of the upgrade authority (multisig signer, deployer EOA, governance executor) and pushes a malicious implementation.
  • Insider attack. A team member with legitimate upgrade rights deliberately deploys a malicious upgrade — to drain funds, censor users, or change tokenomics in their favor.
  • Governance capture. A token-voting system is exploited via a flash-loan, bribery, or vote-buying attack, and a malicious proposal passes.
  • Social engineering / supply chain. A team member's machine is compromised and a malicious proposal is submitted under their legitimate identity.
  • Operational mistake. A buggy implementation is deployed by accident, with no malice but identical user impact.

The defenses below should be evaluated against all five.

Defense 1: Multisig Authorization

The minimum bar for any upgradeable production protocol is that the upgrade authority is held by a multisig wallet, not an EOA. Audit questions:

  • What is the signer threshold? 2-of-3 is the floor for a meaningful multisig; 3-of-5 or 4-of-7 is more typical for serious protocols. 1-of-N is not a multisig.
  • Who are the signers? Are they all team members of one entity (single point of social compromise), or distributed across the team, advisors, and independent parties?
  • Are the signer addresses verifiable? Is the team transparent about who holds keys?
  • What hardware are signers using? Hardware wallets are table stakes; signing from a hot wallet on a laptop is unacceptable for protocols of any size.
  • What is the rotation policy when a signer leaves the project?

Safe (formerly Gnosis Safe) is the de facto standard. Custom multisig implementations should be regarded with suspicion absent very strong justification.

Defense 2: Timelock

A multisig limits who can push an upgrade; a timelock limits how fast. A timelock interposes a mandatory delay between when an upgrade is queued and when it executes, giving users — and the team's own monitoring — time to detect and respond to malicious changes.

queue_upgrade(newImpl)  →  [delay]  →  execute_upgrade(newImpl)

Audit questions:

  • What is the delay? 24 hours is the floor for a meaningful timelock; 48-72 hours is more defensible; some protocols (Compound, Uniswap) use multi-week governance delays for the most sensitive operations. A 10-minute "timelock" is theater.
  • Is the delay long enough for users to exit? A lending protocol with 7-day debt positions and a 24-hour upgrade timelock has not given borrowers a meaningful chance to react.
  • Can the timelock be bypassed? Look for emergency paths (executeImmediate, emergencyAction) that skip the delay. They are sometimes justified (pausing during an active exploit) and sometimes a back door.
  • Who controls the timelock itself? A timelock whose admin is a 1-of-1 EOA has no security; a timelock administered by another timelock or by governance is more meaningful.
  • Is the queued upgrade visible on-chain in human-readable form? If users need to manually decode calldata to know what's being deployed, the timelock's transparency benefit is reduced.
  • Are queued upgrades surfaced by monitoring services? Defender, Tenderly Alerts, Forta, and similar should be configured to alert on queued upgrades.

OpenZeppelin's TimelockController is the canonical implementation. Custom timelocks should be reviewed for the same patterns.

Defense 3: Governance Gating

Some protocols subject upgrades to on-chain governance: token holders or delegates vote on a proposal, and only proposals that pass are queued in the timelock. This significantly raises the bar against insider attacks but introduces governance-capture risk in return.

Audit considerations:

  • What is the voting threshold and quorum? A protocol where 4% of supply can pass a proposal is much more exploitable than one requiring 20%.
  • Is voting power flash-loanable? If governance tokens can be flash-borrowed and used to vote, the protocol is vulnerable to flash-loan governance attacks (see Beanstalk, 2022, for the canonical example). Snapshot-based voting (using getPastVotes at proposal creation) defends against this.
  • Is there a proposal queue/execution delay? Even a passed proposal should sit in a timelock before execution.
  • Is there an emergency bypass to governance? A "guardian" or "emergency council" with the power to skip governance is a common pragmatic choice but moves the trust model back toward multisig control.
  • What is the governance token's distribution? A token with 80% held by team and VCs is a multisig with extra steps.

Defense 4: Implementation Validation

Even with strong governance, the implementation being upgraded to must itself be safe. Defenses:

  • Storage-layout validation in CI for every PR (§4.12.2).
  • Implementation must be deployed and verified on Etherscan before the upgrade is queued. Users should be able to read the new code during the timelock window.
  • The implementation address in the upgrade proposal must match the verified one. Cross-check at queue time and at execute time.
  • The upgrade should be tested on a mainnet fork before being queued, with a publicly available simulation report.
  • A validateUpgrade script using @openzeppelin/upgrades-core should pass before the queue transaction is signed.

A protocol that queues an upgrade pointing at an unverified contract is, charitably, sloppy; uncharitably, hiding something. Either way it's a finding.

Defense 5: User Exit Rights

Even the strongest defenses can fail. The last line of defense is the user's ability to exit before a malicious upgrade executes. This is determined by:

  • The timelock delay relative to the time required to unwind positions.
  • Withdrawal mechanics. Are withdrawals always available, or can the protocol's state (frozen vault, unmatched orders, pending bridges) prevent exit?
  • Pause functionality. Ironically, the same admin who can push a malicious upgrade often can also pause the protocol to prevent users from exiting. A pause function controlled by the same key as the upgrade key effectively eliminates the timelock's value.

Audit questions:

  • Can users always withdraw their funds during the timelock window?
  • Is there an admin function that can prevent withdrawals (pause, blacklist, set withdrawal fee to 100%)? If so, who controls it, and is it subject to the same governance/timelock as upgrades?
  • For lending protocols: can borrowers repay early to release collateral before an upgrade?

Anti-Patterns

The following appear regularly enough to warrant explicit calling-out:

  • EOA-owned upgrade key. Any protocol with non-trivial TVL using a single-signer hot wallet for upgrades is an open invitation.
  • Multisig with all signers controlled by the same entity. Defends against external attackers, does nothing against insiders.
  • No timelock at all. Upgrades execute instantly. Users have no warning, no exit window, and no recourse.
  • Theater-grade timelocks (minutes-long delays). Effectively no delay.
  • Emergency bypass with no governance. A button labeled "skip the timelock" controlled by the same multisig is a back door, no matter what it's called.
  • Upgrade key == pause key == treasury key. Centralizes all power in one place; one compromise loses everything.
  • Hidden upgrade pathways. A "set implementation" function on a peripheral contract that isn't documented as an upgrade vector but is, functionally, an upgrade. These often hide in factory contracts, registries, and adapter modules.
  • Misleading "decentralized" claims. Marketing copy that says "decentralized governance" while a 2-of-3 team multisig has unilateral upgrade rights. Worth pushing back on in the audit report.

Honest Disclosure Is Part of Security

The strongest defense for an upgradeable protocol is often not technical: it is honest disclosure of who controls what, on what timescale, with what oversight. A protocol that publishes:

"Upgrades are controlled by a 4-of-7 multisig with these signers, subject to a 72-hour timelock, with monitoring alerts published to this dashboard. Users can withdraw at any time during the timelock window. Emergency pause is controlled by a separate 2-of-3 guardian multisig and lasts at most 24 hours."

…is honestly admin-controlled, but the admin power is bounded, observable, and survivable. A protocol that hides its upgrade pathway behind vague decentralization marketing is dishonest about a trust model that exists either way.

Audit reports should describe the upgrade pathway clearly in the centralization-risks section, even when no exploitable bug exists. Users deserve to know what trust they are extending.

Auditor's Sanity Check

Before signing off on the upgrade machinery of any protocol, an auditor should be able to answer:

  1. If I were the most malicious imaginable upgrade-authority holder today, what is the worst thing I could do to user funds?
  2. How long would users have to react?
  3. What stops me from doing it?

If the answer to (1) is "drain everything", (2) is "less than a day", and (3) is "we trust the team", that should be the conclusion of the audit's centralization section — not a footnote.