H33-74 Receipt Schema — v1.0.0

Version: 1.0.0
Status: Production
Last Updated: 2026-05-22
Canonical URL: https://h33.ai/schemas/h33-74/
Schema Draft: JSON Schema draft 2020-12
Editor: Eric Beans, H33.ai, Inc.

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`

Offset (hex):  00                              20 21 22 23 24       28                       38                       48  4A
               +-------------------------------+--+--+--+--+--------+------------------------+------------------------+---+
               |         commitment (32)        |v |ct|sf|ch| t_delta|    receipt_locator (16) |     tenant_id (16)     |chk|
               +-------------------------------+--+--+--+--+--------+------------------------+------------------------+---+
               |<-------- on-chain (32) -------->|<-------------- cached receipt (42) ---------------------------------------->|

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

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://h33.ai/schemas/h33-74/v1.0.0",
  "title": "H33-74 Receipt",
  "description": "JSON representation of the 74-byte H33-74 attestation receipt.",
  "type": "object",
  "required": [
    "anchor_commitment",
    "cached_receipt",
    "version",
    "computation_type",
    "signature_flags",
    "chain_target",
    "timestamp_delta",
    "receipt_locator",
    "tenant_id",
    "checksum"
  ],
  "properties": {
    "anchor_commitment": {
      "type": "string",
      "pattern": "^[a-f0-9]{64}$",
      "description": "SHA3-256 commitment. Hex-encoded bytes 0-31."
    },
    "cached_receipt": {
      "type": "string",
      "pattern": "^[a-f0-9]{84}$",
      "description": "Hex-encoded bytes 32-73."
    },
    "version": {
      "type": "integer",
      "const": 1,
      "description": "Primitive version. Must be 1."
    },
    "computation_type": {
      "type": "integer",
      "minimum": 1,
      "maximum": 11,
      "description": "Computation type enum (0x01-0x0B)."
    },
    "signature_flags": {
      "type": "integer",
      "minimum": 0,
      "maximum": 7,
      "description": "Bitfield: bit0=ML-DSA, bit1=FALCON, bit2=SLH-DSA."
    },
    "chain_target": {
      "type": "integer",
      "enum": [0, 1, 2, 3, 4],
      "description": "0=unanchored, 1=Bitcoin, 2=Solana, 3=Ethereum, 4=Arbitrum."
    },
    "timestamp_delta": {
      "type": "integer",
      "minimum": 0,
      "maximum": 4294967295,
      "description": "Seconds since H33 epoch (2026-01-01T00:00:00Z)."
    },
    "receipt_locator": {
      "type": "string",
      "pattern": "^[a-f0-9]{32}$",
      "description": "Cachee locator. Hex-encoded 16 bytes."
    },
    "tenant_id": {
      "type": "string",
      "format": "uuid",
      "description": "Tenant UUID v4."
    },
    "checksum": {
      "type": "integer",
      "minimum": 0,
      "maximum": 65535,
      "description": "CRC-16/CCITT over bytes 0-71."
    },
    "payload_hash": {
      "type": "string",
      "pattern": "^[a-f0-9]{64}$",
      "description": "SHA3-256 of the full 74 bytes. Computed, not stored in binary."
    }
  },
  "additionalProperties": false
}

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.

The H33-74 receipt is a compact reference. The actual signatures reside in the full receipt, retrievable via receipt_locator. The commitment cryptographically binds the compact form to the full form.

8. Canonical Valid Example

8.1. JSON Form

Valid H33-74 Receipt (JSON)
{
  "anchor_commitment": "a3f8c1d2e4b5f67890abcdef1234567890abcdef1234567890abcdef12345678",
  "cached_receipt": "0101070112a50d00c0ffee01020304050607080910111213141516a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f84f2a",
  "version": 1,
  "computation_type": 1,
  "signature_flags": 7,
  "chain_target": 1,
  "timestamp_delta": 12345678,
  "receipt_locator": "c0ffee01020304050607080910111213",
  "tenant_id": "a1b2c3d4-e5f6-a7b8-c9d0-e1f2a3b4c5d6",
  "checksum": 10831,
  "payload_hash": "b7e4c2f1a8d3e6f09b2c5d8e1f4a7b0c3d6e9f2a5b8c1d4e7f0a3b6c9d2e5f8"
}

8.2. Hex Form

Valid H33-74 Receipt (hex, 148 chars = 74 bytes)
a3f8c1d2e4b5f67890abcdef1234567890abcdef1234567890abcdef123456780101070112a50d00c0ffee01020304050607080910111213141516a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f84f2a

9. Canonical Invalid Example

Invalid H33-74 Receipt (JSON)
{
  "anchor_commitment": "ZZZZ",                     // ERROR: not 64 hex chars
  "cached_receipt": "0101",                         // ERROR: not 84 hex chars
  "version": 2,                                     // ERROR: must be 1
  "computation_type": 0,                            // ERROR: minimum is 1 (0x00 is RESERVED)
  "signature_flags": 3,                             // WARNING: only 2 of 3 families (non-conformant)
  "chain_target": 5,                                // ERROR: not a valid chain target
  "timestamp_delta": -1,                            // ERROR: must be >= 0
  "receipt_locator": "c0ffee",                      // ERROR: not 32 hex chars
  "tenant_id": "not-a-uuid",                        // ERROR: invalid UUID format
  "checksum": 70000                                 // ERROR: exceeds uint16 max (65535)
}

10. Encoding Rules

Byte order. Multi-byte integer fields (timestamp_delta, checksum) are little-endian in the binary form. In JSON, they are represented as decimal integers.
Hex encoding. All byte-array fields (anchor_commitment, cached_receipt, receipt_locator) use lowercase hex encoding with no 0x prefix and no separators.
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.
No padding. The 74-byte binary form has no alignment padding. JSON producers MUST NOT add padding fields.
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:

Schema validation. Validate against the JSON Schema in Section 5.
Decode to binary. Reconstruct the 74-byte binary form from the JSON fields.
Checksum verification. Compute CRC-16/CCITT over bytes 0-71. Compare to checksum. Reject on mismatch.
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.
Commitment verification. If the full receipt is available, recompute SHA3-256(domain_separator || canonical_receipt_bytes) and compare to anchor_commitment.
Chain verification. If chain_target != 0, verify the commitment exists on-chain at the expected location.
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

Related Schemas & Specifications

Schema Index HATS Attestation Schema Governance Proof Bundle Verification Result H33-74 Specification HATS Standard