UUPS _authorizeUpgrade correctly permissioned
A code & audits factor in the v1.7.0 rubric. Measured per protocol on a s cadence.
Methodology how we score #
**What this measures** This factor verifies that all UUPS (Universal Upgradeable Proxy Standard) implementation contracts define and correctly restrict the _authorizeUpgrade(address) function. Specifically, the function must revert for any caller that is not the designated owner, admin, or timelock controller. An unprotected or absent _authorizeUpgrade() allows any address to point the proxy at a new, attacker-controlled implementation. The assessment is performed by static analysis of the UUPS implementation's _authorizeUpgrade() visibility and access control gate.
**Why it matters** UUPS puts the upgrade authorization logic inside the implementation contract rather than the proxy, which means an incorrectly implemented _authorizeUpgrade() is a complete proxy takeover vector. A publicly callable or improperly gated _authorizeUpgrade() allows any attacker to call upgradeTo() and replace the implementation with one that drains all protocol funds in a single transaction. Approximately four documented hacks in the T-01 inventory involve UUPS authorization failures or related proxy upgrade bugs. As UUPS has become a common pattern in newer DeFi deployments, the authorization gate is a critical checkpoint.
**Green / Yellow / Red** Green: _authorizeUpgrade() is restricted to owner or admin and reverts for all other callers, confirmed by static analysis; the owner/admin itself is a multisig or timelock. Yellow: _authorizeUpgrade() is correctly restricted but the permissioned caller is a single EOA rather than a multisig or timelock. Red: _authorizeUpgrade() is absent from the implementation contract, or it does not revert for non-owner callers.
**Common gray cases** This factor is gray for protocols that do not use UUPS proxy patterns -- e.g., transparent proxy, beacon proxy, or non-upgradeable implementations.
Measurement what to look for #
Determine whether the UUPS implementation defines `_authorizeUpgrade(address)` restricted to owner/admin/timelock (not open to arbitrary callers).