Skip to main content
The auditor / verifier is the single most important library EnfinitOS publishes. It is open source under MIT in three published repositories:
Don’t trust us. Verify. The library is offline by default — it does not call EnfinitOS or any third-party service. Anyone can fork it, audit it, fuzz the parser, and ship it inside their own compliance pipeline.

What it verifies

A proof pack is a signed, hash-chained document. The auditor does four things against it:
  1. Ed25519 signature against the published EnfinitOS verification key.
  2. SHA-256 hash chain walked end-to-end for the tenant.
  3. Metering re-projection from the source events embedded in the pack — re-running the same projection the platform settled against.
  4. Settlement reconciliation re-run, asserting bit-identical output.
Any failure on any step fails verification. The auditor never “warns” — it either verifies cleanly or it doesn’t.
Use SDK 0.0.4 or later. Settlement verification is version-aware: current packs are stamped settlement.v2 (3-field content-hash idemKey — sha256(meterRecordIdemKey|partyRole|ledgerAccountCode)) and historical settlement.v1 packs still verify under their legacy 2-field key. Earlier published SDK versions predate settlement.v2 and report SETTLEMENT_IDEM_KEY_MISMATCH on every line of a current pack. 0.0.4 also adds signed-export verification (verifySignedExport / verify_signed_export) for the ?export=true metering/settlement envelopes, and cross-pack chain anchoring via priorAfterHash — pass the previous pack’s tail afterHash when verifying a later pack in a tenant’s sealed series.

Rights-provenance signatures

The platform also signs every rights-provenance record — the basis, right, offer, and challenge lifecycle rows — with Ed25519 at write time, and the auditor verifies those signatures independently of any pack. This checks who wrote each row; the hash-chain walk checks where it sits in history. Run both. The signing input is a flat pipe-delimited string — not canonical JSON — so a verifier in any language reconstructs the exact bytes:
with - encoding absent fields. One entry point per language:
  • TypeScriptverifyProvenanceChain from @enfinitos/sdk-auditor
  • Pythonverify_provenance_chain from enfinitos_auditor.provenance
  • Rustenfinitos_auditor::provenance::verify_provenance_chain
The report partitions signed from unsigned records, so “N of M records carry write-time signatures” can be quoted directly. Records written before write-time signing existed (legacy hmac-sha256 rows) report an informational SKIPPED — there is nothing write-signed for an independent party to verify — never an INVALID. Existing exports keep verifying unchanged.

Three language implementations

Byte compatibility

All three implementations are byte-compatible against a shared conformance fixture set. A proof pack that verifies under the TypeScript implementation must verify byte-identically under the Python and Rust implementations. The canonical fixtures are in the sdk-auditor-ts repository under __tests__/fixtures/.

Verification key rotation

The verification key is published — and rotates on a published schedule — at Verification keys. Rotation windows are at least 90 days so offline auditors have time to pick up the new key without service interruption.

Contributing

PRs welcome. Especially:
  • Fuzzers for the proof-pack parser (fast-check, Hypothesis, cargo-fuzz).
  • New language bindings — Go, Java, C#, Swift, Kotlin. Match the conformance vectors and we’ll review.
  • Conformance-suite additions — edge cases around chain breaks, signature mismatch, and metering re-projection.
See CONTRIBUTING.md in each repo (ts, py, rs).

Security disclosure

If you find a vulnerability, do not file a public issue. Email security@enfinitos.com. Full policy in SECURITY.md in each repo (ts, py, rs).