Core Concepts

This guide explains the fundamental building blocks of the QuantZK Verifiable Decision Infrastructure protocol.

Decision Attestation

A Decision Attestation is a signed, portable, self-contained proof that a software decision followed a defined set of rules. It is the core artifact of the VDI protocol.

Structure

Decision Attestation
├── vdi_version: "1.0.0"
├── type: "decision_attestation_v1"
├── attestation_id: "vdi:att:0x..."
├── pipeline
│   ├── id, hash, name, version
│   └── (pipeline definition hash, proves structure)
├── policy
│   ├── manifest_hash (proves which constraints applied)
│   ├── constraint_count
│   └── authority (who reviewed the constraints)
├── outcome
│   ├── id (which pipeline step produced the outcome)
│   └── timestamp
├── proof
│   ├── system: "groth16"
│   ├── curve: "bn128"
│   ├── pi_a, pi_b, pi_c (the ZK proof)
│   └── public_signals
├── verification
│   ├── key (embedded verification key)
│   └── key_hash
├── circuit (governance metadata)
│   ├── circuit_id, circuit_version, circuit_hash
│   ├── compiler, compiler_version
│   └── constraints, audit_reference
├── signature
│   ├── algorithm: "Ed25519"
│   ├── kid (key ID for rotation)
│   ├── public_key
│   └── value (signature over canonical payload)
├── issued_at
└── expires_at

Key Properties

• Self-contained, Everything needed to verify is inside the attestation (including the verification key)
• Portable, Can be stored, transmitted, and verified anywhere
• Offline-verifiable, No server, API, or network required
• Tamper-evident, Ed25519 signature covers the canonical JSON representation
• Time-bounded, Has issued_at and expires_at timestamps
• Privacy-preserving, Private inputs never appear in the attestation; only the ZK proof and public signals

Decision Pipeline

A pipeline defines the structure of a decision process. It is a directed acyclic graph (DAG) of steps with policy constraints attached.

const pipeline = vdi.pipeline({
  name: 'Loan Approval',
  version: '2.0.0',
  steps: ['application', 'identity', 'credit', 'fairness', 'pricing', 'decision'],
  constraints: [
    { id: 'no_protected_class', vertex: 'fairness', critical: true },
    { id: 'rate_within_bounds', vertex: 'pricing', critical: false }
  ],
  authority: {
    type: 'legal_review',
    name: 'Covington & Burling LLP',
    reference: 'Opinion #2026-AI-FL-014'
  }
});

The pipeline hash is a SHA-256 of the canonical JSON representation of { name, version, steps, constraints }. This hash is included in every attestation, proving the exact pipeline definition that was executed.

Policy Constraints

Constraints are rules that must be satisfied at specific steps in the pipeline. They come from policy manifests, versioned, hashed libraries of constraints.

Built-in Manifests

Manifest	Regulation	Constraints
fair-lending-v1	Fair Lending Act, ECOA	no_protected_class, adverse_action_justified, rate_within_bounds, equal_information_requirement
eu-ai-act-art14-v1	EU AI Act Article 14	human_oversight_mechanism, system_understanding, anomaly_detection, intervention_capability, automation_bias_awareness
hipaa-phi-v1	HIPAA Privacy Rule	minimum_necessary, authorized_purpose, audit_trail, de_identification
nist-ai-rmf-v1	NIST AI 100-1	govern_policies, map_context, measure_performance, manage_risk

Authority Types

Constraints have an associated authority, the entity that reviewed and approved them:

Type	Description	Trust Level
legal_review	Reviewed by a named law firm	Highest
standards_body	Published by a standards organization	High
audit_firm	Reviewed by a named audit firm	High
self_attested	No external review	Baseline

Zero-Knowledge Proofs

The ZK proof is the core cryptographic mechanism. QuantZK uses Groth16 proofs on the bn128 elliptic curve.

What the proof proves

Given a decision pipeline with constraints, the proof demonstrates:

• The execution followed a valid path through the pipeline DAG
• All policy constraints evaluated to true
• The causal chain from inputs to outcome is valid

What the proof hides

• The actual input values (credit score, income, etc.)
• The model weights or algorithm logic
• How specific constraints were evaluated
• Any intermediate state

How it works

1. The prover constructs a causal DAG from the pipeline definition
2. Constraint predicates are attached to vertices in the DAG
3. The CausalProver from zk-cp generates a Groth16 proof using snarkjs
4. The proof, public signals, and verification key are embedded in the attestation

Verification

Verification is a 7-step process that runs entirely offline:

Step	Name	What it checks
1	Schema	All required fields present, correct types and formats
2	Timestamps	issued_at is not in the future; expires_at is not in the past
3	Pipeline Integrity	Pipeline hash is valid SHA-256 hex
4	Policy Integrity	Manifest hash is valid; authority type is recognized
5	ZK Proof	Groth16 proof mathematically verifies against verification key
6	Signature	Ed25519 signature over canonical payload is valid
7	Key Integrity	Verification key hash matches embedded key

Step 5 (ZK Proof) is the most computationally expensive but typically completes in 20-30ms. The entire verification takes ~27ms.

Verification Receipts

A receipt is a signed attestation that verification occurred. It enables trust propagation without re-running the full verification.

Verification Receipt
├── receipt_id: "vdi:receipt:0x..."
├── attestation_id (which attestation was verified)
├── attestation_hash (SHA-256 of the attestation, binding)
├── verifier
│   ├── implementation, version
│   └── verifier_id
├── verification_profile (which checks were run)
├── profile_hash
├── result
│   ├── valid: true/false
│   └── checks: { schema: true, timestamps: true, ... }
├── verified_at
├── expires_at (24-hour default TTL)
├── parent_receipt_hash (for chaining)
├── chain_depth
└── signature (Ed25519)

Receipt Verification

Checking a receipt is fast (~2ms) because it doesn't re-run the ZK proof:

1. Check receipt expiry
2. Verify attestation hash binding
3. Check verifier is in trusted set
4. Verify receipt signature

Verification Profiles

Profiles define what "verified" means. They are standardized check configurations:

Profile	Checks	Authority Requirement
VDI_VERIFY_STRICT_V1	All 7 steps	legal_review, standards_body, or audit_firm
VDI_VERIFY_STANDARD_V1	All 7 steps	Any (including self_attested)
VDI_VERIFY_MINIMAL_V1	Schema + timestamps + ZK proof	Any

When a verifier emits a receipt, the profile is recorded so downstream consumers know exactly which checks were performed.

Trusted Verifier Sets (TVS)

A TVS is a k-of-n quorum policy for accepting receipts. It defines which verifiers are trusted and at what level.

const tvs = {
  tvs_id: 'vdi:tvs:acme-production',
  name: 'ACME Corp Production Verifier Set',
  verifiers: [
    { verifier_id: 'vdi:verifier:compliance-bot', trust_level: 'primary' },
    { verifier_id: 'vdi:verifier:risk-monitor', trust_level: 'secondary' }
  ]
};

Acceptance Policies

Level	Requirement
low	1 receipt from any trusted verifier
medium	1 primary receipt OR 2 secondary receipts
high	2+ receipts from independent verifiers
critical	2+ independent verifiers + probabilistic spot-check

Transparency Log

The transparency log is an append-only Merkle tree of receipts, modeled after Certificate Transparency (RFC 6962). It detects receipt equivocation, when a verifier issues contradictory receipts for the same attestation.

Operations

• Append, Add a receipt to the log; returns a Signed Log Entry (SLE)
• Inclusion Proof, Prove a receipt exists in the log
• Equivocation Check, Detect contradictory receipts for the same attestation
• Consistency Proof, Prove the log hasn't been tampered with

Verifier Registry

The verifier registry manages verifier identities and key lifecycle:

• Registration, Add a new verifier with a public key
• Key Rotation, Rotate keys with configurable grace periods
• Revocation, Revoke a verifier (e.g., after equivocation detection)
• Key Validation, Check if a key is valid at a given time

Circuit Governance

Every attestation includes circuit metadata for auditability:

• circuit_id, Identifier for the circuit
• circuit_hash, SHA-256 of the compiled WASM
• r1cs_hash, SHA-256 of the R1CS constraint system
• compiler / compiler_version, Reproducible builds
• constraints, Number of constraints in the circuit
• audit_reference, Link to external audit (if any)

This metadata allows auditors to verify that the same circuit was used consistently and that it hasn't been modified.