How receipt-chain verification works

Verify any DCS receipt chain.

This page explains what verification checks and sends you to the verifier that performs it. This page runs no cryptography itself. Paste a real session ID or erasure-request ID and you will be handed to verify.dcsai.ai, which fetches the chain from api.dcsai.ai and checks every Ed25519 signature and the SHA-256 hash chain against our published public key.

The panel below is an illustration, not a verification. It replays the steps the verifier performs; it fetches nothing and checks nothing. Paste a real session ID (a UUID) and press Verify chain and you will be sent to the live verifier, which does the actual work. The published public key is ed25519:dcs-receipt-key-2026.

Paste a real session ID and press Verify chain to open it in the live verifier, or go straight there: verify.dcsai.ai ↗

Fetch chain

Canonical JSON

Ed25519 verify

SHA-256 chain

PQ co-sig

$ ready — this panel illustrates the steps; paste a real session ID to verify one for real

▶

Illustration finished — nothing was verified This panel is a scripted walkthrough of the steps the real verifier performs. It ran no cryptography and checked no receipt. To verify an actual chain, paste a real session ID above, or go to verify.dcsai.ai.

How verification works

Four checks. What the verifier does.

Every R+2 receipt commits to its predecessor. A valid chain has matching signatures, matching hashes, and the bundle root checks out on R+3.

Fetch the chain

We pull the full receipt list (JSON) over plain HTTPS from api.dcsai.ai. No streaming SSE, no auth handshake — anyone can fetch a chain by ID.

Canonicalise each receipt

RFC 8785 JCS pins one deterministic JSON encoding so the signed bytes are byte-for-byte reproducible. Without this step "the same JSON" can have a different hash.

Verify every Ed25519 signature

Each receipt's signature is checked against the published ed25519:dcs- receipt-key-2026 public key.

Walk the SHA-256 chain

Every receipt's prev_receipt_cid must equal the SHA-256 of the previous receipt's canonical bytes. If anyone altered a historical receipt, the chain breaks — visibly.

What gets checked

Six guarantees from one verification

The verifier at verify.dcsai.ai checks every property below. This page does not.

🧾

Ed25519 signature on every receipt

RFC 8032 EdDSA over Curve25519, ~128-bit classical security. 32-byte public key, 64-byte signature. Verified against the published key.

🔗

SHA-256 hash chain integrity

Each receipt commits to the SHA-256 of the previous one. Tampering with any historical receipt invalidates every digest after it — visibly.

📚

R+3 Merkle bundle root

For an R+3 export, the SHA-256 binary Merkle tree is recomputed leaf-by-leaf and the root compared against the signed bundle root.

🔒

ML-DSA-65 PQ co-signature

When present, the FIPS-204 ML-DSA-65 detached co-signature is verified alongside Ed25519 — a research-reference layer, not a quantum-product claim.

⏱

Timestamp monotonicity

Every receipt's issued_at must be ≥ the previous one's. Out-of-order timestamps mean a chain has been shuffled — an automatic fail.

🏷

CID consistency on Filecoin

Optional: if Storage is enabled, the bundle's content-addressed CID is verified against the published Filecoin deal — the bytes you verified are the bytes mirrored permanently.

Public keys & on-chain anchors

Everything you need to verify, in the open

One signing key, one Reputation SBT contract, one verifier package. Verifiable without contacting DCS.

Production keys · published

Ed25519 receipt keyRFC 8032 · public

dcs-receipt-key-2026 · 4f4ddc7c2f1a8b6e09d3a5f2c7e1b9d4a6e0f3c8b5d1a7e4f2c0b6d8a3e1f5c2

Copy

ML-DSA-65 PQ keyFIPS 204 · co-signature

dcs-pq-key-2026 · published in security.txt and the R-Series repo

Copy

Reputation SBTBase mainnet · F1 LIVE

0xbDd1f5fC349D9a8EfCEb07Edbd491233b2540f5F

Etherscan

Verifier packageMIT · not yet on npm

@dcsplatform/r2-verify — unpublished

—

Open specR+2 / R+3 / R+4

github.com/DCS-LabsAI/r2-standard · r3-standard · r4-standard

GitHub

For developers

Verify the same chain from anywhere

npm, CLI or browser — same code path, same cryptography.

Three lines of code

From session ID to verified chain.

The same logic that runs in this page also runs at the command line and inside any CI pipeline. It has zero non-cryptographic dependencies and is MIT-licensed.

Not yet published. The package name below is reserved for this work and does not resolve on the npm registry today. Do not run an install command for it: a name that 404s is a name someone else can register.

@dcsplatform/r2-verify — name reserved, not published to npm
Same code path: browser, Node, CI, MCP tool
Returns a structured result — not a boolean
Verifies R+2 + R+3, with optional R+4 / PQ extensions

verify.tsbrowser · Node · CI

import { verifyChain } from "@dcsplatform/r2-verify";

const result = await verifyChain({
  sessionId: "sess_9f3c…a17",
  origin:    "https://api.dcsai.ai",
  checkPq:   true,         // ML-DSA-65 co-sig
});

if (result.valid) {
  console.log("chain ok", result.receipts.length);
} else {
  console.error("chain broke at", result.firstFailIndex);
}

chain ok · 17 receipts · PQ co-sig present

FAQ

Verifier questions, answered

Does the panel on this page actually verify anything?

No. The panel on this page is a scripted illustration of the four steps — it loads no cryptographic module, fetches no receipt and checks no signature, and its output is fixed text rather than a result. Real verification happens at verify.dcsai.ai, where you are sent when you paste a real session ID. We would rather say this plainly than let an animation stand in for a proof.

How do I know the public key on this page is real?

It's published in the security.txt of dcsai.ai and in the R+2 standard repository's SECURITY.md. Verify the key independently from either — we deliberately don't ask you to trust this page. (A third location, a signed npm manifest, will exist only once the verifier package is actually published.)

What if a single receipt fails to verify?

The verifier returns the index of the first failing receipt, the failure kind (bad signature, hash mismatch, timestamp regress, missing predecessor) and the raw bytes that broke. Everything before the failure is still cryptographically valid.

Does it work without an internet connection?

Partly. The Ed25519 verifier, SHA-256 walker and JCS canonicaliser all run offline. If you've already saved the receipt JSON locally, you can verify with no network — the CLI takes a path instead of a session ID.

What's the deal with the PQ co-signature?

An optional ML-DSA-65 (FIPS 204) detached signature rides alongside Ed25519, behind the R-Series flag R2_PQ_ENABLED (live in Wave-1). The verifier checks it when present. It's a research reference — not a quantum-product claim.

Can I verify a Storage CID alongside the chain?

Yes. When the chain references a Filecoin-mirrored artifact, the verifier can re-hash the bytes and confirm the CID matches — proving the bundle you saw is the bundle that was preserved.

What about R+4 zero-knowledge proofs?

R+4 v0.1 (Groth16 / BN254) verification is in the same package — verifyProof() takes the proof and the public statement and returns a boolean. The reference prover is in the r4-standard repo.

Is there a verifier in my language?

JavaScript / TypeScript on npm today. A Rust verifier is in the works for embedded use; Python and Go land next. We accept PRs — the spec is small enough to implement in a weekend.