UUPS is the default for new institutional tokenised funds in 2026. It is the same proxy-plus-implementation architecture as the transparent pattern (Part 2), but the upgrade machinery has moved from the proxy into the implementation, which changes the economics, the deployment shape, and the path to eventual immutability. This part covers the architectural shift, the gas and size savings, the sealing option that is genuinely novel, and why the production examples worth naming, BlackRock BUIDL, JPMD on Base, almost certainly the JPMorgan-issued MMF MONY, are running this pattern or a close variant.
The architectural shift
UUPS, the Universal Upgradeable Proxy Standard, lives in EIP-1822. The split is the same as the transparent pattern: a proxy contract holds storage and points at an implementation, the implementation holds logic, delegatecall is the bridge. The difference is where the upgrade function lives. In a transparent proxy, the proxy itself owns upgradeTo and an admin-vs-user discriminator. In UUPS, the proxy contains only the bare delegation logic; the upgradeTo function lives in the implementation, exposed to the proxy via delegatecall like any other function.
The consequence is that the proxy becomes minimal. No admin check on every call, no admin storage, no dispatcher. The proxy is little more than a fallback that delegates to a stored implementation address, plus the EIP-1967 storage slots.
A UUPS implementation inherits from a base contract that supplies the upgrade function plus an authorisation hook the implementation must override:
function _authorizeUpgrade(address newImpl) internal override onlyRole(UPGRADER_ROLE) {
// intentionally empty; access control is in the modifier
}
The modifier is what enforces who can upgrade. Move it from onlyRole(UPGRADER_ROLE) to revert() and you have a contract that can no longer be upgraded by anyone. That is the sealing option, covered below.
Gas, size, and the case for the new default
UUPS is meaningfully cheaper to use. The transparent proxy's per-call admin check is gone. Every transfer, every balance query, every approval skips the discriminator and goes straight to delegatecall. On Ethereum mainnet, where gas dominates total cost of ownership, this is a real saving over a long horizon. On L2s the per-transaction saving is smaller in absolute terms but proportionally larger relative to baseline cost.
The proxy bytecode is also smaller. A transparent proxy ships with the admin dispatcher and storage for the admin role. A UUPS proxy ships with the delegation fallback and the EIP-1967 slots. Smaller bytecode means lower deployment cost. For a fund family that deploys many proxies (one per share class, one per jurisdiction wrapper), the savings compound.
The trade-off is that the upgrade logic lives in the implementation, which means a buggy implementation can break upgradeability. Deploy an implementation that omits the upgradeTo function or its authorisation guard and you have either accidentally sealed the contract (best case) or accidentally opened it to anyone (worst case). This is the reason every credible UUPS deployment runs through standard tooling like OpenZeppelin's upgrades plugin, which validates the new implementation against the old before broadcast.
Sealing: the optional path to immutability
The genuinely novel feature of UUPS is that the upgrade authority can be removed. Because the upgrade function lives in the implementation, the next upgrade can deploy an implementation whose _authorizeUpgrade reverts unconditionally. From that block onward, no upgrade is possible from any address. The contract has been sealed.
This gives the issuer a credible exit from upgradeability. A tokenised fund that needs upgradeability during its first three years of operation can declare a stable v1.0 and seal it once the legal and operational framework has settled. The token then becomes immutable, with all the assurances that property provides, without having committed to it from day one. The path is uncommon in production because most issuers want to keep the option open, but it is structurally available and occasionally raised in tokenised-fund prospectuses as a future commitment.
Why most modern institutional tokenised funds use it
The reasoning compounds. A new tokenised MMF in 2026 expects to live across multiple chains (Ethereum mainnet for institutional reach, an L2 for cheaper distribution, eventually a permissioned ledger like the Canton Network for flows that need privacy). Each deployment is a separate proxy, often with similar implementation logic. UUPS's smaller proxy and lower per-call gas are visible at every instance.
The compliance side reinforces the choice. ERC-3643 and its institutional cousins externalise the compliance logic; the token contract itself is doing relatively little work and changes infrequently. UUPS suits this shape because the upgrade authority is rarely exercised for the token (most rule changes happen in the compliance modules), but when it is, gas is not the constraint and the simpler proxy is the right primitive.
BlackRock BUIDL is widely understood by integrators to use a UUPS-style pattern, although the exact implementation choices are not fully public. JPMD on Base, JPMorgan's natively-issued deposit token, almost certainly uses a UUPS variant given the bank's stated multi-chain strategy. MONY, the JPMAM-issued tokenised MMF, has its public token-contract address on the Kinexys stack but the upgrade architecture is not fully disclosed; the safe framing is "almost certainly UUPS or a close institutional variant," consistent with where the broader institutional tokenised-fund population has converged.
What to keep in mind
Three operational reminders. The implementation address must be set carefully on the first deployment; the proxy itself does not validate that the implementation is UUPS-compatible. Every implementation upgrade is subject to the governance procedures Part 5 covers; the technical pattern by itself does not constrain who can upgrade. The sealing option is irreversible, which is the entire point but also means the decision needs the same scrutiny as any other terminal commitment.
Part 4 turns to two patterns that solve different shape-of-problem cases: beacon proxies for fund families that need to upgrade in coordination, and the diamond pattern for contracts whose function surface warrants per-facet upgradeability.