Most attestation systems make timestamping and chain settlement the same event. An attestation is created when it is written to the chain. Before the chain transaction, there is no attestation. After the transaction, the attestation is permanent.
H33-74 decouples those steps.
Definition. H33-74 is the portable 74-byte post-quantum proof primitive — a 32-byte on-chain commitment plus a 42-byte off-chain receipt, signed under three independent NIST families (ML-DSA, FALCON, SLH-DSA). The proof and its verification come from that cryptography, which is why a receipt is valid before any chain is touched. A blockchain is one interchangeable anchoring substrate for the commitment — never the source of the proof or the trust.
Receipt creation and chain anchoring are separate operations.
A receipt is valid the moment it is signed. Anchoring is an optional later step that adds independent notarization on a public chain. The receipt is the proof; the chain is the notary.
Why decoupling matters
- Cost. You pay chain fees only when notarization is needed. A system producing 100,000 receipts per day does not have to pay for 100,000 chain transactions per day.
- Throughput. Receipt issuance is not bounded by chain confirmation times. The system continues operating at full speed; chain anchoring runs as a batched background process.
- Optionality. You can decide later whether to anchor at all, which chains, and when. Different anchoring strategies for different receipt categories.
- Sovereignty. A system can run in environments where public chains are not appropriate (regulated, classified, air-gapped) and still produce cryptographic evidence.
Three anchoring postures
Immediate per-receipt anchoring
Each receipt produces a chain transaction at the moment of creation. Maximum notarization, highest cost. Appropriate for low-frequency high-value events: large transfers, governance final decisions, custody changes.
Batched periodic anchoring
The system collects receipts produced over a time window (one hour, one day, one week) and anchors a single cryptographic commitment over the batch in one chain transaction. Verifying any individual receipt requires the receipt plus a short proof tying it to the batch. The mechanism is identical to how OpenTimestamps has anchored hundreds of millions of timestamps to Bitcoin since 2016, extended with post-quantum signatures.
On-demand retroactive anchoring
Receipts are produced and held without chain anchoring. When external verification is needed (regulator inquiry, dispute, audit), the system anchors the relevant receipts at that moment. The receipts existed all along; the chain anchor is added when the cost is justified.
What anchoring actually adds
The receipt is already signed by three independent post-quantum families. The chain anchor adds:
- An independent third-party notarization that the receipt existed by no later than a specific block height.
- Replication and durability through whatever chain you choose.
- A public reference that allows any third party to confirm timing without depending on H33 infrastructure.
What the chain anchor does not add: the integrity of the receipt itself. That is already cryptographically established by the post-quantum signatures the moment the receipt is produced.
Anchor migration as a routine operation
Because anchoring is separate, the anchor set can evolve. A receipt anchored only on Polygon today can later be anchored on Bitcoin too, and the original Polygon anchor remains valid. The receipt itself does not change; the set of independent notarizations grows.
What differs between blockchains are their operational and integration characteristics — fee, finality latency, availability. The H33-74 primitive and its cryptographic properties remain unchanged. Migrating from one blockchain to another changes the anchoring substrate and deployment environment. It does not change the H33-74 primitive, the cryptographic evidence, or the verification model.
Delayed anchoring is what makes H33-74 chain-portable. Because receipts are valid without anchoring, the chain you anchor to becomes a deployment choice rather than an architectural commitment.
Compared to traditional timestamping
OpenTimestamps
Bitcoin-anchored. Batched root every block. Receipt creation event = chain anchoring event. Verification requires Bitcoin chain.
EAS / Verax
EVM-anchored. Each attestation = one chain write. Verification requires the host EVM chain.
H33-74
Chain-independent. Receipt valid without any anchor. Anchoring is optional, deferrable, repeatable across chains. Verification requires only the receipt and the public verifier.
What H33-74 does not do
H33-74 mints and anchors the portable proof primitive; delayed anchoring is a property of that primitive. It does not monitor systems for control drift (that is HATS), it does not render the pass/fail verdict on an attestation (an independent verifier does — see Verification), and it does not govern agents or preserve decision authority (that is Agent-008).
Frequently asked
Does anchoring on a chain change the proof?
No. The receipt is already signed by three post-quantum families the moment it is produced. The chain anchor adds an independent third-party timestamp and durability; it does not add or change the integrity of the receipt itself.
Is the trust from the chain or from H33-74?
From H33-74. A receipt is valid before any anchor, verifiable with just the receipt and the open verifier. The chain is the notary that adds a public timestamp, never the source of the proof or the trust.
Can I move a receipt to another chain?
Yes. Because anchoring is separate and repeatable, a receipt anchored on one chain today can be anchored on another later; the original anchor stays valid. Migrating chains changes the anchoring substrate, not the H33-74 primitive, the cryptographic evidence, or the verification model.
Can I hold a receipt without ever anchoring it?
Yes. A receipt is valid and verifiable the moment it is signed. Anchoring is optional and can be added on demand — for a regulator inquiry, dispute, or audit.
Related