DCS / Standards / R+2 Provenance

v0.1 · published · MIT-licensed · adopt freely

The DCS Provenance Standard, R+2 v0.1

An open specification for cryptographically signed AI agent receipts. Defines the receipt envelope, ed25519 signing rules, hash-chain semantics, verification protocol, and retention policy. Published May 17, 2026. MIT-licensed. Submitted to MeitY, ISRO, and Anthropic Standards Program.

Read the spec on GitHub → R-series overview

What R+2 specifies

Five parts to the spec.

📜

1. Receipt envelope

Canonical JSON schema. Required fields: version, issuer SBT, timestamp, action type, input_hash, output_hash, prev_receipt_cid, signature.

🔏

2. ed25519 signing

Deterministic signing per RFC 8032. Canonical JSON serialization per RFC 8785. Key rotation rules + key-IDs in the envelope.

🔗

3. Hash-chain semantics

Each receipt references its predecessor via prev_receipt_cid. Chain-break detection. Monotonic sequence within an issuer.

✅

4. Verification protocol

Independent third-party verify procedure. No trust in issuer required. Step-by-step algorithm in spec § 4.

⏲

5. Retention policy

Filecoin pin lifetimes, expiry rules, archive vs deletion behaviors, right-to-erasure handling within chain integrity.

🌐

+ Compliance crosswalk

Mapping to RTI Act, DPDP, EU AI Act, GDPR, ISO 42001, NIST AI RMF. Spec § 7.

Example

What a receipt actually looks like.

{
  "version": "r2-0.1",
  "issuer_sbt": "0xbDd1f5fC349D9a8EfCEb07Edbd491233b2540f5F",
  "issuer_key_id": "ed25519:dcs-receipt-key-2026",
  "timestamp": "2026-05-26T19:20:02Z",
  "sequence": 4182,
  "action": "agent.run.complete",
  "agent_id": "restaurant.intake.v3",
  "input_hash": "sha256:c4f7a9e2…b1d2e1",
  "output_hash": "sha256:a83f1099…73c4a8",
  "prev_receipt_cid": "bafy…1f0e",
  "metadata": { "latency_ms": 847, "cost_usdc": "0.0042" },
  "signature": "ed25519:9fd2…03c8"
}
// CID of this object: bafy…3a9f

Adopt

Three ways to use R+2.

Path 1 — Reference implementation

Use our open-source signer + verifier from the github.com/DCS-Platform/r2-standard repo. Run as-is, self-hosted or DCS-hosted.

Path 2 — Build your own

Implement the spec yourself in any language. RFC 8785 + RFC 8032 are standard primitives. Run an independent chain.

Path 3 — Federate

Operate independently but handshake at the federation boundary. Cross-network receipts verify mutually. See Federation.

Compliance crosswalk

Spec maps to regulator articles.

Regime	Article	Receipt field that satisfies
EU AI Act	Art. 12 (logging)	timestamp + action + agent_id + input/output hashes
EU GDPR	Art. 5(1)(f) integrity	ed25519 signature + hash-chain pre-image resistance
India RTI	s.6 right to info	receipt fetch by CID, public verification endpoint
India DPDP	s.8 consent record	consent_cid in receipt metadata for memory writes
ISO 42001	cl. A.6.2.4 docs	receipt chain IS the documented information

FAQ

Common questions.

Why ed25519 not ECDSA?

Deterministic signing (no nonce reuse footgun), faster verify, smaller signatures, well-audited (used by SSH, Tor, Signal, Apple).

What if I need post-quantum?

R+4 (in development) defines the PQ migration path — hybrid ed25519 + Dilithium signatures, with cross-validation rules.

How is this different from Solid / Verifiable Credentials?

VCs are identity-centric and human-issued. R+2 is action-centric and machine-issued. We focus on "agent did X at time T" not "user owns credential Y."

Status of submissions?

Submitted May 17 to MeitY (India), ISRO, and Anthropic Standards Program. Adoption decisions tracked publicly on standards.html.