Prove compliance.
Reveal nothing.

§1 Motivation

R+2 produces signed receipts; R+3 aggregates them into Merkle-rooted, signed audit bundles. Both are powerful — but both have an unavoidable privacy property: the verifier sees data. To check an R+2 receipt, you must hold the receipt. To check an R+3 bundle, you must walk the Merkle proof for each included record.

In most operational contexts this is acceptable, even desirable. But three classes of question break the model:

• Cross-jurisdictional audit. A US-headquartered AI vendor must demonstrate EU AI Act Art. 12 compliance to a European regulator without exporting customer-identifying data outside the EU. Sending raw R+2/R+3 evidence violates GDPR Art. 44–49 transfer rules.
• Inter-organisation reconciliation. Two AI operators federate agents across a shared network and need to prove to each other (and to a settlement counterparty) that the period's transaction count, fee total, and policy adherence match — without exposing customer identities or trade secrets.
• Regulator-graded compliance without disclosure. An insurer underwriting an AI deployment requires evidence that the operator processed ≥N actions all within policy, while the operator cannot share the underlying actions because they contain protected health information (PHI), personally-identifying information (PII), or attorney-client material.

R+4 solves these by emitting zero-knowledge proofs over R+2 receipts and R+3 bundles. An R+4 proof is a short cryptographic object (~200 bytes) that lets a verifier check a specific, pre-committed statement about the underlying data without learning anything else. The proof is constant-size, verifiable in milliseconds, and natively anchorable to Base mainnet (or any other EVM L2) so that regulators, counterparties, and the public can verify a property holds — forever, without trusting the issuer or any intermediary.

§2 Relationship to R+2 and R+3

R+4 strictly depends on R+2 and R+3. It is not a replacement for either — it is a verification layer that operates over them.

An R+4 proof references R+2 receipts (via their hashes) and R+3 bundles (via their Merkle roots). It does not transmit them. The verifier can independently confirm that the referenced R+3 bundle was signed and (optionally) on-chain anchored — without ever seeing the receipts inside it.

2.1 Composition example

// Operator emits R+2 receipts continuously throughout Q1.
// Operator aggregates them into a signed R+3 bundle at end of Q1.
// Operator anchors R+3 Merkle root onto Base mainnet.
// Operator generates an R+4 proof of the statement:
//   "≥ 10,000 receipts in the bundle were signed by Agent-X with
//    policy_id = 'pol_v3' and amount ≤ $5.00, in [2026-01-01, 2026-03-31]"
// Operator publishes the R+4 proof + statement.
// Regulator verifies the proof in <10 ms. Sees nothing else.

§3 Terminology

RFC 2119 conformance: MUST, SHOULD, MAY apply throughout this document.

§4 Provable Statements

R+4 defines a small library of statement classes. Each class corresponds to a deployed circuit with a published vk. Issuers MUST emit statements that match an installed circuit; verifiers MUST reject proofs whose statement does not type-check against the circuit's published schema.

4.1 Statement object schema

{
  "r4_version": "0.1.0",
  "circuit_id": "r4-threshold-count-v1",
  "vk_hash": "sha256:7c92...e1f3",
  "statement": {
    "bundle_root": "0x9f...a4",
    "period_start": "2026-01-01T00:00:00Z",
    "period_end": "2026-03-31T23:59:59Z",
    "threshold": 10000,
    "policy_id": "pol_v3",
    "amount_cap_usd": 5.00,
    "issuer_id": "did:dcs:0xbDd1...0f5F"
  },
  "proof": "0xc2...6e"
}

4.2 Statement classes (v0.1 catalogue)

4.3 Adding new circuits

New statement classes are added by publishing a circuit definition (R1CS or PLONK constraints), running a public ceremony (see §6), and registering (circuit_id, vk_hash, schema) in the DCS Labs R+4 registry at registry.r4.dcslabs.ai. Issuers MUST NOT emit statements referencing unregistered circuit IDs in production.

§5 Circuit Construction

R+4 circuits are arithmetised R1CS (Groth16 profile) or custom-gate PLONK (PLONK profile) over a pairing-friendly curve. v0.1 standardises on BN254 for EVM compatibility (Base mainnet precompile); BLS12-381 is supported as an optional curve for higher security margins where on-chain verification is not required.

5.1 Per-statement constraints

Every R+4 circuit MUST enforce the following invariants:

• R+3 binding. The witness includes a Merkle path from each consumed R+2 receipt to the public bundle_root. The circuit verifies the path. Forgery requires breaking SHA-256.
• R+2 signature validity. The witness includes the ed25519 signature on each consumed receipt. The circuit verifies the signature against the issuer's public key (also public). EdDSA-in-circuit uses the in-circuit EdDSA-Poseidon variant or native ed25519 depending on profile.
• Range bounds. All public numeric bounds (thresholds, caps, time windows) are enforced via in-circuit range proofs.
• Time window. Each consumed receipt's timestamp is checked against period_start ≤ ts ≤ period_end.
• Domain separation. The circuit hashes inputs with a circuit-specific domain tag to prevent cross-circuit witness reuse.

5.2 Reference circuit · r4-threshold-count-v1

// Pseudo-code; full circom source in r4-circuits/threshold-count.circom
template ThresholdCount(MAX_RECEIPTS, TREE_DEPTH) {
  // Public inputs
  signal input bundle_root;
  signal input period_start;
  signal input period_end;
  signal input threshold;
  signal input policy_id;
  signal input amount_cap;
  signal input issuer_pk;

  // Private witness
  signal input receipts[MAX_RECEIPTS];
  signal input merkle_paths[MAX_RECEIPTS][TREE_DEPTH];
  signal input signatures[MAX_RECEIPTS];
  signal input active_count;       // number of receipts actually consumed

  // Verify each active receipt
  for (i = 0; i < MAX_RECEIPTS; i++) {
    if (i < active_count) {
      VerifyMerklePath(receipts[i], merkle_paths[i], bundle_root);
      VerifyEd25519(receipts[i], signatures[i], issuer_pk);
      AssertTimeWindow(receipts[i].ts, period_start, period_end);
      AssertPolicy(receipts[i].policy_id, policy_id);
      AssertAmountCap(receipts[i].amount, amount_cap);
    }
  }

  // Threshold check
  AssertGTE(active_count, threshold);
}

5.3 Cost model

§6 Setup Ceremony

Groth16 circuits require a per-circuit trusted setup to produce (pk, vk). The integrity of the resulting proofs depends on at least one participant in the ceremony being honest (1-of-N trust assumption). R+4 mandates a public, multi-party ceremony for every published circuit.

6.1 Ceremony procedure

1. Phase 1 (universal). Reuse the existing Perpetual Powers of Tau ceremony (Ethereum Foundation). DCS Labs publishes the contributor set + verification artefacts.
2. Phase 2 (per-circuit). Open contribution window of ≥ 14 days. ≥ 5 independent contributors (each providing fresh entropy). Each contribution is broadcast with a SHA-256 commitment + ed25519 attestation. The final SRS is the composition of all contributions.
3. Toxic-waste destruction. Each contributor MUST irrecoverably destroy their secret randomness after contributing. R+4 strongly recommends air-gapped machines + verified entropy sources.
4. Verifiability. The full transcript MUST be publicly downloadable. Anyone can re-run the verifier and confirm that the final (pk, vk) is consistent with the contribution chain.
5. Registry binding. The hash of the final vk is registered in the R+4 circuit registry at registry.r4.dcslabs.ai + anchored on Base mainnet for tamper-evidence.

6.2 Why a ceremony?

If a single party generated the SRS, they could secretly retain the trapdoor — the mathematical "trapdoor" that lets the holder forge proofs for any statement. The ceremony distributes this trust: as long as any one of the contributors destroyed their share, no party can forge proofs. With 5+ contributors and public attestation, the practical security is high.

6.3 PLONK profile (universal setup)

PLONK-based R+4 circuits use a universal-and-updatable trusted setup, eliminating the per-circuit ceremony. The trade-off is somewhat larger proofs (~400-600 bytes vs ~200 for Groth16) and slightly higher verification cost. v0.1 supports both; deployments MAY choose PLONK to avoid per-circuit ceremonies entirely.

6.4 Post-quantum considerations

Both Groth16 and PLONK rest on the hardness of discrete log on pairing-friendly curves — they are not post-quantum-secure. R+4 v0.x targets present-day classical security. A future R+4 v1.x profile (under research at DCS Labs) will offer STARK-based proofs (post-quantum, larger proof size) for deployments with long-horizon retention requirements (typically > 15 years).

§7 Proof Object Format

An R+4 proof object is a JSON document containing the statement, the proof bytes, and metadata required for verification. The full object MUST be canonically serialised per RFC 8785 (JSON Canonicalisation Scheme) before any hashing or signing.

7.1 Canonical R+4 proof object

{
  "r4_version": "0.1.0",
  "profile": "groth16-bn254",
  "circuit_id": "r4-threshold-count-v1",
  "vk_hash": "sha256:7c92ab...e1f3",
  "statement": {
    "bundle_root": "0x9f3a...a401",
    "period_start": "2026-01-01T00:00:00Z",
    "period_end": "2026-03-31T23:59:59Z",
    "threshold": 10000,
    "policy_id": "pol_v3",
    "amount_cap_usd_cents": 500,
    "issuer_id": "did:dcs:0xbDd1f5fC349D9a8EfCEb07Edbd491233b2540f5F"
  },
  "proof": {
    "pi_a": ["0x...", "0x...", "0x..."],
    "pi_b": [["0x...", "0x..."], ["0x...", "0x..."]],
    "pi_c": ["0x...", "0x...", "0x..."]
  },
  "public_inputs": ["..."],
  "issued_at": "2026-04-01T12:04:33Z",
  "issuer_signature": "ed25519:0x2bd...9a",
  "anchor": {
    "chain": "base-mainnet",
    "tx_hash": "0x4c...",
    "block_number": 29371204
  }
}

7.2 Field rules

• r4_version, profile, circuit_id, vk_hash — REQUIRED. Verifier MUST reject if any are missing or do not match a registered circuit.
• statement — REQUIRED. Structure depends on circuit_id; MUST validate against the registered schema.
• proof — REQUIRED. Profile-specific binary blob (Groth16 here; different for PLONK).
• public_inputs — REQUIRED. Field elements derived from statement per the circuit's public-input ordering.
• issued_at — REQUIRED. RFC 3339 UTC. Verifier MAY enforce freshness windows.
• issuer_signature — OPTIONAL but RECOMMENDED. Ed25519 signature by issuer over the canonicalised proof object (excluding the signature field itself). Provides attribution; not required for proof soundness.
• anchor — OPTIONAL. On-chain anchor of the proof object's hash for long-term tamper-evidence.

7.3 Wire encoding

Proofs MAY be transmitted as JCS-canonical JSON (default) or as CBOR (deterministic encoding, RFC 8949) for size-sensitive deployments. The binary proof field is hex-encoded in JSON and raw-bytes in CBOR. Verifiers MUST accept both encodings.

§8 Federation Protocol

R+4 enables a federation: a set of independent issuers that share circuit definitions and verifying keys. Within a federation, any participant can produce an R+4 proof, and any other participant (or external verifier) can check it without bilateral key exchange.

8.1 Federation membership

A federation is defined by:

• A canonical federation manifest (signed JSON document) listing member issuer IDs, accepted circuit IDs, and the federation's signing key.
• The federation's manifest hash is anchored on Base mainnet to prevent silent re-writes of membership.
• Members MAY be added or removed via signed manifest updates with monotonically increasing version numbers.

8.2 Cross-issuer verification

To verify a proof issued by an unfamiliar party, a verifier:

1. Fetches the latest federation manifest (signature + on-chain anchor verified).
2. Confirms that proof.issuer_id is in the manifest's member list.
3. Confirms that proof.circuit_id is in the manifest's accepted-circuit list.
4. Retrieves the registered vk for that circuit (registry + on-chain anchor verified).
5. Runs Groth16.Verify(vk, public_inputs, proof). If true, the statement holds.

8.3 Sample federation use cases

§9 Verification Procedure

The verifier algorithm for an R+4 proof object is deterministic and runs in < 10 ms on commodity hardware for the Groth16 profile.

9.1 Verifier pseudocode

function verify_r4(proof_obj, registry, federation_manifest) {
  // 1. Schema validation
  if (!validate_schema(proof_obj.statement, proof_obj.circuit_id))
    return { ok: false, reason: "schema_mismatch" };

  // 2. Circuit registration check
  const circuit = registry.lookup(proof_obj.circuit_id);
  if (!circuit || circuit.vk_hash !== proof_obj.vk_hash)
    return { ok: false, reason: "unregistered_circuit" };

  // 3. Federation membership (optional)
  if (federation_manifest) {
    if (!federation_manifest.members.includes(proof_obj.statement.issuer_id))
      return { ok: false, reason: "non_member_issuer" };
  }

  // 4. Public-input derivation
  const public_inputs = derive_public_inputs(
    proof_obj.statement, proof_obj.circuit_id
  );
  if (!deep_equal(public_inputs, proof_obj.public_inputs))
    return { ok: false, reason: "public_input_mismatch" };

  // 5. Issuer signature (optional)
  if (proof_obj.issuer_signature) {
    if (!ed25519.verify(proof_obj, proof_obj.issuer_signature))
      return { ok: false, reason: "bad_issuer_signature" };
  }

  // 6. Anchor check (optional)
  if (proof_obj.anchor) {
    if (!chain_anchor_resolves(proof_obj.anchor, hash(proof_obj)))
      return { ok: false, reason: "bad_anchor" };
  }

  // 7. The actual zero-knowledge verification
  const ok = groth16.verify(
    circuit.vk, public_inputs, proof_obj.proof
  );
  return ok
    ? { ok: true, statement: proof_obj.statement }
    : { ok: false, reason: "snark_invalid" };
}

9.2 On-chain verification

Groth16 over BN254 has a precompiled pairing on Ethereum and L2s including Base. An R+4 proof can be verified on-chain in approximately ~250,000 gas (well within block limits). This enables R+4 proofs to gate smart-contract execution — e.g. a settlement contract that releases funds only when an R+4 compliance proof is presented.

// Solidity sketch — full implementation in r4-verifier-contract/src/
function verifyAndExecute(
    bytes calldata proof,
    uint[7] calldata public_inputs
) external {
    require(
        groth16Verifier.verifyProof(proof, public_inputs),
        "R+4 proof invalid"
    );
    // public_inputs[0] = bundle_root, [1]=period_start, ...
    // Now the contract knows the statement holds.
    _releaseFunds(public_inputs[0]);
}

§10 Security Considerations

10.1 Soundness

R+4 soundness rests on (a) the cryptographic hardness of the underlying SNARK (Groth16 over BN254 / PLONK), (b) the integrity of the trusted-setup ceremony, and (c) the correctness of the circuit implementation. A failure in any one of these undermines the entire stack. Each circuit MUST be independently audited before being added to the registry.

10.2 Toxic-waste retention

If all ceremony contributors retain their secret randomness, they can collude to forge proofs for any statement. R+4 mitigates this by (a) requiring ≥ 5 independent contributors, (b) requiring public attestations, (c) recommending air-gapped machines, and (d) allowing PLONK universal setup as an alternative for deployments where ceremony coordination is impractical.

10.3 Circuit bugs

A bug in the circuit — e.g. a missing range check or under-constrained signal — can allow the prover to construct proofs of statements that do not actually hold. R+4 mandates:

• Formal verification or extensive fuzz testing for every registered circuit.
• A 90-day open-review window before any new circuit is registered.
• Independent third-party audit before production use.
• Out-of-band notification mechanism for known-bad circuits (vk_hash blocklist).

10.4 Replay and freshness

R+4 proofs are not inherently bound to a verification context. A proof of "Q1 2026 compliance" can be replayed indefinitely. Where freshness matters, verifiers SHOULD include the current period in the statement's public inputs, or rely on the optional issued_at field with a tight acceptance window. For settlement contracts, the on-chain anchor provides natural temporal binding.

10.5 Curve-level attacks

BN254 has degraded since its parameter selection (≤ ~100 bit security against modern attacks). v0.1 deployments accept this for EVM compatibility. Long-horizon archives (proofs retained > 10 years) SHOULD use the BLS12-381 profile (~128 bit security) and migrate to STARK-based v1.x profiles when available.

10.6 Composition risks

R+4 proofs that reference R+3 bundles transitively rely on the R+3 signature and (where present) on-chain anchor. A compromised R+3 issuer signing key allows an attacker to commit a malicious bundle, and any R+4 proof over it will inherit the corruption. Mitigation: federation manifests SHOULD require R+3 anchors for any bundle that gets witnessed by an R+4 proof.

§11 Privacy Considerations

11.1 What R+4 hides

Properly constructed R+4 proofs reveal nothing beyond the public statement. Specifically:

• Individual receipt contents are not revealed.
• Individual principals (agents, customers) referenced in the witness are not revealed.
• Exact counts above the threshold are not revealed (the proof reveals "≥ N", not "= 12,847").
• Timestamps within the period are not revealed individually.

11.2 What R+4 still reveals

The statement itself is public. Verifiers learn whatever the statement encodes — typically: the bundle_root, the period window, the threshold, the policy ID, and the issuer ID. Issuers MUST treat the statement as a public document and choose statements that do not themselves leak sensitive information.

Side-channel leakage MAY occur via timing (proof generation time), proof size (for PLONK proofs with variable-length statements), or proof issuance frequency. Federations SHOULD batch proofs and use constant-time prover implementations where side-channel resistance matters.

11.3 Compatibility with GDPR / DPDP

An R+4 proof generated from a witness that includes PII does not "transfer" the PII to the verifier — the verifier never sees it. This makes R+4 a strong primitive for cross-border AI compliance demonstrations under GDPR Art. 44-49 and DPDP §16-17 (cross-border data transfer restrictions). DCS Labs has published a draft sectoral GDPR profile mapping R+4 statement classes to specific Article-12-and-after disclosures.

§12 Compliance Mappings

Each compliance mapping above is a starting point; jurisdictional and sectoral specifics may require additional circuits. Submit a request via [email protected] for a new statement class.

§13 Example Proof

End-to-end example: an operator generating an R+4 threshold-count proof over a Q1 2026 R+3 bundle, anchored on Base mainnet.

13.1 Inputs (witness)

// 12,847 R+2 receipts from Agent X, signed Jan-Mar 2026,
// all with policy_id = "pol_v3", all amount ≤ $5.00.
// Aggregated into R+3 bundle with Merkle root 0x9f3a...a401.
// R+3 bundle anchored on Base @ block 29240118.

13.2 Public statement

{
  "r4_version": "0.1.0",
  "circuit_id": "r4-threshold-count-v1",
  "statement": {
    "bundle_root": "0x9f3aa1f2bc4d9e7f0a8b3c2d1e0f9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3a401",
    "period_start": "2026-01-01T00:00:00Z",
    "period_end": "2026-03-31T23:59:59Z",
    "threshold": 10000,
    "policy_id": "pol_v3",
    "amount_cap_usd_cents": 500,
    "issuer_id": "did:dcs:0xbDd1f5fC349D9a8EfCEb07Edbd491233b2540f5F"
  }
}

13.3 Verification result

$ r4-verify proof.json --registry registry.r4.dcslabs.ai
[ ok ]     circuit_id          : r4-threshold-count-v1
[ ok ]     vk_hash             : sha256:7c92ab...e1f3 (registered)
[ ok ]     schema validation   : passed
[ ok ]     public input derive : matched
[ ok ]     issuer signature    : ed25519 verified
[ ok ]     base anchor         : tx 0x4c...8e at block 29371204 ✓
[ ok ]     groth16 verify      : valid (8.3 ms)

Statement holds: The operator emitted ≥ 10,000 R+2 receipts in [2026-01-01, 2026-03-31] under policy "pol_v3" with amount ≤ $5.00. No further information was revealed.

The proof object is ~290 bytes including JSON wrapping. The actual SNARK proof is 192 bytes (Groth16 over BN254). Verification took 8.3 ms on commodity hardware. The same proof can be verified on Base mainnet in ~250k gas.

§ References

• Groth, J. (2016). "On the Size of Pairing-Based Non-interactive Arguments." EUROCRYPT 2016.
• Gabizon, A., Williamson, Z. J., & Ciobotaru, O. (2019). "PLONK: Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge."
• RFC 8032 — EdDSA: Edwards-Curve Digital Signature Algorithm.
• RFC 8785 — JCS: JSON Canonicalization Scheme.
• RFC 8949 — CBOR: Concise Binary Object Representation.
• R+2 Open Provenance Standard — dcslabs.ai/standard
• R+3 Tamper-Evident Audit Export Standard — dcslabs.ai/standard/r3
• Bowe, S., Gabizon, A., & Miers, I. (2017). "Scalable Multi-party Computation for zk-SNARK Parameters in the Random Beacon Model." — basis for the trusted-setup ceremony.
• EU AI Act (Regulation 2024/1689), Articles 12, 26.
• NIST AI RMF 1.0 (2023), GOVERN, MEASURE, MAP, MANAGE.
• India DPDP Act 2023, §16-17 (cross-border data transfer).
• HIPAA §164.308 / §164.312 (technical safeguards).