Trust · Standards

Nothing
proprietary where
it matters.

R-Series composes published standards. If DCS disappeared tomorrow, every receipt could still be checked with the published verifier and vectors and the issuer's public keys.

Verify a receiptBuild with it
Canonical formRFC 8785
SignaturesRFC 8032 + FIPS 204
LogsRFC 6962 rules
Standards-body acceptanceNot claimed
00 Why standards

A receipt should not depend on one company.

If verifying a receipt required DCS software, DCS would become the thing you have to trust. So R-Series is built by composing published standards: an IETF canonical JSON scheme, NIST-standardised signatures and key encapsulation, and the Merkle-log rules used by Certificate Transparency.

What R-Series adds is the profile: exactly which bytes are signed, which suites are allowed, how receipts chain, and what a verifier must reject. The profile specification is shared under NDA and its test vectors are published under licence, so a second implementation can prove it agrees.

Interoperability with SCITT and COSE, and a receipt assertion for C2PA content credentials, are in development. Nothing is called accepted until it is accepted outside DCS.

01 What R-Series adds

The standards say how to sign. The profile says exactly what is signed, and what a verifier must refuse.

02 How a receipt cites the specs

Every field traces to a published document.

Standards library01 / 05
01 · BYTES

One exact byte form.

The receipt body is canonicalised with RFC 8785 before anything is hashed or signed. On the wire, the A7 transport uses deterministic CBOR so every implementation produces identical bytes.

02 · DIGEST + LOG

A hash, then a tree.

SHA-256 (FIPS 180-4) gives each receipt its digest. Receipts roll up into Merkle trees that follow the RFC 6962 audit-path rules from Certificate Transparency, so inclusion can be proved with a few hashes.

03 · SIGNATURES

Two signatures, two families.

Ed25519 (RFC 8032) is the classical leg. ML-DSA-65 (FIPS 204) is the lattice-based post-quantum leg. A verifier requires both.

04 · LONG HORIZON

Hash-based archives, sealed memory.

SLH-DSA (FIPS 205) is planned for archive signing. ML-KEM-768 (FIPS 203) seals agent memory and protects transport; it is in development.

05 · INTEROP

Speak other ecosystems' formats.

A SCITT / COSE export, a C2PA receipt assertion, and receipts for every MCP tool call. All three are in development.

03 Building blocks

Every standard, and its state.

StandardRole in R-SeriesState
RFC 8785JSON Canonicalization Scheme. One exact byte form for every receipt body.Staging · release candidate 4
RFC 8032Ed25519. The classical signature.Staging · release candidate 4
FIPS 204ML-DSA-65. The post-quantum signature.Staging · release candidate 4
FIPS 180-4SHA-256. Digests, Merkle leaves and roots.Staging · release candidate 4
RFC 6962Certificate Transparency logs. Merkle tree and audit-path rules.In development
FIPS 203ML-KEM-768. Post-quantum key encapsulation for sealed memory and transport.In development
FIPS 205SLH-DSA. Hash-based signatures for the longest-lived records.Planned
Deterministic CBORCompact transport. The same receipt in fewer bytes for small links.In development
IETF SCITT · COSESupply-chain transparency. An export of the receipt as a transparency statement.In development
C2PAContent credentials. A receipt assertion for content manifests.In development
MCPModel Context Protocol. Receipts for every tool call.In development
RFC 3161Trusted timestamps. Independent proof of when a root existed.Planned
SP 800-208Hash-based signatures for firmware. Firmware and device signing.Planned
CNSA 2.0A stronger national-security profile, for buyers who need it.Planned
04 Profile rules

What a conforming verifier must reject.

REJECT

Unknown suite

A suite identifier not in the registry is a failure. There is no "try the next one".

REJECT

Missing leg

A hybrid receipt with one signature stripped is a downgrade attempt, not a partial pass.

REJECT

Unknown field

The universal receipt is a closed schema. Extra fields are refused at every level.

REJECT

Broken chain

A parent that does not resolve, or an inclusion proof that does not reach the root.

REJECT

Transplanted signature

A valid signature copied onto a different body fails the digest check.

REJECT

Loose encodings

Non-canonical bytes, and Ed25519 encodings outside the strict rule, are refused by the engine.

05 Conformance

A mark for independent implementations.

A conformance mark for implementations written by someone other than DCS, backed by public vectors and a second verifier. Acceptance by a standards body is not claimed.

Three independent verifier implementations, in JavaScript, Python and Go, agree on every published vector. A conformance kit with published, supplementary and reject tiers is in development. A verifier is defined as much by what it refuses as by what it computes.

Planned

Check the rules yourself.

Issue a receipt in your browser, tamper with it, and watch exactly which rule refuses it.

Open the verifier
05b Standards watch

What changed in the standards we track.

DocumentChangeEffect on R-Series
NIST SP 800-185Draft revision published 8 Oct 2026; comments close 7 Dec 2026.Not used in R-Series. No action.
06 Questions

About the standards.

Is R-Series itself a standard?

No. It is a proprietary specification of DCS Labs: use requires a licence from DCS; the public verifier and vectors are published under licence. Acceptance by a standards body is not claimed.

Can I implement a verifier myself?

Yes. The spec, suite identifiers and positive and negative vectors are what a second implementation needs. A conformance badge for independent implementations is planned.

Why RFC 8785 rather than CBOR?

JSON keeps receipts readable and easy to adopt. RFC 8785 removes the ambiguity that normally makes JSON unsafe to sign. Deterministic CBOR is used for transport, where size matters.

What changes when NIST or another body publishes a new scheme?

Receipts are never re-signed in place. A new scheme arrives as a new schema version with its own suite identifier, and signed renewals carry older receipts forward.

Will receipts work with SCITT transparency services?

That is the aim of the SCITT export. Today it is a conformance demo; the full profile is in development.

Want the details for your sector? Book a briefing — we share the full design and a live demo in a private session.