UUPS is the right answer for a single tokenised fund deployed once and upgraded occasionally. It is not the right answer for a fund family running many proxies that should evolve in lockstep, and it is not the right answer for a contract whose function surface is large enough that per-facet upgradeability is worth the complexity cost. This part covers the two patterns that handle those shapes: the beacon proxy for coordinated fund families and the diamond pattern (ERC-2535) for facet-based architectures. Both are real production options. Neither is the default.
Beacon proxies
A beacon proxy decouples the implementation address from each individual proxy. In a UUPS or transparent setup, every proxy stores its own implementation address. Upgrading 50 proxies means 50 upgrade transactions, each with its own governance, gas cost, and opportunity to land in a different state from the others. A beacon proxy points instead at a third contract, the beacon, which stores the implementation address. Each proxy delegates to whatever the beacon currently points at. Upgrading the beacon upgrades every proxy in one transaction.
Architecturally:
[Proxy 1]──┐
[Proxy 2]──┼──> [Beacon] ──> [Implementation]
[Proxy 3]──┘
The beacon is the single source of truth for which implementation is live. The proxies are cheap to deploy because they no longer store their own implementation reference, only the beacon address. The beacon holds whatever upgrade-authority logic the issuer wants (typically an UPGRADER_ROLE or its multi-sig equivalent), exercised once per upgrade rather than once per proxy.
The fund-family use case is where this earns its complexity. An asset manager running a tokenised MMF, a tokenised short-duration treasury fund, a tokenised investment-grade bond fund, and a tokenised cash-management fund as four separate share classes on chain has four proxies. If the BlackRock BUIDL family expands to five or ten variants under similar legal structures, the count grows. Each share class needs the same compliance-module update when sanctions lists change, the same fix when a bug is found, the same feature addition when a new redemption rail comes online. Routing all of them through one beacon is the operationally obvious choice.
The trade-off is concentration of risk. A bug in the implementation behind the beacon is a bug in every proxy pointing at it, simultaneously. The blast radius of a bad upgrade is larger than for an equivalent UUPS deployment. Issuers manage this through additional review on beacon upgrades, longer time-locks, and sometimes a staged rollout in which the beacon upgrade is tested on a single proxy variant first.
Practical fit. A beacon proxy makes sense once you are running five or more proxies that share most of their implementation logic and need to upgrade together. Below that threshold, the operational saving does not justify the additional contract surface. Several institutional issuers start with UUPS and migrate to beacon proxies when the fund family grows.
The diamond pattern (ERC-2535)
The diamond pattern decomposes a logical contract into many facets. Instead of one implementation holding all functions, a diamond maintains a routing table mapping each function selector to the facet that implements it. A call to transfer routes to the transfer facet; a call to mint routes to the mint facet; a compliance check routes to the compliance facet. Facets can be added, replaced, or removed individually without touching the others.
The elegance is real. A contract with many functions can exceed Ethereum's 24KB contract-size limit as a single bytecode blob; the diamond dissolves that ceiling because each facet is its own contract. Per-facet upgradeability is genuinely useful for large contracts where a small change to one subsystem should not require redeploying the whole codebase.
The complexity is also real. Function selector routing has its own subtle bugs. The diamond storage pattern (each facet uses a structured-storage approach to avoid colliding with other facets' state) is easy to get wrong. Auditing a diamond is meaningfully harder than auditing a UUPS contract because the auditor has to reason about the interaction between facets, the consistency of the routing table, and the sequence in which facets were added and replaced. Several auditors charge a premium for diamond audits.
Where it shows up. The diamond pattern is used in some sophisticated DeFi protocols (Aavegotchi is the frequently cited example) and in a small number of institutional tokenisation deployments. It is rarer in tokenised funds, where the function surface is constrained by the fund's legal structure and most variability is pushed out into the compliance module rather than into the token itself.
The honest read for 2026 is that the diamond pattern is worth recognising when an integrator uses it but rarely the right primitive for a new tokenised fund. The problem it solves, per-function-area upgradeability, is usually better solved by externalising variable logic into separate contracts that the token calls into, ERC-3643 style. A token that delegates compliance to an external module gets most of the per-facet flexibility without the routing complexity.
How to choose between the four
A short heuristic. UUPS is the default for any new single-contract deployment. A beacon proxy is the right escalation when the fund family grows beyond a handful of proxies that need to upgrade together. The transparent proxy is what you maintain rather than what you choose. The diamond pattern is reserved for the rare contract whose function surface genuinely outgrows the alternatives, and even then the question is whether externalising logic into separate contracts is a cleaner answer.
Part 5 turns to the layer that wraps all four patterns and matters as much as the technical choice itself: the multi-sig signers, the time-locks, the governance procedures, and the concrete reasons all of this infrastructure exists for tokenised funds in production.