The previous three parts treated the wallet as a single address. That is the right abstraction for the contract layer and misleading at the institution layer. Behind every whitelisted address sits a custody architecture of cryptography, hardware, signers, and policy engines. The choice decides who can sign, how a key compromise is recovered, and whether the compliance model can rely on the address staying under coherent control. This part walks through the four production patterns, the named providers, and how Kinexys-tokenised assets sit on top.
MPC as the institutional default
Multi-Party Computation has won as the de facto standard. The private key is never reconstituted in any single location. It exists only as a set of mathematical shards, each held in a different security domain, and signing requires a threshold number of shards to participate in a distributed signing protocol. The signature that lands on chain is normal; the chain has no idea the key was sharded. The advantage over a hardware wallet is that there is no single point at which the key can be stolen; the advantage over multi-sig is that the on-chain footprint is a single ECDSA address rather than a contract that anyone can audit for the signer set.
The named providers are Fireblocks, Copper, BitGo (the MPC product, distinct from its older multi-sig offering), and bank-internal builds at firms like BNY and Standard Chartered's Zodia subsidiary. Each layers a policy engine on the cryptography: rules requiring human approval over a threshold, outbound-counterparty whitelists, time-of-day gates, integration with the institution's workflow tooling. The policy layer is what most institutional buyers pay for; the cryptography is commoditised.
For a regulated product like MONY or BUIDL, the institutional holder typically sits behind one of these MPC providers. The compliance pipeline at Securitize or Morgan Money sees and verifies the address; key management is the custody provider's problem; the institution's risk and ops teams configure the policy gating outbound activity.
Multi-sig for transparency-first treasuries
Gnosis Safe is the canonical multi-sig pattern, and the on-chain transparency is the feature. A Safe is a smart contract wallet requiring a configurable threshold of approved signers (typically 3-of-5, 4-of-7, sometimes 5-of-9 for very high-value treasuries) to authorise any outbound transaction. The signers are normal EOAs, often held on hardware wallets distributed across geographies. Every signature on every proposed transaction is visible on-chain.
The trade-off against MPC is that on-chain transparency cuts both ways. Counterparties can verify a treasury is held in the multi-sig the institution claims (an advantage for DAOs and foundations); adversaries can also enumerate signer addresses and target them individually. Multi-sig is preferred by crypto-native treasuries and institutions wanting public proof; MPC is preferred by traditional financial institutions treating custody as confidential. For tokenised funds, the issuer's treasury or fee wallet is sometimes a multi-sig; the institutional holder side is almost always MPC.
Cold storage with an online operational layer
Two-tier custody for very high-value balances. The bulk of the position sits in cold storage (offline, hardware-secured, often air-gapped, sometimes geographically distributed) and a smaller operational balance sits in MPC or multi-sig wallets that can transact in real time. Daily activity moves through the online layer; rebalances between online and cold happen on a slower cadence under heightened approval. Same logical structure as the front-office and vault separation in physical securities depositories; implementation is cryptographic rather than physical.
The two-tier pattern is mandatory for regulated qualified custodians (NYDFS Part 200, OCC Trust Charter holders, equivalents elsewhere). For tokenised funds, this means the whitelisted wallet may hold only the operational tranche, with the cold-storage tranche either at a separate whitelisted address or temporarily off the registry. The compliance design has to accommodate the two-tier movement without treating the cold-storage refresh as a new investor.
Anchorage Digital and the federally chartered crypto banks
Anchorage Digital is the only OCC-chartered national trust bank focused on digital assets, and that legal status matters. The federal charter, granted in January 2021, lets Anchorage offer qualified custody under the Investment Advisers Act and the equivalent rules for ERISA fiduciaries, banks, and certain insurance structures. For US institutional allocators with a fiduciary duty that requires a "qualified custodian" by statute (RIAs above the threshold, ERISA plans, mutual funds under the 1940 Act), Anchorage is one of the very small number of providers that can hold tokenised assets without breaching the fiduciary requirement. The technical architecture beneath the charter is MPC plus hardware-backed signing plus a policy engine; the legal wrapper is what sophisticated US clients are paying for.
A handful of other federally or state-chartered entities operate in the same space: BNY under its trust framework, State Street through its digital-asset custody buildout, Fidelity Digital Assets through its New York limited-purpose trust charter, and state-chartered digital asset banks (Wyoming SPDIs regulated by the Wyoming Division of Banking, with Custodia the most prominent though its Federal Reserve access has been contested). The cryptographic custody is MPC; the legal wrapper is a banking or trust charter; the value proposition is fiduciary compatibility.
Where Kinexys-tokenised assets sit
The custody layer is separate from the protocol layer. Kinexys provides the whitelist, compliance module, and transfer-agent integration; the custody provider provides key management. For an institutional client buying MONY through Morgan Money, the typical configuration is: the whitelisted wallet is a Fireblocks vault, BitGo MPC wallet, or Anchorage qualified-custody account; the compliance check happens in JPM-controlled contracts on Ethereum mainnet; the policy engine governing outbound transactions sits at the custody provider. The same separation holds for JPMD on Base.
The architectural lesson is that the protocol layer makes no assumptions about the cryptographic shape of the wallet on the other side. It needs an address, a verified identity, and a compliance check that returns true. The custody provider can be MPC, multi-sig, two-tier, or chartered qualified custody. Part 5 returns to where this separation breaks down: the operational edge cases where protocol and custody have to coordinate.