Custodians and investors

An investor holds its units through its custodian, which holds its keys and runs its wallet. The custodian is the venue, holding its customers’ accounts, or the investor’s own custodian (Deployment patterns). Either way, every payment, acceptance and transfer of the investor’s is signed in its own wallet, never by the venue’s engine.

What it runs

What	Where
The investor’s party	On its custodian’s Canton node
A wallet	One that speaks Canton’s token standard (CIP-56, with CIP-112 allocations)
The packages its node vets	`nodeasset`, with DA’s Registry packages and the token-standard APIs: the investor accepts NodeAsset’s payment requests, and its admission offers where an asset takes the venue’s credential, and is party to its own orders

What it signs

Act	When	On the ledger
Accept an admission	Once per asset that takes the venue’s credential	Accepts the venue’s offer (`AdmissionOffer_Accept`), which creates its credential. On an asset that takes the register keeper’s own credential it signs nothing: the register keeper’s admission consent creates that credential, held by the register keeper and naming the investor
Consent to issuer powers	At admission, where the asset uses them	Accepts the venue’s offer (`ConsentOffer_Accept`); without it, its units move only through its own custodian
Pay for an order on the ledger	Each order	Sets aside the payment and the receipt, one allocation on each registry (`AllocationFactory_Allocate`), then accepts the venue’s request (`AllocationRequest_Accept`)
Order paid off the ledger	Each order	Asks the register keeper to mint, naming the subscription (`AllocationFactory_RequestMint`), or to burn, naming the redemption (`AllocationFactory_RequestBurn`)
Receive a payout	Each distribution	Accepts the transfer of its line, or preapproves the fund’s payouts so they complete at once
Deposit and withdraw the payment asset	As it needs	Asks the bank to mint or burn it on the bank’s registry

What its wallet must support

Allocate through the token standard’s AllocationFactory_Allocate (V2), with the choice context and disclosed contracts the Registry serves.
Accept or reject a V2 AllocationRequest.
Accept a two-step TransferInstruction.
Request a burn through AllocationFactory_RequestBurn.
Submit with explicit disclosure.

What the investor reads at the venue

An investor signed in at the venue’s identity provider calls the venue’s API under the investor role: its own holder’s records, orders, holdings and statements, and the assets it may hold. It can place its own redemptions. It reaches no other holder’s records, and its payments are always signed in its own wallet, never through the API (Roles and access).

What it sees

On the ledger, its own payment requests, allocations, admission and credential, orders and claims, and its own legs of each settlement; never another investor’s orders, legs or holdings. The register keeper’s own credential naming it is the register keeper’s contract: its wallet receives it disclosed, in the context of each transfer the registry checks.

Internal or external

	Internal: the venue holds its customers’ accounts	External: the investor’s own custodian
Who holds the keys	The venue’s custody, apart from the engine	The custodian
Its node	The venue’s own, or a custody node it runs	The custodian’s own
What it signs	The same acts, from the custody wallet	The same acts

Related: Subscriptions · Redemptions · Who sees what

Architecture

Who runs what

Deploy

Operate

Custodians and investors

What it runs

What it signs

What its wallet must support

What the investor reads at the venue

What it sees

Internal or external

​What it runs

​What it signs

​What its wallet must support

​What the investor reads at the venue

​What it sees

​Internal or external

What it runs

What it signs

What its wallet must support

What the investor reads at the venue

What it sees

Internal or external