Circuit Reference

Apertrue uses 19 Noir circuits. This section is a reference catalogue — each circuit's purpose, public inputs, outputs, and approximate constraint count. All circuits compile to BN254 and produce UltraHonk proofs (500 fields) unless otherwise noted.

Circuit map

Split proofs

Every C2PA image generates two proofs that are later combined. ProofA handles certificate chain verification and metadata extraction. ProofB handles COSE signature verification and claim binding. Splitting the workload across two circuits keeps each circuit's constraint count manageable for browser proving.

ProofA — certificate chain + privacy disclosure

ProofA verifies that a C2PA manifest was signed by a certificate chaining to a trusted intermediate CA, extracts metadata (location, time, device, actions), and applies graduated privacy disclosure. The generic circuit handles all five algorithm variants via a selector. The specialised variants (P-256, P-384, RSA-2048, RSA-4096, Skip) are faster because they omit unused code paths.

The circuit proves that the exact coordinates fall within the disclosed privacy circle (centre + radius), the exact timestamp falls within the disclosed time range (min/max), and the certificate chains to a trusted intermediate in the Oracle's Merkle tree.

ProofB — COSE signature + claim binding

ProofB verifies the COSE signature over the C2PA Sig_structure and confirms that the claim bytes are embedded within it. The generic circuit handles both ES256 (ECDSA) and PS256 (RSA-PSS) via a selector. ProofB ES256 and ProofB PS256 are specialised variants.

Six public inputs are shared between ProofA and ProofB and must match exactly: trust_list_root, content_hash, nullifier, proof_timestamp, claim_hash_commitment, and link_commit. The ImageAggregator enforces this — if any value differs, aggregation fails.

Algorithm variants

The browser selects the circuit variant based on the C2PA manifest's signature algorithm. Specialised circuits are 30–60% faster than the generic circuit because they compile only the code paths for one algorithm:

Aggregation circuits

ImageAggregator — single image

The ImageAggregator recursively verifies a ProofA and ProofB inside a new circuit, producing a single proof that represents a fully verified image. It checks that all shared public inputs match between the two split proofs and computes an image commitment from the verified data.

image_commitment = Poseidon2([
  trust_list_root,
  content_hash,
  nullifier,
  proof_timestamp,
  location_commitment,
  time_commitment,
  edit_time_commitment,
  link_commit,
  actions_hash_field
], 9)

The image commitment is a single field element that uniquely identifies a verified image with all its metadata. This commitment is the input to the tree aggregation layer.

TreeAggregator — batch combination

The TreeAggregator combines two proofs into one. It is reusable at every level of the binary tree — it can combine two ImageAggregator proofs, two TreeAggregator proofs, or one of each. The final TreeAggregator proof represents the entire batch.

The padding fields exist so that the TreeAggregator's public input layout matches the ImageAggregator's — both circuits have the same number of public inputs. This simplifies recursive verification because the verifier doesn't need to distinguish between circuit types.

Privacy circuits

Selective Disclosure

The Selective Disclosure circuit lets a user prove specific claims about a verified image (location range, time range, device, actions) without revealing the image itself. The prover chooses which fields to disclose — hidden fields are set to zero.

The circuit verifies a Merkle path from the image commitment to the batch root commitment (8 levels, supporting up to 256 images per batch). For each disclosed field, it proves that the disclosed value is consistent with the original committed data — the prover cannot fabricate disclosed values.

Identity circuits

JWT Identity

The JWT Identity circuit verifies an OIDC JWT from any provider (Google, Microsoft, Okta) and proves the user's email domain without revealing the full email address. Built on ZKEmail's noir-jwt.

Private inputs include the JWT payload (partial SHA mode for efficiency), the RSA-2048 public key, and the signature. The circuit verifies the RSA signature, parses the JWT to find the email claim, confirms email_verified == true, and checks that the domain after the @ matches the public input.

Anonymous Credential

A Semaphore-style credential circuit. Proves membership in a Merkle tree of identity commitments with a scoped nullifier for rate limiting. Uses Baby Jubjub elliptic curve arithmetic from noir-edwards and Poseidon hashing from zk-kit.noir.

The Merkle tree supports up to 20 levels (approximately 1 million identities). The nullifier is deterministic per secret per scope — using the same credential twice in the same scope produces the same nullifier, enabling rate limiting without revealing identity.

Credential Registration

A lightweight circuit that proves knowledge of the Baby Jubjub secret key behind a Poseidon commitment. Used during credential registration to verify the user controls the secret before adding the commitment to the tree.

Aztec contracts

Two Aztec contracts handle on-chain operations. These are Noir programs compiled for the Aztec Virtual Machine rather than standalone ZK circuits.

WebAuthn Account

The user's Aztec account contract. Supports dual-path authorisation via a discriminator at witness[0]:

The WebAuthn path verifies a P-256 ECDSA signature over the transaction hash, with the authenticator data and client data JSON as witness inputs. The session key path verifies a Schnorr signature from an ephemeral Grumpkin key pair authorised by the user's passkey. Session keys have a configurable expiry and scope, stored as encrypted notes in the contract's private state.

ApertrueVerifier

The verification contract. Receives the final TreeAggregator proof and creates private notes representing verified media. Also stores identity proofs (JWT and passport).

Shared cryptographic primitives

Across all circuits, the following primitives are used:

Constraint budget

Constraint count determines proving time. In the browser (Barretenberg WASM), rough benchmarks on mid-range hardware:

The split proof architecture exists specifically because of these constraints. A single monolithic circuit covering all of ProofA + ProofB would exceed 300k constraints and require 30+ seconds of proving time with ~600 MB of memory — impractical for browser use. Splitting into two circuits and proving them in parallel on separate Web Workers halves the wall-clock time.

Sensor line circuits

The sensor fingerprint line has its own circuit family, built and proven on the phone rather than in the browser. Measured on an iPhone 13 Pro Max:

The circuit family is public at Apertrue/sensor-circuits, and the protocol behind it is specified in Prove the Camera, Not the Cloud.

The final section covers the security model — threat analysis, trust assumptions, and the guarantees the system provides.