Same inputs, same hash
Given the same inputs, canonicalization produces the same bytes and the same hash, so two parties can compare their results.
End-to-end workflow
Follow one valuation or NAV update, stage by stage.
A NAV that arrives as a bare number gets its documents requested again. This one would go through seven stages, from the issuer's documents to the parties that rely on the result. The issuer would assemble the evidence, check the figure against its declared reference, record the policy and the verdict in a receipt, and sign an entry that commits to it. An auditor or investor who receives the bundle would take it from there, without having to reach the issuer.
The flow at a glance
Only L4 and L5 would need an operated log and anchor.
Policy is applied on the issuer's side, and L0 to L3 are checked offline, on the verifier's own machine. The registry, its transparency log and the anchor belong on the public side.
Stages
The issuer works through five stages; an investor or auditor would take the last two.
Issuer inputsDocuments, claims and policy
Business
In the protocol, the issuer is whoever produces the figure: a fund administrator, an appraiser or a tokenization platform. Its inputs are the source documents, the figures they support, and the policy that defines an acceptable result.
Technical
Inputs are typed: documents, structured claims (each an assertion with an explicit support basis) and a versioned policy.
Policy evaluationPolicy applied, status recorded
Business
The issuer writes and versions its own policy and applies it to its evidence. A claim like "the NAV is X" comes out as a status, with reason codes that say why. Whether the figure itself is right stays the reviewer's call.
Technical
Inputs are canonicalized with JCS (RFC 8785) and hashed with SHA-256. The policy then produces a status (pass, warning, review or fail) and versioned reason codes; the registry entry states the same result as a verdict (PASS, WARN, REVIEW or FAIL).
Evidence bundleHeld by the issuer
Business
The documents, the inputs and the result are packaged into one portable bundle. It stays with the issuer, who decides whom to share it with.
Technical
The bundle is a directory or ZIP archive holding the canonical inputs, the supporting documents, the policy outcome, a change delta and a manifest of SHA-256 file digests. Every file must be declared in the manifest, and an undeclared file sends the run to review.
Canonical objectsStandard summaries
Business
An auditor or investor usually asks four things: what passed, what changed, what came before, and what is covered or missing. The protocol defines one standard summary for each, derived from the bundle.
Technical
The schemas define the canonical objects. The review is described by verification_summary, verification_receipt, change_summary, lineage_summary and coverage_summary; the public side by registry_entry, the signed commitment, and trust_registry. The registry entry commits to the receipt by its hash.
Registry commitmentPublic, minimal
Business
The issuer signs a minimal record that a verification took place, under which policy and with which result. The record reveals none of the evidence.
Technical
A registry_entry is a signed projection of the receipt: receipt id, issuer id, manifest and receipt hashes, policy id and version, verdict, reason codes and signature, plus an optional anchor field. The trust registry lists authorized issuers, their public keys and the asset types and workflows each key may sign for, and authorization is checked against it offline.
VerificationOffline: integrity, link, authorization
Business
Without calling the issuer or any server, an auditor would learn whether the bundle in hand is the one the issuer committed to, and whether the issuer's key was allowed to sign that commitment.
Technical
The protocol defines six levels. L0 and L1 read the bundle alone and rebuild the manifest hash, with no network. L2 takes the bundle and the registry entry and confirms the cryptographic link between them: the commit-and-reveal check. L3 checks the issuer's signature against the trust registry and distinguishes revoked, suspended, expired, not-yet-effective and out-of-scope keys, so an authority failure is reported separately from an integrity failure. For L4 (log inclusion) and L5 (anchor finality) there is no operated log or anchor yet.
Who relies on the resultInvestors, platforms, auditors
Business
An investor about to allocate, a platform listing the asset and an auditor checking each update would all rely on the same receipt, without needing one another's systems.
Technical
The verifier's checks (L0 to L3) are deterministic: given the same bundle, registry entry, trust registry and evaluation time, they produce the same report.
Architecture
The evidence stays with the issuer; only a commitment would be public.
The boundary runs between the issuer's own environment and a public registry.
An entry commits to the receipt's existence and integrity; the issuer would share the bundle itself only with the reviewers who need to check it.
The history stays private too, in the issuer's summaries: an entry names no earlier entry, so each check crosses the boundary on its own.
Why a registry
A registry would keep a record a verifier cannot.
A public registry would answer a question the files leave open: when a result was recorded.
A verifier answers for the party holding the files, at the moment it is run: these documents match this manifest, this manifest matches this entry, and the key that signed it was authorized for this asset type and workflow. Every one of those answers comes from the two things in that party's hands, which is what makes the check offline.
What no verifier can answer is the question that arrives years later, from someone who was not there: did this receipt exist before the outcome it reports became convenient. An issuer holds its own evidence, so it can run a policy, dislike the result and commit only to a later one. Nothing in the files contradicts that, because the files are the issuer's.
A registry is where that question would be settled, and it is a different kind of object: append-only, shared by many issuers, and read by parties who are shown no evidence at all. Ordering is the whole of what it adds. An entry commits to a receipt without carrying it, so a register of entries would show that a check happened and when it was recorded, and still disclose nothing about what was checked.
The offline levels stand alone and need no registry. Log inclusion and anchor finality are specified, but someone would have to run the infrastructure they depend on, which is why the implementation status page lists them separately.
- 01
A verifier
Answers for the party holding the files, at the moment it is run.
- 02
The later question
Did this receipt exist before the outcome it reports became convenient?
- 03
A registry entry
Commits to a receipt without carrying it.
- 04
The register
Would show that a check happened and when it was recorded, and disclose nothing about what was checked.
Design principles
Five rules the design holds to.
Even a pass carries a reason
A pass must cite at least one informational code and list the checks that ran.
No silent overwrites on the issuer's side
An update produces a new receipt, and the change and lineage summaries name the earlier bundle the new one supersedes. They stay with the issuer, and the history they carry is extended, never rewritten.
No server needed
Verifying a bundle needs no server and no network: only the bundle, its registry entry and the trust registry.
Entries are append-only
The specification requires the registry to keep every committed entry and forbids the operator to edit one.
Download
A PDF to pass around before the review.
The diagram and the seven stages, each with its business and technical reading.