Producing prices is the price source’s job; using them safely is NodeAsset’s. The price source signs every price an order settles at: for a fund, its administrator; for a commodity, its price provider. An asset at par, such as a tokenized deposit or a stablecoin, has none, and a product issued against collateral takes its collateral’s. It is always a party of its own, never the venue’s, nor a fund’s own register keeper or treasury. How the venue names it and checks each price is on Price source and oracles.

​
What it runs

​
What it signs

The order is recorded before its NAV is known, and the price source prices it once its dealing point has closed (forward pricing). The fund’s consent takes a price only from the price source it names, so the price source signs nothing in the settlement itself. Who signs each transaction is on Price the asset.

​
The Oracle interface

Every NAV that moves value is read through one Daml interface, Oracle, in the package nodeasset-oracle-api. Its view is the asset (instrumentId), the NAV (nav), the withholding rate (withholdingRate) and the time it is as of (asOf). Reading a point checks that the asset’s own price source signed it, for that asset, with a NAV above zero and a rate from 0 up to, but not including, 1.
  • PublishedNav, in nodeasset-oracle, is the smallest template that implements it, and the default.
  • A template of its own implements Oracle, is signed by the price source alone, and names the venue’s party as an observer, since the venue reads what its party can see. The venue sets venue.parties.oracle-template to its name.
  • CAPS, if it publishes that way: the price source derives a capsule from its own CAPS feed, and an adapter template it signs presents the capsule as a NAV point behind Oracle, adding the asset and the withholding rate. A capsule anyone else derived prices nothing. The same capsules can share the fund’s NAV with lenders and distributors, one capsule each.
NodeAsset ships the interface and PublishedNav; no NodeAsset package depends on CAPS.

​
Its NAV feed

Off the ledger, the price source sends its official NAV to the venue’s engine with what a signature cannot carry: an expiry and a kill switch. The engine checks the feed against the ledger’s NAV and holds the asset when they disagree, when the NAV expires, or when the kill switch is pulled (what the venue does with it). The venue gives the feed a client of its own at its identity provider, in the feed role, which posts statements and reads nothing, and names the source it posts to.

​
By API

Post each NAV as canonical JSON to the source. The examples use $ENGINE for the venue’s engine and $FEED for the feed client’s bearer. The same bytes again answer 200 with the statement already stored, so a retry is safe; a new statement answers 201 with the reconciliation run its arrival started.
curl
Retry a 5xx or a lost answer. Set a 4xx aside with its problem: the same bytes get the same refusal. Decimals go as strings or plain JSON numbers.

​
By file

A price source that sends files writes each one in the same JSON. A connector of the deployment’s own posts each file whole, in name order, under the feed’s client, and keeps the engine’s answer beside it. A correction goes in as a new file; a file already sent is never edited.

​
What it sees, and never needs

It sees the orders and claims it prices, and its own prices; never holdings, or the legs of a settlement. It never needs the venue’s engine or a NodeAsset install: it signs on its own node and posts its feed. Related: Price source and oracles · Price the asset · Pricing