Explore (579)Live Systems (52)Pricing
Log InGet API Key✓ Verify It Yourself
Live demo · real Solana mainnet anchor

Watch the canonical bind happen.

A real $50M restricted Treasury note. The cryptographic computation that actually binds identity to asset content. Three independent post-quantum families sign it. Anchored live on Solana mainnet. Then projected onto every chain that can store 32 bytes.

~30 seconds · the Solana anchor is real · click the explorer link after to verify on-chain
U.S. TREASURY $50M T
$50M Restricted Treasury Note
CUSIP 912828ZE7 · 10-yr · Reg-S
Canonical identity awaiting build
The cryptographic bind to this asset will compute here, live.
Press Start to begin.
This is the canonical bind. The commit is a single SHA3-256 of all four inputs concatenated. Change any input — different commit. Forge the commit — three PQ families have to be forged simultaneously. The asset and its identity are one cryptographic object. ↺ swap test: try to pair this commit with a different asset → asset_hash changes → commit invalid.
3 independent post-quantum families sign over the commit
ML-DSA-65Module-LWE lattice ·
FALCON-512NTRU lattice ·
SPHINCS+ 128fhash-based, no lattice ·
32B on-chain commit 42B off-chain proof bundle = 74 bytes canonical identity
Solana mainnet · live · real anchor writing…
commit (32B)
program
block
attestation
explorer
The same 32 bytes — projected onto every chain

Solana is just where it landed first. The commit is portable to any chain that can store 32 bytes.

Solana
memo program
32 BYTES · LIVE
Bitcoin
Taproot (BIP-341)
32 BYTES · ARCH
Ethereum
calldata + event
32 BYTES · ARCH
Polygon
event log
32 BYTES · ARCH
Arbitrum
indexed topic
32 BYTES · ARCH
Base
indexed topic
32 BYTES · ARCH
Avalanche
indexed topic
32 BYTES · ARCH
Zcash
unique nullifier
32 BYTES · ARCH
Issuer
Custodian
Sovereign Fund
Replay 2050 ✓
Traditional tokenization stores identity in an issuer database. Issuer-controlled, mutable, lost when the operator disappears.
H33 binds canonical identity into the asset's own commitment. One 74-byte object. Survives transfers, custodians, chains, and decades.
Replay in 2050: even if H33 doesn't exist, the receipt corpus + the public anchor chain reconstruct the ownership lineage. Verifiability does not depend on the vendor.
What this enables

A portable 32-byte post-quantum anchor across chains means…

  • Replayable operational infrastructure
  • Post-quantum attestations
  • Encrypted AI / agent execution tracking
  • Independently verifiable governance replay
  • Cryptographic continuity across organizations and agents
  • Live operational proof systems
  • Cross-chain replayable receipts
  • Privacy-preserving compliance and audit trails
  • Agent-Zero operational lineage
  • H33-Upstream provenance + governance continuity
  • Q-Sign post-quantum signing infrastructure
  • 74-byte portable attestations across Bitcoin, Solana, Ethereum and Polygon zkEVM
Beyond tokenization or proofs. This is reconstructable operational truth at AI scale — trillions of transactions, 100% accuracy, no operator dependency.

What "canonical bind" actually means

A canonical bind is the cryptographic operation that makes the asset and its identity one object. The commit is SHA3-256(asset_content || authority || timestamp || policy_state). The four inputs are concatenated and hashed together. Change any one of them — a different commit comes out. This is what makes the asset and the identity inseparable: the identity literally encodes the asset's content into the same hash.

The 32-byte commit then becomes the input to three independent post-quantum signature families (ML-DSA-65, FALCON-512, SPHINCS+-SHA2-128f). Each signs over the commit. To forge the identity, an attacker would have to forge all three signatures simultaneously — three independent hardness assumptions (Module-LWE, NTRU, hash-based) would have to break at the same time. That has no known credible path.

Together: 32 bytes of bound commit + 42 bytes of PQ proof index = 74 bytes of canonical identity. The commit goes on-chain (any chain that can store 32 bytes). The proof bundle index goes off-chain. Both halves are needed to verify. Neither can be forged without the other.

Is the Solana anchor really real?

Yes. The demo calls https://api.h33.ai/api/v1/privacy/age — the same endpoint that powers the live Solana-Privacy page. The commitment returned is from a real Solana mainnet program account (program ID 5eAwAv59YqpnSBMj59KeXhDdLqmn99HBYSjrb6jcLbC5, currently live on Solana mainnet). The Solscan and Solana Explorer links in the demo are real block-explorer links — click them and you'll see the on-chain transaction.

Solana mainnet — currently live

H33-Solana is live on Solana mainnet. The cryptographic primitive is identical to the devnet integration that preceded it — the same 32-byte commitment, same three NIST post-quantum signature families (ML-DSA-65, FALCON-512, SPHINCS+-SHA2-128f), same program account binding logic. The mainnet transition was a deploy flag, not an architectural change.

FAQ

Are the other chains real too, or animated?

Honest answer: the Solana anchor in the demo is real, just-written to Solana mainnet. The other chain tiles show the same 32 bytes as they would appear on each surface. The architecture for anchoring on Bitcoin Taproot, Ethereum, Polygon, etc. is built and tested (see the H33-74 whitepaper), but live multi-chain anchoring in a 30-second demo would be gas/finality-bound — the visual is honest about which is live (the "LIVE" badge on Solana) and which is architecturally portable ("ARCH" on the others).

What about Bitcoin and OP_RETURN?

H33 anchors on Bitcoin via Taproot (BIP-341) as the production primitive — the commitment is hidden inside an x-only tweaked public key per BIP-341, producing a normal spendable P2TR output indistinguishable from any other Taproot UTXO on-chain. No data-carrier baggage. No soft-fork relitigation. OP_RETURN is supported as an alternative for use cases that explicitly need the data-carrier semantics, but Taproot is the lead. See /bitcoin-privacy/.

What about delegated authority, transfers, revocation, KYC privacy?

Authority is governed by Q-Key — time-bound, state-scoped, computation-bound authority objects. Transfers emit hash-linked continuation receipts. Revocation is a first-class receipt type. KYC privacy is preserved via authority-binding to a hash of the KYC bundle (verifiers see "this transfer was approved by an authority bound to a KYC bundle hashing to X" without seeing the SSN/jurisdiction/name). See /zk-kyc/ for the underlying primitive.