✅ Client-side cryptographic verifier

Verify any DCS receipt chain — in your browser.

Paste a session ID or erasure-request ID. We fetch the receipt chain from api.dcsai.ai and verify every Ed25519 signature and the SHA-256 hash chain client-side, against our published public key. No trust in DCS's servers required.

Try the demo session above, or paste any ID issued by DCS. Verification runs entirely in this tab — the 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 — paste an ID and press Verify chain

✓

Verified — chain intact 17 receipts · Ed25519 ok · SHA-256 chain matches · ML-DSA-65 co-sig ok

How verification works

Four checks. Run in your browser. No server trust.

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. The check runs in WebAssembly, in your tab.

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

One Verify-chain click validates every property below in your browser.

🧾

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 packagenpm · MIT

@dcsplatform/r2-verify

npm

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. The package has zero non-cryptographic dependencies, ships an audited WebAssembly Ed25519 verifier, and is MIT-licensed.

@dcsplatform/r2-verify on npm — published, audited
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 this verifier actually run in my browser, or on a DCS server?

In your browser. The Ed25519 verifier is an audited WebAssembly module loaded with this page; the SHA-256 chain walk is plain JavaScript. The only network call we make is the HTTPS GET for the receipt JSON — you can swap that endpoint for any mirror, including a Filecoin gateway.

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

It's published in three places: the security.txt of dcsai.ai, the R+2 standard repo's SECURITY.md, and committed to the @dcsplatform/r2-verify npm package's signed manifest. Verify the key independently from any of them — we deliberately don't ask you to trust this page.

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.