Use cases
Use cases
The specification registers two asset types and four workflows. No organization uses them in production. For each workflow, the sections below show who prepares the NAV or valuation, who receives it and what the verifier checks.
- Asset types: fund_nav, property.
- Workflows: fund_nav_initial, fund_nav_update, property_pre_listing, property_review.
- Registry entry verdicts: PASS, WARN, REVIEW, FAIL. A verifier reports PASS, REVIEW or FAIL.
Where it applies
Assets, platforms and integrations
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. A receipt would record the policy applied, the documents it rested on and how each check came out.
The asset
A receipt goes with the NAV or the valuation it describes.
Property valuation
The receipt fixes the documents by the manifest digest and records the policy, the status and the reason codes. A lender reading it later could see what was checked, with the valuer's files left unpublished.
Fund NAV
An initial NAV and each update could have a receipt of its own, tying the NAV to its source documents. A question about why it changed starts from the receipt and its change summary.
The platform
A platform can point to a registry entry instead of publishing evidence
A listing could point to its registry entry, with the policy, the verdict and the reason codes, so an investor could see what was checked without a document request. The check runs against the bundle a venue already holds. It needs no transparency log, and the project operates no registry or log. No platform does this today.
Before onboarding
A venue checks the bundle against the listed registry entry, offline. A document changed after the check fails the integrity check, or the link check if the manifest was rebuilt.
Issuer authorization
The trust registry limits each issuer key to named asset types and workflows, and the authorization check enforces that limit. An entry signed outside an issuer's remit fails on a named reason.
Integrations
Reporting systems and anchoring
Fund reporting systems
A receipt could accompany each periodic NAV update, so investors and administrators could see how it was checked and which policy applied. No reporting system does this today.
Anchoring(planned)
Anchoring is reserved and not implemented. It would place a commitment where the operator cannot retract it, so the time and content of a publication are attested from outside the protocol.
In review
What changes in a review
No saving of time or cost has been measured. A receipt records what the last review covered, so the next one could start from there.
Before the review
The receipt records the policy, the status and the reason codes. A reviewer could start from what the receipt leaves open instead of re-establishing what the last review covered.
During the review
An issuer that shares the bundle would share the documents already assembled for the first check, in the same structure. Change summaries record what moved between versions.
After a change
A document changed after the check fails the integrity check. If the manifest is rebuilt to match, the failure moves to the link check against the registry entry. Reason codes name what failed.
Years later
A registry entry still shows the verdict, the reason codes, the policy and its version and the signer. It holds none of the documents and no figure.
Asset types
Two asset types, registered in versioned lists
Property valuations and fund NAVs are the asset types registered in this version. The receipt, the registry entry and the four checks are the same for both, and the authorization check reads the type only to test an issuer key's scope. An asset type or workflow the verifier does not know makes the run REVIEW rather than PASS, and a value that is not a well-formed identifier makes it FAIL.
The same objects for each asset type
To the receipt and the registry entry, the asset type is one field among the rest. A NAV correction or a revalued property produces a new receipt, linked to the one it replaces.
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 needs no chain, no anchor and no transparency log.
Workflows in scope
A workflow you want to discuss
Write to the maintainer about the two institutions it runs between, such as an administrator and an auditor, the documents that go out each time, and the checks the second reviewer repeats.