AIR
Proof Lab
StartEcosystem
Explore (579)Live Systems (52)Pricing
Log InGet API Key✓ Verify It Yourself
The portable audit bundle standard

.h33bundle v1

Standard: .h33bundle  ·  Version: v1  ·  Status: Locked

One drag-droppable artifact bundles the receipts, envelopes, proofs, and parameter captures produced by a Federal L5 session window, with file-level SHA3-512 integrity hashes and registry-bound product_id / bundle_id attribution.

A recipient feeds the bundle to one verifier instead of routing the component artifacts through five different binaries.

.h33bundle is the portable container that carries the evidence H33-74 produces — receipts, envelopes, proofs, and parameter captures — as one drag-droppable artifact whose integrity stands on hash cryptography alone and verifies fully offline. Unlike the H33-74 receipt (the primitive it wraps unchanged) or the Conformance Suite (the vectors it is tested against), .h33bundle is the on-wire package format, not the proof primitive and not the test corpus.

Trust model

Bundle integrity stands on hash cryptography alone.

The verifier rejects any drift in:

No encryption, no signing, no remote calls in v1. Signing under ML-DSA-87 lands when the production key ceremony closes. Encryption is out of v1 scope.
At a glance
Container
Uncompressed POSIX tar
USTAR / PAX-compatible. No gzip, no zstd, no encryption. Inspect with tar -tvf bundle.h33bundle — no H33 binary required.
File hash
SHA3-512 per file
128 hex chars, lowercase. One hash per file in manifest.files[].
Receipt hash
SHA3-256 canonical
Receipt filename must equal its canonical receipt_id. Drift is fatal.
Encryption
None in v1
Receipts already carry commitments, not plaintexts.
Signing
None in v1
ML-DSA-87 authenticity lands after the production key ceremony closes.
Network
Offline verifier
No remote calls. Hard gate; tested.
Section 1 — On-wire format

File-tree layout

A .h33bundle is an uncompressed POSIX tar archive. The recipient can inspect contents without any H33 binary present.

h33bundle/ ├── manifest.json # Required. One file. UTF-8 JSON. Schema in §2. ├── INSTRUCTIONS.md # Required. Human-readable verifier guide. ├── receipts/ │ └── <receipt_id>.json # One file per receipt. UTF-8 JSON. ├── envelopes/ │ └── <receipt_id>.json # H33-PQ-1 envelope, one per receipt. ├── proofs/ # Optional. Present when ZK proofs ride along. │ └── <receipt_id>.bin # bincode-encoded ZkProofBundle. └── artifacts/ # Optional. Present when FHE commitments ride along. └── <receipt_id>.json # Ciphertext commitments — NOT plaintexts.

manifest.json is at the root of the bundle tree. The verifier asserts:

Path constraints

Section 2 — manifest.json schema

UTF-8, compact JSON. Field order = struct order.

{ "format": "h33bundle", "version": "v1", "created_at": 1781040351, "customer_id": "e2etest", "session_window": { "start": 1781040000, "end": 1781041000 }, "files": [ { "path": "receipts/a54225cd...adea8.json", "kind": "receipt", "sha3_512": "<128 hex chars>" } ], "receipts": [ { "receipt_id": "a54225cd...", "product_id": "ckks-256", "bundle_id": "federal-integrity-suite", "engine_id": "ckks-256", "operation": "keygen", "status": "success" } ] }

Self-referential hash handling

The manifest cannot directly contain its own SHA3-512. v1 handles this by:

  1. The builder writes files[] with one entry whose kind: "manifest" and sha3_512: "" (empty string).
  2. The bytes serialized at that point ARE the canonical manifest.
  3. The builder rewrites the empty sha3_512 field with the actual hex of SHA3-512(canonical_bytes).
  4. The verifier re-derives the canonical by setting the manifest's own sha3_512 field to "", re-serializing in struct order, and computing SHA3-512.
Sections 3 & 4 — receipt and envelope format

Receipts and envelopes ride unchanged.

Receipts (§3) are byte-equivalent to what GET /v1/fhe/l5/receipts/<id> returns. The bundle adds no envelope around the receipt; the file IS the receipt. The canonical SHA3-256 (= receipt_id) MUST match the file's base name. A mismatch is an explicit receipt-id-mismatch failure.

Envelopes (§4) carry the H33PqEnvelope JSON that the receipt's envelope_hash field commits to. The verifier recomputes envelope_hash(env) and compares to the receipt's envelope_hash. Any mismatch is an envelope-mismatch failure.

Section 7 — CLI surface

Create and verify.

h33 bundle create

$ h33 bundle create \ --customer-id <id> \ --receipts <dir> # Directory containing receipt JSON files --envelopes <dir> # Directory containing envelope JSON files --proofs <dir> # Optional --artifacts <dir> # Optional --output <path> # Path to write the .h33bundle

Output: a .h33bundle file at --output. Exit 0 on success, non-zero on any input validation failure.

h33 bundle verify

$ h33 bundle verify <bundle.h33bundle> ✓ h33bundle v1 verified customer_id: e2etest receipts: 3 (3 success, 0 failure) files: 9 (all SHA3-512 match) session: [1781040000 ..= 1781041000]

Stderr on failure: a single explicit reason and a non-zero exit code.

Section 8 — hard verification gates

Sixteen gates. No warnings. Each is fatal.

The verifier returns non-zero on any of the following. There is no warning state; a v1 bundle either passes every gate or it does not verify.

GateReason code
Tarball cannot be openedtar-open-failed
manifest.json missingmanifest-missing
manifest.json malformedmanifest-malformed
manifest.format != "h33bundle"format-mismatch
manifest.version != "v1"version-unsupported
File listed in manifest not present in tarfile-missing
File present in tar not listed in manifestextra-file
File's actual SHA3-512 ≠ manifest hashfile-hash-mismatch
Receipt file name ≠ receipt's canonical SHA3-256receipt-id-mismatch
Receipt canonical recomputed ≠ stated receipt_idreceipt-canonical-fail
Envelope hash recomputed ≠ receipt's envelope_hashenvelope-mismatch
Manifest receipts[] summary ≠ receipt file fieldsreceipt-summary-drift
Receipt's product_id not in canonical registryunknown-product
Receipt's bundle_id not in canonical bundlesunknown-bundle
INSTRUCTIONS.md missinginstructions-missing
Manifest self-hash recipe (§2.2) doesn't recovermanifest-self-hash-fail
Section 9 — non-goals for v1 (explicit)

What v1 is deliberately not doing.

Each non-goal is a v2 conversation, not a v1 omission to argue with.

No signing
Authenticity lands with ML-DSA-87 activation, after the production key ceremony closes.
No encryption
Receipts already carry commitments, not plaintexts.
No compression
Bit-identity across builder implementations matters more than archive size.
No remote calls
Verifier MUST run offline. Hard gate; tested.
No proof re-verification
v1 verifier checks hash integrity, not STARK soundness. Replay is ZK-256 verifier's job.
No live attestation
.h33bundle is a snapshot of a session window, not a continuous stream. Continuous attestation lives on H33-PQ Verified.
Why it exists

Why .h33bundle exists — and when not to use it.

A single session produces receipts, envelopes, proofs, and parameter captures across several artifact types. Without a container, a recipient has to route each through a different binary. .h33bundle exists so the whole session ships as one artifact that a recipient verifies with one offline verifier, with no vendor infrastructure in the loop — which is what makes the evidence H33-74 produces genuinely portable.

Use it when you need to hand a complete, self-contained session's evidence to an auditor, insurer, or counterparty who will verify it independently and offline.

Do not reach for it when you need a continuous, live evidence stream rather than a snapshot of a session window — that is continuous post-quantum attestation's job — or when you expect v1 to re-verify STARK soundness or carry signatures. Per the v1 non-goals above, the v1 verifier checks hash integrity only; signing under ML-DSA-87 lands after the production key ceremony closes, and encryption is out of v1 scope.

FAQ

Frequently asked questions

What is .h33bundle?

A portable audit bundle standard: one uncompressed POSIX tar artifact that packages the receipts, envelopes, proofs, and parameter captures from a session window, with per-file SHA3-512 hashes and canonical SHA3-256 receipt IDs, so a recipient can verify it offline with no H33 binary required.

How does verification work?

The verifier rejects any drift in a file's SHA3-512, a receipt's canonical SHA3-256 (its receipt_id), the registry mapping (product_id/bundle_id), or the manifest's file enumeration. Integrity stands on hash cryptography alone, and the verifier runs fully offline.

When should I use .h33bundle?

When handing a complete, self-contained session's evidence to an auditor, insurer, or counterparty who will verify it independently and offline. It is a snapshot of a session window, not a continuous stream.

What does v1 deliberately NOT do?

v1 does not sign (ML-DSA-87 authenticity lands after the production key ceremony closes), does not encrypt (receipts carry commitments, not plaintexts), does not compress, makes no remote calls, does not re-verify STARK proof soundness, and does not provide live attestation. Each is an explicit v1 non-goal, not an omission.

How is .h33bundle different from H33-74?

H33-74 is the 74-byte post-quantum attestation primitive that produces the receipts. .h33bundle is the portable container that wraps those receipts unchanged, sharing the same canonical SHA3-256 join key. One is the proof; the other is how the proof travels.

Related

Where .h33bundle sits in the stack.

Version 1  ·  Locked 2026-06-10  ·  Author: Eric Beans, CEO, H33.ai, Inc.