In conventional tokenization, identity sits in a database the issuer controls. Here, the identity is born with the asset, follows every transfer, anchors on every chain, and remains independently verifiable for decades — including after H33 stops existing.
Start the demo →Not similar. Not wrapped. Not compressed differently. The same canonical commitment, written to each chain's native attestation surface.
Asset size is irrelevant. The chain never sees the asset. The chain sees the canonical commitment that binds to it.
Pick any asset below. Your browser computes the real SHA-256 commitment in this tab — same primitive that lands on-chain.
Step 1 · Choose an asset
The 74 bytes break down into a 32-byte canonical commitment and a 42-byte post-quantum proof bundle (ML-DSA-65 + FALCON-512 + SPHINCS+-SHA2-128f). A WASM verifier runs in this tab, with zero calls to h33.ai, and returns PASS or FAIL.
⛔ Complete Scene 01 first
In conventional tokenization, ownership history sits in an issuer's database. If the database goes away, the history goes with it. Here, every transfer emits a continuity receipt linked to the previous one — a cryptographic chain of custody that nobody can rewrite.
⛔ Complete Scene 01 first
The commitment is post-quantum-portable. Anchor it on Bitcoin via Taproot (BIP-341, x-only tweaked key — monetary path, no data-carrier baggage), on Solana via the memo program, on Ethereum/Polygon/Arbitrum/Base/Optimism/Avalanche/Zcash/Hyperliquid via calldata or indexed event topics — same 32 bytes. The identity didn't change. Only its anchoring surface did.
⛔ Complete Scene 01 first
Pick any moment in the asset's lifetime — past or 25 years from now. The verifier replays every receipt from origination up to that timestamp and produces an auditor-grade report: who owned the asset, under what authority, validated by which policy state, anchored on which chains.
⛔ Complete Scene 01 first
Asset blob, full receipt lineage, verifier WASM binary, README with one-line instructions. The auditor unzips on an air-gapped laptop, runs ./verify, and gets PASS. No network. No accounts. No vendor in the loop.
⛔ Complete Scene 01 first
For implementers, regulators, and auditors who need to understand the primitive — not just the demo.
32-byte canonical commitment (SHA3-256 of the asset content concatenated with policy state, authority scope, and timestamp). 42-byte composite proof bundle: ML-DSA-65 attestation tag + FALCON-512 attestation tag + SPHINCS+-SHA2-128f attestation tag, each a truncated index into the H33-74 substrate proof corpus. The full per-family signatures live in the substrate; the 42 bytes are the index that lets a verifier locate and check them. This is what makes H33-74 a portable identity primitive: 74 bytes is small enough to fit in a Bitcoin Taproot output, a QR code, a tweet, or an IoT device's flash — but it's a verifiable index into a post-quantum-signed audit trail of unlimited size.
The SHA3-256 hashing is real, computed in your browser via WebCrypto (or a fallback shim). The post-quantum signatures shown are simulated for demo speed — real ML-DSA-65 / FALCON-512 / SPHINCS+ signing happens in the H33 substrate backend; the WASM verifier at /verify-the-story/playground/ shows the actual post-quantum verification operation on a real production receipt. The point of this demo is to show the shape of canonical identity — the live verifier playground is where you confirm the cryptography actually does what we claim.
The 32-byte commitment is a content-addressable digest of the asset's canonical state. Any chain that can store 32 bytes can anchor it — Bitcoin Taproot (the commitment is hidden inside an x-only tweaked public key per BIP-341, so the output is a normal spendable P2TR — no data-carrier baggage, no soft-fork relitigation, indistinguishable from any other Taproot UTXO on-chain), Solana memo program, Ethereum/L2 calldata, indexed event topics, Zcash unique nullifier, etc. The commitment is the same everywhere because the input (asset + authority + timestamp) is the same. Verifying an anchored commitment requires only reading the anchor location on that chain and recomputing the digest from the asset and its associated receipt — no bridge, no wrapped token, no custodian.
Each transfer emits a continuation receipt: a new 74-byte canonical identity whose 32-byte commitment includes the previous identity's hash plus the new owner's authority. This makes the chain of custody an immutable hash-linked DAG — like a blockchain, but specific to one asset. Replaying the chain at any timestamp reconstructs the ownership lineage exactly. Tamper with any receipt and downstream hashes break; the tamper is detected automatically.
Three properties make this work. (1) The verifier is portable. The verification logic is published as an open spec and runs as a WASM binary — anyone can compile a verifier from spec. (2) The anchor is on a public chain. Bitcoin/Ethereum/etc. don't depend on H33's continued existence. (3) The proof corpus is replicable. The substrate proof index that the 42 bytes points into can be mirrored anywhere — auditor archives, sovereign archives, academic institutions. As long as someone, somewhere, has a copy of the substrate corpus and the public anchor chain is alive, the identity is verifiable. H33 going away does not destroy any past identity.
Authority in the 74-byte identity is governed by Q-Key (see /q-key/). A Q-Key authority object is time-bound, state-scoped, and computation-bound — meaning a transfer can only happen if the acting agent (human, wallet, transfer agent, AI) holds an authority that includes "transfer," is within its TTL window, and matches the asset's policy state. Delegation is hash-linked: a parent authority can issue strictly-narrower child authorities for delegated actions, and the full delegation chain is replayable from receipts.
Revocation is a first-class receipt type. A regulator with revocation authority emits a revocation receipt against the asset's identity; downstream attempts to transfer or anchor see the revocation in the lineage and reject. The revocation itself is a cryptographic fact — visible to every verifier, never silently applied. Same goes for freezes, sanctions list updates, and compliance overrides: every regulatory action is part of the public lineage, replayable by any auditor.
The 74-byte identity binds to authority, not to PII. The owner's KYC details live in encrypted custody (H33-Vault / H33-Share), and the authority object commits to a hash of the KYC bundle without exposing the bundle itself. Verifiers see "this transfer was approved by an authority bound to a KYC bundle that hashed to X" — they don't see the SSN, name, or jurisdiction. Privacy is preserved while compliance is enforced. See /zk-kyc/ for the privacy-preserving KYC primitive that drives this.
The same primitive lives across the rest of H33 — encrypted compute, replayable governance, cyber-insurance evidence, AI agent action proofs. Tokenization is one canonical surface; the others are listed below.