Use Cases
Property and fund NAV first, and the same record designed for what follows.
The schemas name two asset types across four workflows today: an initial NAV and its updates, a property before listing and under review. A fund administrator would pass the receipt to an auditor, a lender would read it beside a valuation it did not commission, and the offline check needs no chain. Nothing in the record depends on which asset it is, so the same receipt could carry evidence about other real-world and financial assets as asset types are added.
Where it applies
Wherever a figure changes hands, the evidence is asked for again.
A valuation or a NAV is asserted once and then asked about many times — by a venue before a listing, by a lender against its own file, by an auditor later. The receipt records the policy applied, the documents it rested on and how each check came out, so each of them would start from that record.
The asset
The evidence behind a NAV or a valuation would arrive with it.
Property valuation
The receipt names the documents the valuation rests on and the outcome of each check, so a lender reading it later would see what was tested without the appraiser's files being published.
Fund NAV
An initial NAV and each update would get a receipt of its own, tying the figure to its source documents and to the figures it must agree with, so a question about why it moved would land on one record rather than on a mailbox.
The platform
A platform could show what was checked without publishing the evidence.
A listing would point to its registry entry, with the policy, the verdict and the reason codes, so an investor would see on the listing itself what was checked, without a document request. The check runs against the bundle a venue already holds: it needs no operated registry, and none is operated today.
Before onboarding
A venue would check the bundle against the listed registry entry, offline, and catch a document changed after sealing before it reached the listing. It fails against the manifest (L1), or against the entry (L2) if the manifest was rebuilt.
Issuer authorization
The trust registry limits each issuer key to named asset types and workflows, and the verifier enforces that limit (L3), so a receipt signed outside an issuer's remit fails on a named reason rather than passing as one more record.
Integrations
A figure would reach the next system with its record attached.
Fund reporting systems
A receipt would travel with each periodic NAV update, so investors and auditors would see how it was checked.
Blockchain networks
A public chain could show that a record existed by a given time, without resting on either party's word: it would carry the anchor for the transparency log's head, which covers every entry in the log.
What follows
The record does not change shape when the asset does.
Property and fund NAV come first by choice: depth before breadth, both carried to institutional quality before anything is added. Another asset type would be added as a new version of the protocol, through its proposal process.
The same objects, a different asset
To the receipt, the registry entry, the reason codes and the four verification levels, the asset type is one field among the rest. A NAV correction or a revalued property produces a new receipt.
Assets that were never tokenized
The object model contains no token, so the same path covers an asset that was never tokenized. A fund administrator handing a receipt to an auditor would need no chain, no anchor and no deployed registry.
Widening the vocabulary
The lists of allowed values are closed on purpose, so a verdict means the same thing in every entry. Adding to them takes a new version of the protocol, through its proposal process.
Workflows in scope
The same documents go out twice on a fund NAV or a property review.
Name the two institutions it runs between, such as an administrator and an auditor, and the documents that go out again each time. A receipt records what was already checked, so the first thing to work out is which of those documents a second reviewer would no longer need.