IQ Claim-Aware Routing

Every routing decision attested. Every computation proven. Every handoff verifiable.

H33 FHE-IQ Router v3.0

The Axis

"The axis is not 'TFHE vs not.' The axis is: what do you already know vs what must be computed."

CLASS 1 — INGRESS CONSTRAINTS

Always available. Caller-supplied. Hard filters.

CLASS 2 — EXTERNAL ATTESTATIONS

Signed objects from outside. Available before compute.

CLASS 3 — DERIVED TAGS

Computed metadata. Available only after derivation.

The Flow

Ingress + Attestations

Caller-supplied constraints (Class 1) and signed attestations (Class 2) enter together. Both available before any computation begins.

↓

STAGE 1 ROUTER

Hard filters + authorization checks + attestation hints. Determines initial routing path based on what is known at ingress time. No FHE required at this stage.

↓

A: Execute B: Execute + Derive C: Derive First

Path A: All constraints satisfied, proceed directly to execution engine.
Path B: Execute and derive additional tags for downstream consumers.
Path C: Missing derived tags required. Compute them first, then re-route via Stage 2.

↓

[Optional Stage 2 if C] → EXECUTION ENGINE

If Path C was taken: Stage 2 router re-evaluates with newly derived Class 3 tags. Then dispatches to the correct execution engine (FHE, ZKP, or plaintext pipeline).

↓

RESULT CLAIM

The execution engine produces a cryptographic result claim. This includes the computation output and a proof of correct execution.

↓

H33-74 SUBSTRATE

All six routing fields committed to a single 74-byte post-quantum substrate. 32 bytes on-chain, 42 in Cachee. Quantum-resistant. Permanently anchored to Bitcoin.

The Six-Field Rollup

H33-74 Substrate — 74 bytes total (32 on-chain + 42 Cachee)

1

ingress_hash

›

SHA3-256 of the original ingress payload. Proves exactly what data entered the system. Tamper-evident: any modification breaks the chain.

2

stage1_routing_hash

›

Hash of Stage 1 routing decision: which claims were evaluated, which constraints matched, which path (A/B/C) was selected. The "how it was routed" proof.

3

tag_bundle_hash

›

Hash of all derived Class 3 tags. These are computed metadata tags generated during processing. Proves what additional information was derived.

4

stage2_routing_hash

›

Hash of second-pass routing decision (if Path C was taken). Proves the re-routing after tag derivation was deterministic and correct.

5

dispatch_hash

›

Hash of the execution engine selection. Proves which specific engine (FHE pipeline, ZKP verifier, plaintext processor) was dispatched.

6

execution_root

›

Merkle root of execution results. Proves what actually happened: inputs, outputs, intermediate states. The final cryptographic commitment.

All six fields committed to a single 74-byte H33-74 substrate. Click any field to expand.

Authorization Model

"Data provenance without control integrity is insufficient."

ACTION_AUTHORIZED

Mandate covers this action

The caller's mandate explicitly authorizes this specific action type. Carries: mandate_id, action_type, scope constraints, expiration. Without this claim, the request never enters Stage 1.

DELEGATION_CHAIN_VERIFIED

Authority chain is valid

The delegation chain from principal to actor is complete and verified. Carries: chain of signer public keys, delegation depth, constraint narrowing at each level. Ensures no authority escalation.

SIGNATORY_VALID

Signer identity confirmed

The cryptographic identity of the signatory is verified against the authority registry. Carries: public key fingerprint, identity attestation, key validity window. PQ-signed (ML-DSA).

CUSTODIAN_APPROVED

Custodian has signed off

The custodian responsible for the underlying asset has approved this operation. Carries: custodian_id, asset_reference, approval_timestamp, conditions. Required for settlement.

LIMIT_WITHIN_BOUND

Within risk limits

The operation is within all applicable risk limits (position, notional, concentration, counterparty). Carries: limit_type, current_exposure, limit_value, headroom. Real-time check.

Bond Trade Example

1

Trader submits bond trade

SUBMITTED

2

ACTION_AUTHORIZED: mandate covers instrument

✓

3

LIMIT_WITHIN_BOUND: within risk limit

✓

4

DELEGATION_CHAIN_VERIFIED: authority from desk

✓

5

CUSTODIAN_APPROVED: settlement confirmed

✓

6

All four present → Stage 1 proceeds

ROUTED

Time Semantics

Every claim carries temporal bounds. Expired claims are not degraded — they are absent.

effective_at

Start

pricing_timestamp

T+0

market_context

Hours

valid_until

Hard cutoff

settlement_window

T+1/T+2

bond_maturity

30Y

"Expired is absent. Not degraded. Absent. Always."

Multi-Party DAG

Bond Trade Lifecycle — Four Parties, One Verifiable Chain

NODE 1

Trade Creation

Broker

→

NODE 2

Validation

Exchange

→

NODE 3

Clearing

Clearinghouse

→

NODE 4

Settlement

Custodian

Broker creates the trade with ingress constraints. H33-74 substrate commits: ingress_hash (trade terms), stage1_routing_hash (mandate check), execution_root (order created). The execution_root becomes the next node's ingress_hash.

Exchange validates the trade. ingress_hash = Node 1's execution_root. Adds: market validation, price reasonability check, crossing engine match. New H33-74 substrate for this node.

Clearinghouse performs clearing. ingress_hash = Node 2's execution_root. Adds: margin computation, netting, counterparty risk assessment. Own H33-74 substrate with CCP signature.

Custodian settles the trade. ingress_hash = Node 3's execution_root. Adds: DvP confirmation, asset movement, final settlement proof. Bitcoin-anchored H33-74 substrate. End of chain.

ingress_hash → execution_root references link nodes

"Any party can verify their node without accessing any other party's systems."

Dispute Model

ORIGINAL TRANSACTION

↓

DISPUTED

Workflow suspends. All downstream operations halt.

↓

SETTLED_DISPUTE

Resolution — select an outcome:

ORIGINAL STANDS

AMENDMENT

REVERSAL

"All correction events are themselves H33-74 committed. The correction chain is as permanent as the original."

Regulatory Profiles

Profiles are additive. When multiple profiles apply, stricter wins.

SEC_REPORTING

Trade reporting

Requires: full audit trail, T+1 reporting, position transparency, beneficial ownership disclosure. Maps to: ingress_hash, execution_root, tag_bundle_hash fields.

BASEL_III_RISK

Capital adequacy

Requires: risk-weighted asset computation, leverage ratio tracking, liquidity coverage ratio. Maps to: LIMIT_WITHIN_BOUND claim, real-time position aggregation.

GLBA_PRIVACY

Financial privacy

Requires: PII encryption at rest and in transit, access logging, data minimization. Maps to: FHE-encrypted ingress, H33-74 never contains PII in plaintext.

HIPAA

Health data

Requires: PHI encryption, access controls, audit logging, breach notification. Maps to: FHE computation over encrypted health records, ZKP verification without decryption.

SOLVENCY_II

Insurance capital

Requires: solvency capital requirement (SCR), minimum capital requirement (MCR), own risk assessment. Maps to: claim-aware routing with LIMIT_WITHIN_BOUND for insurance portfolios.

FEDNOW

Instant payments

Requires: real-time settlement finality, fraud detection, sanctions screening. Maps to: sub-second routing decisions, attestation-based fraud signals, OFAC claim checks.

BITBOND

Digital Treasury

Requires: 30-year custody chain, PQ-resistant signatures, annual attestation, ZK redemption proof. The crown jewel of H33 regulatory compliance.

BitBond Lifecycle

30-Year Digital Treasury Bond — Full DAG

ISSUANCE

Year 0

→

CUSTODY_INIT

Year 0

→

ANNUAL_ATTEST

Year 1

→

. . .

Years 2-29

→

MATURITY_TRIGGER

Year 30

→

ZK_REDEMPTION

Year 30

→

SETTLEMENT

Year 30

ISSUANCE — Treasury issues the digital bond. H33-74 substrate commits: CUSIP, face value, coupon rate, maturity date, initial holder. PQ-signed by issuing authority. Bitcoin-anchored at issuance.

CUSTODY_INIT — Custodian accepts the bond into custody. H33-74 references ISSUANCE execution_root. Custodian's PQ signature attests safekeeping. Begins the 30-year chain.

ANNUAL_ATTESTATION — Each year, the custodian produces a proof-of-custody attestation. H33-74 substrate chains from the previous year. Proves: bond still in custody, no disputes, coupon payments processed. 30 attestation nodes form the spine of the DAG.

MATURITY_TRIGGER — Automated trigger when the maturity date is reached. Confirms all 30 annual attestations are present. Enables the redemption workflow.

ZK_REDEMPTION — Zero-knowledge proof of valid redemption. Proves: valid CUSIP, not previously redeemed, no active disputes, maturity reached, valid holder. Reveals only: CUSIP, validity boolean, redemption amount. No trusted third party required.

SETTLEMENT — Final DvP settlement. Bond extinguished, principal returned. Final H33-74 substrate Bitcoin-anchored. The entire 30-year chain is now permanently verifiable by any party, forever.

ZK Redemption Proof

PROVES

Valid CUSIP in registry
Bond not previously redeemed
No active disputes on record
Maturity date has been reached
Holder is valid and authorized

REVEALS

CUSIP (public identifier)
Validity (boolean: yes/no)
Redemption amount

DOES NOT REVEAL

Holder identity
Other portfolio positions
Acquisition price or history
Intermediate custody transfers

"No trusted third party. No phone call. Mathematical proof."

What H33-74 Proves

Honest scope — what the substrate guarantees and what it does not

PROVES

Specific inputs entered the system
Specific routing decisions were made
Specific execution engine was selected
Specific result was produced
Cryptographic chain links all steps
Quantum-resistant signature integrity

DOES NOT PROVE

Tag derivation algorithm correctness
External attestation truthfulness
Routing decision optimality
Computation engine bug-freedom

Ingress constraints and external attestations drive initial routing. Derived tags tighten later routing and become reusable assets. H33-74 attests the ingress basis, routing decisions, and execution lineage — across single operations, multi-party workflow DAGs, and decade-scale custody chains alike.

Can you prove that the right person was authorized to act, on the right data, under the right policy, at the right time, with the right result, across every party in the workflow?

The answer is yes.

That is what banks buy.
That is what regulators require.
That is what BitBonds need.
That is what H33 provides.

Eric Beans · CEO · H33.ai, Inc.

support@h33.ai

PATENT PENDING