The receipt is created once and stays valid forever. Anchoring is a separate operation that can happen on any chain, at any time, repeated as needed. Verification works as long as the receipt exists and the verifier is preserved.
This is the operating model underneath every H33-74 deployment. Three operations, each independent, each playing one specific role.
An H33-74 receipt is produced from the result of one bounded computation. The computation can be anything: an AI decision, a compliance determination, a governance vote, a transfer authorization, a KYC outcome, a FHE output, a tokenization action.
The receipt commits to the computation's result and signs it under three independent post-quantum families (ML-DSA-65, FALCON-512, SLH-DSA-128f). The signing happens once. The 74-byte receipt is fixed from that moment.
Anchoring is the act of recording the receipt's existence to a public chain. It is optional, deferrable, and repeatable.
None of these choices affect the receipt itself. The receipt was minted before anchoring and remains the same regardless of which chains hold notarizations.
Verification requires only the receipt and the verifier tooling. The verifier is open-source, runnable without H33 infrastructure, and architected to survive H33 itself. (This is documented in H33-74 whitepaper and in the H33 verifier project on GitHub.)
A receipt remains verifiable as long as:
None of those requirements depend on a specific chain. A receipt anchored on a chain that is later deprecated remains verifiable because the chain anchor was independent notarization, not the proof itself.
A tokenized fund operates for five years on Ethereum. Every action produces an H33-74 receipt. Year one through year three, anchors go to Ethereum daily. Year three, the fund adds Bitcoin anchors weekly for high-value receipts. Year four, post-quantum considerations push the fund to add a third chain that uses PQ-secured consensus. Year five, the fund decides to migrate off Ethereum entirely.
Mint operations: unchanged. Receipts produced exactly the same way.
Anchor operations: evolved. Anchor set per receipt category shifted over time, additively. No anchor was retracted; new anchors were added.
Verify operations: unchanged. Every receipt produced in year one is still verifiable in year five using the same verifier with no migration needed.
Read why this model makes chain migration a routine operational event instead of an existential project.
Why Chain Migration Shouldn't Exist H33-74 Overview