Security and limits
Security and limits
Each receipt names the policy and version applied and the reason codes behind the outcome, so a reviewer sees why a check passed, warned, needed review or failed. The documents remain in the issuer's custody, and the registry entry carries no evidence. No independent cryptographic review of the protocol or the verifiers has taken place.
- A receipt cites its reason codes from a versioned catalog of 57, and names the policy and its version.
- The registry entry carries no document, no figure and no evidence.
- Vulnerability reports follow the SECURITY.md of the affected repository; the process is set out below.
Principles
Reading a receipt
Coded reasons
Each outcome cites codes from a versioned catalog, so a reviewer sees why a check passed, warned, needed review or failed.
Changes between receipts
A change summary records what moved between two receipts for the same NAV or valuation, so a reviewer does not compare them by hand.
Reproducible checks
Given the same bundle, registry entry, trust registry, trust root and evaluation time, a second reviewer gets the result the first one saw.
Named policies
Every receipt names its policy and version, so outcomes under one policy can be compared and a change of policy is visible.
Disclosure
What the registry entry discloses
The issuer keeps the bundle. The signed registry entry holds just enough for an auditor who is shown the bundle to confirm the two belong together.
With the issuer
- Source documents and canonical inputs
- The asserted figure, such as a NAV or a valuation
- Addresses, tenant data and metrics such as LTV
- The issuer's private signing key
- The verification receipt and its summaries
In the registry entry
- Receipt, issuer and entry identifiers
- The identifier of the issuer key that signed it
- Manifest and receipt hashes
- Policy identifier and version
- Verdict and reason codes
Outside the protocol's scope
- It computes no values. It does not show that the asset exists or that the NAV or valuation is correct. It shows who stated what, on which documents, and that the files are the ones the signed registry entry commits to.
- It issues no tokens, puts no evidence on a chain and is not a price oracle.
- It is not a custodian.
- It does not replace a reviewer's judgment or an auditor's opinion.
- It is not a compliance system: no legal opinion, audit or certification stands behind it, and it performs no KYC or AML checks.
Cases
Reviews without the documents
In each case below, which is hypothetical because no organization uses receipts today, a reviewer would need to see how a NAV or a valuation was checked, and the documents behind it would go no further than their holder allows.
A fund administrator could hand the evidence behind a NAV to an auditor between two audits, without sending every document.
A lender or servicer could rely on a collateral valuation it did not produce and cannot see the files behind.
A venue could list a tokenized asset and show what supports its reported values without publishing the documents.
A compliance team could review an asset before onboarding it and would need to know which checks ran, under which policy.
Release 0.1
Known limits of release 0.1
No independent cryptographic review of the protocol or the verifiers has taken place. The maintainer's own testing, carried out with the help of AI tools, is internal verification and not an audit. The verdict path of both verifiers contains no AI: no machine-learning model takes part in any outcome.
The protocol itself has these limits in release 0.1. Each is stated in the specification where its rule is.
The envelope in the bundle is not authenticated. Nothing the issuer signs commits to it, so its subject, anchor and provenance members, and any registry entry embedded in it, can be rewritten without a key and the run still passes.
A pinned trust root has no scope. It names no issuer, operator or trust registry, so every pinned root can authorize a key for every issuer.
The opening of the subject reference is not verified. A bundle may carry it, but no check recomputes the subject reference hash from it, so a run passes whether or not it opens the entry's commitment.
No signing time is attested. The operator's clock says whether a key is in its window now, not when an entry was signed, so a PASS does not say when an entry was signed.
The documentation site lists these limits with what an operator can do about each.
Security
Report a vulnerability
Open the Security tab of the affected repository on GitHub and choose Report a vulnerability. If that is not available to you, write to security@loquitur.dev. Describe the affected surface, the steps to reproduce it and its impact on the protocol, the verifiers or this website. Keep the details out of public issues.
The maintainer acknowledges a report within 5 working days, and gives an assessment of its scope within 10.
The maintainer agrees a disclosure date with the reporter before anything is published.
The reporter is credited unless they ask not to be. Fixes land on the default branch, with no backports.
Scanning beyond read-only requests to public pages is not permitted, and the project offers no bug bounty.
Disclosure
Questions about disclosure
Write to the maintainer about which documents stay with the issuer and what a reviewer still needs to see.