ZK-STARK proofs compressed into H33-74 attestations. Zero knowledge preserved. Post-quantum signed. Independently verifiable.
A ZK-Attestation combines a zero-knowledge proof with a post-quantum attestation in a single cryptographic object. It proves a statement is true without revealing the underlying data, and binds that proof to who made it, when, and under what authority.
Proves a statement about data (age > 18, balance > threshold, credential is valid) without revealing the data itself. Mathematical certainty, zero information leakage.
Binds the proof to an identity, timestamp, authority scope, and governance chain. Three post-quantum signature families. Independently verifiable by anyone.
The combined object: 74 bytes total. 32 bytes go on-chain as a permanent commitment. 42 bytes cached off-chain for full verification. Privacy and accountability in one primitive.
A zero-knowledge proof tells you that a statement is true. It does not tell you who proved it, when, under what authority, or whether the prover was authorized to make that claim. ZK needs attestation.
| Property | ZK Proof Only | ZK-Attestation |
|---|---|---|
| Statement validity | Yes | Yes |
| Data privacy | Yes | Yes |
| Prover identity | No | Yes |
| Timestamp binding | No | Yes |
| Authority scope | No | Yes |
| Governance chain | No | Yes |
| Tamper detection | No | Yes |
| Post-quantum security | Depends | Yes (3 families) |
Four steps from private data to publicly verifiable, post-quantum attested proof.
Define the claim: "user is over 18", "account balance exceeds $10,000", "credential was issued by authority X". The underlying data never leaves the client.
Generate a ZK-STARK proof that the statement is true. No trusted setup. Transparent verification. Quantum-resistant hash-based commitments.
The STARK proof is attested with three post-quantum signature families (ML-DSA, FALCON, SLH-DSA), binding it to identity, timestamp, authority, and governance state. Result: 74 bytes.
32 bytes are written to any blockchain (Solana, Bitcoin, Ethereum). The full 74-byte attestation is cached off-chain. Anyone can verify against the on-chain commitment.
H33's ZK-STARK engine uses cached lookup tables for repeated proof patterns. Cold proofs run in milliseconds. Cached lookups return in nanoseconds.
| Operation | Latency |
|---|---|
| Cold STARK proof generation | 495 ms |
| Cached STARK proof lookup | 0.062 µs |
| STARK verification | 71 µs |
| H33-74 attestation (full pipeline) | 42 µs |
ZK-Attestation is the primitive for any scenario where you need to prove a fact without revealing the data, and need accountability for who proved it.
Prove a user is over 18 without revealing their date of birth, ID number, or any personal information. The attestation proves who verified it and when.
Complete Know Your Customer checks without transmitting personally identifiable information. The ZK proof confirms compliance. The attestation proves the check was performed.
Prove regulatory compliance (capital adequacy, risk thresholds, data residency) without revealing proprietary business data to the regulator.
Prove a transaction satisfies all rules (balance sufficient, sender authorized, limits respected) without revealing amounts, parties, or account details.
ZK-Attestations are not locked to any blockchain. The 32-byte commitment can be anchored on any chain that can store 32 bytes.
Zero-knowledge proofs are powerful but incomplete. They prove that a statement is true — but not who proved it, when, or under what authority. Attested ZK proofs close every gap that standard ZK leaves open.
| Property | Standard ZK Proof | Attested ZK Proof (H33) |
|---|---|---|
| Proves truth | Yes — mathematical certainty | Yes — same STARK foundation |
| Proves who | No — proofs are anonymous | Yes — signer identity bound via PQ signatures |
| Proves when | No — no timestamp binding | Yes — compact timestamp in attestation bundle |
| Proves authority | No — no authority context | Yes — authority scope flags and governance link |
| Proves policy | No — no governance binding | Yes — policy hash chained in governance state root |
| Quantum-resistant | Depends on proof system and hash function | Yes — three independent PQ hardness assumptions |
| Chain-portable | Usually tied to one chain's verifier contract | Yes — 32-byte commitment works on any chain |
| Independently verifiable | Requires chain-specific verifier | Yes — offline verification with public binary, no API key |
Standard ZK proofs answer "is this true?" Attested ZK proofs answer "is this true, who proved it, when did they prove it, were they authorized to prove it, and can I verify all of that independently without trusting the prover?" The attestation layer transforms ZK from a privacy tool into an accountability tool.
The H33 ZK-attestation pipeline transforms a private statement into a chain-portable, post-quantum attested proof through a four-stage architecture.
Stage 1: Algebraic Intermediate Representation (AIR). The statement to be proved (for example, "this user's age exceeds 18") is compiled into an Algebraic Intermediate Representation — a set of polynomial constraints that encode the computation. The AIR defines the trace table structure, transition constraints, and boundary conditions. H33 uses purpose-built AIR definitions for common statement types (age verification, balance thresholds, credential validity) to minimize constraint count and prover time.
Stage 2: STARK Proof Generation. The prover executes the computation, generates the execution trace, extends it via low-degree extension (LDE) over a larger evaluation domain, commits to the extended trace using Merkle trees with SHA3-256 hashing, and then constructs the FRI (Fast Reed-Solomon IOP of Proximity) commitment to prove that the trace polynomial is low-degree. No trusted setup is required — the proof is transparent and relies only on hash function security. Cold proof generation takes 495 milliseconds. For repeated statement patterns, H33 caches proof structures, reducing subsequent lookups to 0.062 microseconds.
Stage 3: Three-Family Post-Quantum Attestation. The STARK proof is hashed (SHA3-256) and signed with three independent post-quantum signature families: ML-DSA-65 produces the primary signature from MLWE lattice hardness, FALCON-512 adds a compact NTRU-based signature, and SLH-DSA-SHA2-128f provides a conservative hash-based fallback. The three signatures, signer set identifier, timestamp, authority scope flags, and governance link are compressed into the 74-byte H33-74 Post-Quantum Attestation Primitive bundle. Forgery requires simultaneously breaking MLWE lattices, NTRU lattices, and SHA-2 preimage resistance — three independent mathematical bets.
Stage 4: Chain Commitment. The first 32 bytes of the attestation bundle (the SHA3-256 commitment hash) are written to the target blockchain. The remaining 42 bytes are cached off-chain for full verification. Verification requires only the 32-byte on-chain value and the 74-byte bundle — no H33 infrastructure, no API key, no network connection. The verifier binary is publicly available and deterministic: same inputs always produce the same verification result.
Common questions about combining zero-knowledge proofs with post-quantum attestation.
ZK-attestation combines a zero-knowledge proof (which proves a statement is true without revealing underlying data) with a post-quantum attestation (which binds that proof to a specific identity, timestamp, authority scope, and governance chain). The result is a single 74-byte cryptographic object — the H33-74 Post-Quantum Attestation Primitive — that proves both what is true and who proved it, when, and under what authority. The proof cannot be replayed, misattributed, or presented outside its authorized context.
A zero-knowledge proof tells you that a statement is true, but it does not tell you who proved it, when it was proved, under what authority the prover operated, or whether the prover was authorized to make that claim. Without attestation, a valid ZK proof can be replayed by a different party, presented outside its intended time window, or used to claim authority the prover never had. Attestation closes the gap between mathematical truth and operational accountability.
After a STARK proof is generated, H33 computes a SHA3-256 hash of the proof and signs it with three independent post-quantum signature families: ML-DSA-65 (MLWE lattice hardness), FALCON-512 (NTRU lattice hardness), and SLH-DSA-SHA2-128f (stateless hash function security). The three signatures, signer metadata, and governance link are compressed into the 74-byte attestation bundle. An attacker would need to break all three independent mathematical hardness assumptions simultaneously to forge an attestation.
Cold STARK proof generation takes 495 milliseconds. Once generated, cached STARK proof lookups return in 0.062 microseconds — effectively instantaneous. STARK verification itself takes 71 microseconds. The full H33-74 Post-Quantum Attestation Primitive attestation pipeline completes in 42 microseconds per authentication. For applications with repeated proof patterns (such as age verification or balance checks), the cached path delivers sub-microsecond performance for the ZK component.
Yes. ZK-attestations are independently verifiable without any connection to H33 infrastructure, the internet, or any third-party service. The public verifier binary is freely downloadable and requires no API key, account, or subscription. Given the 74-byte attestation bundle and the 32-byte on-chain commitment, any party can verify the proof's validity, the signer identities, the timestamp, and the governance chain integrity entirely offline. This makes ZK-attestations suitable for air-gapped environments, field verification, and dispute resolution.
ZK-attestations are chain-agnostic. The 32-byte commitment can be anchored on Solana (native program with sub-second finality), Bitcoin (OP_RETURN for permanent record), Ethereum (calldata, EVM-compatible), any EVM L2 rollup (Arbitrum, Optimism, Base, zkSync), or stored off-chain for local verification without any blockchain at all. The proof itself never changes — only the anchoring destination varies. This means a proof generated for Solana can be verified against Ethereum with zero modification.
Expanded scenarios where ZK-attestation solves problems that neither ZK proofs nor attestation can solve alone.
A European fintech needs to verify that a US customer meets regulatory requirements without transmitting personally identifiable information across jurisdictions. Using ZK-attestation, the customer's home bank generates a STARK proof confirming "customer passes all AML/KYC requirements" without revealing the underlying data (name, address, document numbers). The proof is attested with three PQ signature families, binding it to the specific bank, the specific timestamp, and the specific regulatory framework version. The European fintech verifies the attestation independently — the customer's PII never crosses borders, the proof is quantum-resistant, and both parties have cryptographic evidence of the verification for audit purposes.
A DeFi lending protocol requires institutional borrowers to prove they have sufficient collateral without revealing their specific positions (which would expose trading strategy). The institution generates a STARK proof that their aggregate collateral exceeds the borrowing threshold by a required margin. H33 attests the proof, binding it to the institution's identity, the exact timestamp, and the specific risk parameters used. The attestation is anchored on-chain as a 32-byte commitment. Liquidators, auditors, and counterparties can verify solvency at any historical timestamp without the institution ever revealing which assets compose the collateral.
Zero-knowledge proofs with post-quantum attestation. Prove statements without revealing data. Anchor on any chain. Verify anywhere.
A standard zero-knowledge proof answers one question: "Is this statement true?" An attested ZK proof answers four: "Is it true, who proved it, when, and under what authority?" The H33-74 Post-Quantum Attestation Primitive binds accountability to every proof.
| Property | Standard ZK Proofs | H33 Attested ZK Proofs |
|---|---|---|
| Proves statement truth | Yes — mathematical guarantee of statement validity | Yes — same STARK proof with identical mathematical guarantees |
| Proves prover identity | No — proof is anonymous by design | Yes — signer set cryptographically bound to the attestation |
| Proves timestamp | No — proof carries no time binding | Yes — timestamp is part of the signed attestation bundle |
| Proves authority scope | No — proof does not capture authorization context | Yes — authority scope and governance chain state are committed |
| Replay protection | None — valid proof can be presented by anyone, anytime | Built-in — attestation is bound to specific signer, time, and governance state |
| Quantum resistance | Varies — STARK proofs are post-quantum but many ZK systems use elliptic curves | Three independent PQ families (MLWE, NTRU, hash-based) sign every proof |
| Independent verification | Requires verifier for the specific proof system | Universal verifier — 74-byte bundle verifiable offline with no H33 connection |
| Chain anchoring | Application-specific — must build custom anchoring per chain | 32-byte commitment anchors to any chain (Solana, Bitcoin, Ethereum, L2s) |
| Governance linkage | None — proof exists in isolation | Every attestation links to a governance chain via predecessor hash |
| Dispute resolution | Proof is valid or invalid — no context for disputes | Full context: who, when, under what authority, linked to governance history |
The core insight is that mathematical truth is necessary but not sufficient for real-world accountability. A ZK proof that someone is over 18 is useless if you cannot determine who proved it, whether the prover was authorized, or whether the proof was generated today or replayed from last year. Attested ZK proofs close every accountability gap while preserving the zero-knowledge property: the verifier still learns nothing about the underlying data.
From STARK proof generation to three-family PQ signing, every step of the ZK-attestation pipeline is designed for production-grade latency and independent verifiability.
H33 uses AIR (Algebraic Intermediate Representation) based STARK proofs. The prover encodes the statement as a set of polynomial constraints over a finite field, generates the execution trace, extends it via Reed-Solomon encoding, and produces the proof using FRI (Fast Reed-Solomon Interactive Oracle Proofs of Proximity) commitment. Cold proof generation takes 495 milliseconds. Once a proof is generated, the result is cached in the H33 cache engine. Subsequent lookups for identical proof patterns return in 0.062 microseconds — a 7,983x speedup. This caching is critical for high-frequency applications like repeated age verification, balance threshold checks, or compliance attestations where the same proof structure is evaluated thousands of times per second.
After the STARK proof is generated or retrieved from cache, H33 computes a SHA3-256 hash of the proof and binds it to the signer identity, timestamp, authority scope, and governance chain state. This composite is then signed with three independent post-quantum signature families: ML-DSA-65 (MLWE lattice hardness), FALCON-512 (NTRU lattice hardness), and SLH-DSA-SHA2-128f (stateless hash function security). The three signatures and metadata are compressed into the 74-byte H33-74 Post-Quantum Attestation Primitive. Forging a single attestation requires simultaneously breaking all three independent mathematical hardness assumptions — MLWE lattices, NTRU lattices, and hash functions.
STARK verification takes 71 microseconds. The full H33-74 attestation pipeline (including all three PQ signature verifications) completes in 42 microseconds per authentication. Verification is entirely self-contained: given the 74-byte bundle, the 32-byte on-chain commitment, and the public key set, any party can verify the proof offline. No connection to H33 infrastructure is required. The public verifier binary is freely downloadable and operates without API keys, accounts, or subscriptions.
The 32-byte SHA3-256 commitment hash is the only data stored on-chain. This makes anchoring cost-constant regardless of proof complexity. On Solana, the commitment is stored via a native program with sub-second finality. On Bitcoin, it uses OP_RETURN for permanent record. On Ethereum and EVM L2 rollups, it is stored as calldata. The proof itself, the three PQ signatures, and the complete attestation metadata remain off-chain in the H33 cache layer or any storage system the customer controls. Verification checks the commitment against the off-chain bundle — any modification to the off-chain data produces a hash mismatch.
Attested zero-knowledge proofs unlock new categories of privacy-preserving verification where both mathematical truth and operational accountability are required.
A cloud provider uses ZK-attestation to prove that a computation was performed inside a secure enclave without revealing the computation inputs or outputs. The STARK proof verifies correct execution, while the attestation binds the proof to the specific enclave identity, the timestamp, and the security policy version. Auditors verify the attestation independently without accessing the enclave or the confidential data.
A lender needs to verify that a borrower meets credit thresholds without accessing their full credit history. The borrower's financial institution generates a STARK proof confirming "credit score above 700" without revealing the actual score or any account details. H33 attests the proof, binding it to the institution, the exact timestamp, and the specific scoring model version used. The lender verifies the attestation and makes a lending decision — no raw credit data ever leaves the originating institution.
A cryptocurrency exchange proves its reserves exceed customer deposits without revealing individual account balances or wallet addresses. The STARK proof aggregates all balances and verifies the inequality. The attestation binds the proof to the exchange's identity, the exact block height used for the snapshot, and the specific methodology. Regulators, customers, and auditors all verify the same 74-byte attestation independently — no trust in the exchange required.
An electronic voting system proves that a voter is eligible (registered, correct district, has not already voted) without linking the eligibility proof to the voter's identity or their ballot. The STARK proof verifies all eligibility criteria in zero knowledge. The attestation binds the proof to the election authority, the election timestamp window, and the specific voter roll version — creating an auditable record that the eligibility check occurred without revealing who was checked.
Detailed answers to the most common questions about combining zero-knowledge proofs with post-quantum attestation.
ZK-attestation combines a zero-knowledge proof (which proves a statement is true without revealing the underlying data) with a post-quantum attestation (which binds that proof to a specific identity, timestamp, authority scope, and governance chain). The result is a single 74-byte H33-74 Post-Quantum Attestation Primitive that proves both what is true and who proved it, when, and under what authority. The zero-knowledge property is preserved: the verifier still learns nothing about the private data, but now has cryptographic accountability for the proof itself.
A zero-knowledge proof tells you that a statement is true, but it does not tell you who proved it, when it was proved, under what authority the prover operated, or whether the prover was authorized to make that claim. Without attestation, a valid ZK proof can be replayed by a different party, presented outside its intended time window, or used to claim authority the prover never had. In regulated environments, this accountability gap makes naked ZK proofs unusable for compliance, audit, and dispute resolution purposes. Attestation closes the gap between mathematical truth and operational accountability.
After a STARK proof is generated, H33 computes a SHA3-256 hash of the proof and signs it with three independent post-quantum signature families: ML-DSA-65 (MLWE lattice hardness), FALCON-512 (NTRU lattice hardness), and SLH-DSA-SHA2-128f (stateless hash function security). The three signatures, signer metadata, and governance link are compressed into the 74-byte attestation bundle. An attacker would need to simultaneously break all three independent mathematical hardness assumptions to forge a single attestation.
Cold STARK proof generation takes 495 milliseconds. Once generated, cached STARK proof lookups return in 0.062 microseconds. STARK verification itself takes 71 microseconds. The full H33-74 Post-Quantum Attestation Primitive attestation pipeline completes in 42 microseconds per authentication. For applications with repeated proof patterns (age verification, balance checks, compliance attestations), the cached path delivers sub-microsecond performance for the ZK component while maintaining full attestation accountability.
Yes. ZK-attestations are independently verifiable without any connection to H33 infrastructure, the internet, or any third-party service. The public verifier binary is freely downloadable and requires no API key, account, or subscription. Given the 74-byte attestation bundle and the 32-byte on-chain commitment, any party can verify the proof's validity, the signer identities, the timestamp, and the governance chain integrity entirely offline. This makes ZK-attestations suitable for air-gapped environments, field verification, and legal dispute resolution where network connectivity cannot be guaranteed.
ZK-attestations are chain-agnostic. The 32-byte commitment can be anchored on Solana (native program with sub-second finality), Bitcoin (OP_RETURN for permanent record), Ethereum (calldata, EVM-compatible), any EVM L2 rollup (Arbitrum, Optimism, Base, zkSync, Scroll), or stored off-chain for local verification without any blockchain at all. The proof format is identical regardless of the anchoring destination. A proof generated for Solana can be verified against Ethereum with zero modification. This means organizations can choose their anchoring chain based on cost, speed, and permanence requirements without any impact on proof validity.