Sub-custody for retail distribution of tokenized funds — omnibus, or on-ledger under CIP-0112?

App Development
1

Hello, Canton community,

A licensed broker wants to distribute a tokenized money market fund to retail clients. There are two ways they can hold and I cannot work out which one the network intends.

Per-client on chain - Every client holding is a contract. Traffic is metered by the byte, so ten thousand clients means ten thousand positions to create, maintain and service and every client’s balance is a fact on a shared ledger.

Omnibus - The broker holds one position; per-client positions live in the broker’s own books and are reconciled against it continuously. This is how nominee accounts already work in traditional custody, and the economics are not close.

Omnibus wins on cost and on privacy and loses something real: on chain those units belong to the broker, so the client cannot post them as collateral anywhere else on Canton. Composability is exactly what the chain is supposed to add and omnibus gives it back.

CIP-0112 supports modelling custody chains on the ledger - If on-ledger sub-custody is the intended pattern for retail distribution, then an off-chain sub-ledger is the wrong answer however well it reconciles.

I have built the second one - an omnibus position reconciled continuously against a per-client sub-ledger, with the invariants executable rather than documented and a verified exit export so a broker can leave with their book. Notes and real output, including a deliberately injected fault that the reconciliation catches:

Before taking it further I would rather know it is the wrong shape.

  1. Is on-ledger sub-custody under CIP-0112 the intended pattern here, or is omnibus-plus-reconciliation the expected one?
  2. For issuers already on Canton, how do your distributors hold today and what do they ask you for that you cannot give them?
  3. For brokers - is the reconciliation the hard part, or is it registry admission and custodian integration?
  4. Is secondary transfer between holders expected to work - client to client, outside the fund’s dealing cycle and is an omnibus broker expected to support it?
  5. Would a shared open specification for the sub-ledger reconciliation and the exit format be useful, or is everyone content building their own?

Best regards

dfrnw

2

Hey @Dfrnw! Here are my thoughts on the approach after reading the post and the GitHub md files:

I wouldn’t say there is a right or wrong shape here, since both models you describe are feasible. The choice is ultimately a trade-off, and which trade-off is acceptable depends on the business you are actually serving. Which takes me to the second point:

I would expect this decision to be heavily driven by the legislation governing the asset, the clients, and the exchange. That one sentence can mean very different things depending on what licensed covers, which fund and registry it is, and which retail client you are trying to serve. So I would recommend starting from a more explicit, defined business workflow before going deeper into implementation. You may already have those details, but I would expect the design to lead with business and compliance factors and let implementation follow from them.

Third point: if you want to compare trade-offs between setups, dig deeper into what you expect from each actor and what you will offer them. That translates into explicit workflow decisions. For example, the custody model per client (who controls the client’s party and keys, whether the client ever signs) and the privacy each stakeholder expects (who must not see a client balance) will completely change the implementation, in either shape.

That said, I believe the fastest path to useful feedback is to validate the setup directly with the client of the solution, the licensed broker, and understand their specific expectations for the custody and composability of the asset. The network can support both models; only the broker, the asset issuer, and their regulator can tell you which one they expect.