Verification protocol
An open protocol for checking the evidence behind NAVs and property valuations
The issuer signs a record of the checks it ran on its evidence. Anyone given the files can run the checks again, offline. A PASS means the files match what the issuer's signed registry entry commits to; it says nothing about whether the NAV is correct.
Status: the specification, the schemas, the conformance corpus and the two verifiers are published as an Alpha preview. Their interfaces can still change.
Receipt
Receipt contents and boundaries
What it records
The policy and the version the evidence was checked under.
The status, and the reason codes it follows from.
The digest of every file in the evidence bundle, through the manifest.
Who signed the registry entry, and with which key.
What changed since the previous receipt, in the change summary.
What it does not do
It forms no opinion on value and does not say whether a NAV or a valuation is correct.
It does not replace the valuer, the administrator or the auditor, or their professional judgment.
A PASS means the evidence matches what the issuer's signed registry entry commits to. It does not mean the inputs were true.
It does not check facts outside the bundle, and it cannot detect false data the issuer signed.
It relies on the keys the trust registry authorizes and cannot detect a compromised issuer key or trust root.
The problem
Checking starts again at each handover
The protocol starts from one premise: a NAV or a valuation is checked again at each handover, and nothing in the file says what was already checked.
The documents stay with the producer
A NAV moves from administrator to auditor, and a valuation from valuer to lender. The documents behind each stay confidential with whoever produced it.
Checking starts again
Where the next reviewer has no way to reuse the last review, the same NAV is checked from its source documents again.
A PDF has no record of the checks
A PDF or a spreadsheet shows the number. It does not show which policy was applied, what was checked or what changed since the last review.
Worked example
Five runs over one property valuation bundle
Each row is a case from the conformance corpus, run on a sample bundle with its registry entry, the trust registry and a pinned trust root. Both verifiers return the verdict shown.
- 01
Structure
The files the manifest names are present, and each object has exactly its closed set of fields.
- 02
Integrity
Every file digest recomputes to the value in the manifest, and the manifest digest to the value the envelope declares.
- 03
Link
The registry entry commits to this receipt and this manifest, and to no other.
- 04
Authorization
The key that signed the entry is authorized in the trust registry for this asset type and workflow at the evaluation time, and the pinned trust root authenticates the trust registry.
| Case | Checks established | Verdict | Report reason |
|---|---|---|---|
| All files intact; entry, trust registry and pinned trust root supplied | structure, integrity, link, authorization | PASS | local_integrity_registry_link_and_trust_checks_passed |
| One file of the bundle changed after sealing | structure | FAIL | p1_integrity_failed |
| The registry entry states fund_nav where the receipt states property | structure, integrity | FAIL | registry_link_verification_failed |
| The signing key is authorized for fund NAVs only | structure, integrity, link | FAIL | trust_registry_verification_failed (ISSUER_KEY_SCOPE_MISMATCH) |
| No trust root is pinned | structure, integrity, link | REVIEW | trust_registry_root_not_pinned |
Conformance
Two verifiers, compared on one corpus
The Python and TypeScript verifiers are run over the same conformance corpus. For each case the corpus declares the expected outcome at each of the four checks: structure, integrity, link and authorization. A report that differs from it is a failure.
| Input | Run against | Expected |
|---|---|---|
| 1093 verification runs | The Python and TypeScript verifiers, each through an adapter | The declared outcome, check by check |
| 54 schema documents that must be rejected | The schemas, and a separate JSON Schema validator | Rejected by each |
| Disagreements recorded in the baseline | 0 | |
- RFC 8785
JSON Canonicalization Scheme: one document has exactly one byte sequence, so two parties signing the same object sign the same bytes.
- SHA-256
Every digest in a document is written as sha256: followed by 64 lowercase hexadecimal characters, and is compared as the whole string.
- secp256k1 ECDSA
Signatures must be low-S and are made over a message that starts with a fixed domain prefix, so a signature made for one context does not verify in another. Reference signing uses deterministic nonces (RFC 6979); a verifier cannot check that.
Where it fits
Two asset types, four workflows
The specification registers two asset types, each with two workflows. The receipt has no field for a token: a tokenized fund and an untokenized fund are checked the same way. No organization uses these workflows in production.
Initial NAV
The issuer checks a NAV under a named policy when it is first struck. The receipt records the policy and the result. The source documents stay with the issuer.
NAV update
Each later NAV is checked under the same policy. An auditor could run the offline checks on the bundle of any update without waiting for the next audit.
Property before listing
A property valuation is checked against its source documents before the asset is listed. The receipt records what the check covered, so a lender or a venue could read it without asking for the documents.
Property under review
A collateral or portfolio valuation is checked again later. The change summary shows what moved since the previous receipt.
Who it is for
Who it is for
Relying parties
Banks, insurers, lenders and trading venues that receive a NAV or a valuation they did not prepare. The receipt shows which checks were run on the evidence, under which policy, and with what outcome.
Evidence producers
Fund administrators, valuers and servicers who prepare the documents behind a NAV or a valuation. The bundle holds those documents once, in one structure, and the issuer chooses who receives it.
Engineers and integrators
Teams that run the verifiers where receipts are received and, once a producer exists, where they are issued. The schemas are closed and the four checks run offline.
Questions
A NAV or valuation workflow in mind
Write to the maintainer about it, or read the specification and the status page first.