trust & receipts
Receipts, not promises.
A receipt is a signed claim you can check yourself, with or without us. This page shows what it proves, how to verify one in five minutes, and what no signature can establish.
What a valid signature establishes
That the corresponding key signed these canonical bytes, and that the checked bytes have not changed. A signature or digest check is not a protocol verdict; it does not establish that the claim is true, that the key holder had authority, that a key has not been revoked, that an action occurred, that payment reached finality, or that a service was delivered. A cryptographic check is narrower than a policy decision.
The format is open: Ed25519 over canonical JSON with a did:key issuer, published as spec 0.5 (spec 0.6 is an experimental draft). Spec and vectors are pinned at the reviewed public commit in the source repository.
Start with the browser example
No installation, key, or upload. Choose a hosted or on-device verifier when you need a protocol verdict.
No installation, key, or upload. Checks signatures, digests, and structure; it does not compute the protocol verdict.
Get a free evaluation key and send a receipt bundle. The service processes what you send; daily limits apply.
Requires Python and pip. Install the published package; the receipt check runs locally.
Try the published browser example
The explorer runs the signature and digest checks client-side on a published settle receipt or a local bundle. It does not compute the protocol verdict and does not establish authority, revocation, payment finality, or delivery.
The built-in 0.4 example is the published 17_agreement_bound.json test vector; it demonstrates checks, not that its sample events happened.
Check a sample or your own bundle
The published sample is checked locally in your browser. You can also paste your own continuity-receipt task bundle. Bundle bytes are not sent to a hosted service.
Local integrity check
Published sample: continuity-receipt/0.4The current input has not been checked. Open the JSON editor and run a local check.
This is not the protocol core TRUSTED / PROVISIONAL / INSUFFICIENT_EVIDENCE / UNTRUSTED verdict. It does not resolve authority or revocation, identify a real-world signer, prove events occurred, or establish payment finality or service delivery.
Built-in sample: continuity-receipt/0.4 · urn:uuid:01a0d12f-c327-7953-928b-d3089c9da9df
Hosted protocol verification: full steps
Requires curl and a free evaluation key. Get a key (no account, daily-capped). Replace the placeholder below with your key and keep it private. This downloads a pinned public test vector and sends it to the hosted service; review what you can share before substituting your own file.
curl -fLsS https://raw.githubusercontent.com/lbailey94/continuity-receipt/v0.5.0/vectors/17_agreement_bound.json -o bundle.json
export WM_API_KEY='paste-your-evaluation-key-here'
curl -s https://api.whitemagic.dev/verify \
-H "Authorization: Bearer $WM_API_KEY" \
-H 'Content-Type: application/json' \
-d @bundle.jsonRead the returned verdict: TRUSTED, PROVISIONAL, INSUFFICIENT_EVIDENCE, UNTRUSTED. Add ?require_anchor=1 to require an external timestamp, or ?receipt=1 to request a signed result record. The verdict depends on supplied evidence and policy; a test vector does not prove real events happened.
Offline protocol verification: full steps
Requires Python, pip, and curl; you can also download the sample manually. Package installation and the sample download need network access, after which you can check the file locally. Use your existing Python virtual environment if you have one.
python3 -m pip install continuity-receipt==0.5.2
curl -fLsS https://raw.githubusercontent.com/lbailey94/continuity-receipt/v0.5.0/vectors/17_agreement_bound.json -o bundle.json
continuity-receipt-verify bundle.jsonReplace bundle.json with your file path to check your own receipt bundle. Offline verification evaluates the evidence supplied; external state, timestamps, and policy premises still require their corresponding evidence.
Evaluator & Auditor Fast-Path
Find evidence by topic
A technical-review index. Links point to project test records, standards work, or live metadata; each card states the scope and limits of its evidence. Tests at a pinned source revision do not qualify a published package or hosted runtime; check each artifact's identity and evidence separately.
Host Sandbox · Runtime MetadataReported filesystem controls and network-test scope
The live /info endpoint reports host-sandbox fields; these service-provided values are not an independent runtime audit. Source includes a local zero-egress test script, but its existence and a separate local namespace run do not establish default production egress denial.
Storage Integrity · Memory CrystalsCrystal-store tamper matrix: 8/10 and 10/10 (T1–T10)
The pinned wm-crystal test matrix refused 8/10 edits on read with a same-disk commitment and 10/10 with an erasure-aware commitment anchored outside the store directory, including T9 whole-store rollback and T10 erasure resurrection. This is one implementation's test record, not an IETF specification or a finding about other storage products.
Causal Provenance · Reference CoreCausal Provenance Receipts (CPR 0.5.1)
The repository ships 80 canonical JSON vector fixtures (including 27 verification-receipt vectors); pinned records report Python↔Rust differential agreement on 40 bundle vectors and 21 verification-receipt vectors, and JavaScript has a separate CONFORMANT report on that corpus (40/40 bundles, 21/21 receipts, 208/208 hostile inputs) while documenting non-vector edge differences. These are published records, not fresh reruns.
Interop · Technical NoteMemory Crystals compared with the SAIHM draft profile
A pinned project note proposes comparisons for cellId, key rotation, and signature profiles. SAIHM -03 is an Internet-Draft, not endorsed by the IETF; its core profile is operator-custodial, while holder-held keys are outside that revision's scope. The crosswalk does not show W3C endorsement, standards compliance, or validated interoperability.
At-Rest Storage · Tamper TestOpt-in record sealing: 8/8 byte-flips refused
In one fresh Gen3 store, a test flipped a disk byte in each of eight records sealed with XChaCha20-Poly1305; all eight reads refused. At-rest sealing is opt-in today. This test does not evaluate erasure, audit-trail requirements, or EU MDR / 21 CFR Part 11 compliance.
Public Interface · Client-Side Integrity ChecksBrowser-side signature and digest checks
The browser example checks signatures and digests locally for a published test vector or a user-provided bundle; it does not compute the protocol verdict or establish authority, revocation, payment finality, or delivery. The hosted OpenAPI document is a separate interface description.
Automated Supply-Chain Signals · CI Run RecordScorecard Signals and a Traceable CI Result
OpenSSF Scorecard reports automated repository security signals; it is not an independent security audit. CI example: run 40791608285 for revision 91a2005fa39ff8da7137fe2e69bea9772c915670 failed overall; seven jobs succeeded and the macOS advisory job was cancelled because a hosted runner could not be acquired. Dominion Observatory Issue #28 records a private, unsigned 55-tool MCP tools/list snapshot from 2026-10-27. Its author says no tools were called. The issue provides no release-binary, SBOM, or runtime-audit evidence.
spec, packages, conformance
Three implementations, one corpus.
Published packages
- Python 0.5.2 – pip install continuity-receipt==0.5.2
- Rust 0.5.1 – cargo add continuity-receipt@0.5.1
- JavaScript 0.1.1 – independently versioned; the package version is not the spec version
Python 0.5.2 is an experimental local receiver release. It leaves spec 0.5, Rust 0.5.1, JavaScript 0.1.1, and the hosted verifier 0.5.1 unchanged; it does not claim a wire-format 0.6 release.
Hosted: api.whitemagic.dev/verify, stateless and keyed or x402; metadata at /info and /openapi.json. This deployment advertises verifier 0.5.1 and spec support 0.1–0.6; advertised range is not a conformance proof for every path.
Spec, vectors, and review
- Normative spec 0.5 · experimental 0.6 draft · conformance vectors
- IETF SCITT payload profile (individual Internet-Draft, work in progress): draft-bailey-scitt-agent-session-receipt-00 (plain text) — maps CPR session bundles and chain_head commitments onto RFC 9943 / RFC 9942 without modifying either base standard; an individual submission is a working document, not an IETF standard or WG adoption claim.
- Public CI grades implementations and corpus comparisons at the reviewed revision; unsupported or malformed inputs fail closed, and missing evidence never upgrades a verdict.
- The hosted conformance referee grades third-party verifiers and returns a signed report binding the submission and corpus digests; it never executes submitted code.
- Independent review is open and not yet completed – REVIEW_BRIEF.md.
third-party scanners
When a scanner misreads a guard.
Read scanner explanations and source pointers
Security directories occasionally flag WhiteMagic for strings that are inverted guards, decoys, or packaging steps — not capabilities. The three that recur:
- Cloud-metadata references — crates/wm-memory/src/embedder.rs carries a blocklist headed “Block cloud metadata endpoints” (its function returns false for 169.254.169.254 and similar hosts). That is SSRF hardening: WhiteMagic refuses those destinations and never calls them.
- Credential-looking files — crates/wm-governance/src/decoy_shell.rs plants a decoy tree of structurally invalid fake secrets at the paths an intruder checks first (each tagged DECOY_TAG); it never touches real credentials.
- “Runs an external command” — the npm package is an installer: it downloads the checksum-verified wm binary and execs it. That is its entire job.
Every item above is checkable in the source; real vulnerabilities go through SECURITY.md.
at-rest integrity
At-rest sealing: a dated eight-record test.
One local fixture with optional record sealing enabled. The default store is not encrypted; this dated result does not qualify every release or store.
Read test scope, controls, and dated results
We tested whether our own store refuses modified encrypted records on disk. The exact eight-record harness and raw outputs are retained locally for review; this page does not provide a public reproducer for that fixture. The separately linked suites below have their own published records. This experiment does not compare other storage products.
Measured — a fresh Gen3 store (eight records) sealed per-record with XChaCha20-Poly1305, each record's identity bound into the authentication data. For every sealed record: flip one byte in its encrypted body, directly in the store file; try to read it; put the byte back; read everything again. No cooperation from the running system.
- 8 out of 8 flips were refused — each time on exactly the record that was modified, with record open failed (wrong key, tampered ciphertext, or AAD mismatch).
- The other seven records kept reading normally — no false positives, no collateral failures — and after the byte was restored, all eight read again.
- A read attempt without the store's at-rest key fails closed too — sealed values refuse rather than leak.
- Receipt layer, same run: a signed state receipt verified; flipping one character of its content digest made verification fail (content_digest mismatch); restoring it made it verify again.
What this proves: with at-rest sealing enabled in this eight-record fixture, all attempted byte-flips caused reads to refuse rather than return silently modified content. What it doesn't: this is one attacker model (disk access without the at-rest key). An adversary holding the key can re-seal modified content, and the store's state receipts commit to epochs and counts, not record contents — measured 2026-10-14; content-level evidence for that class is the next design step. What receipts plus an outside witness already bound is a rewritten evidence chain: sealed heads are held off-machine, so even a correctly re-signed rewrite cannot match them. At-rest sealing is opt-in today; the default store mode is plaintext pass-through.
The test harness and raw outputs are retained for local review. This dated candidate result does not establish behavior for every release or store.
Additional measured storage and chain suites (2026-10-15/22): (1) In the ten-edit storage-integrity matrix (T1–T10), client-encrypted Memory Crystals (wm-crystal) rejected 8 of 10 edits on the read path when the signed wm.crystal-set-commitment head is stored beside the store directory, and 10 of 10 edits (including T9 whole-store snapshot rollback and T10 erasure resurrection) when the erasure-aware commitment is held off-store (adapter & pin test). (2) On the external verifier rail of the 14-case anchored-record-chain/v1 corpus, tools/verify_anchored_chain.py matched 14 of 14 expected decisions and reasons with zero disagreements (conformance report). (3) Emitted continuity-receipt chain heads are sealed hourly to an external witness log (published snapshot; bounds an un-witnessed rewrite to the seal interval, without proving completeness of unsealed turns). (4) The current local replacement-service and archive-integrity exercise ran in an isolated network namespace at 2026-10-18T03:27:47Z; its saved record reports 23 of 23 checks passed. It covers archive bytes and member safety, restored-store and application checks, local gateway authentication, and receipt, owner, and replay checks. Its detailed evidence is retained locally and does not establish parity with the signed release or deployed next-lane binary. Earlier 00:36Z and 16:59Z results remain as historical records. These exercises do not measure full-host RTO or worst-case RPO, or qualify a clean operating-system bootstrap, systemd restoration, Caddy/TLS, DNS cutover, or next-lane recovery.
hosted defense evidence
Request logs describe observed traffic, within a defined window.
A response code, denied request, or automated alert is an observation about a particular service and time window. A 4xx response alone does not establish a blocked attack, a unique attacker, or successful containment. Automated alert text needs corroboration before it is treated as an incident finding.
A useful defense report identifies its source, observation window, deployment, counting rules, and the control that produced an outcome. Request counts do not establish adversaries' inference costs or the absence of compromise. Isolation claims need successful controls and denied negative tests against the exact runtime.
CPR verifies signed records under its implemented rules. A receipt does not automatically run a storage-attack suite, prevent rollback, or establish secure deletion. Follow the scoped evidence trails and their negative controls; source, published package, and hosted results require separate qualification.
honest limits
What a receipt never proves.
Release distribution health covers download availability, signed artifact identity, and attached install checks. Source CI and performance qualification are separate. The recorded 2026-10-17 PEB-10 timing comparison remains unqualified: its median speedup was 1.1140× against the retained 1.4× floor, using an emulated DAG baseline. See the dated timing run and raw samples. A newer GitHub prerelease, v10.5, also missed the timing floor (median 1.1489×); see its separate timing record. The website keeps its current install pin; neither distribution health result qualifies swarm execution or receipt-based credit issuance.
A valid signature says the issuer signed this claim, not that the claim is correct. Anchors are optional; when required, their absence yields PROVISIONAL, not TRUSTED. Revocation checking is opt-in and only as fresh as the published revocation document. Verification receipts are signed by the API issuer, which makes the verifier itself checkable.
Standard verification processes the bundle in memory and does not store bundle content. Gateway audit entries can include a key name, time, method, status, byte count, normalized route, client family, and decision details; they exclude bundle contents, query text, tool arguments, and bearer tokens. Disclosed exceptions: the anonymous trial counter uses the client IP in memory, and faucet audit entries may persist IP and payer identifiers. See the Privacy Policy.
First non-self settle (2026-09-28): the lab's content-free attestation records a 0.01 USDC Base settlement associated with one gateway audit line. The transfer is on-chain fact; linking it to a hosted request is the lab's attestation; identity, intent, and service delivery are not claimed. Sources: Base transaction · lab attestation · OpenTimestamps anchor.
Organic demand (through 2026-10-14): 7 non-self x402 settlements across 5 distinct payer wallets, 3 of which paid twice — 0.046 USDC total on Base. Each transaction is listed in the demand attestation; classification uses the same non-self basis as above, and amounts are the published x402 tiers, not a measure of service value, independent user identity, or broader adoption. The attestation records the lab's classification and has the limits described in its source.
Scheme registry: continuity-receipt schemes publish with status and verifier pointers — spec 0.5 (active), 0.6 (candidate), 0.6-pq (planned dual-sign Ed25519 + ML-DSA). Transitions and aggregate counters live in the content-free registry manifest; it is an operator attestation, not a global census, and counters stay unpublished until they are wired.
Regulatory & Compliance Mapping
How WhiteMagic Maps to Security Standards
Security teams and auditors can map WhiteMagic's zero-egress hardware containment and Causal Provenance Receipts directly to institutional requirements:
| Framework / Standard | Mandate & Criteria | How WhiteMagic Satisfies It |
|---|---|---|
| NIST AI RMF 1.0 | AI system state provenance, execution bounds, and traceability. | Deterministic Causal Provenance Receipts (CPR) + Linux Landlock LSM capability bounds. |
| EU AI Act | Continuous logging, auditability, and incident post-mortems for autonomous operations. | Ed25519-signed canonical JSON receipt envelopes; tamper-evident and offline-verifiable. |
| SOC 2 Type II / HIPAA | Prevent unauthorized exfiltration of proprietary code, keys, and context to third parties. | Local-first LMDB storage; zero off-device egress by default; local stdio MCP IPC. |
| IETF SCITT / AER | Standardized verifiable claim envelopes for autonomous agent execution and tooling. | Published open spec 0.5.0 & 0.6 draft with test vectors and multi-language verifiers. |
Anatomy of a Causal Provenance Receipt (CPR)
did:key public identity of the executing agent runtime
SHA-256 digest of exact action, parameters & code commit
Canonical JSON envelope containing environment facts & parent hashes
Detached Ed25519 cryptographic signature proving immutability