Aggregate audit bundles
over R+2 receipts.

§1 Motivation

R+2 receipts are individually signed. They prove that a specific action occurred, was authorised, and has not been tampered with. They are emitted cheaply, automatically, and at high frequency — one per agent action.

But auditors do not consume single events. They consume periods. A compliance officer asks: "Show me everything Agent X did in Q1 2026, with proof that the record is complete and intact." A regulator asks: "Prove that no records were silently deleted between January and March." A Series-A investor asks: "Show me a verifiable settlement ledger across the last 90 days."

Answering those questions from raw R+2 receipts is feasible but expensive. The auditor would have to fetch every receipt, verify every signature, walk the hash chain, and trust that no receipts are missing. That is not how regulators work — and it does not scale beyond a few hundred receipts.

R+3 solves this by producing aggregate bundles. An R+3 export contains:

• A Merkle root over all R+2 receipts in the time window
• A monotonic sequence number linking the bundle to its predecessor
• A signature by the issuing principal (typically the operator)
• Optional on-chain anchor: one transaction on Base mainnet commits the Merkle root, making the entire bundle independently verifiable forever
• Optional PDF rendering for human regulators alongside the JSON bundle

§2 Relationship to R+2

R+3 is strictly an aggregation and export layer on top of R+2. It introduces no new signing scheme for individual actions, no new cryptographic primitives, and no new identity model. R+2 receipts are the source data; R+3 exports are the bundled, signed, regulator-ready output.

Layered architecture

┌──────────────────────────────────────────────────────────┐
│  R+3  · Audit Bundle                                  │
│        Merkle root + signature + optional on-chain anchor
│        Time-range aggregate over many R+2 receipts
├──────────────────────────────────────────────────────────┤
│  R+2  · Signed Action Receipt                          │
│        ed25519 + RFC 8785 canonical JSON + hash chain
│        One receipt per agent action
└──────────────────────────────────────────────────────────┘

An R+3 export does not modify R+2 receipts. It commits to them via Merkle root. R+2 receipts remain individually verifiable using the R+2 verification procedure (see /standard §6).

§3 Terminology

The key words MUST, MUST NOT, REQUIRED, SHALL, SHOULD, and MAY are interpreted as in BCP 14 [RFC 2119] and [RFC 8174].

§4 Audit Bundle Format

An R+3 bundle is a single canonical JSON document (per RFC 8785) with the following structure.

4.1 Top-level fields

4.2 Time range

The time_range object SHALL contain:

• from — RFC 3339 UTC timestamp of the inclusive start of the audit window
• to — RFC 3339 UTC timestamp of the exclusive end

The bundle MUST include every R+2 receipt where from ≤ receipt.timestamp < to, subject to scope. The bundle MUST NOT include receipts outside this window.

4.3 Scope filter (optional)

An optional scope object MAY filter the included receipts. Defined filter types:

• agent_id — list of DIDs to include
• action_type — list of dotted action-type prefixes (e.g. "treasury.", "memory.write")
• regulatory_scope — list of scope tags (e.g. "gdpr", "hipaa", "dpdp")

If scope is absent, all receipts in the time window MUST be included. If scope is present, the filter rules apply with OR semantics within a field and AND across fields.

§5 Merkle Tree Construction

R+3 v0.1 uses a deterministic binary SHA-256 Merkle tree with RFC 8785-canonicalised leaves.

5.1 Leaf hash

For each R+2 receipt to be included:

1. Canonicalise the receipt JSON per RFC 8785 (excluding the receipt's own signature field, which is already part of the canonical content of the signed receipt — verifiers MUST canonicalise the receipt including its signature for the leaf hash)
2. Compute leaf_hash = SHA-256(canonical_bytes)

5.2 Pair hash

For internal nodes, concatenate the left and right child hashes as raw bytes and hash:

pair_hash = SHA-256(left_hash || right_hash)

5.3 Odd-node padding

If a level has an odd number of nodes, the final node MUST be duplicated. (Equivalent to Bitcoin Merkle tree construction.)

5.4 Leaf ordering

Leaves MUST be ordered by:

1. Primary: ascending receipt.timestamp
2. Secondary: ascending receipt.action_id (UUIDv4 lexicographic)

This ordering is deterministic and reproducible by any verifier with access to the receipt set.

5.5 Empty bundle

An R+3 bundle with receipts_count = 0 is permitted (e.g. for "no activity in this period" audits). The merkle_root for an empty bundle SHALL be "sha256:0000000000000000000000000000000000000000000000000000000000000000".

§6 Signature Scheme

R+3 bundles are signed using Ed25519 (RFC 8032). The signature commits to the canonical JSON of the entire bundle object except the signature field.

6.1 Signing procedure

1. Remove the signature field if present
2. Canonicalise the remaining object per RFC 8785
3. Sign the resulting bytes with the issuer's Ed25519 private key
4. Set signature to the structure below

6.2 Signature object

"signature": {
  "alg": "ed25519",
  "key_id": "did:dcs:base:issuer-prod#auditor-key-2026-05",
  "sig": "<base64url-encoded 64-byte signature>"
}

The key_id MUST resolve to a public key via DID Document resolution. R+3 verifiers SHOULD cache the resolved public key for the duration of the bundle's signature validity.

§7 On-Chain Anchor (optional)

An R+3 bundle MAY include an anchor object recording an on-chain transaction whose calldata contains the bundle's merkle_root. This makes the bundle's commitment publicly verifiable forever, independent of the issuer.

7.1 Anchor object

"anchor": {
  "chain": "base-mainnet",
  "tx_hash": "0x61f6d9019dd3503eafdc5ffc0f0335f05abce8bf19ac50d4e78369226a7211a1",
  "block_number": 12345678,
  "contract": "0xbDd1f5fC349D9a8EfCEb07Edbd491233b2540f5F",
  "method": "anchorMerkleRoot(bytes32,bytes32)",
  "params": {
    "root": "0xabc...123",
    "export_id": "0xdef...456"
  }
}

7.2 Anchor verification

A verifier with on-chain access SHOULD:

1. Fetch the transaction at tx_hash
2. Confirm it called contract with method method
3. Decode the parameters and confirm params.root matches the bundle's merkle_root (modulo the sha256: prefix)
4. Confirm the block number is final (sufficient confirmations for the chain's safety model)

7.3 Anchor contract

The reference anchor contract on Base mainnet accepts (bytes32 root, bytes32 export_id) tuples and emits an AnchorAdded event. The contract is intentionally minimal: it stores nothing and verifies nothing. The on-chain record exists only to make the calldata indelibly visible.

§8 Verification Procedure

To verify an R+3 bundle:

8.1 Bundle-level verification

1. Resolve signature.key_id to a public key via DID Document resolution
2. Remove signature, canonicalise the bundle, and verify the Ed25519 signature
3. Validate that predecessor_hash matches the canonical hash of the previous bundle in the issuer's series (or is the genesis zero hash)
4. If anchor is present, perform anchor verification per §7.2

8.2 Receipt inclusion verification

To prove that a specific R+2 receipt is included in an R+3 bundle:

1. Compute the leaf hash for the receipt per §5.1
2. Obtain the Merkle path (siblings from leaf to root) from the bundle's bundle_uri
3. Walk the path, hashing pairwise, and check that the final hash equals the bundle's merkle_root
4. Independently verify the receipt's R+2 signature per the R+2 specification

A successful verification proves: (a) the bundle was signed by the claimed issuer, (b) the receipt was committed to in this bundle, (c) the receipt itself is signed and untampered. If an on-chain anchor is present and verified, the bundle is independently verifiable without trusting the issuer.

8.3 Reference verifier

A reference implementation is published as @trdnetwork/r2-verify on npm. The R+3 verification commands include:

npx r2-verify r3-bundle <bundle.json>            # full bundle verification
npx r2-verify r3-inclusion <bundle.json> <receipt.json>  # proof of inclusion
npx r2-verify r3-anchor <bundle.json>            # on-chain anchor verification

§9 Security Considerations

9.1 Issuer key compromise

If an issuer's Ed25519 private key is compromised, an attacker can sign forged R+3 bundles. R+3 mitigates this with:

• The predecessor_hash chain — any forged bundle disrupts the chain and is detectable by any verifier holding earlier bundles
• On-chain anchoring — once anchored, a Merkle root cannot be replaced
• Key rotation — issuers SHOULD rotate signing keys at most every 90 days. Old keys remain valid for historical bundle verification

9.2 Receipt omission

An issuer might attempt to silently omit R+2 receipts from a bundle (selective non-disclosure). R+3 v0.1 does not prevent this — it only proves that the included receipts are committed to. Future revisions of R+3 will define completeness assertions via anchored receipt counts and gap-detection challenges.

9.3 Canonicalisation

All hashing and signing MUST use RFC 8785 canonicalisation. Implementations that deviate (e.g. by sorting keys differently or using non-UTF-8 encodings) will produce verification failures.

9.4 Replay attacks

An R+3 bundle is uniquely identified by (issuer, sequence). Replayed bundles fail uniqueness checks at the verifier. Bundle predecessor-hash chaining additionally prevents reordering attacks.

§10 Privacy Considerations

R+3 bundles contain commitments (hashes) to R+2 receipts, not the receipts themselves. The receipt content is referenced through bundle_uri and MAY be access-controlled.

10.1 Selective disclosure

An issuer MAY publish the Merkle root and signature publicly (or anchor on-chain) while keeping the receipt contents behind authentication. A regulator with credentials retrieves the receipts; the public sees only the commitment.

10.2 Payload-hash receipts

For receipts referencing PHI, PII, or other regulated data, the underlying R+2 receipt MAY use the payload_hash_only mode (R+2 §7) where the receipt commits to a hash of the payload rather than the payload itself. R+3 bundles built from such receipts are publishable without revealing the underlying data.

10.3 GDPR Article 17 (Right to Erasure)

When a data subject requests erasure under GDPR Article 17, the issuer SHALL:

1. Erase the receipt payload at the source
2. Mark the receipt as erased via a follow-up R+2 receipt referencing the original by action_id
3. Include both the original and the erasure receipt in subsequent R+3 bundles

This satisfies erasure (the payload is gone) while preserving the auditability of the erasure act itself (regulators can prove that erasure was performed).

§11 Compliance Mappings

R+3 bundles are designed to satisfy specific audit-export requirements in major regulatory regimes.

§12 Example R+3 Bundle

A complete, signed, anchored R+3 bundle covering one day of treasury activity:

{
  "version": "r+3/0.1.0",
  "export_id": "7d8e3a1c-2f4b-4d9e-8a5c-1234567890ab",
  "issuer": "did:dcs:base:treasury-prod",
  "sequence": 42,
  "predecessor_hash": "sha256:9f8e7d6c5b4a3a2918073625140312fffeeddccbba99887766554433221100",
  "time_range": {
    "from": "2026-05-20T00:00:00Z",
    "to":   "2026-05-21T00:00:00Z"
  },
  "scope": {
    "action_type": ["treasury.settle"],
    "regulatory_scope": ["dpdp", "sox"]
  },
  "receipts_count": 1,
  "merkle_root": "sha256:c4f7b9a2e3d1f5c8a7b6e4d9c2f1e0a3b8c5d4e7f2a1b0c3d6e9f8a7b4c5d2e1",
  "merkle_construction": "binary-sha256-rfc8785",
  "anchor": {
    "chain": "base-mainnet",
    "tx_hash": "0x61f6d9019dd3503eafdc5ffc0f0335f05abce8bf19ac50d4e78369226a7211a1",
    "block_number": 12345678,
    "contract": "0xbDd1f5fC349D9a8EfCEb07Edbd491233b2540f5F",
    "method": "anchorMerkleRoot(bytes32,bytes32)"
  },
  "bundle_uri": "ipfs://bafybeih...",
  "signature": {
    "alg": "ed25519",
    "key_id": "did:dcs:base:treasury-prod#auditor-key-2026-05",
    "sig": "BASE64URL_ENCODED_SIGNATURE_BYTES_HERE"
  }
}

FAQ Frequently Asked Questions

Refs References

• R+2 v0.1.0 — DCS Open Provenance Standard (R+2)
• r2-gov-v1 — Government sectoral profile
• r2-health-v1 — Healthcare sectoral profile (HIPAA + EU AI Act)
• r2-finance-v1 — Financial-services sectoral profile
• RFC 8032 — Edwards-Curve Digital Signature Algorithm (EdDSA)
• RFC 8785 — JSON Canonicalization Scheme (JCS)
• RFC 3339 — Date and Time on the Internet: Timestamps
• RFC 2119 / 8174 — Key Words for Use in RFCs (MUST / SHOULD / MAY)
• EU AI Act — Regulation (EU) 2024/1689, Article 12 — Record-keeping
• NIST AI RMF 1.0 — GOVERN-1.4 — Audit Trail Requirements
• India DPDP Act — §8(4), §8(5) — Accuracy and safeguards
• HIPAA Security Rule — 45 CFR 164.312(b) — Audit Controls
• SOX — Sarbanes-Oxley Act 2002 §404 — Internal Controls
• ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system
• CAIP-2 — Chain Agnostic Improvement Proposal — Blockchain ID Specification