Every result your AI produces moves through the same five steps — watch it happen, step by step.
An AI agent does something — a build, a decision, a transaction.
The action is signed into a canonical, tamper-proof receipt.
Receipts are bundled into a Merkle-proofed audit export.
A zero-knowledge proof is generated — correct, without exposing data.
Anyone verifies the result — checked on Base, on-chain.
The moment an agent does something, R+2 records it as a canonical receipt — signed with Ed25519, written in a strict canonical form so the same action always produces the same receipt. A receipt for the work, the way a payment leaves a receipt.
R+3 collects receipts into an audit export built on a SHA-256 Merkle tree. Change one entry — even a single character — and the root hash changes, so the whole bundle visibly breaks. An audit trail that can't be quietly edited.
R+4 generates a zero-knowledge proof: a small cryptographic object that proves a result was produced correctly, without revealing the input behind it. The proof is checked by an on-chain verifier live on Base mainnet — anyone, anywhere, can confirm it.
The Trust SKU turns a track record of verified receipts into a single, portable reputation mark — recorded on-chain. Anyone deciding whether to rely on an agent can check its trust score instantly, instead of taking it on faith.
A result shouldn't be trusted because one server says so. Federation lets independent nodes hold the same epoch chain and co-sign the audit record — so a result is confirmed by a quorum of nodes, not a single point of trust.
R+2, R+3 and R+4 are open specifications — published on GitHub with reference verifiers. Anyone can read the spec, audit the code and verify a receipt without asking us for anything.
R+4 zero-knowledge proofs are checked by a production verifier contract deployed on Base mainnet. A proof isn't trusted because a DCS server says so — it's confirmed by a smart contract that anyone, anywhere, can call.
Cryptography ages. R+2 receipts and R+3 Merkle bundles can each carry a detached
ML-DSA-65 (FIPS 204) post-quantum hybrid co-signature — deployed behind
the R2_PQ_ENABLED flag and verified by an 8-verifier regression matrix;
rollout follows a staged soak — so a chain stays
verifiable even as the threat model changes.
The R-Series doesn't hide behind buzzwords. Each layer's cryptography is chosen on the record — with the reasons stated and the migration path written down.
Deterministic EdDSA over Curve25519. No catastrophic failure from a bad RNG; 32-byte keys, 64-byte signatures, fast batch verify, ~128-bit classical security.
A signature only means something if signer and verifier agree byte-for-byte on what was signed. JCS fixes a single deterministic JSON encoding, reproducible by any independent verifier.
Hash-chained per-receipt; SHA-256 binary Merkle for R+3 bundles. Ubiquitous, hardware-accelerated, strong collision-resistance record.
Constant ~200-byte proof, <1ms verify. Classical security only on BN254 today. R+4 v0.1 ships behind a documented future-proofing roadmap, not a "quantum-safe" claim.
Every action your AI takes flows through one layer — and comes out the other side verifiable by anyone, anywhere.
Every receipt is a small, canonical record — signed, hashed and chained. Here is what's in one.
RFC 8785 ordering — the same action always produces the same receipt.
Proves who produced it and that it hasn't been altered.
A SHA-256 fingerprint of the exact action and its result.
Each receipt links to the one before it — an unbroken history.
R+3 hashes receipts into a Merkle tree. Watch what happens when a single receipt is altered — the change climbs straight to the root.
Change one receipt and its hash changes — and so does every hash above it, all the way to the root. Nothing can be edited quietly.
A zero-knowledge proof travels from the agent to an on-chain verifier — confirmed without ever revealing the data behind it.
The R-Series is an open spec — just Ed25519 signatures and SHA-256 hashes. Verify a receipt from any language, with our verify libraries or a few lines of your own.
Verify a single result, or seal a thousand into a tamper-evident audit bundle.
The R-Series standards power these products across the platform.
The R-Series is built for technical scrutiny. Here's the short version.
api.dcsai.ai —
public verifier package @dcsplatform/r2-verify on npm. R+4 v0.1
(Groth16 over BN254) is the public draft with a working reference prover. The R+5 /
R+6 work is internal-only and stays internal until each lands as a public draft.R2_PQ_ENABLED flag and verified by an
8-verifier regression matrix; rollout follows a staged soak. It's a research reference that lets
the audit trail survive even if BN254 or Ed25519 break before NIST PQ standards
finalise their broader adoption story.verify.dcsai.ai is a client-side verifier — paste a
session ID and every signature is validated in the browser against the published
public key. The @dcsplatform/r2-verify package runs the same code on the
command line, in CI, or inside your own server.@dcsplatform/r2-verify); a
Rust verifier is in the works; Python and Go land next. The "Verify from any stack"
section shows the matrix.Read the open standards, or verify a receipt for yourself — no account needed.