$OPERATOR and $APPROVER are two bearers.
Tx 1 · The issuer creates the asset
The issuer configures the asset on its own registry, with its registry’s tooling, and requires a credential of every holder: its own, which its admission consent creates (Tx 5 and 6), or the venue’s. None of it goes through this API, and nothing is deployed for the asset.GET /v1/instruments/FUND/admission-consent answers whose the configuration requires (credentialIssuer, and credentialIssuerKind: register-keeper or venue).
Record the asset
The venue keeps this record off the ledger: the asset’s id on the registry, how it is valued, its price source, holder cap, distribution terms, and how people see it. It comes back pending until an approver approves it (four eyes).curl
valuation is rebasing for a fund whose units grow with its yield, par for a tokenized deposit or a stablecoin (with a currency), and accumulating for a backed instrument priced by its reserve, such as a note (Backed issuance).
currency is the ISO 4217 currency of the asset’s prices and values, whatever its valuation: a fund’s NAV, a deposit token’s unit. Every read that serves the asset’s display serves it beside it, and prices, portfolio totals, statements, distributions and tax statements carry it. A backed instrument’s reserve values its assets in one unit of account, its own.
Set its policy
The policy is replaced whole and versioned. Send the version you read asexpectedVersion (0 for the first). A stricter policy takes one approver and applies at once; a looser one takes two and waits out the timelock.
curl
admission.trustedIssuers, admission.requires, countries and investorTypes are also its admission consent’s terms. Once the consent is live, a change of them is proposed to the registrar with the policy, and the policy’s operation answers it under admissionConsent: terms with the terms proposed and when they take effect, or unchanged.
An asset is recorded with its market identifiers (ISIN, CUSIP, FIGI, the issuer’s LEI, and any other code such as its CFI, FISN or a national code), its legal name and the time zone of its business day.
GET /v1/instruments/FUND/policy reads the policy in effect and any version still to take effect. To try a rule before it bites, GET /v1/instruments/FUND/precheck answers the codes a subscription (act=subscription) or a transfer (act=transfer) would meet now, without acting. GET /v1/instruments/FUND/headroom answers what the policy and the supply ledger still admit: units under the fund size, investors under the holder cap, and the day’s issuance and redemption, and with holderId what that investor may still claim.
Tx 2 · Propose the standing consent
The standing consent is for an asset paid on the ledger. It names the asset, its treasury account (the asset’s cash account, its own party), the payment asset (such as a tokenized deposit or a stablecoin) and its decimals, and the price source (the asset’s recorded one when absent). An asset paid off the ledger has no consent and skips Tx 2 to 4.curl
oracle-is-manager) or the fund’s own registrar or treasury (oracle-is-issuer), if the treasury is the registrar, or if a consent in the same payment asset is already live or proposed. Neither the issuer nor the venue prices the fund: the consent’s own terms refuse both on the ledger too. A fund has at most one live consent per payment asset: to take a stablecoin beside a tokenized deposit, propose a second consent naming it.
Tx 3 and 4 · The registrar and the treasury sign
The fund’s registrar accepts the proposal on its DA Registry (Tx 3,PrimaryMarketProposal_Accept), then the fund’s treasury account accepts it from its own node (Tx 4). Each reads every term on its own node before it signs, and the consent binds nobody until both have signed.
GET /v1/primary-markets?instrumentId=FUND then shows the consent live, with who signed it; while it waits, awaiting names who has not.
Tx 5 · Propose the admission consent
For an asset that requires the register keeper’s credential. The admission consent takes its terms from the policy in effect: the KYC providers the registrar trusts (admission.trustedIssuers), the claims an admission needs (admission.requires), and the residencies (countries) and investor types (investorTypes) it admits. The call takes no body, and comes back pending until an approver approves it.
curl
admission-consent-exists), and for an asset the registry does not configure (not-on-registry).
Tx 6 · The registrar accepts
The fund’s registrar accepts the proposal from its own node (AdmissionConsentProposal_Accept), reading every term first, and makes the asset’s configuration require its own credential if it does not already. From then on it does nothing per admission: each admission creates its own credential about the holder, which it holds. GET /v1/instruments/FUND/admission-consent shows the consent live, with the terms in effect, any accepted change still to take effect, and the proposals still waiting on the registrar.
Next: Onboard investors · Back to the workflow: Set up an asset