An open standard for
cryptographically signed
AI agent action receipts.

§1 At a glance #

An AI agent performs an action. The action is wrapped in a receipt. The receipt is signed with ed25519, links to the agent's previous receipt by content hash, and is published either inline or to IPFS. Any consumer — a regulator, a downstream system, a citizen filing an RTI request — can independently verify three things:

1. Identity: the action was performed by the agent identified by this public key.
2. Integrity: the action data hasn't been altered since it was signed.
3. Sequence: this action is part of an unbroken chain of actions from this agent, with no gaps and no replacement.

That's it. The rest of this document specifies exactly how to produce, transport, and verify such a receipt — with no ambiguity, so that two independent implementations will interoperate.

§2 Scope & non-goals #

In scope

• The schema and serialization of an Action Receipt.
• The cryptographic primitives used to sign and chain receipts.
• The verification procedure consumers MUST be able to execute without trusting the issuer.
• The conformance rules an implementation MUST follow to claim "R+2-compatible."
• The optional extensibility points for sectoral profiles (healthcare, finance, government, etc.).

Explicitly out of scope

• Identity discovery. R+2 does not specify how a verifier learns an agent's public key. That's left to deployments — DNS, on-chain registries (DCS Labs uses a soul-bound token on Base mainnet), DIDs, or simple key servers all work.
• Action semantics. R+2 doesn't define what an "action" is. An action could be a payment, a model inference, a tool call, a database write — anything an agent does that needs to be auditable. Sectoral profiles MAY constrain action types.
• Privacy / encryption. R+2 receipts are integrity-protected, not confidentiality-protected. Consumers who need confidentiality MUST encrypt receipts at the transport or storage layer using a method outside this standard.
• Revocation. R+2 does not define a key-revocation protocol. Deployments that need revocation SHOULD use their identity layer (e.g., burn the agent's SBT) and treat receipts after the burn as unverifiable.

§3 Terminology & conformance #

The keywords MUST, MUST NOT, SHOULD, SHOULD NOT, MAY, and RECOMMENDED in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Defined terms

§4 The Action Receipt schema #

A conforming Action Receipt is a JSON object with exactly the following top-level fields. Implementations MUST NOT add unknown top-level fields; extensions go inside the extensions object (§11).

Example (unsigned form)

{
  "spec_version":     "r2/v0.1",
  "agent_pubkey":    "u4yK_lH8Z6vJ3qZ5tNwQpRz_aBcDeFgH1iJ2kL3mN4o",
  "agent_id":        "0001",
  "action_id":       "3f8a7c12-8b91-4e2c-9b3a-5f7d8e1a2c4b",
  "action_type":     "memory/write",
  "action_data": {
    "memory_id":   "mem_a83f12cd",
    "content_hash": "sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
    "embedding_model": "text-embedding-3-large",
    "embedding_dim": 1536
  },
  "occurred_at":     "2026-05-19T15:42:08.123Z",
  "prev_receipt_cid": "sha256:bafy2bzaceabc...",
  "nonce":           "k3J9p2qR7sT5vXyA",
  "extensions": {}
}

§5 Cryptographic primitives #

Signature algorithm — Ed25519

R+2 uses Ed25519 as specified in RFC 8032 §5.1. Implementations MUST use pure Ed25519 (not Ed25519ph or Ed25519ctx). Signature size: 64 bytes (86 chars base64url, no padding). Public key size: 32 bytes (43 chars base64url, no padding).

Hash algorithm — SHA-256

R+2 uses SHA-256 (FIPS 180-4) for receipt content hashes and the chain pointer. SHA-256 hashes appear as hex strings prefixed with "sha256:" in fields where they're stored as JSON values. When transported as IPFS CIDs, they use multibase-encoded CIDv1 with the SHA-256 multihash code.

Encoding — Base64url, no padding

All cryptographic byte strings in R+2 use base64url encoding as defined in RFC 4648 §5, without padding. Two-character base64 padding (==) MUST be omitted. The character set is [A-Za-z0-9_-].

Why these choices

• Ed25519: Constant-time by design (resistant to side-channel attacks), 32-byte keys are short enough to publish in DNS / SBT metadata, and modern libraries in every major language ship correct implementations.
• SHA-256: Universally supported in hardware and software. Not yet replaceable without breaking compatibility, but Section §11 specifies how a future R+3 could deprecate SHA-256 in favor of SHA-3 or BLAKE3 without re-issuing past receipts.
• Base64url without padding: URL-safe, no special-character issues when receipts are passed through HTTP query strings or stored in DNS TXT records.

§6 Canonical JSON (RFC 8785) #

Signing JSON is harder than it looks. Two JSON serializations of the same logical object may differ in whitespace, key order, number representation, or Unicode escaping — but produce different hashes, and therefore different signatures. To eliminate this ambiguity, R+2 mandates RFC 8785 — JSON Canonicalization Scheme (JCS).

JCS in 6 rules

1. Object keys are sorted lexicographically (Unicode code-point order).
2. No insignificant whitespace.
3. Numbers are serialized using ECMAScript's Number.prototype.toString() algorithm.
4. Strings use minimum-length escaping (only quote, backslash, and control chars are escaped).
5. Arrays preserve their original order.
6. The output is UTF-8.

Implementations MUST use a library that follows RFC 8785 strictly. We RECOMMEND canonicalize (npm), jcs (Go), or the W3C reference TypeScript implementation. Do not roll your own.

§7 Signing flow #

1. Construct the receipt JSON object with all required fields except signature.
2. Compute the canonical JSON form (RFC 8785) of the receipt, treating the signature field as if it didn't exist.
3. Sign the canonical bytes with the agent's Ed25519 private key.
4. Base64url-encode (no padding) the resulting 64-byte signature.
5. Insert the encoded signature into the receipt as the signature field.
6. Serialize the receipt for transport in any preferred encoding. The transport form does not need to be canonical JSON; only the signed bytes do.

Reference signing snippet (TypeScript)

import { ed25519 } from '@noble/curves/ed25519';
import canonicalize from 'canonicalize';
import { Buffer } from 'buffer';

function signReceipt(receipt, privateKey) {
  const { signature, ...unsigned } = receipt;
  const canonical = canonicalize(unsigned);
  const sig = ed25519.sign(new TextEncoder().encode(canonical), privateKey);
  const sigB64 = Buffer.from(sig).toString('base64url');
  return { ...unsigned, signature: sigB64 };
}

§8 Verification flow #

A Verifier receives a Receipt and the agent's expected public key from an identity layer (DNS, on-chain SBT, etc.). The Verifier MUST perform the following checks in order. Any failure means the Receipt is invalid and SHOULD be rejected.

1. Schema: All required fields from §4 are present, with correct types and value ranges.
2. Spec version: spec_version equals "r2/v0.1" (or a version the Verifier supports per §11).
3. Public key match: The agent_pubkey in the receipt equals the public key the Verifier obtained from the identity layer for this agent_id.
4. Signature: Decode signature from base64url; remove the signature field from the receipt; canonicalize the result per §6; verify the Ed25519 signature over the canonical bytes using the public key from step 3.
5. Chain: If prev_receipt_cid is not null, the Verifier SHOULD fetch the previous receipt by CID and verify it recursively. The Verifier MAY rely on a previously-verified receipt cached locally.
6. Timestamp sanity: occurred_at SHOULD be within a reasonable window. Outside ±24h from the verification time, the Verifier MAY flag the receipt for further inspection but MUST NOT reject solely on this basis.

Reference verification snippet (TypeScript)

function verifyReceipt(receipt, expectedPubkey) {
  const { signature, ...unsigned } = receipt;
  if (unsigned.agent_pubkey !== expectedPubkey) return false;
  if (unsigned.spec_version !== 'r2/v0.1') return false;

  const canonical = canonicalize(unsigned);
  const sigBytes = Buffer.from(signature, 'base64url');
  const pubBytes = Buffer.from(expectedPubkey, 'base64url');
  const msg = new TextEncoder().encode(canonical);
  return ed25519.verify(sigBytes, msg, pubBytes);
}

§9 The receipt hash-chain #

Each Receipt's prev_receipt_cid field MUST contain the SHA-256 hash (or IPFS CIDv1 with SHA-256 multihash) of the canonical JSON form of the agent's immediately preceding signed Receipt.

This produces a strict total order over an agent's Receipts and makes any tampering immediately detectable. Specifically:

• Insertion: Inserting a fake receipt requires forging two signatures (the fake one and the subsequent one that now points to it). Both are infeasible without the private key.
• Deletion: Removing a receipt breaks the chain — the next receipt's prev_receipt_cid now points to a missing predecessor.
• Reordering: Swapping two receipts breaks both their chain pointers.
• Replacement: Substituting a receipt invalidates the next receipt's chain pointer.

The first Receipt from an agent MUST have prev_receipt_cid: null. A Verifier MAY choose to record the first receipt's CID separately as a tamper-evidence anchor.

§10 Optional IPFS/Filecoin pinning #

R+2 receipts MAY be pinned to IPFS (and durably backed by Filecoin) to guarantee permanence beyond the issuer's infrastructure. Pinning is OPTIONAL; the standard does not require it.

When pinned:

• Receipts use IPFS CIDv1 with the SHA-256 multihash. CIDs are stored in prev_receipt_cid as "ipfs:<CID>" instead of "sha256:<hex>".
• Implementations SHOULD pin via two independent pinning services for redundancy.
• Verifiers MAY fetch receipts directly from IPFS gateways without involving the issuer.

§11 Versioning & extensions #

Spec version

The spec_version field uses the format "r<major>/v<minor.patch>". The current version is "r2/v0.1". Major versions (r2 → r3) MAY introduce breaking changes; minor versions MUST remain backward-compatible.

Extensions

Implementations MAY add fields inside the extensions object. Extension fields MUST use a namespaced key of the form "<org>.<feature>" to avoid collisions. Examples:

• "dcs.memory_receipt_v1" — DCS Labs Sovereign Memory metadata
• "meity.dpdp_consent_v1" — Indian DPDP §8 consent metadata
• "isro.tile_provenance_v1" — ISRO satellite imagery provenance fields

Verifiers MUST ignore unrecognized extension fields. Verifiers that understand a specific extension MAY apply additional validation rules to it.

Sectoral profiles

A sectoral profile is a public document specifying:

• Required action_type values for that sector.
• Required extensions fields and their JSON Schema.
• Any additional validation a conforming implementation MUST apply.

Profiles are registered at https://dcslabs.ai/standard/profiles/<profile-name>. The first profiles in active drafting: r2-health-v1 (healthcare), r2-gov-v1 (Indian government RTI-compliance), and r2-finance-v1 (cross-border payment provenance).

§12 Worked example #

A complete R+2 signed receipt for a memory-write action, followed by a verification you can run yourself.

The signed receipt

{
  "spec_version":     "r2/v0.1",
  "agent_pubkey":    "u4yK_lH8Z6vJ3qZ5tNwQpRz_aBcDeFgH1iJ2kL3mN4o",
  "agent_id":        "0001",
  "action_id":       "3f8a7c12-8b91-4e2c-9b3a-5f7d8e1a2c4b",
  "action_type":     "memory/write",
  "action_data": {
    "memory_id":    "mem_a83f12cd",
    "content_hash": "sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
    "embedding_model": "text-embedding-3-large",
    "embedding_dim":  1536
  },
  "occurred_at":     "2026-05-19T15:42:08.123Z",
  "prev_receipt_cid": "sha256:bafy2bzaceabc1234567890abcdef1234567890abcdef1234567890abcdef00",
  "nonce":           "k3J9p2qR7sT5vXyA",
  "extensions":      {},
  "signature":       "sig_base64url_86chars_no_padding_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
}

Verify it with curl + jq + a one-liner

# Fetch the receipt from the DCS reference implementation
$ curl -s https://api.dcslabs.ai/api/receipts/r2_a83f12cd \
    | jq '.receipt' \
    > receipt.json

# Get the expected public key from the on-chain identity layer (Base mainnet)
$ EXPECTED_PK=$(cast call 0xbDd1f5fC349D9a8EfCEb07Edbd491233b2540f5F \
    "agentPubkey(string)" "0001" --rpc-url https://mainnet.base.org)

# Run R+2 verifier (npm install -g @trdnetwork/r2-verify)
$ r2-verify --receipt receipt.json --pubkey $EXPECTED_PK
✓ Schema valid
✓ Spec version r2/v0.1 supported
✓ Pubkey matches Base mainnet record
✓ Signature valid
✓ Chain pointer matches predecessor (sha256:bafy2bzaceabc...)
✓ Timestamp within window

Receipt verified.

§13 Adoption checklist #

If your organization wants to adopt R+2, here's the minimum work required:

For an AI vendor (issuer-side)

1. Generate an Ed25519 keypair per agent. Keep the private key in a secrets manager.
2. Publish the public key to a discoverable identity layer (DNS TXT, on-chain registry, DID document).
3. For every action your agent takes, construct an R+2 receipt and sign it.
4. Store receipts in a queryable database (Postgres works fine). Index by agent_id, action_id, and occurred_at.
5. Expose a public read endpoint for receipt retrieval. GET /receipts/<action_id> returning the JSON.
6. Optionally pin receipts to IPFS for long-term durability.

For a regulator or downstream consumer (verifier-side)

1. Establish a process for obtaining the agent's expected public key (typically via the identity layer in use).
2. Run the verification flow from §8 on every receipt before trusting its claims.
3. For sensitive decisions, also walk the chain back to a known anchor.
4. Use the reference verifier (@trdnetwork/r2-verify) or implement your own — both are equally conformant.

A reference implementation written in TypeScript ships with the DCS Labs @trdnetwork/mcp-server npm package. It produces and verifies R+2 receipts by default for every MCP tool call. You can study it as a working example.

§14 Governance & change-log #

Editor

The current editor is DCS AI Technologies L.L.C. Contact: [email protected].

Path to multi-stakeholder governance

R+2 v0.1 is a single-editor draft. The intended trajectory:

• v0.1 (now): single-editor draft, public comment open.
• v0.2 (after first standards-body acknowledgment): editorial group expanded to include the first 2-3 adopting organizations.
• v1.0: proposed for ratification by a recognized standards body (target candidates: Anthropic Standards Program, MeitY/IndiaAI, W3C-AI Working Group).

DCS Labs will not hold a veto over any future version. The spec is MIT-licenced from v0.1 onward and can be forked at any time.

Change-log

§15 Frequently asked questions #

§16 Contact & contribution #

Comments, corrections, and contributions are warmly welcomed.

For policymakers

If you represent a government agency, regulator, or international body and want to evaluate R+2 for adoption: we'll arrange a 30-minute technical briefing and provide a sector-specific adoption guide. Email [email protected] with your context and we'll respond within 48 hours.