H33 Digital SCIF

The SCIF Wallet · Three Canonical Screens

The consumer surface — the Digital SCIF wallet as a PWA. Every screen is the user-facing rendering of receipts and capabilities defined in the substrate. Three screens shown: Dashboard (entry point), Payment Authorization (Chase Mortgage as a real example), Document Distribution Matrix (estate succession UX). Detailed flow walkthrough at §40a.

Stylized representations · canonical PWA in production · final visual design renders in H33 copper + cream over obsidian phone chrome

Table of Contents

Executive Summary

H33 Digital SCIF is a post-quantum custodial platform built entirely in Rust with zero external cryptographic dependencies^*, presenting two coherent product surfaces from a single substrate.

Both surfaces share the same Rust crate, the same FHE engine, the same H33-74 attestation, the same key lifecycle, the same evidence chain, the same Root authority substrate, the same Q-Sign approval substrate, the same Authority Transfer substrate, and the same H33-Key secret-use substrate. The product is not two products — it is one substrate with two presentations.

Proof of Enforcement

Every operation traverses five gates. Each gate is independently attested. Each gate can fail closed. Each failure mode is named, gated by a different cryptographic primitive, and produces evidence.

Human Authority Model

Seven roles, cryptographically separated. Every institutional buyer needs to know exactly who can do what before signing anything. This is that table.

The Auditor / Regulator Story

This is Digital SCIF's single largest underplayed advantage. It is the strongest claim in the entire stack and it is framed here as a guarantee, not a feature.

What an auditor receives

• The full H33-74 evidence chain in CBOR + JSON (machine-readable, redactable, exportable)
• Policy snapshots at each decision point
• Signer identities bound to PQ public keys
• Self-contained verifier instructions — the receipt tells the auditor how to verify itself
• Per-jurisdiction retention policies
• Structured side-table records (SecretUseRecord, AuthorityDelegationRecord) so the auditor can re-derive every op_msg byte-for-byte and recompute the commitment hash

What the auditor does

Architecture — 5-Layer Custodial Model

Stacked guarantees, not alternatives. Every custodial operation traverses every layer in order.

Substrate Composition — Five Primitives

H33 Digital SCIF is built on five composable governance substrates. Each substrate independently verifies a different question. The platform's distinguishing property is that the five compose into a single externally-verifiable chain — no product surface depends on a private vocabulary.

The five substrates — one platform, one vocabulary

How the five compose in a single operation

An operator runs:  h33 key use openai-prod --env OPENAI_API_KEY -- curl https://api.openai.com/v1/models

  ┌─ H33-Key ─────────────────────────────────────────────────────────────────────────┐
  │  Terminal cert verifies (Stage 2)                                                  │
  │  H33KeyCapsule presented · passes 9-stage verify_capsule (Stage 3)                 │
  │  Handle store dispenses plaintext only after capsule + policy + root match (St 4) │
  │  SecretActivated 0x82 · SecretResolved 0x83 emitted                                │
  │  Child process exec'd via tokio::process::Command (NEVER sh -c, NEVER argv)        │
  │  After child.wait(): SecretUsed 0x84 emitted with exit_code + duration + argv[0]   │
  └────────────────────────────────────────────────────────────────────────────────────┘
                                            │
  ┌─ H33-74 ─────────────────────────────────┴─────────────────────────────────────────┐
  │  Every receipt: ML-DSA-65 detached signature over SHA3-256(substrate)              │
  │  Cache-pointer chain: compact[32..42] = predecessor.chain_hash()[..10]             │
  │  74-byte wire format: substrate(58) || compact[..16]                               │
  └────────────────────────────────────────────────────────────────────────────────────┘
                                            │
  ┌─ Root v0 ────────────────────────────────┴─────────────────────────────────────────┐
  │  Handle's root_hash binds to a Root artifact (origin or transition)                │
  │  Definition A walker (/root/lineage/:hash) terminates at h33-root:identity-origin  │
  │  authority_lineage_verified = AND of per-step h33_74 + qsign + scope + predecessor │
  └────────────────────────────────────────────────────────────────────────────────────┘
                                            │
  ┌─ Q-Sign / HATS ──────────────────────────┴─────────────────────────────────────────┐
  │  At Root inscription time (or transition): GovernanceBundle verified               │
  │  4-stage: HATS 20-check · envelope binding · ML-DSA-65 crypto · quorum threshold   │
  │  qsign_verified_at_emit recorded on the host receipt                               │
  └────────────────────────────────────────────────────────────────────────────────────┘
                                            │
  ┌─ Authority Transfer ─────────────────────┴─────────────────────────────────────────┐
  │  If a transition is in play: AuthorityDelegated 0x70 → Activated 0x71 → Transferred 0x72  │
  │  Predecessor invariant locked: Transferred MUST walk back through Delegated         │
  │  /key/handle/rebind moves the handle's authority anchor under the new chain         │
  └────────────────────────────────────────────────────────────────────────────────────┘

  Result: GET /key/use/:receipt_hash/verify  →  secret_use_verified: true
          7 gates each independently false-able; failure_reasons array enumerates any miss

Cryptographic Stack — Complete Inventory

7.1 · Post-Quantum (NIST-standardized)

7.2 · Fully Homomorphic Encryption

7.3 · Zero-Knowledge & ZK-related

7.4 · Classical / Hybrid

7.5 · Engineering guarantees (all modules)

• All secrets zeroized on drop via Rust ownership (the zeroize crate is pinned to 1.3.0 to coexist with Solana's pin; v0.1 hardens H33-Key buffers to use Zeroizing<Vec<u8>> explicitly)
• Constant-time operations — no timing side-channels
• Feature-gated compilation — server builds cannot include decrypt code paths
• Sanitized API errors — details in logs only, never exposed to API consumers
• Information-theoretic threshold security — k-1 shares reveal zero, mathematically (not by policy)
• Hard Q-Sign gates at every transition (identity recovery, guardian designate, authority transfer) — any envelope failure emits PolicyDenied 0x51 and refuses to advance the chain
• Type-static no-secret-leak guarantees — InspectResponse and SecretUseVerifyResponse have no secret field by struct definition; serializing them cannot leak plaintext

H33-74 Evidence Receipt — Wire Format

The 74-byte H33-74 receipt is the platform's universal evidence primitive. Every meaningful SCIF operation produces one. The format is open, documented here, and offline-verifiable against a published ML-DSA-65 public key.

8.1 · The 58-byte substrate header — visual layout

8.2 · The 42-byte compact receipt

┌─────────────────────────────────┬──────────────────────────┐
│       receipt_hash              │     cache_pointer        │
│  32 B = SHA3-256(signature)     │  10 B (predecessor[..10])│
└─────────────────────────────────┴──────────────────────────┘
   [0..32]                          [32..42]

8.3 · The 74-byte wire format (the X-H33-Receipt header)

substrate (58) + compact[..16] = 74 bytes. The remaining 26 bytes of compact stay internal to the chain. The 74-byte form is what ships on every HTTP response, what's anchored on Bitcoin (segment-level), and what auditors export.

8.4 · The full receipt structure (server-internal)

Receipt {
    event:     Event,            // u8 discriminant (§09)
    substrate: [u8; 58],
    compact:   [u8; 42],
    signature: Vec<u8>,          // ML-DSA-65 detached, ~3309 bytes
    pubkey:    Vec<u8>,          // ML-DSA-65 public key, ~1952 bytes
}

8.5 · Chain hash linkage

chain_hash(R) = SHA3-256(substrate || compact || signature)
predecessor(R_next).compact[32..42] = chain_hash(R)[..10]

Each successor's cache_pointer is the first 10 bytes of its predecessor's chain_hash. A verifier confirming chain membership re-derives chain_hash(R_i) from the receipt body and matches the prefix against R_(i+1).compact[32..42]. Any tampering breaks the prefix match.

8.6 · Segment closure & external anchoring (Sprint 3, optional)

• close_segment() finalizes the open segment; returns the chain_tip and a 32-byte op_return_payload = SHA-256(chain_tip || segment_id_le)
• External party submits the payload as a Bitcoin OP_RETURN, posts the txid back via POST /h33-74/anchor/confirm
• The segment now carries an immutable on-chain durability witness
• v0 ships unanchored; anchoring is operational, not capability — explicitly deprioritized as a development milestone

8.7 · External verifier protocol — three artifacts

1. The 74-byte H33-74 receipt (from X-H33-Receipt header or GET /h33-74/receipt/:hash)
2. The emitter's ML-DSA-65 public key (GET /h33-74/pubkey)
3. The structured op_msg record for this event type (from the event's verifier endpoint, e.g. GET /key/use/:hash/verify for SecretUsed)

From these three, the auditor independently re-builds the canonical op_msg, computes SHA3-256(op_msg), verifies the ML-DSA-65 signature over SHA3-256(substrate), compares the recomputed commitment to receipt.substrate[2..34], and walks the chain predecessor backwards. No live SCIF access is required.

Receipt Event Taxonomy — All 29 Events

The complete v2 event taxonomy. Discriminants are stable and hard-pinned by tests (all_event_discriminants_unique, authority_transfer_discriminants_locked) in the h33_74_receipt crate. Adding a new event reserves its discriminant; reordering existing ones is a compile-time error.

9.1 · Identity (0x01–0x02)

9.2 · Document (0x10–0x11)

9.3 · Consent (0x20–0x21)

9.4 · Beneficiary (0x30–0x31)

9.5 · Delegation (CKA, 0x40–0x41)

9.6 · Policy (0x50–0x51)

9.7 · Payment (0x60–0x61)

9.8 · Authority Transfer (0x70–0x74) NEW Sprint Authority-Transfer-0

9.9 · Secret Use Governance (H33-Key, 0x80–0x89)

Root v0 — Authority Lineage Substrate

Root v0 answers: "does this action still trace back to the human's original authority?" It is not a separate product; it is a lineage primitive consumed by every other substrate. Definition A aggregate verification is the formal model.

10.1 · The RootAuthorityArtifact (8 fields × 32 bytes = 256 bytes canonical)

RootAuthorityArtifact {
    root_origin_hash:           [u8; 32],   // stable identifier of the human-origin claim
    human_origin_receipt_hash:  [u8; 32],   // R#1 receipt; zero at origin itself
    authority_subject:          [u8; 32],   // pubkey holding authority at this point
    authority_scope:            [u8; 32],   // SHA3-256 of canonical scope label
    delegated_to:               [u8; 32],   // target principal for delegations; zero otherwise
    predecessor_authority_hash: [u8; 32],   // prior artifact's lineage_hash; zero at origin
    qsign_proof_hash:           [u8; 32],   // four-hash envelope commitment
    authority_lineage_hash:     [u8; 32],   // computed: SHA3 over all 7 prior fields
}

10.2 · Canonical scope labels

10.3 · POST /root/inscribe — origin-scope minimal inscription

Minimal Root inscription path for callers (e.g., H33-Key handles) that bind to a Root WITHOUT going through full identity-create / guardian-add / recovery-execute Solana CPI ceremonies. v0 guardrail: only h33-root:identity-origin scope is accepted. Transitions go through dedicated identity / authority handlers that enforce the full Soulbound + Q-Sign chain.

10.4 · GET /root/lineage/:receipt_hash — Definition A walker

Walks the chain backwards via predecessor_authority_hash, terminating at h33-root:identity-origin. For each step, the walker computes six independent booleans:

10.5 · Definition A aggregate verdict

authority_lineage_verified =
       terminated_at_origin
    ∧ root_origin_consistent
    ∧ ∀ step ∈ walk : step_aggregate_ok
verification_level = "aggregate_v0"

Q-Sign / HATS — Approval Substrate

Q-Sign answers: "does an approved governance bundle authorize this action?" The implementation is the HATS-as-Q-Sign adapter — Q-Sign is the vocabulary; HATS (a separate audited Rust crate) is the substrate. The adapter sits at every authority-transition call site.

11.1 · The four-stage verifier

11.2 · The four envelope hashes (what every transition request carries)

QSignProofSlot {
    qsign_proof_hash_hex:     String,   // bundle merkle root
    policy_id_hex:            String,   // SHA3 of the Policy node's payload.policy_hash string
    quorum_hash_hex:          String,   // canonical hash of sorted Authority node_ids
    replay_witness_hash_hex:  String,   // canonical hash of the ReplayWitness
}

11.3 · Call sites in v0 (all hard-gated)

• POST /identity/guardian/add · action_type h33.guardian.add
• POST /identity/recovery/execute · action_type h33.recovery.execute
• POST /authority/delegate · action_type h33.authority.delegate
• POST /authority/activate · action_type h33.authority.activate
• POST /authority/transfer · action_type h33.authority.transfer

At each site, an envelope failure emits a chain-bound PolicyDenied 0x51 with the deny stage in the op_msg tag. The chain records WHY refusal happened, not just THAT it happened.

H33-Key — Secret Use Governance

H33-Key v0 ships against the Use column of the credential market (Storage = 1Password / iCloud Keychain · Management = Vault / Doppler / Infisical · Use = H33-Key). Pair with whichever vault the customer already uses; H33-Key produces the signed proof of use. Do not market it as a vault — see Stage 8D narrative freeze.

12.1 · The five components

1. Terminal Certificate Registry — ed25519 self-signed certs · idempotent registration · algorithm-agnostic surface (cert.algorithm dispatches verify)
2. H33KeyCapsule — wrapper above CKA (does NOT modify h33-agent-token) · 9-stage verifier · CKA hash reference + capability bits + handle/policy/root/terminal bindings + ed25519 signature
3. HandleStore — in-memory plaintext custody · HashMap<[u8;32], StoredHandle> · v0 NOT persistent, NOT encrypted at rest, NOT a vault
4. Resolver + Use-Receipt Endpoint — emits SecretActivated/Resolved on dispense, SecretUsed only after child.wait()
5. Aggregate Verifier — GET /key/use/:receipt_hash/verify · re-derives op_msg from side-table · 7-gate aggregate_v0

12.2 · The 7-gate aggregate_v0 verifier

12.3 · CLI surface

h33 key terminal register
h33 key terminal show
h33 key store HANDLE --policy-id HEX --root-hash HEX [--mode env|stdin|file] [--owner OWNER]
h33 key inspect HANDLE
h33 key use HANDLE (--env VAR | --stdin | --file PLACEHOLDER) -- CMD [ARGS…]
h33 key verify RECEIPT_HASH

12.4 · Killer demo (locked 2026-06-16)

h33 key use openai-prod --env OPENAI_API_KEY -- curl https://api.openai.com/v1/models

• No secret in argv (the env var name is — OPENAI_API_KEY)
• No secret in parent shell env
• No secret in shell history
• No secret printed by the CLI
• SecretUsed 0x84 emitted only after curl exits (tokio::process::Command::wait returns)
• Aggregate verifier returns secret_use_verified: true (Stage 7 live proof captured 2026-06-16)

12.5 · What v0 explicitly is NOT

Authority Transfer — Fifth Substrate

Authority Transfer is the transition primitive. It generalizes a pattern that surfaced across six independent use cases — identity recovery, role offboarding, estate succession, agent ownership transfer, service-account migration, and secret rebinding — into one substrate. It became the fifth H33 primitive on 2026-06-16 after a six-question generic-substrate test resolved unanimously.

13.1 · The three canonical operations

13.1.1 · State machine visualization

13.2 · The predecessor invariant (locked 2026-06-16)

VALID:    identity-origin → authority-delegate → authority-transfer
VALID:    identity-origin → authority-delegate → authority-activate → authority-transfer
INVALID:  identity-origin → authority-transfer            (no prior delegation — REJECTED)
INVALID:  identity-origin → authority-activate            (activate without delegate)

The validator is validate_authority_predecessor_chain. The implementation walks back up to 32 hops via a caller-supplied lookup closure, rejecting any non-{delegate, activate} scope on the walk. Errors are MissingPriorDelegate or InvalidPredecessorScope, mapped to PolicyDenied 0x51 + HTTP 422 at every authority/* route.

13.3 · activation_required policy

At delegate time, the request carries activation_required: bool. SCIF persists it in the AuthorityDelegationRegistry side-table keyed by the delegate's authority_lineage_hash. At transfer time, if the policy demanded activation, the direct predecessor MUST be an AuthorityActivated (not the bare Delegate) — enforced beyond the chain-walk rule.

13.4 · Six consumers, one substrate

13.5 · POST /key/handle/rebind — first substrate consumer (Stage 3)

The H33-Key rebind endpoint is the v0 proof that Authority Transfer composes with another substrate without modifying it. The rebind enforces five gates (any failure → SecretDenied 0x88):

1. Handle exists and old_root_hash matches its metadata
2. AuthorityTransferred receipt exists and event is exactly 0x72
3. Root artifact at that receipt indexed, lineage_hash = new_root_hash, scope = authority-transfer
4. Transfer's predecessor chain walks back to reach old_root_hash (32-hop bounded walk)
5. Q-Sign was verified at the AuthorityTransferred emit-time

On success: handle metadata's root_hash updates, rotation_epoch bumps, SecretDelegated 0x86 emitted — chosen over SecretPolicyChanged 0x85 per the framing "this is not a policy edit; it is a secret-use authority delegation to a new root."

Identity & Biometric Authentication

14.1 · UPQ-ID — The Unified Identity Object

One biometric → one DID → three PQ key families. Soulbound on Solana (immutable per-owner PDA). Used across Bitcoin, Solana, Ethereum, FIDO2, OAuth, physical access. Format: DID:PQ.

14.2 · Client/Server FHE Split — The Load-Bearing Architecture

The product's hardest single guarantee. Type-system-enforced via Rust feature gates.

14.3 · Modalities — 4 active, fused

14.4 · Unified Biometric API

• Two modes: FHE-Only (single key holder) + Collective Authority (k-of-n threshold)
• LSH-based 1:N candidate reduction — sub-linear search across millions of templates
• Sharded user store — lock-free parallel operations
• Anti-spoofing liveness — face + voice
• Configurable match thresholds + bias-aware risk assessment

14.5 · Performance

Identity Trust Chain — Soulbound + Guardian + Recovery

The Identity Trust Chain answers "are you who you say you are?" across one principal's lifetime. Sprint 4B Phase 2 shipped 2026-06-15 with externally-verifiable end-to-end attestation of every state change. Estate Trust Chain (across principals) is documented in §22.

15.1 · The on-chain anchor — Soulbound Identity program

15.2 · The 9-step trust chain (Sprint 4B + 4C audits)

15.3 · Recovery flow — what's cryptographically gated today

1. Client constructs RecoveryExecuteRequest with: original_owner, new_owner, guardian_signatures[], qsign_proof (4-hash slot), root_artifact (scope=authority-recover), qsign_bundle (HATS JSON)
2. SCIF runs parse_root_input → rejects malformed Root
3. SCIF runs verify_qsign_envelope → 4-stage; any fail emits PolicyDenied 0x51 + 422
4. SCIF emits BeneficiaryExecuted 0x31, indexes Root artifact with qsign_verified_at_emit=true
5. Client submits Solana tx recover_identity; SCIF confirms on-chain owner field
6. On match: SCIF emits IdentityUpdated 0x02 bound to txid, slot, account_size, snapshot_hash
7. On mismatch (recovery landed but owner unexpected): SCIF emits PolicyDenied 0x51 + 422

Wallet & Transaction Operations

16.1 · Three-Family Signing

16.2 · Multi-Sig Wallet

• Configurable approval policies
• Corporate treasury, DAO governance, joint custody arrangements
• Quorum policies are themselves signed — cannot be modified without satisfying current quorum

16.3 · Biometric-Gated Operations

High-value wallet operations gated by FHE biometric verification: transaction signing, key export, recovery initiation all require encrypted biometric match.

16.4 · Consumer Wallet Surface (substrate-derived)

• Multi-chain (Solana, Bitcoin, Ethereum, Polygon, Base, Arbitrum)
• 74-byte H33-74 attestation per transaction
• Mining: H33 token, +2.4 H33/hr base rate, +50% referral multiplier, 8.4% APY staking
• Send / Receive / Swap / Stake action surface
• WASM in-browser live ML-DSA-65 keypair generation (1,952-byte public key, secret zeroized in WASM memory, server never saw the keys)
• Hardware wallet bridges (Ledger PQ firmware, optional)

DeFi Integration

DeFi access is mediated by the policy engine and the Q-Sign/HATS substrate. Every DeFi interaction emits H33-74 receipts so a regulator can later replay which protocol, which counterparty, which approval, and which authority chain authorized each interaction. v0 ships as guarded access; v1 layers programmatic strategy attestation.

17.1 · Policy-gated DEX swaps

• Counterparty allowlist (per-protocol, per-pool) · default-deny
• Per-swap value limits + daily aggregate caps + velocity controls
• Slippage policy ceiling — high-slippage swaps require dual-control
• Sandwich/MEV mitigation: private RPC routes (Flashbots, Eden, Jito) per chain
• Receipts: PaymentAuthorized 0x60 → on-chain settle → PaymentExecuted 0x61 with txid

17.2 · Lending & staking attestation

• Position open / collateralize / borrow / repay / withdraw — each as a distinct receipt-chained operation
• Liquidation risk monitoring with on-chain price oracle attestation
• Staking deposits, rewards claim, unstake — auditable yield trail
• Health-factor breaches trigger PolicyDenied with reason code (not silent refusal)

17.3 · Permissioned LP & vault interaction

• Liquidity provision restricted to allow-listed pools with audited contract addresses
• Vault deposit/withdraw signed with three-family signatures · vault strategy attested at deposit time
• Per-vault TVL caps prevent silent over-allocation

17.4 · DeFi Travel Rule + counterparty proof

• Each DeFi receipt binds the counterparty contract address + chain ID + protocol identifier
• Travel Rule (FATF) export bundle includes the chain-bound counterparty even when destination is a smart contract
• OFAC-aware denylist integration at the policy layer

17.5 · ZK-proven solvency & PoR

• Proof of Reserves via ZK-STARK over BFV-encrypted balance commitments
• Selective disclosure: prove ≥X without revealing exact reserves
• Periodic attestation publishable to auditors / customers

Payments Surface

Payments are the highest-volume H33-74 emission surface. Every authorization and every settlement produces a receipt. The chain is the auditor's primary surface.

18.1 · Supported rails

18.2 · Per-transaction guarantees

• Policy decision recorded before signing (PolicyApproved 0x50 or PolicyDenied 0x51)
• Three-family PQ signature (ML-DSA-65 + FALCON-512 + SLH-DSA)
• Counterparty bound in receipt op_msg — chain-of-counterparty replayable
• PaymentAuthorized 0x60 → on-chain broadcast → PaymentExecuted 0x61 with confirmed txid + block hash
• Failed broadcasts emit PolicyDenied with reason (not silent loss)

18.3 · Velocity, limits, and dual-control

• Per-tx max · daily aggregate · weekly rolling window · per-asset limit overrides
• Velocity breach → escalation (not silent denial)
• High-risk withdrawal: dual-control · 24-hour mandatory delay (configurable) · compliance reviewer sign-off
• Limit changes are policy-version-bound · cannot be silently raised

18.4 · Reconciliation export

• Daily / monthly statement bundles (CBOR + JSON)
• Per-asset opening balance · receipts list · closing balance · independently re-derivable
• Insurer-ready: every receipt independently verifiable against published ML-DSA-65 pubkey

International Settlement & Cross-Border

Cross-border payments and asset transfers carry the heaviest compliance load. Digital SCIF treats Travel Rule, sanctions screening, and counterparty identity as first-class receipt-bound primitives — not bolt-on log entries.

19.1 · FATF Travel Rule integration

• Per-transaction counterparty identity (originator + beneficiary) bound in receipt op_msg
• VASP-to-VASP envelope: TRP (Travel Rule Protocol) or TRISA-compatible bundle
• Recipient VASP identity verified against allowlist + public PQ-signed registry
• Travel Rule data exported as a CBOR sub-bundle within the H33-74 evidence pack
• Selective disclosure via ZK proofs — counterparty existence + jurisdiction provable without identity leak to third parties

19.2 · Sanctions / OFAC screening

• Counterparty address + entity name screened pre-authorization
• OFAC SDN list + per-jurisdiction sanctions lists · jurisdiction-of-operator + jurisdiction-of-counterparty both checked
• Match → PolicyDenied 0x51 with reason code; sealed evidence snapshot captured for later filings
• Fuzzy-match adjudication routes to Compliance Reviewer with policy-engine dual-control

19.3 · Cross-currency & FX

• FX rate sourced from policy-bound oracle set (configurable, signed price feeds)
• Spot, forward, and time-of-execution rates recorded — rate disputes resolvable on-chain
• Stablecoin routing for fiat-equivalent transfers (USDC, EURC, USDT)
• Multi-hop routing attested per hop

19.4 · Atomic cross-chain swaps

• HTLC with Dilithium pre-images — both legs PQ-signed
• Settlement finality evidence per chain (block depth + reorg-safety threshold)
• Failed second leg → refund attested + counterparty notified
• v1 adds threshold-MPC custody on bridge contracts to eliminate single-sig bridge risk

19.5 · Jurisdiction-aware policy

• Geographic restrictions at policy layer · gated by signer geolocation, counterparty jurisdiction, regulatory zone
• Per-jurisdiction retention policies on receipt export (data residency)
• EU GDPR data-minimization via ZK selective disclosure
• BSA / FinCEN / FCA / MAS / MAS Notice 626 compliance export profiles

Document Management & Archival

Documents are first-class custodial objects. Every document version, every consent grant, every disclosure is receipt-bound. The Document Trust Chain (Sprint 4A) provides the substrate; ArchiveSign, MedVault, Contracts, and PQ Messaging are surfaces above it.

20.1 · Contract Validation Flow (field-by-field, human-in-the-loop)

20.2 · Document operations supported

• Create, version (clause-level), share (per-counterparty PQ envelope), redact (ZK proof of redaction validity), archive (ArchiveSign batch), revoke access, transfer ownership
• Consent ledger: explicit ConsentGranted/Revoked receipts per data subject + purpose
• Templating: contract templates signed by template author; instantiation records template_hash for legal lineage

Document Trust Chain (Sprint 4A)

The Document Trust Chain answers "is this document the same one the author signed, who else has touched it, and who has consented to what?" Sprint 4A shipped the full lifecycle: create → version → consent grant → consent revoke → ownership transfer.

21.1 · Endpoints

21.2 · DocumentRecord structure

DocumentRecord {
    doc_id:                       String,
    receipt_hash:                 [u8; 32],     // host h33-74 receipt
    predecessor_receipt_hash:     Option<[u8; 32]>,
    versions:                     Vec<VersionEntry>,
    consents:                     Vec<ConsentEntry>,
}

ConsentEntry {
    receipt_hash:                 [u8; 32],
    revokes_receipt_hash:         Option<[u8; 32]>,  // points to the grant being revoked
}

21.3 · Verification — "is this consent live?"

1. Resolve the most-recent ConsentGranted for (subject, purpose) pair
2. Walk forward looking for ConsentRevoked whose revokes_receipt_hash targets that grant
3. If found: live consent = false (revoked)
4. If not found and (now < expiry): live consent = true
5. If not found and (now ≥ expiry): live consent = false (expired)

The chain replays this deterministically. A regulator does not trust the store; they walk the chain.

Wills, Estates & Succession

The Estate Trust Chain answers "if the principal dies tomorrow, can a third party independently prove the person receiving control is the person the principal explicitly authorized while alive?" Today: not fully. v0 ships the substrate; full estate end-to-end is the canonical Authority Transfer demo (§13).

22.1 · The Estate role distinct from Guardian

v0 conflates these in the BeneficiaryAdded/Executed events (0x30/0x31) which today carry the guardian-add semantics. The architectural correction is Authority Transfer (§13) — Beneficiary becomes a generic authority-delegate with succession conditions, Activate fires when dormancy + biometric incapacity proof is observed, Transfer rebinds assets.

22.2 · Patent-backed digital estate succession (current capability)

• 30-day life-validation intervals — principal must produce a biometric match every 30 days; missed intervals accrue
• Multi-modal biometric proof (4 modalities) at 99.8% confidence threshold
• 120-day dormancy detection activates succession
• 72-hour cooling-off on beneficiary changes
• Duress detection + geographic locks · medical emergency override
• Blockchain audit trail (Dilithium signed)

22.3 · Estate Activation business flow

22.4 · Key Escrow (Enterprise) — COMPLIANCE

• Multi-party escrow with Shamir reconstruction under threshold
• Court order and subpoena workflows
• Agent roles: Primary, Backup, External, Regulatory, Court-appointed
• Time-locked release · full audit trail

Recovery & Digital Estate Lifecycle

Three independent recovery paths. No mnemonics — purely cryptographic. Digital estate succession with biometric life validation.

23.1 · PQ Recovery Keys — REPLACES BIP-39

• 256-bit recovery keys split via Shamir across registered devices
• Each share encrypted under device's ML-KEM public key
• Recovery via k-of-n device threshold
• H33-74 attestation binds recovery configuration to device fingerprints

23.2 · Guardian Social Recovery — 3 INDEPENDENT PATHS

Guardian types: personal, hardware, institutional, self-custody, cloud. Time-locked delays prevent immediate compromise. Recovery history audit trail.

23.3 · Recovery Request flow

Privacy & Zero-Knowledge

Privacy is enforced at three layers: data never decrypts (FHE), assertions disclose minimum (ZK), interactions reveal counterparty only on policy match (selective consent). Each layer composes; none is a substitute.

24.1 · ZK proof suites

24.2 · Selective disclosure patterns

• Prove balance ≥ threshold without revealing balance
• Prove jurisdiction without revealing residence
• Prove counterparty allowlist membership without revealing counterparty
• Prove document integrity without revealing document contents
• Prove consent grant validity without revealing consent terms
• Prove role authorization without revealing role identity

24.3 · Privacy primitives composed

• FHE computation: results never decrypt server-side
• ZK proofs: assertions never reveal underlying secrets
• PQ encrypted messaging (§25): payloads never decrypt in transit
• Oblivious Transfer: receiver learns exactly one, sender cannot determine which
• Private Set Intersection (BFV-PSI): set membership without set disclosure

24.4 · Compliance × Privacy reconciliation

PQ Messaging & Chat

Forward-secret post-quantum messaging. Survives TLS compromise, survives intermediate-CA compromise, survives indefinite ciphertext capture (harvest-now-decrypt-later resistant by construction).

25.1 · Channel construction

• Ephemeral ML-KEM (Kyber) session keys with ratcheting (Double Ratchet over Kyber)
• ML-DSA-65 (Dilithium) signing of every message — non-repudiation
• Forward secrecy independent of TLS — inner-channel encryption survives outer transport failure
• Per-message replay protection via sequence numbers + nonce
• Optional FALCON-512 second-family signature for high-value channels

25.2 · 1:1, group, broadcast

• 1:1 chat — ratcheted forward secrecy · device-fanout per recipient · self-destruct timers
• Group chat (≤ 1000 members) — group ratchet · member add/remove via signed key transitions · transcript hash attestation
• Broadcast (1:N announcement) — sender-signed · receiver verifies independently · no group key custody

25.3 · Cross-organization & counterparty messaging

• VASP-to-VASP envelopes for Travel Rule data transmission
• Counterparty identity resolved against signed VASP registry
• Receipts: every counterparty message emits an attestation receipt (no silent transmission)
• Compliance review queue: high-risk messages auto-routed to reviewer

25.4 · Chat surface for consumer + institutional

• Consumer: 1:1 + group chat with disappearing messages, voice notes, file attachments (FHE-encrypted)
• Institutional: secure operator chat, compliance reviewer escalation channel, board-level emergency channel
• Healthcare (MedVault-bridged): clinician-to-patient channel with HIPAA-bound consent
• Legal: attorney-client privileged channel with court-order-bound disclosure (key escrow §22.4)

Encrypted Decision Engine

TFHE programmable bootstrapping enables Boolean-level decisions on encrypted data. Compliance checks, policy evaluation, and classification all run without decryption.

WiFi & Network Security

Post-quantum network access. WPA3-PQ for WiFi, IPSec-PQ for site-to-site tunnels, mTLS-PQ for service-to-service. All bound to the same UPQ-ID that authorizes wallet transactions and document access.

27.1 · WPA3-PQ — Post-Quantum WiFi authentication

• SAE (Simultaneous Authentication of Equals) handshake replaced with ML-KEM key encapsulation
• EAP-PQ method: client authenticates with ML-DSA-65 signature over a server-issued nonce
• Device identity bound to the UPQ-ID — same DID authorizing the wallet authorizes the network
• Per-session ephemeral keys derived via HKDF (SHA3-512) from the Kyber shared secret
• WiFi access event chained: a DeviceAuthorized receipt links to PaymentAuthorized when the device transacts

27.2 · IPSec-PQ — Site-to-site tunnels

• IKEv2 PQ extension: ML-KEM key exchange + ML-DSA peer authentication
• SA rekeying on policy-driven intervals · zero-downtime rotation
• Per-tunnel attestation: tunnel establishment emits an H33-74 receipt binding peer IDs + key versions
• Failover policy: secondary tunnel pre-negotiated; failover is attested, not silent

27.3 · mTLS-PQ — Service-to-service

• X.509 cert signed by hybrid CA (ML-DSA-65 + ECDSA during transition window)
• OCSP / CRL distribution with PQ-signed status
• Per-call attestation receipt for cross-service calls within a SCIF deployment
• Cert lifecycle: pending → active → overlap → retired (same state machine as key lifecycle §29)

27.4 · Network access control (NAC) policy

• Device must present valid UPQ-ID + recent biometric attestation (within policy window)
• Policy engine evaluates: device posture, jurisdiction, time-of-day, network segment
• Quarantine VLAN for failed posture · attested quarantine, not silent isolation
• Guest access via short-lived ephemeral DID with restricted policy bundle

27.5 · Why this matters

Agent Governance — Agent-008, CKA, PQ-Video

AI agents acting on behalf of humans (or other agents) are first-class principals. The substrate distinguishes what an agent did from why an agent was allowed to act. The chain answers both.

28.1 · CKA — Canonical Agent Capability Token

28.2 · Agent-008 — PQ AI Governance Infrastructure

Agent-008 is the runtime layer that takes a CKA, evaluates Q-Sign envelopes per action, walks Root lineage for authority, and emits H33-74 receipts. It is the system that turns "an agent did X" into "this agent was allowed to do X because: human → Root → Q-Sign policy → Delegation → Activation → Authority → action."

28.3 · The runtime moat statement

28.4 · The four runtime evaluators

28.5 · H33-PQ-Video — Provable Authority Meetings

Meetings are first-class authority events. Every participant (human or agent) holds a per-meeting delegated principal. Authority Map shows who is admitted, who can speak, who can approve. Authority Flow shows decisions made + their downstream commits. The meeting produces a receipt; the receipt walks back to the principals' Root chains.

• Provable Authority is the hero (not encryption — encryption is the floor)
• Three v1 capabilities: Who Joined / What Happened / What Was Authorized
• Per-viewer delegated principals (never session-wide keys)
• Pause Autonomous Authority — substrate-level capability under "Verify What Was Authorized"
• Meeting → Action Request → Approval → Execution flow with receipt at every step

28.6 · Agent runtime catalog (v1 LOCKED)

28.7 · Rogue agent defense

• Pause Autonomous Authority — instant chain-wide freeze of all agent actions of a specified class
• Authority Diff — compare what an agent was authorized to do vs. what it did
• Authority Replay — scrub through a session and watch authority decisions accumulate
• Genesis Receipt — the initial authority pack that started a session, referenced by every action receipt in it
• NAP (No Action Performed) — first-class proof that a required action did NOT happen (governance failure attestation)

Custody & Key Lifecycle

Split key authority across parties, geographies, or compliance domains. No single entity can sign, decrypt, or access key material alone.

29.1 · Shamir Secret Sharing — FOUNDATION

• Information-theoretic k-of-n threshold over GF(256)
• Splits master keys up to 64 KB
• Any k-1 shares reveal zero information — proven mathematically, not by policy
• SHA3-256 integrity checksum per share
• Constant-time verification · shares zeroized on drop

29.2 · Distributed Key Generation (DKG v2) — ADVANCED

• Asynchronous DKG with Feldman Verifiable Secret Sharing + Pedersen commitments
• Participants jointly generate shared key — no dealer, no single point of trust
• Proactive resharing (participant add/remove without exposing master)
• ML-KEM (Kyber) key agreement · AES-256-GCM encrypted share transport
• Complaint handling & dispute resolution

29.3 · MPC Signing Channel — PRODUCTION

• Post-quantum protected multi-party computation channel
• Session-based ephemeral key exchange: Kyber + Dilithium
• Forward-secret — TLS compromise does not expose signing keys
• Replay protection via sequence numbers
• Dilithium-authenticated sessions

29.4 · Threshold Signatures — PRODUCTION

• Threshold-controlled PQ signing workflow
• Shamir share-gated authorization with Dilithium final signatures
• No k-1 participants can forge a signature
• Constant-time field operations over Ed25519 scalar field (side-channel prevention)
• Partial signature aggregation · Shamir share verification

29.5 · Oblivious Transfer — PRIMITIVE

• 1-out-of-2 OT using Kyber KEM
• Sender offers two encrypted messages · receiver learns exactly one · sender cannot determine which
• Foundation for secure multi-party protocols · private matching · blind signing

29.6 · HD Key Derivation — CORE

• BIP-32-style hierarchical deterministic keys for PQ algorithms
• Replaces BIP-39 mnemonics with pure cryptography
• Path format: m/8333/0/'acct'/idx
• SHA3-512 derivation function
• Dilithium + Kyber child keys · master key zeroized on drop

29.7 · Automated Key Rotation — CORE

• Scheduled with configurable grace periods
• Key states: Pending → Active → Overlap → Retired
• Atomic rotation prevents transitional gaps
• Usage caps enforce hygiene: 1M encryptions, 10M signatures per key
• Pre-generation before activation · revocation for compromised keys

29.8 · KeyStore (Server-Side) — PRODUCTION

Automatic rotation scheduling · version tracking · usage limiting · sanitized error output (details in logs only, never exposed to API consumers).

29.9 · Encrypted Backup — PRODUCTION

• Versioned backups under ML-KEM (Kyber) + AES-256-GCM
• Optional Dilithium signatures
• Content types: master keys · wallet state · credentials · full system snapshots
• Per-jurisdiction retention bound to backup policy

Policy Engine & Authorization

30.1 · Role-Based Approvals — CORE

• Configurable m-of-n quorum per operation type
• Each approval role bound to a PQ identity, attested via H33-74
• Quorum policies themselves signed
• Approval escalation chains · time-of-day restrictions · dual-control for high-value
• Emergency freeze (instant, policy-driven)

30.2 · Transaction Limits — LIMITS

• Per-transaction max · daily aggregate ceiling · weekly rolling window
• Per-asset limit overrides
• Limits cryptographically bound to policy version — cannot be silently raised

30.3 · Velocity Controls — LIMITS

• Tx count limits per window (1hr, 24hr)
• Automatic throttle on threshold exceed
• Velocity breaches trigger escalation — not silent denial
• Cooldown periods after breach · separate velocity per asset class

30.4 · Asset Allowlists / Denylists — POLICY

• Explicit lists for asset types, contract addresses, counterparty wallets
• Default-deny for any asset not on approved list

30.5 · Jurisdiction Controls — POLICY

• Geographic restrictions at policy layer
• Gated by signer geolocation, counterparty jurisdiction, regulatory zone
• OFAC-aware denylist integration

Separation of Duties — Role × Capability Matrix

Explicit role separation enforced cryptographically. Each role is bound to a distinct PQ identity. No role can exceed its authority — enforced at the policy engine, not by convention.

Role definitions

• Operator — initiates transactions, manages day-to-day operations
• Approver — authorizes operations above threshold
• Recovery Agent — manages guardian networks, initiates recovery
• Compliance Reviewer — reviews evidence, signs off on policy changes
• Key-Share Holder — custodies Shamir shares, participates in MPC
• Auditor — read-only access to evidence chain, cannot initiate
• System Admin — infrastructure only · no key access · no tx authority

Incident Response & Emergency Controls — 9

Nine emergency controls covering every compromise scenario from key exposure to legal holds. Every emergency action is itself attested — no "off-the-record" interventions.

Custody Business Flows — 9 Specified Procedures

Concrete operational flows for the nine most critical custodial scenarios. Every step produces an H33-74 evidence receipt.

33.1 · New Account Creation

33.2 · Deposit Authorization

33.3 · Withdrawal Approval (Standard)

33.4 · High-Risk Withdrawal

33.5 · Recovery Request

33.6 · Court-Order Release

33.7 · Estate Activation

33.8 · Signer Rotation

33.9 · Breach Response

Compliance Mapping — 8 Frameworks

How custodial capabilities map to regulatory frameworks. Each row shows the H33 capability satisfying the compliance requirement.

Threat Model — "Designed Against"

Every architectural decision maps to a specific threat. The system is designed to survive each of these scenarios independently.

API Reference

Every public endpoint shipped or reserved in Digital SCIF v2. Implementations live in rust-service/api/src/routes/.

36.1 · Identity

36.2 · H33-74

36.3 · Root

36.4 · Authority Transfer

36.5 · H33-Key

36.6 · Document Trust Chain

36.7 · FHE / Biometric

36.8 · Threshold Custody · KEMs · Signatures

36.9 · Health & observability

Source Code Map — Rust Workspace

Digital SCIF is a Rust workspace. Each member crate has a single responsibility and a clean public API. Reviewers can audit each crate independently.

37.1 · Workspace members

37.2 · `api` crate modules

37.3 · CLI repo (separate workspace)

h33-cli-rs · the canonical Rust CLI (binary h33) · subcommands: signup, mint, mcp, status, audit, domains, detect, wrap, verify, scan, bitcoin, key, health. H33-Key surface lives under h33 key {terminal, store, inspect, use, verify}.

37.4 · Test counts (as of 2026-06-16)

• h33_74_receipt: 13/13 unit tests pass (incl. all_event_discriminants_unique covering 29 events + authority_transfer_discriminants_locked)
• api: 51/51 unit tests pass (incl. 8 chain-invariant tests · 10 Stage 6 verifier tests · 2 Q-Sign fixture self-tests · 1 full-chain rebind happy-path)
• Stage 7 live proof: secret_use_verified=true end-to-end against the binary on 2026-06-16

Asset & Protocol Support

Multi-chain, multi-asset custodial support. Three phases, explicitly demarcated.

Performance & Numeric Claims

Buyer Outcomes & Differentiation

40.1 · What makes Digital SCIF unlike anything in market

1. Server structurally cannot decrypt biometrics — not policy, not procedure, compile-time enforced via Rust feature gates. The decrypt code path does not exist in server binaries.
2. Three-family PQ signing on every transaction — forgery requires breaking MLWE, NTRU, and stateless hash functions simultaneously. No other custodian offers this triple-bet on a single op.
3. 74-byte self-verifying evidence on every operation — regulators verify offline, without H33 cooperation, without an API.
4. Five composable governance substrates (H33-74, Root, Q-Sign/HATS, H33-Key, Authority Transfer) — one consistent vocabulary across identity · payments · DeFi · documents · estate · messaging · WiFi · agents.
5. 18 custodial modules in one Rust crate, zero external crypto deps — auditable as a single artifact.
6. Identity, custody, recovery, estate, biometric, documents, messaging, wallet, network, agents — all from the same substrate. Competitor stacks bolt these together · H33 derives them from one cryptographic root.
7. k-1 shares reveal zero — mathematically, not by policy. Information-theoretic threshold security is a stronger guarantee than computational security; very few custodians ship it.
8. Patent-backed digital estate succession with cryptographic life validation. Wallet competitors do not address generational continuity at all.
9. Externally-verifiable per-use receipts for every credential dispensed (H33-Key) — first system in the credential-Use category.
10. Per-transition authority attestation (Authority Transfer) — generic across identity recovery, estate succession, agent ownership, and service-account rotation.

40.2 · Boardroom-grade headlines

40.3 · Buyer use cases

Consumer Application Surface (PWA)

The consumer wallet PWA is the user-facing presentation of the entire substrate. Every screen is a thin renderer of receipts and capabilities defined in earlier sections. This section enumerates the canonical screens, surfaces the receipt that backs each one, and connects them to the substrate calls.

Six screens · Auth Management · Home Network · Quantum Camera · Secure Chat · H33 Staking · Data Requests

40a.1 · Dashboard & AI Quick Actions

Single-screen entry point. AI-curated quick actions surface the most-likely-next operation (pay rent, sign contract, attest document, approve agent action). Every quick action is a one-tap shortcut to an authority-attested flow — the AI suggests; the substrate enforces.

• Per-user policy learns frequency + amount patterns within the policy ceiling (cannot raise policy)
• Suggestions audit-replayed: which suggestion was shown, which was taken, which was rejected
• Voice-activated quick actions gated by voice-modality biometric (FHE-encrypted)

40a.2 · AI-Powered Send

• Plain-language send: "send Mom $200 for groceries" → resolved to recipient (allowlist), amount, asset
• Confidence + sensitivity badges per inferred field
• User confirms or edits before signing
• Same three-family PQ signing path as any other transaction — AI is the keyboard, not the signer

40a.3 · AI Document Agents · NFT Document Agents

• Per-document AI agents that read, organize, and respond to specific document types (tax forms, mortgage, healthcare records, contracts)
• Agents are owned by the user as NFTs on the consumer chain — transferable, revocable, attestable
• Each agent acts under a CKA token with capability bits scoped to its document set
• Receipts: every read, classification, response emits a chain-bound attestation
• Marketplace: third-party agents (e.g., tax-prep agent) can be granted scoped access via Authority Transfer Delegate

40a.4 · Auth Management — Connected Websites & Services

• Replaces "Sign in with Google" / "Sign in with Apple" with "Sign in with H33" (FIDO2-compatible)
• Per-site capability bitmap (read profile · read email · post on behalf · request payment)
• Per-site receipt: every login emits a SignedMatchAssertion receipt — replayable across the user's device history
• Bulk-revoke + per-site freeze · capability transfer to a new device
• Compromised site triggers chain-wide alert (other users with that site connection see a warning)

40a.5 · Modern Linking — Cross-Device Authentication

• Two-device pairing without shared secret: device A generates ML-KEM ephemeral, device B encapsulates, both sign a pairing receipt
• QR-code-mediated handshake · NFC tap pairing · BLE-PQ pairing
• Pairing receipt names both devices, the pairing scope, and the capability transfer
• Lost-device handling: paired devices form a guardian set automatically (with explicit user opt-in)

40a.6 · Quantum Camera · Secure Document Ingestion

• On-device document capture with simultaneous biometric attestation (camera authenticates the captor before the capture)
• Page-by-page FHE encryption on-device · plaintext never crosses the boundary
• OCR + AI field extraction (per §20.1 contract validation flow) runs over FHE ciphertext where possible
• Document chain receipt at every capture: DocumentCreated 0x10 with device attestation + biometric assertion bound
• Tamper detection: any post-capture edit fails the canonical-hash check

40a.7 · Data Requests — The Inbox

• Bank statements, hospital records, legal documents, government notices arrive in a unified inbox
• Sender authenticates via Connected Websites binding; recipient verifies with one tap
• FHE-encrypted on arrival; only the user's device can decrypt
• Inbox receipts: DocumentCreated 0x10 with sender attestation + ConsentGranted 0x20 when user authorizes the sender's continued access
• Auto-categorization via AI Document Agents (§40a.3)

40a.8 · Bill Pay & Recurring Payments (Chase Mortgage example)

• Recurring authorization is a Q-Sign-bound policy: "approve up to $X to counterparty Y on day N each month"
• Policy itself signed; modification requires re-authorization
• Pre-pay attestation receipt 24 hours ahead — user can cancel before the on-chain commit
• Pay-day flow: PaymentAuthorized 0x60 → broadcast → PaymentExecuted 0x61
• Missed payment: PolicyDenied 0x51 with reason (insufficient balance, allowlist drift, velocity breach) — never silent
• Counterparty's billing statement arrives in the inbox (§40a.7), automatically matched to the payment receipt

40a.9 · Beneficiary Details · Document Distribution Matrix

• Per-asset, per-beneficiary distribution matrix: "100% house to spouse · 50/50 brokerage to children · medical records to executor"
• Each row in the matrix is its own delegation under Authority Transfer
• Document Distribution Matrix is the UX over §22.4 estate succession
• Each beneficiary's view shows only what they're entitled to (zero-knowledge against other beneficiaries' allocations)
• Cooling-off + dormancy from §22.2 surface as countdown UI

40a.10 · Home Network · Privacy Controls

• Home Network screen: WiFi (§27) + device authentication + per-device policy visible in one map
• Each device's last attestation + freshness state + auto-quarantine policy
• Guest access via short-lived ephemeral DID with restricted bundle
• Privacy Controls: per-counterparty ZK disclosure preferences · per-app data sharing scopes · audit timeline for who's seen what

40a.11 · H33 Staking & Mining

• Staking deposits emit StakeAuthorized + StakeExecuted receipt pair · validator chosen via policy
• 8.4% target APY (canonical) · auto-compound option · unstaking surfaces the lockup period
• Mining: H33 token reward at +2.4 H33/hr base rate · attestation activity earns it
• Receipts: every reward credit emits an attested entry — the user's yield is auditable as a chain

40a.12 · Invite & Earn — Referral Mechanics

• 2× rewards multiplier on referred users' attestation activity for 90 days
• Per-referral receipt: ReferralEstablished bound to the referrer + referree DIDs
• Anti-abuse: referrer's reward gated by referree's sustained attestation activity (not just signup)
• Multi-level cap (no MLM dynamic) · single-hop only

40a.13 · Settings, Help & Support

• Settings: theme, language, biometric preferences, notification scope, default chain, default asset, default modality
• Help & Support: in-context per-screen help · biometric-gated support chat (operator must verify identity before access)
• Account export: full chain-bound receipt bundle in CBOR + JSON · for migration or auditor handoff
• Compliance disclosures and version pinning surfaced at the bottom of Settings

Auth Model · Biometric-First Hybrid (Decision D)

Locked 2026-06-17. Every sensitive substrate call passes through a three-layer auth gate. Biometric proves the human, terminal certificate proves the device/session, Auth1 keeps the app session usable. Auth1 alone is never sufficient — it is the session shell, not the trust root.

40b.1 · The three layers

40b.2 · Wire shape · every sensitive request

POST /key/handle/resolve   (or any sensitive endpoint)
Headers:
  X-H33-Biometric-Session: <opaque session token issued by /auth/biometric/begin>
  X-H33-Terminal-Id:       <terminal_certificate_id>
  X-H33-Nonce:             <16-byte random hex>
  X-H33-Timestamp:         <unix-ms>
  X-H33-Signature:         <hex ed25519 over canonical message>
Body: { ... endpoint-specific JSON ... }

Canonical signed message:
  SHA3-256( method.utf8 || ":" || path.utf8 || ":" || body.bytes
         || ":" || nonce.hex || ":" || timestamp.ascii )

40b.3 · Verification order · backend

1. Timestamp freshness. abs(now − ts) ≤ 60s. Outside window → 401 + PolicyDenied 0x51.
2. Nonce uniqueness. Lookup in NonceReplayCache (TTL 5min, sized for peak QPS). Seen → 401 + PolicyDenied.
3. Biometric session. Lookup BiometricSessionRegistry. Must exist, not expired, not revoked, bound to X-H33-Terminal-Id. Any miss → 401 + PolicyDenied.
4. Terminal cert resolution. Lookup TerminalRegistry by id. Cert must be active. Resolved pubkey = trust anchor for next step.
5. Request signature. Verify ed25519 over the canonical signed message against the cert's pubkey. Mismatch → 401 + PolicyDenied.
6. Endpoint-specific gates. All previously-documented gates (Q-Sign envelope, predecessor invariant, capsule verify, policy/root match, etc.) continue to apply after the three auth layers pass.

40b.4 · Receipt op_msg extensions

The receipt wire format (74-byte H33-74) does NOT change. The structured side-tables (SecretUseRecord, AuthorityDelegationRecord, and the new BiometricSessionRecord) gain two fields:

• biometric_session_id · which biometric proof authorized this specific call
• user_id · the Auth1 / app-level subject (audit-attribution only · NOT a trust signal)

Verifiers re-derive these fields from the side-table; the recomputed op_msg commitment matches without breaking any prior receipts.

40b.5 · Auth1's role · honest scope

40b.6 · Why this composition

• A biometric proof alone names the human but not the device — a captured FHE assertion is replayable across devices.
• A terminal cert alone names the device but not the human — a stolen device acts unchecked.
• Together: every sensitive call proves this human, on this device, in this session, at this moment. Forging the chain requires breaking ML-DSA-65 (FHE assertion signature) and compromising the device's ed25519 private key and capturing a live biometric session token before it expires — three independent bets.
• Auth1 stays useful for everything that doesn't need that level of proof. The substrate gets the three-layer gate.

40b.7 · New endpoints

Honest Gaps — v0.1 Hardening + v1 Roadmap

What is documented here is the explicit gap list as of 2026-06-16. The product's defensibility depends on the honesty of this section. Marketing copy that conflicts with this section is wrong.

41.1 · v0.1 hardening blockers — small, mechanical, must close before public release

41.2 · v1 must-haves before general sellability

1. Persistent SecretUseRegistry — today in-memory only · SCIF restart loses verifiability of pre-restart receipts · DB-backed (SQLite or Postgres)
2. Vault adapters — 1Password · HashiCorp Vault · Doppler · AWS Secrets Manager pull-through · handle becomes pointer + attestation, NOT plaintext copy in SCIF · closes the "compromised SCIF = full dump" honest disclosure
3. Per-use Q-Sign approval — today Q-Sign verifies at Root inscribe time · v1 adds a fresh Q-Sign envelope at resolve time · closes the runtime moat ("why was THIS use authorized")
4. Windows + Linux CI parity — v0 tested on macOS only · cross-platform matrix
5. Persistent terminal-cert binding — today terminal_binding_required only checks registry membership · v1 should match against original storing terminal
6. Authority Transfer Stage 4 — full Estate-variant demo binary using qsign_test_fixture::build_passing_bundle with the qsign-fixtures feature enabled · proves end-to-end estate succession against the live binary
7. Bitcoin L2 anchoring — DEPRIORITIZED as a development milestone (assurance / compliance / marketing, not capability) · re-prioritize when a customer requires Tier-2 attestation
8. Estate substrate completion — full beneficiary-distinct-from-guardian flow (succession-execute scope, dormancy oracle, biometric incapacity gate) on top of Authority Transfer

41.3 · Out of scope (explicitly deferred or rejected)

• Clipboard interception for H33-Key — many products get this wrong and create false sense of security · deferred until product direction clearer
• OS keychain integration — nice feature, not category-defining · deferred
• Browser autofill / SSO bridge for H33-Key — out of scope · H33-Key targets API-key-for-CLI workflows
• SCIF as the primary vault — explicitly NOT positioned this way · pair with the customer's existing vault

41.4 · Marketing banned-phrases list (Stage 8D narrative freeze)

Canonical Specifications

These are the reconciled, authoritative values. They override any conflicting figures found in older marketing, slide decks, or design files.

Confidentiality & Contact

Contact

• Partner evaluation: support@h33.ai
• Schedule a demo: h33.ai/schedule-demo/
• Authoritative source URL: h33.ai/digital-scif/spec/
• Downloadable PDF: h33-digital-scif-spec.pdf