UUPS Proxy
A pattern for upgradeable smart contracts where the upgrade logic sits in the implementation contract itself. Cheaper gas than the older Transparent proxy, but the implementation must be written carefully or the contract can be bricked.
Also known as: Universal Upgradeable Proxy Standard, EIP-1822
The Universal Upgradeable Proxy Standard, defined in EIP-1822 and operationalised in OpenZeppelin’s contracts library, is one of two dominant proxy patterns for upgradeable Solidity contracts. The proxy is a thin contract that forwards every call to an implementation contract via delegatecall, so the proxy holds the storage and the implementation provides the logic. To upgrade, the implementation address stored in the proxy is changed and subsequent calls execute against the new logic with the existing storage layout.
UUPS differs from the older Transparent proxy in where the upgrade function lives. In a Transparent proxy, the proxy contract itself owns an admin-controlled upgradeTo function; the proxy needs extra logic to route admin calls separately from user calls. In a UUPS proxy, the upgrade function lives in the implementation, which means the proxy is smaller, gas is cheaper on every call, and there is no admin-vs-user routing in the proxy. The trade-off is that if a new implementation is deployed without its own upgrade function, the contract is permanently frozen on that implementation. This is the failure mode UUPS is most criticised for; it is also why OpenZeppelin’s UUPS implementations include explicit safeguards in the parent contract.
The governance posture of a UUPS proxy is determined entirely by who can call the upgrade function. Common patterns include an Ownable owner (single key), a Pausable owner-plus-pause role, a multisig, a DAO timelock or no owner at all. The same code can be sovereign or fully controlled depending on how the access control is configured. For a token contract, the relevant question is whether the upgrade authority is held by a single key (highest centralisation, fastest emergency response), a multisig (intermediate), a DAO (slowest, most decentralised), or has been renounced.
For OYM’s coverage, the UUPS pattern shows up most often on retail-stablecoin-adjacent or compliance-sensitive tokens where the project wants to retain the ability to respond to regulatory or security events. Auki’s AUKI on Base is a UUPS proxy with an owner-controlled pause; the implementation contract is recorded separately and was last upgraded on a documented date. The audit chain on a UUPS token has to cover both the proxy and every deployed implementation, since storage-layout incompatibilities between implementations are the canonical bug class for this pattern.