Why Upgradeable Contracts Create a Liability Black Hole

A multi-sig or DAO-controlled proxy admin is not a trustless solution. It creates a persistent attack surface and governance capture risk for the $10B+ TVL often secured by these keys. The failure of any signer (compromise, legal action, apathy) can freeze or rug the protocol.

A "trusted" upgrade can retroactively change the rules for all existing user positions and assets. This violates the principle of finality and creates a black hole of contingent liability, where past interactions are only as safe as the current admin's intentions. It's the antithesis of a credibly neutral base layer.

Solutions like EIP-2535 Diamonds or explicit contract migration (e.g., Uniswap v1 → v2 → v3) separate upgrade logic from core security. New features deploy as separate, immutable modules or contracts, allowing users to opt-in. This preserves state finality and eliminates the admin key risk vector.

A flawed proposal execution in October 2021 mistakenly distributed ~$80M in COMP tokens. The upgrade mechanism, controlled by token holders, became the attack vector.

• Problem: Governance-approved code is not inherently safe; a single bug can drain the treasury.
• Lesson: Decentralized upgradeability still centralizes catastrophic failure into one governance vote.

The dYdX v3 security module had a 2-day timelock, but its upgrade proxy allowed the team to bypass it entirely via a privileged function.

• Problem: Complex proxy patterns create hidden admin backdoors, rendering public timelocks theater.
• Lesson: Proxy architecture determines real control; a single upgradeTo call can nullify all other safeguards.

During the Terra collapse, the Wormhole bridge to Solana was paused by a 4/9 multisig to prevent fund flight, trapping user assets.

• Problem: 'Upgradeability' includes pausing functions, allowing a small committee to unilaterally freeze $100M+ in liquidity.
• Lesson: User funds are only as sovereign as the weakest administrative function in the proxy contract.

An attacker exploited an access control flaw in Sushi's MISO launchpad in September 2021, stealing ~$3M because the contract used an upgradeable proxy pattern.

• Problem: The proxy's init function was unprotected, allowing re-initialization and takeover.
• Lesson: Upgradeable contracts expand the attack surface; initialization logic is a critical, often overlooked vulnerability.

A faulty upgrade to Nomad's bridge in August 2022 left a critical verification function accepting all messages, leading to a $190M exploit in hours.

• Problem: A routine security upgrade introduced a catastrophic bug due to human error in the proxy's new implementation.
• Lesson: The upgrade process itself is the risk; every deployment is a potential total system failure event.

The only way to delete the admin key risk is to delete the admin key. Protocols like Uniswap V3 Core and MakerDAO core contracts are immutable.

• Solution: Build using immutable cores with modular, disposable extensions.
• Result: User assurance that the rules cannot change, forcing innovation into safer, composable layers rather than monolithic, mutable proxies.

The upgrade mechanism is controlled by a private key, not code. A compromised admin can rug, drain, or brick any contract in the system instantly.

• Key Risk: Centralized failure mode defeats decentralization guarantees.
• Key Data: Over $10B+ in historical exploits (e.g., Nomad, Audius) stemmed from compromised admin keys.

A multi-sig with a 7-day timelock creates a false sense of security. It only protects against impulsive acts, not determined attackers or insider collusion.

• Key Flaw: Governance attacks (e.g., Compound's Prop 64) or a compromised multi-sig still execute the upgrade.
• Key Reality: Timelocks shift, but do not eliminate, the trust assumption from code to people.

The only way to guarantee contract logic is to remove the upgrade key entirely. This forces rigorous auditing and formal verification before deployment.

• Key Benefit: Code-as-law is finally enforceable; users verify once, trust forever.
• Key Trade-off: Requires sophisticated migration patterns (like Uniswap v2 → v3) instead of in-place upgrades.

While they make the proxy admin address publicly visible, they don't solve the core governance problem. They just make the centralization obvious.

• Key Insight: Transparency ≠ Security. It only improves auditability of the admin, not the safety of its power.
• Key Practice: Used by protocols like OpenZeppelin and Aave, but the admin risk remains.

Modular upgradeability via facets seems elegant but creates a sprawling, interconnected system. A bug in any facet or the diamond core can compromise the entire protocol.

• Key Complexity: Upgrading one module can have unintended side effects on others, making security analysis exponentially harder.
• Key Example: Used by projects like Aave Gotchi, but introduces new reentrancy and storage collision risks.

Adopt the Uniswap v3 model: keep the core liquidity engine immutable, but allow new features via peripheral contracts that can be deprecated.

• Key Architecture: Users interact with a permanent, verified core. Periphery contracts (e.g., routers) can be upgraded with user opt-in.
• Key Outcome: Eliminates systemic risk while preserving development agility where it's safe.