Chapter I established the token-standard layer that institutional issuers actually deploy. ERC-3643 separates the token contract from the compliance contract precisely so the compliance side can change without redeploying the token. That separation only works if the contracts on the chain can be upgraded at all. This part sets out why immutability, the default property of code on most general-purpose chains, is a non-starter for tokenised funds and tokenised deposits, and what the trade-off looks like once you accept that upgradeability has to exist. Parts 2 through 4 cover the technical patterns; Part 5 covers the governance layer that makes those patterns operationally safe.
The default is permanence
Smart contracts on Ethereum and most EVM chains are immutable by construction. Once a contract is deployed, the bytecode at that address is fixed. There is no admin function to change it, no upgrade path baked into the protocol, no mechanism by which the deploying party can edit the logic later. This is a feature for some use cases. A bearer token, a one-shot escrow, a fully decentralised protocol whose value proposition is precisely that no one can intervene, all benefit from the strong assurance that the rules cannot move under the holder.
The property fails the moment the issuer is a regulated entity with continuing obligations to a regulator, an auditor, and a board. A tokenised money-market fund (MMF) lives inside a compliance perimeter that changes. Sanctions lists update weekly. Investor classifications shift, occasionally on a single name. Jurisdictional carve-outs arrive in response to enforcement actions or new guidance. The fund's transfer agent owes a duty to honour each of these without redeploying the fund as a new instrument and asking every holder to migrate.
Three concrete forcing functions
Regulatory change is the cleanest case. When the CFTC issued Letter 25-39 in December 2025 covering acceptable collateral for cleared derivatives, including treatment of tokenised MMF shares posted into clearing, every issuer running a tokenised MMF used as cleared-derivatives collateral had to update its compliance module to handle the new acceptance and segregation rules within the letter's effective window. An immutable token cannot adapt. The choice in an immutable world is to deploy a new token, fragment liquidity, and ask holders to swap, which is the operational equivalent of asking holders to redeem and resubscribe.
Bug fixes are the second forcing function and the most defensible publicly. The Compound finance liquidation bug in October 2021, where a faulty proxy upgrade briefly distributed roughly USD 80 million of COMP tokens incorrectly, was eventually contained through a follow-on proxy upgrade that corrected the comptroller logic. The episode is often cited as evidence against upgradeability, but the better reading is that the same upgrade authority that made the loss possible also made the recovery possible. An equivalent immutable contract would have made the original bug unfixable, the loss permanent, and the only remedy a hard fork or a full redeployment.
Feature additions are the third. A tokenised fund that initially issues on Ethereum mainnet, then extends to a Layer 2 (L2) for cheaper distribution, then adds a new redemption rail in a second currency, then takes on a new transfer-agent provider, will accumulate a multi-year backlog of small operational changes. None of them individually justify a new token. Cumulatively, they require a contract that can evolve.
The trade-off you accept
Upgradeability adds a counterparty. Whoever holds the upgrade authority can, in principle, replace the implementation with code that does anything. They can mint new units, freeze existing balances, redirect transfers. The institutional reader's first instinct, which is to refuse upgradeability on those grounds, is the wrong instinct because the alternative is worse: an unfixable contract holding several billion dollars of regulated assets, with no path to comply with a regulator's next move. The right response is to accept the upgrade authority as a real risk and manage it the way every other privileged operational role inside a regulated institution is managed.
The management toolkit is what Part 5 lays out in detail. At a high level, the upgrade authority is held by a multi-signature wallet (Gnosis Safe being the canonical pattern), the signers are drawn from product, compliance, legal, and risk, the upgrade process flows through a documented governance procedure, and the upgrade itself is gated by a time-lock so that holders can see what is coming and exit if they object. Time-locks of 24 to 72 hours are typical for institutional issuers; longer for assets where the holder population is less able to react quickly.
The right framing is that upgradeability is a managed risk, not an absent one. A holder of BlackRock BUIDL or BlackRock's tokenised treasury fund accepts that BlackRock can in theory replace the underlying contract, just as a holder of a traditional fund accepts that the asset manager can in theory amend the prospectus. The on-chain mechanism is more transparent than the off-chain one, not less; the multi-sig signers are visible, the time-lock is visible, the upgrade transactions are visible. Compare to a fund prospectus amendment, which is filed and disclosed but rarely watched in real time.
The reading sequence from here
Parts 2 through 4 walk through the four technical patterns the institutional stack actually uses: the transparent proxy (the original mainstream pattern, expensive but well-audited), UUPS (the current standard, cheaper and the right default for new tokenised funds), beacon proxies (for fund families that need to upgrade in sync), and the diamond pattern (more powerful, less common). Part 5 returns to the governance layer that wraps all of them. Read in order; the governance layer is meaningless without understanding what it is governing, and the technical patterns are dangerous without understanding what governs them.