H33-74 Attestation Primitive — Specification v1.0.0

1. Abstract

This document specifies H33-74, a 74-byte fixed-width post-quantum attestation primitive. H33-74 provides a compact, chain-anchored proof that a computation occurred, that its output was attested under a defined policy, and that the attestation is bound to three independent post-quantum signature families.

The primitive consists of two contiguous regions: a 32-byte on-chain commitment (the SHA3-256 digest of the attestation payload) and a 42-byte cached receipt (containing signature metadata, computation type, and a timestamp delta). Together, these 74 bytes constitute the minimum complete attestation unit in the H33 system.

H33-74 is designed for environments where attestation volume is high, storage is constrained, and quantum resistance is non-negotiable. Implementations MUST conform to this specification to produce interoperable attestation primitives.

2. Status of This Document

This specification is at Production status. The byte layout, field semantics, computation type enumeration, and verification algorithm defined herein are frozen per the H33 Protocol Stability policy. Changes to frozen surfaces require a major version increment (v2.0.0), a published migration guide, and a minimum 12-month overlap window.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

3. Definitions

Attestation

A cryptographic binding between a computation's input, its output, the policy under which it was evaluated, and the identities that signed the result. An attestation is not a proof of correctness; it is a proof of execution under stated conditions.

Commitment

The 32-byte SHA3-256 digest of the full attestation receipt (see Attestation Receipt Schema). This value is stored on-chain and serves as the binding anchor between the compact primitive and the full receipt.

Receipt

The full attestation record from which the H33-74 primitive is derived. The receipt contains all fields necessary for independent verification. See Attestation Receipt Schema Specification.

Anchor

The act of publishing a commitment to a public ledger (Bitcoin, Solana, Ethereum, or other supported chain). Anchoring binds the attestation to a specific block height and timestamp on the target chain.

Cached Receipt

The 42-byte suffix of the H33-74 primitive. Contains metadata sufficient to locate the full receipt, identify the computation type, and validate temporal bounds without fetching the full receipt from storage.

Domain Separator

A fixed byte string prepended to hash inputs to ensure that digests computed in one context cannot collide with digests computed in another. The H33-74 domain separator is the UTF-8 encoding of H33-74:v1:commitment: (24 bytes).

4. Byte Layout

An H33-74 primitive is exactly 74 bytes. Implementations MUST NOT accept primitives that are shorter or longer than 74 bytes. The layout is as follows:

Offset	Length	Field	Type	Description
0	32	commitment	bytes	SHA3-256 digest of the canonical receipt serialization. Computed as SHA3-256(domain_separator || canonical_receipt_bytes).
32	1	version	uint8	Primitive version. MUST be 0x01 for this specification.
33	1	computation_type	uint8	Enumerated computation class (see Section 5).
34	1	signature_flags	uint8	Bitfield indicating which PQ signature families are present. Bit 0: ML-DSA. Bit 1: FALCON. Bit 2: SLH-DSA. Bits 3-7: reserved, MUST be zero.
35	1	chain_target	uint8	Target chain identifier. 0x01=Bitcoin, 0x02=Solana, 0x03=Ethereum, 0x04=Arbitrum, 0x00=unanchored.
36	4	timestamp_delta	uint32 LE	Seconds elapsed since the H33 epoch (2026-01-01T00:00:00Z). Little-endian encoding. Maximum representable date: approximately 2162.
40	16	receipt_locator	bytes	Opaque locator for the full receipt in the Cachee layer. Format is implementation-defined but MUST be deterministically derivable from the receipt ID.
56	16	tenant_id	UUID bytes	The tenant identifier (UUID v4, big-endian byte order) that owns this attestation.
72	2	checksum	uint16 LE	CRC-16/CCITT over bytes 0-71. Used for transport integrity, not cryptographic binding.

4.1. Canonical Byte Diagram

4.2. Commitment Computation

The commitment field MUST be computed as follows:

1. Serialize the full attestation receipt into its canonical byte form (see Attestation Receipt Schema, Section 5).
2. Prepend the domain separator: the UTF-8 bytes of the string H33-74:v1:commitment: (24 bytes, no null terminator).
3. Compute SHA3-256 over the concatenation: SHA3-256(domain_separator || canonical_receipt_bytes).
4. The resulting 32-byte digest is the commitment.

5. Computation Types

The computation_type field at byte offset 33 encodes the class of computation that was attested. Implementations MUST reject H33-74 primitives containing undefined computation type values.

Value	Name	Description
0x01	BIOMETRIC_AUTH	FHE-encrypted biometric authentication (BFV inner product).
0x02	ZKP_VERIFY	Zero-knowledge proof verification (STARK or PLONK).
0x03	DOCUMENT_SIGN	Post-quantum document signing (ArchiveSign).
0x04	KEY_EXCHANGE	Post-quantum key encapsulation (ML-KEM / Kyber).
0x05	FHE_COMPUTE	General-purpose FHE computation result attestation.
0x06	GOVERNANCE_DECISION	Governance graph node attestation. See Governance Proof Model.
0x07	CHAIN_ANCHOR	Periodic chain anchor (batch Merkle root of prior attestations).
0x08	AI_INFERENCE	Attested AI inference result (encrypted or cleartext).
0x09	TOKEN_MINT	Tokenization event attestation.
0x0A	WIRE_PROOF	Payment wire attestation.
0x0B	THRESHOLD_DECRYPT	Threshold decryption event (MPC completion attestation).
0x00	RESERVED	Reserved. MUST NOT be used.
0x0C-0xFF	—	Unassigned. Implementations MUST reject these values.

6. Signature Requirements

An H33-74 primitive references a signature bundle stored with the full receipt. The signature_flags byte at offset 34 indicates which post-quantum signature families were used to sign the attestation receipt.

6.1. Required Families

A conformant H33-74 primitive MUST have all three signature bits set (signature_flags = 0x07), indicating the receipt was signed with:

1. ML-DSA-65 (FIPS 204, Module-Lattice Digital Signature Algorithm, security level 3). The MLWE-based lattice signature.
2. FALCON-512 (NTRU-lattice-based signature, NIST Round 3 selection). Provides an independent hardness assumption from ML-DSA.
3. SLH-DSA-SHA2-128f-simple (FIPS 205, Stateless Hash-Based Digital Signature Algorithm). Hash-based; provides security even if both lattice assumptions fail.

6.2. Binding Rules

Each signature in the bundle MUST be computed over the identical canonical receipt bytes. Implementations MUST NOT sign different serializations or subsets of the receipt with different signature families. Verification MUST fail if any one of the three signatures does not verify.

7. Anchoring

Anchoring publishes the 32-byte commitment to a public ledger. The chain_target field at byte offset 35 identifies the target chain.

7.1. Bitcoin (Taproot)

The commitment is embedded in a Taproot (BIP-341) witness script as an OP_RETURN output prefixed with the 4-byte tag H33\x00. The full output script is: OP_RETURN H33\x00 <32-byte commitment> (37 bytes total).

7.2. Solana (Memo)

The commitment is written as a Solana Memo Program (MemoSq4gqABAXKb96qnH8TysNcWxMyWCqXgDLGmfcHr) instruction. The memo data is the hex-encoded commitment (64 ASCII characters) prefixed with H33:.

7.3. Ethereum (Calldata)

The commitment is published as calldata in a transaction to the H33 anchor contract. The function selector is anchor(bytes32) with the commitment as the sole argument.

7.4. Unanchored Primitives

If chain_target = 0x00, the primitive has not been anchored to any public chain. Unanchored primitives are valid attestations but do not carry chain-binding guarantees. Implementations SHOULD distinguish anchored and unanchored primitives in user-facing outputs.

8. Verification

Independent verification of an H33-74 primitive proceeds as follows. All steps are REQUIRED for a conformant verifier.

8.1. Step-by-Step Procedure

1. Length check. Verify that the primitive is exactly 74 bytes. Reject otherwise.
2. Checksum. Compute CRC-16/CCITT over bytes 0-71. Compare to bytes 72-73 (little-endian). Reject on mismatch.
3. Version. Verify version = 0x01. Reject unknown versions.
4. Computation type. Verify computation_type is in the range 0x01-0x0B. Reject reserved or unassigned values.
5. Signature flags. Verify signature_flags = 0x07 (all three families present). Reject if any required bit is unset.
6. Timestamp bounds. Decode timestamp_delta as uint32 LE. Compute the absolute time: 2026-01-01T00:00:00Z + timestamp_delta seconds. Reject if the timestamp is in the future by more than 300 seconds (clock skew tolerance).
7. Fetch full receipt. Use the receipt_locator to retrieve the full attestation receipt from the Cachee layer or other storage.
8. Recompute commitment. Serialize the retrieved receipt canonically (see Receipt Schema, Section 5). Compute SHA3-256(domain_separator || canonical_receipt_bytes). Compare to the commitment field. Reject on mismatch.
9. Verify signatures. Verify all three PQ signatures in the receipt's signature bundle against the canonical receipt bytes. Reject if any signature fails.
10. Chain verification (if anchored). If chain_target != 0x00, verify the commitment exists on the indicated chain at the expected location. This step is RECOMMENDED but MAY be deferred for offline verification.

9. Failure Modes

Conformant verifiers MUST produce deterministic, structured error output for each failure mode. The following table enumerates all defined failure codes.

Error Code	Condition	Severity	Description
H74_ERR_LENGTH	Primitive is not 74 bytes	Critical	The input does not conform to the fixed-width format. No further processing is possible.
H74_ERR_CHECKSUM	CRC-16 mismatch	Critical	Transport corruption detected. The primitive MUST NOT be processed further.
H74_ERR_VERSION	Unknown version byte	Critical	The verifier does not support this primitive version.
H74_ERR_COMP_TYPE	Invalid computation type	Critical	The computation type is reserved, unassigned, or outside the valid range.
H74_ERR_SIG_FLAGS	Missing signature family	Critical	Not all three required PQ signature families are indicated.
H74_ERR_TIMESTAMP	Future timestamp beyond tolerance	Warning	The timestamp is more than 300 seconds in the future. May indicate clock drift.
H74_ERR_RECEIPT_FETCH	Full receipt not found	Critical	The receipt locator did not resolve to a valid receipt.
H74_ERR_COMMITMENT	Hash mismatch	Critical	The recomputed commitment does not match the on-chain commitment.
H74_ERR_SIG_MLDSA	ML-DSA signature invalid	Critical	The ML-DSA-65 signature over the canonical receipt bytes failed verification.
H74_ERR_SIG_FALCON	FALCON signature invalid	Critical	The FALCON-512 signature over the canonical receipt bytes failed verification.
H74_ERR_SIG_SLHDSA	SLH-DSA signature invalid	Critical	The SLH-DSA signature over the canonical receipt bytes failed verification.
H74_ERR_CHAIN	Anchor not found on chain	Warning	The commitment was not located on the indicated target chain. The primitive may still be valid if unanchored verification is acceptable.

10. Conformance Requirements

An implementation claiming conformance to this specification MUST satisfy all of the following:

1. Produce H33-74 primitives that are exactly 74 bytes with the byte layout defined in Section 4.
2. Use SHA3-256 (FIPS 202) with the specified domain separator for commitment computation.
3. Set version = 0x01.
4. Set signature_flags = 0x07 for all production primitives.
5. Compute CRC-16/CCITT over bytes 0-71 and store the result at bytes 72-73 in little-endian order.
6. Implement the verification procedure in Section 8 in its entirety, including all 12 failure codes in Section 9.
7. Produce structured error output that includes the error code, severity, and a human-readable description.
8. Reject primitives that fail any Critical-severity check without proceeding to subsequent checks.
9. Encode timestamp_delta relative to the H33 epoch (2026-01-01T00:00:00Z) in little-endian uint32.
10. Support at least one anchoring method (Section 7) for production deployments.

Implementations SHOULD additionally:

1. Implement chain verification (Section 8, step 10) for at least one supported chain.
2. Support all defined computation types (Section 5).
3. Log verification outcomes in a format compatible with the Attestation Receipt Schema.
4. Participate in the HATS Conformance Suite test vector program.

11. Security Considerations

11.1. Quantum Resistance

H33-74 attestations are bound by three independent post-quantum hardness assumptions: MLWE lattice problems (ML-DSA), NTRU lattice problems (FALCON), and the security of SHA-256-based hash chains (SLH-DSA). A quantum adversary must break all three to forge an attestation. This follows the H33 principle of three independent mathematical bets.

11.2. Replay Protection

Each H33-74 primitive includes a tenant_id, timestamp_delta, and receipt_locator that together make each primitive unique. The underlying receipt chain (see Receipt Schema, Section 6) further binds each receipt to its predecessor via predecessor_hash, preventing receipt reordering or substitution.

11.3. Chain Binding

On-chain anchoring provides a public, immutable timestamp and ordering guarantee. However, the anchoring transaction itself is not post-quantum (Bitcoin, Solana, and Ethereum use classical ECDSA/EdDSA). The security of the attestation does not depend on chain-level signature security; the chain serves only as a timestamping and publication layer. Even if the chain signature is broken, the 32-byte commitment and three PQ signatures over the receipt remain valid.

11.4. Checksum Limitations

The CRC-16/CCITT checksum at bytes 72-73 detects accidental transport errors. It is not a cryptographic integrity mechanism. The cryptographic binding is provided by the commitment (SHA3-256 digest). Implementations MUST NOT rely on the checksum for security-critical integrity verification.

12. Changelog

Version	Date	Changes
1.0.0	2026-05-22	Initial publication. Byte layout frozen. Computation types 0x01-0x0B defined. Verification algorithm specified. Failure modes enumerated.

13. References

13.1. Normative References

• [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [FIPS 202] NIST, "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", FIPS PUB 202, August 2015.
• [FIPS 204] NIST, "Module-Lattice-Based Digital Signature Standard", FIPS PUB 204, August 2024.
• [FIPS 205] NIST, "Stateless Hash-Based Digital Signature Standard", FIPS PUB 205, August 2024.
• [H33-RECEIPT] H33.ai, Inc., "Attestation Receipt Schema Specification v1.0", 2026.

13.2. Informative References

• [H33-GOV] H33.ai, Inc., "Governance Proof Model Specification v1.0", 2026.
• [H33-STABILITY] H33.ai, Inc., "Protocol Stability & Replay Integrity", 2026.
• [HATS] H33.ai, Inc., "HATS Standard v1.0", 2026.
• [H33-74-WP] H33.ai, Inc., "H33-74 White Paper", 2026.
• [BIP-341] Wuille, P., Nick, J., Town, A., "Taproot: SegWit version 1 spending rules", 2020.