Skip to main content
← All docs

Concepts

What each part of a CertNode receipt actually does, and what it lets you prove later.

The three-layer timestamp chain

A CertNode receipt binds together three independent timestamp proofs. Each layer targets a different attack: a single source of trust isn't a chain, just a claim.

Layer 1 — CertNode signature

ES256 JWS (JSON Web Signature, RFC 7515) over a payload containing the sha256 content hash, model identifier, provider, optional prompt hash, and signing timestamp. Verifiable against CertNode's published EC P-256 public key without contacting CertNode at all — the cryptography is self-contained.

Layer 2 — RFC 3161 timestamp

Independent Time Stamp Authority (TSA) countersignature over the layer-1 signature, following RFC 3161. The TSA is a third party we don't control. This is the format cited in case law for self-authenticating digital evidence — if CertNode disappears tomorrow, RFC 3161 verifiers still validate the timestamp.

Layer 3 — Bitcoin OpenTimestamps anchor

Layer-1 hash batched into an OpenTimestamps Merkle tree that gets committed to a Bitcoin block. Confirms in 1-2 hours typically. Once anchored, the receipt is cryptographically pinned to a publicly-auditable blockchain — even if CertNode AND the RFC 3161 TSA both disappeared, the Bitcoin proof remains independently verifiable forever.

Bitcoin anchoring is queued; status starts as pending and transitions to anchored when a confirming block lands. Receipts are signed + RFC 3161 timestamped synchronously at sign time.

Content hashing

CertNode never stores the raw content you sign. It computes sha256 of the content at sign time, signs that hash, and stores only the hash. The receipt then proves: "some content with this hash existed at this timestamp."

Re-verification re-hashes your stored content and compares — if the hashes match, the content hasn't been modified since signing. If they don't, either the content changed or someone is presenting a different copy.

JWS signature payload

The signed payload follows a stable schema (versioned). Each field is part of the binding:

{
  "iss": "https://certnode.io",       // issuer
  "iat": 1715381450,                   // signing time (Unix)
  "rid": "uuid-of-receipt",            // receipt id
  "ch":  "sha256:abc123...",           // content hash
  "ct":  "ai_output",                  // content type
  "m":   "claude-opus-4-7",            // model (optional)
  "p":   "anthropic",                  // provider (optional)
  "ph":  "sha256:def456..."            // prompt hash (optional)
}

Verifying the signature confirms: (a) every field was present at signing time, (b) no field has been altered. Modifying the payload invalidates the signature.

Prompt-hash binding (optional)

When you pass promptHash at signing time, that hash gets bound into the JWS payload. CertNode never sees the raw prompt — only the hash. Later verification can prove "this output was produced from a prompt whose sha256 matched X."

Uses include: privacy-preserving audit of sensitive prompts (the prompt content stays in your infrastructure), RAG source-manifest binding (encode the retrieved-doc hash manifest as prompt hash), and tool-call binding (encode tool name + args hash). See recipes for working patterns.

Content types

Receipts carry a content-type tag for downstream verifiers + filtering. The four built-in types:

  • ai_output — default. AI-generated text or structured output.
  • image — image binary (pass base64). Use C2PA assertions in metadata for image-specific provenance.
  • document — PDF, DOCX, structured documents.
  • json — structured JSON records, useful for tool-call outputs + agent transcripts.

FRE 902(13)/(14) framing

CertNode receipts are designed for admissibility under Federal Rule of Evidence 902(13) (electronic records generated by a process producing accurate results) and 902(14) (electronic records authenticated by digital signature). Receipts include the certification a proponent typically needs to lay foundation without extrinsic testimony.

What this means: a receipt is structured so its admissibility argument is one paragraph instead of days of expert testimony. The cryptography is open standards (ES256, JWS, RFC 3161, Bitcoin OpenTimestamps) — an opposing expert can verify the chain independently.

What this doesn't mean: no court has ruled specifically on CertNode's implementation. "Designed for" is the precise framing — admissibility is ultimately the trier of fact's call. For high-stakes litigation, cite the underlying primitives (RFC 3161 is well-precedented; ES256 + JWS are standard) rather than CertNode's brand.

See the Compliance page for the full framing breakdown.

EU AI Act Article 50 alignment

Article 50 of the EU AI Act (enforced August 2026) requires providers of AI systems generating synthetic content to mark the content as artificially generated in a machine-readable format. CertNode receipts satisfy the cryptographic-marking requirement: each receipt carries the model + provider + timestamp metadata in a verifiable structure, and the public verify URL provides the disclosure surface. Designed for the Article 50 disclosure obligation, not auto-compliance — your specific deployment still needs Article-50-compatible UX (e.g., visible "AI generated" labels on rendered content).

Next