H33
Live Production Replay

Run the Proof.
Six stages. One click.

Step through the exact chain that produced bundle d9adcfb0-e0bc-426b-8725-fc12d555692b on June 2, 2026. Every value below is real — captured from the actual production response. Anyone can verify the bundle URL at the end.

Ready to run
Identity → Authority → Replay → Receipt → Anchor → Bundle. Six stages, played in 6 seconds.

This is a faithful replay of the real production response — every commitment, every authority ID, every PQ signature byte is the exact data that came back from api.h33.ai. The bundle URL at the end is live: GET it now and you'll see the same anchored receipt.

1
Identity
Auth1 EdDSA Bearer

The customer signed in to auth.h33.ai via the production OTP flow. Auth1 minted a fresh EdDSA-signed JWT with claims tied to the canonical principal.

# JWT header alg = EdDSA typ = JWT kid = kid-eddsa-prod-active-2026-06-01-d31134fbc177 # JWT claims sub = princ_customer_9 iss = https://auth.h33.ai aud = substrate-receipts jti = jti-1780359511-cf79e5f189cb41fd iat = 1780359511 (2026-06-02 00:18:31 UTC) exp = 1780360411 (15-min TTL)

What this means: the Bearer is asymmetric (EdDSA). Anyone with the public key in the JWKS can verify it. The sub claim canonicalizes to the principal H33 will look up.

2
Authority lookup
JwksValidator + map_subject

V101 forwarded the Bearer to api.h33.ai/api/v1/h33-auth/v101-bundle-issue. JwksValidator verified the signature against the JWKS it fetches from Auth1.

# JWKS fetch (cached, refreshed every TTL/2) GET https://auth.h33.ai/.well-known/jwks.json → matched kid=kid-eddsa-prod-active-…d31134fbc177 # signature verification EdDSA.verify(jwt_signing_input, sig, pubkey) → true # principal canonicalization map_subject("princ_customer_9") → princ_customer_9

What this means: the Bearer is real — signed by Auth1's production key. The principal naming is canonical (no email-only identity, no tenant-name leakage).

3
Replay
replay_until(now) over canonical_auth_events

The canonical event log was replayed forward to now. Two signed events: a policy registration and a grant. Both signed offline with production PQ keys.

# events fetched from canonical_auth_events table [ { kind: policy_register, policy_id: pol_v101_exporter_v1, registered_by: princ_root_v101_44962d9b-…, signature: [148 hex] }, { kind: grant, authority_id: auth_44962d9b-…_v101_export, granted_by: princ_root_v101_44962d9b-…, granted_to: princ_customer_9, scope: ["export_content_bundle"], policy_basis: pol_v101_exporter_v1, signature: [148 hex] } ] # replay_until(now) → snapshot active_grants: [ { authority_id: auth_44962d9b-…_v101_export, granted_to: princ_customer_9, granted_by: princ_root_v101_44962d9b-… } ] verdict: Valid

What this means: the authority is not "stored." It is reconstructed from signed events. Anyone with the same events and the same public keys produces the same active-grants snapshot. Bit-identical. Every time.

4
Policy evaluation
pctl_* require_capability

The grant's policy_basis was looked up and asked whether export_content_bundle is allowed. Yes. Decision: issue receipt.

require_capability( active_grants, principal=princ_customer_9, capability=export_content_bundle ) → EnforcementOutcome::Allowed { authority_id: auth_44962d9b-…_v101_export, policy_basis: pol_v101_exporter_v1, principal: princ_customer_9 }

What this means: the receipt has a real grant behind it and a real policy justifying it. Both are traceable to signed canonical events. The decision is not a flag — it's a derivation.

5
Anchor
H33SubstrateAnchorSink (74-byte H33-74)

The receipt was canonicalized to JSON, SHA3-256 hashed, and anchored with H33's three-PQ-key signer. The 74-byte H33-74 receipt is the anchor — no external chain required.

# commitment = SHA3-256(canonical-JSON(issued_receipt)) commitment = ff770fc838fde707d91f35248946d6928b0a3a999dbd28a2906ce4f0274745e7 # three independent PQ signatures over the commitment ML-DSA-65 → [Dilithium signature] FALCON-512 → [FALCON signature] SLH-DSA-SHA2-128f → [SPHINCS+ signature] # 42-byte CompactReceipt = SHA3-256(domain || commitment || pks || sigs) CompactReceipt = 016fb294cb7ddf8073700a2cd13531a352da28068b4921c05839b82b8633547fdd0000019e85bb875107 # 74-byte tx_reference = commitment || CompactReceipt tx_reference = ff770fc838fde707…0000019e85bb875107 (148 hex chars) chain = h33-substrate-v1

What this means: the anchor is signed by three independent post-quantum families. Forgery requires breaking all three simultaneously. H33's own primitive — no Polygon, no Ethereum, no Solana, no testnet faucet, no per-anchor gas.

6
Bundle
V101 manifest persisted

V101 embedded the anchored receipt into the customer's content bundle, persisted to Netlify Blobs, and returned the bundle ID.

bundle_id = d9adcfb0-e0bc-426b-8725-fc12d555692b creator_uuid = 44962d9b-25f5-5622-bd9a-98d5580bb8a2 h33_74_receipt.status = anchored anchor_ref.chain = h33-substrate-v1 created_at = 2026-06-02T00:28:40.068Z # Bundle is live, publicly retrievable: GET https://app.v101.ai/v101/bundle/d9adcfb0-e0bc-426b-8725-fc12d555692b

What this means: the bundle is real and retrievable RIGHT NOW. Open the URL above in another tab. The receipt you see there is the receipt this demo just walked you through.

Proof Complete

That's the chain. Every arrow real.

No synthetic step. No mocked identity. No simulated replay. Real Bearer from Auth1. Real authority grant in the canonical event log. Real H33-74 anchor. Real V101 bundle, retrievable right now.

Fetch the bundle → Read the full report Download PDF