Verification protocol
A verifiable record of how an asset figure was checked.
When a NAV, a property valuation or a collateral figure passes to another party, Loquitur is designed to record what was checked, under which policy and with what verdict. The issuer would keep the evidence bundle and sign a minimal commitment to the verification receipt, called its registry entry. A counterparty holding the bundle could confirm offline that the bundle is intact and matches that entry, and that the entry was signed by an authorized key.
The problem
Whoever receives a figure has to trust it or redo the work.
The figure reaches its next reader as a document, and the evidence behind it does not.
Figures travel without their evidence
A NAV moves from administrator to auditor, and a valuation from appraiser to lender, while the documents behind each stay confidential with whoever produced it.
Every recipient starts again
The same figure can be re-checked from the source documents several times over, because a recipient rarely has any way to reuse another's review.
A file does not record the check
A PDF or a spreadsheet shows the figure. It does not show which policy was applied, what was checked or what changed since the last review.
The receipt
Later reviewers would all read the same record of the check.
The policy and version applied, so a reviewer knows which rules the figure was checked against.
A status that follows from its reason codes, instead of an unexplained approval.
What supports the figure: whether it is asserted, backed by a document, located in it and consistent with the other figures.
The manifest hash, which covers every file's digest. The signed registry entry carries it too, so a later change to the evidence can be detected.
Cross-implementation conformance
Two separately written verifiers, compared case by case.
A Python verifier and a TypeScript verifier run over the same conformance corpus, and an automated gate compares their reports field by field on structure, integrity and the schema contract. The gate fails on any disagreement. It does not yet compare the link (L2) or authorization (L3) checks, and its corpus was written within the project.
| Input | Run against | Cases |
|---|---|---|
| Adversarial vectors | 4 checkers: both verifiers, the schemas package and a schema oracle | 36 |
| Bundle cases | Python and TypeScript verifiers | 7 |
| Disagreements reported | 0 | |
- RFC 8785
JSON Canonicalization Scheme: one document has exactly one byte sequence, so two parties signing the same object sign the same bytes.
- RFC 6962
Merkle inclusion and consistency proofs, as used by Certificate Transparency and specified here for the transparency-log level (L4).
- secp256k1 ECDSA
Low-S, RFC 6979 nonces and a NUL-delimited domain prefix, so a signature made for one context does not verify in another. Neither verifier signs.
Where it fits
A tokenized asset is checked like any other.
Two asset types are in scope, each with two workflows: a fund NAV when first struck and at each update, and a property before listing and under review. The object model contains no token.
Initial NAV
A NAV checked under a named policy when it is first struck, with its source documents kept by the issuer.
NAV update
Each later NAV checked under the same policy, so an auditor could verify each update's bundle between audits instead of waiting for the next one.
Property before listing
A property valuation checked against its source documents before the asset is listed.
Property under review
A collateral or portfolio valuation checked again later, with a change summary showing what moved since the previous receipt.
Who it is for
Teams on both sides of a handoff, and those who fund or study the protocol.
Fund administrators & auditors
NAV evidence handed from the administrator to the auditor.
Lenders & servicers
Mortgage lenders and servicers relying on collateral valuations produced by an appraiser.
Platforms & trading venues
Tokenization platforms, transfer agents and venues that need evidence one party could check without trusting another.
Integration partners
Platforms and administrators that would produce receipts where figures are issued, or run the verifier where they are received.
Investors & grant providers
Funders assessing the protocol and its current state.
Researchers & public programs
Universities and public bodies that study financial infrastructure.
Get in touch
Start from one figure that is checked more than once.
For example, a NAV reviewed again at each update, or a valuation that a lender and then a servicer rely on.