Dated, citable, MIT-licensed reference notes. Every claim is independently checkable with the tools we publish.
DCS Labs Technical Note · TN-2026-01 Date: June 2026 · Status: Open · MIT-licensed reference implementation Authors: DCS Labs (DCS AI Technologies L.L.C)
We describe two layers of the R-Series, an open standard for cryptographically verifiable AI-agent actions: R+4, a zero-knowledge layer that lets an agent prove a statement about a private value (e.g. "balance ≥ threshold", "age ≥ 18", "amount within a range") without revealing the value; and the Trust SKU, a buyer-visible meta-seal that lets a non-technical buyer confirm, in one check, that a vendor runs the full R+1–R+4 stack. We present a working reference implementation of R+4 that requires no trusted setup, using Pedersen commitments with per-bit Chaum-Pedersen OR-proofs under Fiat-Shamir, and a Trust SKU verification scheme that is offline-checkable and resistant to single-key compromise via a required co-signer. Both are released openly; all claims in this note are independently verifiable with the tools we publish.
Verifiable provenance for AI-agent actions is becoming a procurement requirement: buyers and auditors increasingly need to confirm what an agent did without trusting the vendor's word. The lower R-Series layers (R+1 timestamp, R+2 signed provenance, R+3 audit export) establish a tamper-evident record. This note addresses two harder problems on top of that record:
To our knowledge, the second is novel in this category: existing efforts standardize receipt formats, but none provide a buyer-visible seal layered above the format.
The reference implementation proves that a committed value v lies in [0, 2^32) without revealing it, and composes this into threshold and range predicates.
C = vG + rH over the ed25519 prime-order group, with H derived by a nothing-up-my-sleeve procedure so that log_G(H) is not exploitable for forgery.v is decomposed into 32 bits; each bit b_i is committed as C_i = b_i G + r_i H.C_i we run a Chaum-Pedersen OR-proof showing C_i commits to 0 or 1, made non-interactive via Fiat-Shamir. The proof reveals nothing about which value the bit holds.value − threshold is in range; "value in [low, high]" by showing value − low is in range. No trusted setup is required for this construction.The production deployment additionally targets Groth16/Plonk circuits (compiled with circom/snarkjs, finalized by a multi-party trusted-setup ceremony) for the five standard predicates; the verification interface is identical, so the reference and production provers are interchangeable behind one verifier dispatch.
A Trust SKU seal is a signed JSON document asserting a vendor runs R+1–R+4, with:
Verification is offline: given the seal and the Authority's public key, a buyer confirms expiry, co-signature(s) over the RFC 8785 canonical seal body, and that each standard is active — with no dependency on a live DCS endpoint.
The reference implementation is tested and the test suite is public. Observed results:
The full R-Series reference suite reports 40 passing tests across the R+2 core, post-quantum signing, conformance vectors, R+3 export, R+4, and Trust SKU.
The design choices reflect a consistent principle: verifiability should not require trusting us. R+4 proofs are checkable by anyone with the verifier; Trust SKU seals are checkable offline with a public key; R+2 receipts are checkable by an independent Python implementation. This is deliberate — independent verifiability is the credibility mechanism, not our assertion of correctness.
Two honest limitations. First, the no-trusted-setup reference proof is a bit-decomposition range proof; the production Groth16/Plonk path is gated on a multi-party trusted-setup ceremony, which is in progress and whose integrity depends on independent contributors. Second, the Trust SKU's strength rests on the security of the Authority co-signing key; the 30-day rotation bounds, but does not eliminate, the consequences of its compromise — which is why production custody is HSM-based.
For sensitive domains (healthcare, government, finance, and other safety- or rights-affecting verticals), the R-Series provides auditability of actions, and DCS Labs holds those applications in research-mode per its published Research Policy. The standard records and verifies what occurred; it does not make clinical, financial, or other domain decisions.
The specifications are open and MIT-licensed. The reference implementation, conformance vectors, and the independent Python verifier are published so that every claim in this note can be checked. A live verification demo lets anyone validate a receipt in their browser.
Cite as: DCS Labs, "Verifiable Selective Disclosure and Buyer-Visible Trust Seals for AI Agents," DCS Labs Technical Note TN-2026-01, June 2026.
DCS Labs Technical Note · TN-2026-02 Date: June 2026 · Status: Open · MIT-licensed reference implementation Authors: DCS Labs (DCS AI Technologies L.L.C)
We describe R+2, the provenance layer of the R-Series: a scheme for producing signed, hash-chained, independently verifiable records of AI-agent actions, and the crypto-agility and post-quantum migration design that lets those records remain verifiable across a change of signature algorithm without breaking the chain or weakening its guarantees. R+2 uses Ed25519 signatures over RFC 8785 (JCS) canonical JSON, with each receipt referencing its predecessor by content identifier to form a per-agent chain. We add an explicit, hybrid-signed algorithm-transition receipt that records a migration from a classical to a post-quantum scheme (ML-DSA-65, FIPS 204) such that the migration is itself an auditable, tamper-evident, downgrade-resistant event. The reference implementation is published and independently verified by a second implementation in a different language.
An action record is only useful if a third party can confirm it without trusting the recorder. R+2 targets two properties: authenticity (the record was produced by the claimed agent and is unmodified) and continuity (records form an ordered chain that cannot be silently reordered, inserted into, or truncated). A third concern is longevity: a record signed today may need to remain verifiable for decades, which raises the prospect of the signature scheme itself becoming obsolete — most acutely, the eventual arrival of cryptographically relevant quantum computers.
This note covers the R+2 construction and then the migration design that addresses longevity: how an agent moves from Ed25519 to a post-quantum scheme while keeping its entire history verifiable and its migration auditable.
ed25519-sha256 suite). The receipt carries the agent's public key and is verified against it.Receipts carry an explicit algorithm identifier (alg) resolved against a registry that marks each suite's status (active / experimental / reserved) and whether it is production-approved. Verification fails closed: unknown or reserved suites are rejected, and an experimental suite is accepted only when explicitly enabled. This makes the signature scheme a first-class, negotiable property rather than a hard-coded assumption.
For longevity we support ML-DSA-65 (FIPS 204) and a hybrid Ed25519+ML-DSA suite. The migration itself is the careful part:
Large post-quantum public keys are handled by anchoring a hash of the key on-chain and serving the full key off-chain; a verifier confirms the full key matches its anchor.
The reference implementation is public and tested:
The first production R+2 receipts are anchored on a public chain, and an issuing service produces chained receipts that verify end-to-end with both the reference verifier and the in-browser demo.
The migration design reflects a specific worry: a naive algorithm switch — just changing the signature scheme mid-chain — is indistinguishable from an attack. By making the transition an explicit, doubly-signed, fingerprint-bound event, the migration becomes more auditable than the steady state, not less, and the downgrade rule closes the obvious attack of replaying the old scheme after a break.
Honest limitations. The hybrid suite's guarantee is "valid if either scheme holds," which is the conservative choice during the transition era; a pure-PQ chain is available where a buyer mandates it (e.g. CNSA 2.0), at the cost of larger signatures. Hash-function agility (moving beyond SHA-256) is reserved in the registry but not yet exercised. And as with all such systems, verification establishes provenance — that an action occurred and is unmodified — not the correctness or wisdom of the action itself; sensitive-domain applications remain research-mode per our Research Policy.
The R+2 specification, the algorithm registry, the conformance vectors, the post-quantum reference code, and the independent Python verifier are published and MIT-licensed. Every result above is reproducible with the published tools.
Cite as: DCS Labs, "Hash-Chained Action Provenance and a Tamper-Evident Post-Quantum Migration Path," DCS Labs Technical Note TN-2026-02, June 2026.