Deterministic Verification · Replay Integrity

Same proof.
Same verdict. Everywhere.

Independently reproducible cryptographic verification.

H33 verifiers are deterministic. Any conformant implementation processing the same proof produces identical challenge derivation, identical transcript state, identical replay outputs, and identical rejection behavior — without contacting H33 infrastructure, without trusting a single vendor, without ambiguity.

Why replayability matters.

Most security evidence cannot be re-verified after the fact. Logs are mutable. Screenshots are unsigned. Vendor dashboards are vendor-controlled. Six months later, none of it answers "what actually happened."

Traditional Security Evidence Requires
  • trusting the vendor
  • trusting screenshots
  • trusting logs
  • trusting timestamps
  • trusting the original verifier was honest
Deterministic Verification Provides
  • cryptographically complete evidence
  • independent third-party reproducibility
  • verifier-independent results
  • long-term archival replay
  • regulator-grade and insurer-grade audit posture

The verifier either reproduces the same trust state — or it fails deterministically.

Every commitment absorbed before every challenge.

The transcript is the source of truth. Every commitment — trace, constraint, FRI layer, AIR identifier — is absorbed into the SHA3-256 sponge before the dependent challenge is derived. No gaps. No mutable state injection between commit and challenge.

The Verifier Freezes
  • transcript byte layout
  • domain separators
  • AIR identifiers
  • challenge ordering
  • FRI configuration semantics
  • serialization profile identifiers
Property: Any divergence in transcript construction by an independent verifier produces a different challenge sequence, which deterministically rejects the proof. Serialization drift cannot silently pass.

Fiat-Shamir, audited and frozen.

Every verifier challenge is derived deterministically from the transcript state. The OtterSec Fiat-Shamir vulnerability pattern that impacted six independent zkVM implementations in March 2026 does not apply — H33's transcript follows strict absorb-then-squeeze discipline.

DEEP-FRI Cross-Check

The FRI verifier independently regenerates query positions from the Fiat-Shamir transcript. Prover-supplied positions are matched against derived positions. Any mismatch causes immediate rejection.

Domain-Separated SHA3-256

Each proof type and protocol step uses a unique prefix. Length-prefixed and labeled hash inputs prevent concatenation collisions and cross-context replay. Native length-extension resistance.

Read the full Fiat-Shamir audit report →

Failure is never ambiguous.

When a proof fails to verify, every conformant verifier returns the same structured rejection code from the HATS_ERR_* namespace. Operators, auditors, and downstream systems get one canonical reason — not one opaque "verification failed."

Deterministic Rejection For
  • swapped FRI layers
  • tampered commitments
  • invalid query positions
  • malformed OOD evaluations
  • truncated proofs
  • mismatched AIR identifiers
  • orphan governance references
  • cyclic lineage
  • cross-domain replay attempts
  • cross-tenant boundary violations
  • authority-state mismatch
Property: Every rejection is structured, namespaced (HATS_ERR_*), and reproduces identically across independent verifier implementations. No verifier can "soft-pass" a tampered proof; no verifier can disagree about why a proof failed.

Verifier-generated, not hand-authored.

The H33 reference verifier emits deterministic conformance vectors covering positive cases, negative cases, and adversarial corpora. Independent implementations prove compatibility by reproducing identical roots, hashes, replay outputs, and rejection codes against the same vectors.

Conformance Vector Contents
  • input bundle
  • expected verification result
  • vector manifest
  • canonical serialization profile identifier
  • governance state root hash
  • lineage Merkle root hash
  • replay frame hash
  • timestamp normalization rule
  • expected verifier behavior code
Vector Categories

Positive vectors — prove valid governance satisfaction and correct acceptance behavior.

Negative vectors — prove deterministic rejection. Without negative vectors, conformance certification is incomplete. Compliance tooling, verifier qualification programs, and adversarial validation all depend on proving correct rejection behavior, not just correct acceptance.

Malformed-proof corpus — 29-test adversarial fuzz corpus over the STARK protocol surface.

Property: Expected outputs are generated by the canonical verifier, not hand-authored. Golden-output drift is eliminated by construction.

No vendor in the verification path.

A third-party implementation in any programming language is conformant when it produces identical root hashes, replay frame hashes, Merkle roots, validity determinations, and structured rejection codes against the same conformance vectors — without ever calling H33 infrastructure.

Independent Verifier Consensus
            Proof
              ↓
       Verifier A ─┐
       Verifier B ─┼── IDENTICAL RESULT
       Verifier C ─┘

Deterministic replay across independent implementations.

No implementation-defined behavior. No verifier ambiguity. No trusted verifier dependency.

Three levels. One canonical grade per proof.

Every proof verification returns a deterministic replay integrity classification. Third parties can distinguish complete, partial, and tampered evidence without contacting H33 and without trusting any single verifier.

FULLY_REPLAYABLE

Cryptographically complete evidence. Every commitment, challenge, and rejection path reproduces under any conformant verifier.

STRUCTURALLY_VALID

Partially reconstructable evidence. Proof structure passes but one or more replay frames are unavailable (e.g., expired external anchor).

INVALID

Invalid or tampered proofs. Deterministic rejection from the HATS_ERR_* namespace identifies the exact failure mode.

29 malformed-proof tests. 238 total protocol tests.

Conformance is proved against an adversarial corpus, not a happy path. Every malformed-proof case produces a deterministic rejection code and replay classification. CI breaks on any drift.

PropertyValue
Canonical transcript vectorsFrozen
Deterministic verifier modeYes
Structured rejection codesHATS_ERR_*
Replay integrity gradingFULLY_REPLAYABLE / STRUCTURALLY_VALID / INVALID
Adversarial malformed-proof corpus29 tests
Total STARK protocol tests238
Conformance vector formatVerifier-generated
Negative vectorsRequired for conformance

Proofs that survive infrastructure.

Determinism is what makes evidence survive vendor transitions, organizational changes, infrastructure replacement, and decade-scale archival. The verifier never depends on H33 being online — or even existing.

Proofs Survive
  • vendor transitions
  • organizational changes
  • infrastructure replacement
  • verifier implementation rewrites
  • long-term archival replay (decades)
  • cryptographic-era changes (subject to underlying primitive security)
Property: An attestation produced today verifies identically on any conformant verifier built in any future language or framework, against the frozen canonical vectors, without contacting H33.

Build against the canonical verifier.

Conformance vectors, transcript freeze vectors, the HATS_ERR_* namespace, and the malformed-proof corpus are part of the H33 reference verifier distribution.