Most research asks you to trust its publications. We hand you the tools to check ours — in your browser, offline, with no DCS code in the path.
Verify a receipt in your browser →Most research asks you to trust its publications. We'd rather you check ours. Everything DCS Labs claims about the R-Series is independently verifiable — here's how, with the tools to do it.
Paste any R+2 receipt and its agent public key into the in-browser verifier. The Ed25519 signature check and the RFC 8785 canonical form run entirely in your browser using the native Web Crypto API — nothing is sent to DCS, and no DCS code runs in the signature path. If a receipt is authentic and unmodified, you'll see it; if it's been altered by a single byte, you'll see that too. This is the core promise made literal: a receipt is checkable by anyone, offline, without trusting us.
The standard ships six independent verifiers — JS, Go, Rust, Java, C#, and Swift (plus an experimental WebAssembly build), each compiled and run against the 30 conformance vectors in CI on every push. That independent implementations agree is evidence the standard is real and interoperable, not an artifact of one codebase. The reference verifier is published as dcslabs-r2-verify on npm; all six live at github.com/DCS-LabsAI/r2-standard. Run any of them on a receipt and confirm for yourself.
Our R+4 zero-knowledge proofs are checkable: a proof that "balance ≥ threshold" can be verified without learning the balance. The verifier is published. You can confirm that a valid proof passes, a forged one fails, and that the proof reveals nothing about the underlying value.
Given a vendor's seal and the DCS Standards Authority public key, you can confirm offline that the seal is valid, current, and co-signed — no call to DCS required.
The reference implementation's test suite is public and currently reports:
| Layer | Tests | What's checked |
|---|---|---|
| R+2 conformance | 30 / 30 | single receipts, all signature suites, hash chains, raw-byte forms, and the negative cases — mostly forgeries (tampering, wrong key, unknown/reserved algorithms, broken chains, replayed nonces, duplicate keys, oversized data); a verifier passes only if it rejects every one. Run across 6 implementations in CI. |
| R+3 audit export | 7 / 7 | Merkle bundle construction, inclusion proofs, tamper detection on receipts/proofs/root |
| R+4 zero-knowledge | 8 / 8 | valid proofs verify; false statements unprovable; tampered proofs rejected; proofs are randomized (ZK) |
| Trust SKU | 7 / 7 | offline verification, co-signer requirement, expiry, tamper rejection |
| Post-quantum identity | 6 / 6 | key resolution, hash-anchor checks, tamper-evident algorithm migration |
| Total | 40 / 40 |
We report the negative tests deliberately. A system that only demonstrates the happy path hasn't shown much; what matters is that it correctly rejects bad input — tampered receipts, forged proofs, expired seals, downgraded algorithms. Those are the tests that count.
Borrowing the standard that makes academic work trustworthy — reproducibility — we hold to these:
It does not mean the underlying AI is correct, safe, or making good decisions. The R-Series verifies what an action was and that it is unmodified — its provenance — not the wisdom of the action. For sensitive domains we verify the audit trail and human-oversight steps; we do not certify clinical, financial, or other domain judgments. Being precise about this is part of the methodology.
DCS Labs will commission an independent external security audit of the R-Series cryptographic core, and will open the R+4 trusted-setup ceremony to independent contributors — because the integrity of a zero-knowledge system depends on parties other than its author. Findings from each will be published in full once it is underway.
Every claim on this page resolves to something you can run, curl, or read — a public repo, a live endpoint, an on-chain transaction. If a claim doesn't check out, tell us and we'll fix it or remove it. That's the deal.