Why ZK Proofs Are Not Enough
You Need Attested ZK

Zero-knowledge proofs are one of the most important cryptographic primitives of the past two decades. They allow a prover to convince a verifier that a statement is true without revealing any information beyond the truth of the statement itself. The mathematics is elegant. The applications are real. The technology works.

But ZK proofs alone are not enough for production systems that need accountability, compliance, or governance. A ZK proof answers exactly one question: is this statement true? It does not answer: who made this proof? When was it made? Under what authority was the computation performed? Can this proof be replayed by an independent verifier to reconstruct the governance context? Is the proof post-quantum secure?

These are not edge cases. They are the questions that regulators ask, that insurers require answers to, that forensic investigators need resolved, and that compliance teams must address before deploying ZK in production. This article explains the accountability gap in standard ZK proofs and describes how attested ZK closes it.

What ZK Proofs Actually Prove

A zero-knowledge proof proves that a prover knows a witness W such that a relation R(X, W) holds, where X is a public statement. The proof reveals nothing about W beyond the fact that such a witness exists.

Concrete example: a ZK proof can prove that a bank account balance exceeds $10,000 without revealing the actual balance. The statement X is "balance ≥ $10,000." The witness W is the actual balance. The proof convinces the verifier that the statement is true without disclosing that the balance is, say, $47,293.

This is genuinely useful. ZK proofs enable privacy-preserving compliance checks, selective disclosure of credentials, anonymous credential verification, and confidential transactions. The privacy guarantee is mathematically sound. A verifier learns nothing about the witness beyond what the statement already implies.

But here is what a standard ZK proof does not tell you:

• Who generated the proof. A ZK proof is a mathematical object. It has no inherent attribution. If you receive a valid proof, you know the statement is true, but you do not know who proved it. The proof could have been generated by the account holder, by a third party with access to the data, by an AI agent acting on behalf of the account holder, or by an attacker who obtained the witness through compromise.
• When the proof was generated. A ZK proof has no inherent timestamp. A proof generated today is indistinguishable from a proof generated a year ago (assuming the same statement and witness). There is no way to determine whether the proof reflects the current state of the world or a historical state.
• Under what authority. A ZK proof carries no governance context. Was the prover authorized to access the data that constitutes the witness? Was the computation performed within a permitted operational scope? Did the prover's authority expire between proof generation and verification? The proof itself is silent on all of these questions.
• Whether the proof is part of a larger governance chain. Standard ZK proofs are standalone objects. They do not reference previous proofs, authority delegations, or operational context. Each proof exists in isolation, without connection to the broader system of decisions and actions that led to its generation.

The Accountability Gap

The accountability gap is the space between "this statement is true" and "this statement was proven by an authorized party, at a specific time, under a specific governance scope, and the proof can be independently replayed in context." Standard ZK closes the first half. The second half is wide open.

This gap creates real problems in regulated environments:

Compliance. A financial regulator does not just want to know that a computation is correct. They want to know who performed it, when, under what authorization, and whether the computation falls within the regulated entity's approved operational scope. A ZK proof that says "this risk calculation is correct" without attribution, timestamp, or governance context is insufficient for regulatory compliance.

Auditability. An auditor needs to reconstruct the chain of decisions that led to a particular outcome. ZK proofs in isolation provide no chain. Each proof is an independent mathematical object with no connection to the proofs that came before or after it. Auditing a system that uses standard ZK requires maintaining a separate, non-cryptographic record of proof generation context — which defeats the purpose of using cryptographic proofs in the first place.

Forensics. When something goes wrong — a fraudulent transaction, a compliance violation, a security breach — investigators need to determine what happened, who was responsible, and when it occurred. ZK proofs without accountability metadata provide no forensic utility. The proof says the computation was correct. It says nothing about the circumstances of the computation.

Insurance. Cyber insurers increasingly require cryptographic evidence of security controls. A ZK proof that an authentication check was performed is useful. A ZK proof with no attribution, no timestamp, and no governance binding is not — because the insurer cannot determine whether the proof reflects the policyholder's actual operational state at the time of a claimed breach.

Why Tornado Cash Failed

Tornado Cash is the most instructive example of what happens when you deploy ZK proofs without accountability. Tornado Cash used ZK-SNARKs to enable private transactions on Ethereum. The cryptography was sound. The privacy guarantee was real. Depositors could withdraw funds without revealing the link between deposit and withdrawal addresses.

The system was sanctioned by the U.S. Treasury's Office of Foreign Assets Control (OFAC) in August 2022. The core technical reason — separate from the legal and policy dimensions — was that the protocol provided privacy without compliance. It was impossible to determine who was using the system, under what authority, or for what purpose. The ZK proofs guaranteed that the transactions were valid. They could not guarantee that the transactions were authorized, that the users were not sanctioned entities, or that the funds were not proceeds of crime.

This was not a failure of ZK technology. The proofs worked exactly as designed. It was a failure of accountability architecture. The system proved statements about transactions without binding those proofs to any governance context. Privacy without accountability is not a product for regulated markets. It is a vulnerability.

The lesson is not that ZK proofs are bad. The lesson is that ZK proofs without accountability are incomplete. For privacy-preserving systems to operate in regulated environments, the privacy guarantees of ZK need to be composed with the accountability guarantees of attestation.

Attested ZK: Closing the Gap

Attested ZK is the composition of a zero-knowledge proof with a post-quantum attestation that binds the proof to its generation context. The attestation answers every question that the ZK proof leaves open: who generated it, when, under what authority, and how it connects to the broader governance chain.

An attested ZK proof contains three layers:

Layer 1: The ZK proof itself. A STARK proof that a specific computation was performed correctly. The proof provides computational integrity — the statement is true. STARKs are used rather than SNARKs because STARKs require no trusted setup and are post-quantum secure (their security relies on hash functions, not elliptic curves).

Layer 2: The PQ attestation. A post-quantum signature bundle that binds the proof to an identity, a timestamp, and a governance scope. The signature uses three independent mathematical families — three hardness assumptions (MLWE lattices, NTRU lattices, and stateless hash functions) that would all need to be simultaneously broken to forge an attestation. The attestation is not a wrapper around the proof — it is cryptographically bound to the proof's content hash.

Layer 3: The governance binding. A reference to the authority chain that authorized the computation. This connects the proof to the operational context: which policy permitted this computation, which human authority delegated to the system that generated the proof, and where this proof sits in the broader governance graph.

The composition produces a single verifiable object: a proof that this computation was correct, was performed by this identity, at this time, under this authority, and connects to this governance chain.

The Pipeline: Statement to 32-Byte Commitment

The attested ZK pipeline transforms a computational statement into a 32-byte on-chain commitment through five stages:

Stage 1: Statement definition. The computation to be proven is defined as an Algebraic Intermediate Representation (AIR). The AIR specifies the constraints that the computation must satisfy — the rules of the game. This stage is deterministic and auditable: the same computation always produces the same AIR.

Stage 2: STARK proof generation. The prover executes the computation and generates a STARK proof. The proof demonstrates that the execution trace satisfies all AIR constraints without revealing the witness. Proof generation is the most computationally intensive step, but it happens once — verification is fast.

Stage 3: Attestation. The proof hash, the prover identity, the timestamp, and the governance scope reference are signed with the three-family post-quantum signature bundle. This produces the attestation layer that binds the proof to its context.

Stage 4: Distillation via H33-74. The attested proof is compressed into a 74-byte commitment (32 bytes on-chain, 42 bytes in the cache layer). Three post-quantum signature families, the proof hash, the governance binding, and the temporal commitment — all distilled into 74 bytes. This is not lossy compression. The 74 bytes are a cryptographic commitment that can be expanded and verified against the full attested proof.

Stage 5: Chain commitment. The 32-byte on-chain portion is committed to the target blockchain. This works on any chain that supports 32-byte data commitments — Bitcoin (OP_RETURN), Solana (memo), Ethereum (calldata). The commitment is chain-agnostic by design.

# Generate an attested ZK proof
curl -X POST https://api.h33.ai/v1/zk/attest \
  -H "Authorization: Bearer $H33_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "statement_type": "balance_threshold",
    "public_inputs": {"threshold": 10000, "currency": "USD"},
    "witness_hash": "a3f2...b891",
    "governance_scope": "scope:compliance:aml:tier2",
    "chain_target": "bitcoin"
  }'

# Response:
# {
#   "proof_id": "prf_7x9k...",
#   "h33_74_commitment": "f1a03d7c...32_bytes",
#   "attestation": {
#     "signer": "org:acme-bank:compliance-engine",
#     "timestamp": "2026-05-21T14:30:00Z",
#     "scope_ref": "scope:compliance:aml:tier2",
#     "pq_families": ["ML-DSA", "FALCON", "SLH-DSA"]
#   },
#   "verify_url": "https://api.h33.ai/v1/zk/verify/prf_7x9k..."
# }

Standard ZK vs. Attested ZK

The comparison is not "standard ZK is bad and attested ZK is good." Standard ZK is correct but incomplete. Attested ZK composes the correctness guarantee of ZK with the accountability guarantee of post-quantum attestation. For applications that need only correctness (academic research, personal privacy tools, experimental protocols), standard ZK is sufficient. For applications that need correctness and accountability (regulated finance, insurance, healthcare, government), attested ZK is the minimum viable architecture.

Chain-Agnostic by Design

Attested ZK is not tied to any blockchain. The 32-byte on-chain commitment is designed to fit into the data commitment mechanism of any major chain:

• Bitcoin: OP_RETURN output (up to 80 bytes, 32-byte commitment fits trivially)
• Solana: Memo program instruction (arbitrary data, 32-byte commitment as base58)
• Ethereum: Transaction calldata (32 bytes = one EVM word)
• Any chain with data commitment: 32 bytes is the universal minimum. If a chain can commit 32 bytes, it can host an attested ZK commitment.

This chain-agnostic design means organizations are not locked into a single blockchain ecosystem. An attested ZK proof committed to Bitcoin today can be verified against the same governance chain tomorrow, regardless of which chain the verifier prefers. The commitment is the same 32 bytes. The verification is the same 42-microsecond process. The governance context is the same regardless of the underlying chain.

This also means that multi-chain organizations can maintain a unified governance layer across their blockchain deployments. A DeFi protocol operating on Solana and Ethereum can use the same attested ZK pipeline for both chains, with a single governance graph that spans both ecosystems.

What This Means for Privacy Layers

The privacy layer of the future is not pure ZK. It is attested ZK — privacy with accountability. This is not a contradiction. Privacy and accountability are not opposites. Privacy means the witness is hidden. Accountability means the proof generation context is visible. You can have both simultaneously.

A bank can prove that a customer's identity has been verified (ZK) while also proving that the verification was performed by an authorized system, at a specific time, under a specific compliance scope (attestation). The customer's identity details remain private. The fact that the verification occurred, who performed it, and under what authority is accountable.

An AI agent can prove that it computed a risk score correctly (ZK) while also proving that it was authorized to access the input data, that the computation fell within its governance scope, and that the result was committed to the governance chain before any action was taken on it (attestation). The input data and internal model weights remain private. The operational context is accountable.

This is the architecture that enables ZK in regulated environments. Not ZK alone. Not attestation alone. The composition of both.

Frequently Asked Questions