The technical pattern is half the answer. The other half is governance: who can propose an upgrade, who has to approve it, how long the network sees the upgrade coming before it lands, and what the documented procedure looks like for the unusual cases (emergency fixes, contested upgrades, signer rotation). This part covers the operational layer that wraps every upgradeable contract a regulated issuer runs, then closes with the concrete forcing functions that make all of this infrastructure load-bearing for tokenised funds.

Multi-sig as the primitive

The upgrade authority on an institutional tokenised fund is never a single private key. A single key is a single point of failure: lose it, the contract is sealed by accident; compromise it, and the attacker can replace the implementation with anything. The institutional default is a multi-signature wallet, where some quorum of authorised signers must approve any privileged action.

The canonical implementation is Gnosis Safe (now Safe). A Safe is itself a smart contract holding the upgrade authority for the proxy. It enforces an M-of-N policy: at least M of N authorised signers must approve a transaction before the Safe will execute it. Typical institutional configurations are 3-of-5, 4-of-7, or 5-of-9. Higher M reduces the risk that a single compromised signer can push through a malicious upgrade, but raises the operational cost of legitimate upgrades and the risk of paralysis if signers are unavailable.

For an issuer like JPMorgan Asset Management running MONY on the Kinexys stack, the signer set is almost certainly drawn from product, compliance, legal, and risk, with the precise composition undisclosed. Signers use hardware-backed signing (Ledger, YubiKey, or equivalent) under existing institutional access controls. Not publishing the signer identities is itself the right posture: it expands the attack surface without adding governance value to outside readers.

Time-locks for visibility

Even after multi-sig approval, the upgrade does not execute immediately. A time-lock contract sits between the Safe and the proxy. When the Safe approves an upgrade, the time-lock queues the transaction with a timestamp at which it becomes executable. Anyone watching the chain can see the queued upgrade, inspect the proposed implementation, and decide whether to exit the position before it lands.

Common delays are 24 hours for routine upgrades, 48 to 72 hours for sensitive upgrades, and up to 7 days for protocols whose holders bargained for longer notice. The choice trades the issuer's need to respond quickly (a 7-day delay is unworkable for an emergency fix) against the holder's need to see what is coming (a 6-hour delay does not give an institutional treasury time to react). Most institutional tokenised funds sit in the 24-to-72-hour band.

A short illustration of the layering:

[Multi-sig signers]
        │ propose, approve
        ▼
   [Gnosis Safe]
        │ execute (M-of-N)
        ▼
   [Time-lock contract]
        │ queue, then execute after delay
        ▼
   [Proxy upgradeTo()]
        │ delegatecall now points at new implementation
        ▼
   [New implementation live]

Three contracts, three checkpoints. Each is on chain, each is auditable, each is the kind of thing an institutional integrator can attest to in writing when a counterparty asks how upgrades work.

Governance procedures

The contracts only enforce the mechanical part. The governance procedure is the documented process by which an upgrade is proposed, reviewed, and approved before it reaches the Safe. For a regulated issuer, this includes a change-management policy, a security review of the new implementation (internal team plus typically a third-party auditor), compliance sign-off, and a decision log.

The procedure also covers signer rotation when a signer leaves the firm, emergency upgrades that bypass the standard time-lock when a live exploit needs to be stopped (typically through a separate emergency multi-sig used only under defined criteria), and contested upgrades when internal disagreement reaches the signer set. Each is the kind of question an auditor or regulator will ask; a credible issuer has written answers before the situation arises.

Why this matters for tokenised funds, three concrete cases

Regulatory change. When the CFTC issued Letter 25-39 in December 2025 covering treatment of tokenised MMF shares posted as cleared-derivatives collateral, every issuer running an MMF used in this way had a window to update its compliance modules. Multi-sig approval into a time-locked transaction landing the new implementation was the operational mechanism. An immutable contract had no path. The issuers without working upgrade governance scrambled; those with mature governance executed within the letter's effective window.

Bug fixes. The Compound liquidation bug in October 2021, where a faulty proxy upgrade briefly distributed roughly USD 80 million of COMP tokens incorrectly, was contained through a follow-on proxy upgrade that fixed the comptroller logic. The bug is often cited against upgradeability; the fix is the better evidence in favour. Audits catch most issues but not all, and the right response when an audit-missed bug reaches production is the ability to patch. Institutional tokenised funds inherit the same logic.

Feature additions. As MONY extends to new chains (a Base deployment, a Canton Network deployment), as new redemption rails come online, and as new collateral mechanics are added on the Kinexys Tokenized Collateral Network, the underlying contracts evolve. Without upgradeability, every change is a new token, fragmenting holder liquidity. With upgradeability, the changes land behind a constant user-facing address.

The framing to leave with

The right question to ask about an upgradeable token is not "is it upgradeable" but "who governs the upgrade, how, and on what time-frame." A UUPS contract behind a 4-of-7 institutional multi-sig with a 48-hour time-lock and a documented governance procedure is a categorically different risk than a UUPS contract whose upgrade authority is a single externally-owned address held on an unknown laptop. The technical pattern is necessary infrastructure; the governance is what makes it operationally safe.

This closes Chapter II. Chapter III turns to settlement mechanics: the distinction between speed and atomicity, the BIS DvP models, and the cash-leg infrastructure that the atomic DvP foundations chapter introduced.