Cryptographic Integrity Layer

Cryptographic Audit Infrastructure

QUORUM does not ask auditors to trust its records. Each decision is recorded before it is returned and sealed into a signed, hash-chained ledger, and QUORUM produces proofs that a third party can check with public keys and standard algorithms.

01
The Evidence Chain

A decision is linked to the signed ledger in four steps. Each step can be checked on its own; together they show that a specific decision was recorded, when, and that it has not been changed since.

1
Decision record
canonical · hashed before the verdict is returned

Verdict, score, flags, reference, time and a SHA-256 digest of the inputs — never the raw inputs — serialised canonically and hashed. If the record cannot be stored, no verdict is issued.

2
Merkle batch root
every few seconds · per institution

A sealer places each institution's new records under a Merkle root. An inclusion proof for one decision is a short list of SHA-256 hashes (O(log n)).

3
Signed ledger entry
hash chain · Ed25519 + ML-DSA-65

The batch root is appended to the audit ledger. Each entry carries the previous entry's hash and two signatures — Ed25519 and the post-quantum ML-DSA-65 (FIPS 204) — and both must verify. A scan every 15 minutes detects broken links or signatures and raises an alert; it never repairs or re-signs.

4
RFC 3161 timestamp
external time anchor · when configured

When a timestamp authority is configured, the ledger's Merkle root is timestamped every 100 entries. The authority receives only a hash. Tokens are verified against pinned authority root certificates.

02
Proofs Available to Institutions
Decision proof

Record → batch root → signed ledger entry → ledger root (→ timestamp), for any decision ID.

GET /audit/decision-proof/{id}
Ledger inclusion proof

Merkle proof that a ledger entry is under a published root, checkable with SHA-256 alone.

GET /audit/inclusion-proof/{logId}
Zero-knowledge score proof

A Bulletproofs range proof that a decision's score was within stated bounds, without revealing the score. Bound to the decision and its record hash and signed by QUORUM. No trusted setup.

POST /compliance/zk/decision-score
Public signing keys

The Ed25519 and ML-DSA-65 public keys needed to verify ledger entries and proofs offline.

GET /audit/signing-keys
03
Verifying Without QUORUM
1. Obtain the public keys and the proof

From the institution's own QUORUM deployment. Archive the keys and anchored roots outside the database.

2. Recompute the record hash

From the canonical decision record.

3. Walk the Merkle path

Hash up to the batch root, then confirm the root appears in the ledger entry.

4. Check both signatures and the chain link

Standard Ed25519 and ML-DSA-65 verification, plus the previous-entry hash.

5. Check the timestamp, if present

Parse the RFC 3161 token and verify the authority's signature over the root hash.

6. Verify a score proof offline

The source repository includes a stand-alone verifier for Bulletproofs score proofs (scripts/verify-zk-proof.ts).

04
Limits, Stated Plainly
Tamper-evident, not immutable

The ledger is stored in PostgreSQL. A privileged database user could alter it, but any change to an anchored entry is detectable without trusting QUORUM.

Integrity, not correctness

The proofs show a decision was recorded and not changed. They do not prove the rules were the right ones; that is a governance question.

Keys and hardware

Production signing keys are held in an AWS Nitro Enclave. This is implemented but not yet exercised on Nitro hardware. No independent cryptographic review has yet been performed.

KB Analytical Solutions Inc. // Cryptographic Audit Overview // Describes QUORUM at code baseline e9c2cf7