Related · tier-1 reading. For the integrity anchor that makes this verifiable, see Avalanche Evidence Anchoring.
A visual walkthrough of the H33-74 attestation workflow. The encrypt/decrypt step runs real AES-GCM in your browser; the FHE, STARK, and post-quantum signature values illustrate the production pipeline. Verify the real cryptography — every byte — in the Proof Lab.
What you're about to see
A Solana SPL token transfer goes through the full H33-74 attestation pipeline: the transaction data is encrypted with homomorphic encryption (so it's never visible in plaintext), a compliance check runs on the encrypted data, and then the result is designed to be signed with three independent post-quantum signature families and committed to a compact cryptographic primitive. H33 is designed to bind evidence using three independent post-quantum signature families: ML-DSA, FALCON and SLH-DSA. Full three-family production verification remains pending completion and independent qualification of the FALCON repair. The encrypt/decrypt step runs real AES-GCM in your browser and the Bitcoin mainnet anchor is a live on-chain transaction; the signature and FHE values shown are illustrative of the production pipeline — see the Proof Lab for sample artifacts.
This demo reinforces H33-74, which produces and anchors the portable 74-byte post-quantum evidence primitive. Related H33-74 demos: Avalanche · BitBonds · ArchiveSign.
STEP 1 / 7WAITING
Create Solana Transaction
Solana SPL token transfer with post-quantum attestation
What's happening: An example Solana SPL transfer (1,000 USDC) shows where attestation fits; the attestation recorded and anchored below is a BitBond issuance, not this transfer. This is the raw transaction that needs cryptographic attestation before it touches the chain.
STEP 2 / 7WAITING
Encrypt with FHE
Transaction data encrypted using BFV Fully Homomorphic Encryption
What's happening: Every field of the transaction (amount, sender, recipient, program) is encrypted using lattice-based homomorphic encryption. The data is never decrypted at any subsequent step. All computation happens on the encrypted values. This is not tokenization or hashing — it's mathematically proven encryption that allows computation without decryption.
STEP 3 / 7WAITING
Encrypted Compliance Check
TFHE threshold check: "Is transfer amount ≤ limit?" — computed on encrypted data
What's happening: Using a different FHE scheme (TFHE, optimized for comparisons), the system checks whether the transfer amount complies with the configured limit. The check runs entirely on encrypted bits. Neither the transfer amount nor the threshold value is ever decrypted. The result itself is encrypted — only the authorized party can see it.
STEP 4 / 7WAITING
Transaction Fingerprint
SHA3-256 hash of the encrypted transaction data + compliance result
What's happening: A cryptographic fingerprint is computed over the encrypted transaction and the compliance result. This fingerprint uniquely identifies this specific transaction at this specific moment. It cannot be forged, and any change to the underlying data produces a completely different fingerprint.
STEP 5 / 7WAITING
Mint H33-74 Primitive
58-byte attestation primitive — the permanent cryptographic record
What's happening: The fingerprint is embedded into a 58-byte H33-74 primitive. This is the atomic unit of trustless verification in the H33 system. It contains: the computation type (here BitBondIssuance, 0x40), the SHA3-256 commitment, a timestamp, and a cryptographic nonce. 58 bytes. That's the entire persistent footprint.
STEP 6 / 7WAITING
Three-Family Post-Quantum Signing
ML-DSA-65 + FALCON-512 + SLH-DSA-SHA2-128f — three independent mathematical bets
What's happening: The H33-74 primitive design calls for three post-quantum signature algorithms, each based on a different mathematical hardness assumption (demo; not yet available in production). To forge this signature, an attacker would need to break lattice problems, NTRU lattice problems, AND stateless hash functions simultaneously. No known or theoretical quantum computer can do this.
STEP 7 / 7WAITING
Solana Mainnet Anchor RECORDED ANCHOR
H33-74 commitment anchored to Solana mainnet via memo instruction
What's happening: The SHA3-256 commitment of the recorded attestation (a BitBond issuance) was written to Solana mainnet via a memo instruction, and this page re-reads it from the chain on every load. Once anchored, the anchor records when this transaction attestation's commitment was written — without knowing anything about the transaction itself. The anchor is permanent and immutable.
Verification
The values below illustrate a production H33-74 attestation. Verify real H33-74 proofs and post-quantum signatures — offline — in the H33 Proof Lab.
Decrypt Transaction Data
The transaction metadata below is AES-256-GCM encrypted. Paste the decryption key to reveal the data. Wrong key = no data.
Encrypting...
YOUR DECRYPTION KEY:
HOW THIS WORKS IN PRODUCTION
This demo uses AES-256-GCM for browser efficiency. In production, H33 uses BFV Fully Homomorphic Encryption — the transaction data is encrypted with a lattice-based scheme that allows computation on the ciphertext without decryption. The key holder sees the data; the compute layer never does.
The attestation proves that the encrypted data was processed correctly (threshold checks, compliance gates) without ever decrypting it. The decryption key is held by the transaction originator or authorized party — not by H33, not by the compute infrastructure, not by any intermediary.
Three independent post-quantum signature families (ML-DSA, FALCON, SLH-DSA) are designed to sign the attestation. To forge it, an attacker would need to simultaneously break lattice problems, NTRU problems, AND stateless hash functions. No known or theoretical quantum computer can do this.
