H33-74 Receipt Schema — v1.0.0

1. Overview

The H33-74 receipt is a 74-byte fixed-width attestation primitive. This schema defines the JSON representation used for API transport, storage, and interoperability. The JSON form is a lossless mapping from the binary layout defined in the H33-74 Specification.

Every field in the JSON representation corresponds to a specific byte range in the 74-byte binary form. Producers MUST be able to round-trip between binary and JSON without data loss. Consumers MAY accept either form.

2. Definitions

Anchor Commitment

Bytes 0-31. A 32-byte SHA3-256 digest of the full attestation receipt. Published on-chain as the binding anchor.

Cached Receipt

Bytes 32-73. A 42-byte suffix containing version, computation type, signature flags, chain target, timestamp delta, receipt locator, tenant ID, and checksum.

H33 Epoch

2026-01-01T00:00:00Z. The reference point for timestamp_delta. All timestamp deltas are seconds elapsed since this epoch.

Receipt Locator

A 16-byte opaque identifier used to retrieve the full receipt from the Cachee layer.

Domain Separator

The UTF-8 string H33-74:v1:commitment: (24 bytes). Prepended to hash inputs.

3. Binary Layout

The 74-byte binary form is the canonical representation. The JSON form is derived from it.

Offset	Length	Field	Type	JSON Key
0	32	Commitment	bytes	anchor_commitment
32	1	Version	uint8	version
33	1	Computation Type	uint8	computation_type
34	1	Signature Flags	uint8	signature_flags
35	1	Chain Target	uint8	chain_target
36	4	Timestamp Delta	uint32 LE	timestamp_delta
40	16	Receipt Locator	bytes	receipt_locator
56	16	Tenant ID	UUID bytes	tenant_id
72	2	Checksum	uint16 LE	checksum

4. JSON Representation

The JSON form maps each binary field to a named key. Byte arrays are hex-encoded. Integer fields are represented as JSON numbers. The payload_hash field is a computed convenience field not present in the binary form.

JSON Key	Source	JSON Type	Encoding
anchor_commitment	Bytes 0-31	string	Lowercase hex, 64 characters
cached_receipt	Bytes 32-73	string	Lowercase hex, 84 characters
version	Byte 32	integer	Unsigned integer
computation_type	Byte 33	integer	Unsigned integer (see enum)
signature_flags	Byte 34	integer	Unsigned integer (bitfield)
chain_target	Byte 35	integer	Unsigned integer (see enum)
timestamp_delta	Bytes 36-39	integer	Unsigned 32-bit LE integer
receipt_locator	Bytes 40-55	string	Lowercase hex, 32 characters
tenant_id	Bytes 56-71	string	UUID string (8-4-4-4-12)
checksum	Bytes 72-73	integer	Unsigned 16-bit LE integer
payload_hash	Computed	string	SHA3-256 of full 74 bytes, hex

5. JSON Schema Definition

6. Field Definitions

Field	Type	Required	Description	Constraints
anchor_commitment	string	Yes	SHA3-256 digest of the canonical receipt serialization, hex-encoded.	64 lowercase hex chars
cached_receipt	string	Yes	Hex encoding of the 42-byte cached receipt (bytes 32-73).	84 lowercase hex chars
version	integer	Yes	Primitive version number.	Constant: 1
computation_type	integer	Yes	Enumerated computation class. Values 1-11 are defined.	1-11 inclusive
signature_flags	integer	Yes	Bitfield for PQ signature families. Conformant receipts have value 7 (all three).	0-7
chain_target	integer	Yes	Target chain for anchoring.	0, 1, 2, 3, or 4
timestamp_delta	integer	Yes	Seconds since H33 epoch (2026-01-01T00:00:00Z).	0 to 4,294,967,295
receipt_locator	string	Yes	Cachee locator for full receipt retrieval.	32 lowercase hex chars
tenant_id	string	Yes	UUID v4 of the owning tenant.	UUID format
checksum	integer	Yes	CRC-16/CCITT over bytes 0-71. Transport integrity only.	0-65535
payload_hash	string	No	SHA3-256 of the full 74 bytes. Convenience field.	64 lowercase hex chars

7. Cryptographic Assumptions

• SHA3-256 (FIPS 202) — Commitment computation and payload hash. Collision resistance assumed.
• CRC-16/CCITT — Checksum for transport integrity. Not a cryptographic binding. Polynomial: 0x1021, init: 0xFFFF.
• Signature families (referenced, not embedded) — ML-DSA-65, FALCON-512, SLH-DSA-SHA2-128f-simple. The receipt itself does not contain signatures; the signature_flags field indicates which families were used to sign the full receipt.

8. Canonical Valid Example

8.1. JSON Form

8.2. Hex Form

9. Canonical Invalid Example

10. Encoding Rules

1. Byte order. Multi-byte integer fields (timestamp_delta, checksum) are little-endian in the binary form. In JSON, they are represented as decimal integers.
2. Hex encoding. All byte-array fields (anchor_commitment, cached_receipt, receipt_locator) use lowercase hex encoding with no 0x prefix and no separators.
3. UUID encoding. The tenant_id is stored as 16 big-endian bytes in binary. In JSON, it is represented as the standard UUID string format: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.
4. No padding. The 74-byte binary form has no alignment padding. JSON producers MUST NOT add padding fields.
5. Canonical JSON. When computing payload_hash over the JSON form, keys MUST be sorted alphabetically, with no whitespace. UTF-8 encoding.

11. Verification Flow

To verify an H33-74 receipt from its JSON representation:

1. Schema validation. Validate against the JSON Schema in Section 5.
2. Decode to binary. Reconstruct the 74-byte binary form from the JSON fields.
3. Checksum verification. Compute CRC-16/CCITT over bytes 0-71. Compare to checksum. Reject on mismatch.
4. Consistency check. Verify that cached_receipt hex decodes to bytes 32-73 of the reconstructed binary. This confirms the expanded fields match the compact form.
5. Commitment verification. If the full receipt is available, recompute SHA3-256(domain_separator || canonical_receipt_bytes) and compare to anchor_commitment.
6. Chain verification. If chain_target != 0, verify the commitment exists on-chain at the expected location.
7. Signature verification. Retrieve the full receipt via receipt_locator. Verify all signatures indicated by signature_flags.

12. Failure Modes

Failure Code	Description	Severity
SCHEMA_INVALID	JSON does not conform to the schema. Missing fields, wrong types, pattern mismatches.	Fatal
CHECKSUM_MISMATCH	CRC-16 over bytes 0-71 does not match checksum. Transport corruption.	Fatal
COMMITMENT_MISMATCH	Recomputed commitment does not match anchor_commitment. Receipt has been tampered with.	Fatal
RECEIPT_NOT_FOUND	receipt_locator does not resolve to a full receipt in Cachee.	Fatal
CHAIN_NOT_ANCHORED	chain_target is non-zero but the commitment is not found on the target chain.	Warning
SIGNATURE_INCOMPLETE	signature_flags is not 0x07. Fewer than three PQ families signed the receipt.	Warning
VERSION_UNKNOWN	version is not 1. This implementation does not support the version.	Fatal
COMPUTATION_TYPE_RESERVED	computation_type is 0x00 or in the unassigned range (0x0C-0xFF).	Fatal
CONSISTENCY_FAILURE	Expanded JSON fields do not match the cached_receipt hex string.	Fatal
TIMESTAMP_OVERFLOW	timestamp_delta resolves to a date before the H33 epoch or unreasonably far in the future.	Warning

13. Frequently Asked Questions

What is an H33-74 receipt, and what does it NOT do?

It is the portable 74-byte post-quantum evidence artifact H33-74 produces. It is the evidence, not the verdict: it does not render the independent verdict (that is Verification), does not monitor operations (that is HATS), and does not make the governance decision (that is Agent-008).

How is this different from Verification?

H33-74 produces the receipt described by this schema; Verification independently renders the verdict on it. The verification flow in Section 11 confirms the receipt is well-formed and reproducible; judging whether the evidence should be trusted, against policy, is Verification's role on a separate axis.

How is a receipt independently verified?

Offline, by anyone, trusting no one. A verifier validates the JSON against this schema, decodes to binary, re-checks the CRC-16 checksum and the SHA3-256 anchor commitment, and verifies the PQ signatures indicated by signature_flags (Section 11). Any changed byte breaks a check, so the result is tamper-evident. SHA3-256, CRC-16/CCITT, and the ML-DSA / FALCON / SLH-DSA families are external standards this schema uses.

When should someone use an H33-74 receipt? And when not?

Use it when you need portable, offline-verifiable proof that a computation happened and survives infrastructure, key rotation, and time — confirmable by an outside party with no H33 contact. Do not use it when you need the independent verdict on whether that receipt should be trusted — use Verification instead; when you need to monitor operations over time — use HATS instead; or when you need to decide who may act — use Agent-008 instead. The receipt is the evidence, not the verdict on it.