Custody Architecture

Fund assets are held in wallets secured by multi-party computation: the private key is never assembled in one place. Instead, key shares are generated and held separately, on hardware-isolated infrastructure across independent parties, and a transaction is signed only when a threshold of shares participates. Loss or compromise of one share does not expose the key. Shares are backed up under separate procedures so that a provider failure does not mean loss of assets.

Every transaction passes a policy engine before it can be signed. Policies define which wallets may send to which destinations, in what amounts, requiring which approvals from which named individuals. Destination addresses are whitelisted under a separate approval chain from trading. A transfer that does not match a policy is not signed, regardless of who requests it. The engine’s rules are changed only through their own approval process, and every change is logged.

Each fund’s assets are held in vault accounts segregated from every other fund’s and from the firm’s own, and within a fund by purpose: long-term holdings, working balances for exchange settlement, collateral pledged to venues. Segregation is enforced by the custody platform, not by labeling, and is visible to the administrator and auditor.

Where an asset class or a fund’s regulatory position calls for a qualified custodian, assets are held with a regulated trust company or bank under a custody agreement. Working balances at exchanges are the exception that the architecture is designed to minimize: capped per venue, swept to custody on a schedule, and treated as counterparty exposure.