Register keeper

The register keeper keeps an asset’s register: the issuer, or the transfer agent it appoints, and on the DA Registry the asset’s registrar. It decides every change to the register, by its own act or under a consent it signed. It is another firm, or the venue’s own organization through an issuance desk (Deployment patterns).

What it runs

What	Where
Its party	On its own Canton node. Hosted on another firm’s node, it is an external party that signs with its own key
The fund’s treasury	The fund’s cash account, a party of its own beside it, which signs the fund’s consent too
Its registry	On the DA Registry, through DA’s registry tools: each asset’s configuration, which names the credential every holder needs (its own, or the venue’s), and its block list
The packages its node vets	`nodeasset`, `nodeasset-oracle-api`, and the package its price source publishes NAV points on (`nodeasset-oracle`, for `PublishedNav`), with DA’s Registry packages and the token-standard APIs. The fund’s consent reads each order’s price in the transaction the register keeper signed for, so its node runs the price’s packages too. For a backed instrument, also the reserve’s two, `nodeasset-reserve` and `nodeasset-reserve-lock`, which the node hosting the reserve’s holder vets too

What it approves and signs

Act	When	On the ledger
Create the asset	Once	Its configuration on its registry, naming the credential every holder needs
Sign the fund’s standing consent	Once per fund, with the treasury	Accepts the venue’s proposal (`PrimaryMarketProposal_Accept`): the payment asset, the treasury and the price source. Every order paid on the ledger then mints or burns within it, at the price the price source signed
Accept the admission consent	Once per asset on its own credential	Accepts the venue’s proposal (`AdmissionConsentProposal_Accept`): the KYC providers it trusts, the claims an admission needs, and the residencies and investor types admitted. Each admission the venue asks for under it then creates the register keeper’s own credential in the same transaction, held by the register keeper and naming the investor, who signs nothing
Require its own credential	Once per asset	Makes the asset’s configuration name its own credential instead of the venue’s, on its registry. The venue then re-admits each holder under the consent, each in one transaction that revokes the venue’s credential and creates its own
Accept new eligibility terms	When the venue proposes them	`EligibilityTermsProposal_Accept`, on the live consent. A loosening takes effect only after the consent’s delay
Revoke its credential	When an investor it admitted must stop	`Credential_Revoke`, on its own credential: the venue cannot revoke it
Accept the supply terms	When the venue proposes them	The fund size cap, the daily issuance and redemption limits, and wind-down (`SupplyTermsProposal_Accept`). A loosening takes effect only after the ledger’s delay
Mint an order paid off the ledger	Each order	Accepts the investor’s mint request, naming the subscription, once its bank confirms the cash (`MintRequest_Accept`), or refuses it with a reason
Burn a redemption paid off the ledger	Each redemption	Accepts the burn request naming the claim (`BurnRequest_Accept`), or refuses it; the fund then pays the proceeds through its bank
Pay a distribution	Each period	Mints the period’s payout to itself and transfers each line of the venue’s frozen plan to its holder
Block a frozen investor	Each freeze on every asset	Lists the investor’s party on its registry’s block list, and takes it off once the venue lifts the freeze
Accept a backed instrument’s reserve	Once per reserve, with the reserve’s holder	Its standing consent to every mint and redemption against the reserve (`ReserveProposal_Accept`); another registrar whose asset the reserve holds signs its lock agreement once (`ReserveLockAgreementProposal_Accept`)
Accept a reserve’s new terms	When the venue proposes them	`ReserveTermsProposal_Accept`: a tightening at once, a loosening after the reserve’s delay. It also withdraws a par reserve’s excess to itself and closes a reserve with nothing outstanding
Agree to issuer powers	Once	Its standing agreement to forced transfers and recoveries (`PowersAgreementProposal_Accept`), which it ends in one act (`PowersAgreement_Terminate`)
Send its statement of holdings	On its schedule	Off the ledger: the register’s statement, by API or file, which reconciliation compares with the holdings

Each workflow shows these acts transaction by transaction: Set up an asset, Subscriptions, Redemptions, Distributions and period end, Holds, freezes and issuer powers and Reconciliation.

What it reads at the venue

Its own systems call the venue’s API under the registrar role: the parties the venue asks it to block (GET /v1/block-list), and the distributions it pays, with their frozen lines (GET /v1/distributions). The role reads nothing else, and signs nothing. Its statement of holdings reaches the venue under a feed client of its own, which posts statements and reads nothing.

What it never needs

No NodeAsset install and no part of the venue’s engine: every act above is its own, on its own node. Its key stays its own; the venue never holds it.

Internal or external

	Internal: the venue’s own issuance desk	External: another firm
Its party	Signs with its own key, never a local party on the venue’s Canton node	On its own node, or an external party on another firm’s
Its people	The issuance desk’s own staff, apart from the venue desk’s	Its own staff
Its acts	The same acts, the same way	The same acts, the same way

Architecture

Who runs what

Deploy

Operate

What it runs

What it approves and signs

What it reads at the venue

What it never needs

Internal or external

​What it runs

​What it approves and signs

​What it reads at the venue

​What it never needs

​Internal or external

What it runs

What it approves and signs

What it reads at the venue

What it never needs

Internal or external