Parties and the DA Registry

The parties

Party	Who it is	Signs
	Your institution, through the engine: the Registry’s provider for its assets	Admissions (it issues each holder’s credential where the asset takes the venue’s, and admits under the registrar’s consent where it takes the registrar’s), settlements as their executor, each reserve with the issuer and the reserve’s holder, proposals
	The asset’s registrar: a fund’s transfer agent, or the issuer of a payment asset (a bank for its tokenized deposit, the issuer of a stablecoin)	Mints and burns, the reserves it accepts and their terms, the fund’s standing consent, and its admission consent, under which its own credential about each eligible holder is created
	The fund administrator	Its NAV points, and the price of each order
	A holder, through its custodian’s wallet	Its own allocations, and its acceptance of each admission to an asset that takes the venue’s credential
A reserve’s holder	A party of each reserve’s own, hosted by the issuer or a custodian it appoints	Its reserve, beside the venue and the issuer; it owns every reserve holding
Another registrar	The registrar of an asset a reserve holds, on its own node	Its lock agreement, once: the reserve may lock and merge its asset’s holdings, never transfer them
DA’s operator	Digital Asset, on its own node	The Registry’s configuration; it observes every allocation and settlement on its registry

A fund’s treasury, the account its payments land in, is a party of its own that signs the fund’s standing consent beside the registrar.

Who signs what

The engine acts as the venue’s party alone and holds no other party’s key, so every command it submits is that party’s.
Only the registrar creates units: the venue’s party can propose an issue but cannot mint one.
Where an asset requires the registrar’s credential, the venue’s party asks for each admission but cannot issue the credential. The ledger creates it under the registrar’s admission consent, which the registrar signs once, and only for a holder whose KYC credentials from the providers the registrar trusts meet the consent’s terms. The credential is the registrar’s own: issued and held by the registrar, naming the holder, so the holder and its custodian accept nothing. The venue cannot set when it ends or revoke it; the registrar can.
The issuer’s and the holder’s signatures on a reserve are their standing consent, which covers each mint and redemption at the amounts the investor allocated, never at an amount named later.
A reserve’s holdings are its holder’s own, locked to the venue, the issuer and the holder together: none of them can release one alone, and only the reserve can.
Every price that moves value is signed by the price source on its own node. The venue reads prices and cannot set one.
An investor’s units move with its consent, through its custodian’s allocation. For an investor that consented in advance, the venue’s party can also move them alone, in a forced transfer or a recovery, under the registrar’s standing agreement; the registrar ends that agreement in one act.
A role lets a person or a system ask the engine for an act. The ledger decides whether it happens, because each party authorizes its own part on its own node.

Whoever takes over the engine can propose acts but cannot create a unit, set a price, or admit a holder to an asset that requires the registrar’s credential outside the registrar’s terms. The engine’s one direct power over holdings, moving a consenting investor’s units, lasts only while the registrar’s agreement stands, and reconciliation matches every move to the operation that approved it. Each workflow page shows these signatures transaction by transaction; see Actors and roles and, for who decides each kind of change, Duties and governance.

The DA Registry and NodeAsset

The Registry knows units: who holds how many, and whether a party may hold them. NodeAsset knows what the units mean: which order a mint was for, what backs a product, whom income is owed to, and whether a mint should have happened at all.

Area	The DA Registry provides	NodeAsset adds
Assets	The registrar defines each instrument: its id, outside identifiers such as an ISIN, and the credentials a holder needs	A record of the asset under four eyes: how it is valued, who prices it, its holder cap, its distribution terms and its display
Credentials	An allowlist per instrument, checked on every mint, burn and transfer	Admission within the asset’s holder cap, each holder’s credential carrying its eligibility claims: the registrar’s, created under its admission consent once the ledger has checked the holder’s KYC claims against its terms, or the venue’s, carrying the claims the venue recorded and its validity
Block list	Parties the registrar blocks, refused on mint, transfer and burn	The parties the venue’s freezes name, for the registrar to block
Mint and burn	By request and acceptance	Every mint and burn must be planned: a delivered order, a claimed redemption or a distribution line. Anything else stops the book
Transfer	Offer-and-accept and pre-approved transfers, checked against credentials	Settlement with NodeAsset’s checks in the same transaction; a transfer between two holders outside NodeAsset is detected and graded
Settlement	One batch per registry (CIP-112)	Batches on two registries in one transaction, under the fund’s standing consent

The Registry checks each act as it happens: does the acting party hold the credentials the asset requires, is it blocked, are its holdings locked. NodeAsset checks the acts themselves: was the mint planned, is the product still covered, is the investor within the asset’s policy, do the outside records agree. Reconciliation runs these checks on a schedule and on demand, and a blocking finding stops the book until people release it.

What each party runs

Every other party acts as its own party, on its own node, through its own wallet, registry tools or NAV system. NodeAsset never acts for another party: the engine holds the venue’s party alone, and the venue never holds a register keeper’s, a treasury’s or a price source’s key. What each party runs, signs and vets is on its own page: Register keeper · Price source · Bank and payment registry · Custodians and investors. Deployment patterns gives the rules that make any combination of parties valid. Related: Architecture · Who sees what · Duties and governance

Architecture

Who runs what

Deploy

Operate

Parties and the DA Registry

The parties

Who signs what

The DA Registry and NodeAsset

What each party runs

​The parties

​Who signs what

​The DA Registry and NodeAsset

​What each party runs

The parties

Who signs what

The DA Registry and NodeAsset

What each party runs