Research Mode — Not a verification path

In-Browser KYC Architecture

An exploration of what's possible when the entire KYC pipeline runs client-side. This is not production KYC and is not the path to a live credential — for that, use Sumsub verification.

Why this is not real KYC

A demo user can bypass this flow with a printed photo, a deepfake video, a forged ID, or by simply reusing a face across wallets. The browser cannot:

  • Detect MRZ/chip/hologram authenticity on a passport
  • Run iBeta L2 passive liveness (skin depth, Moiré, micro-movement)
  • Detect injection attacks (virtual cameras, OBS, emulators)
  • Dedup faces across an applicant database
  • Check government / PEP / sanctions lists

What it does demonstrate

  • Tesseract.js — real OCR of passport/ID fields in WebAssembly
  • face-api.js — 128-dim face descriptor + doc↔selfie match distance
  • Adaptive blink detection — eye aspect ratio over time with auto-calibrated baseline
  • Zero-data-to-server architecture — only a SHA-256 hash of extracted fields ever leaves the browser
  • Session resume — IndexedDB-backed stage persistence across tab close/reload

Useful as a template for privacy-first on-device flows (e.g., age attestation, country-of-residence proofs) where identity strength is not the threat model. We are not using it in the production HSK Passport KYC path.

Production path for HSK Passport:
  1. User opens /kyc
  2. Sumsub SDK runs (iBeta L2 liveness, document forensics, dedup)
  3. Sumsub issues GREEN webhook → backend auto-triggers issuer
  4. Credential minted on-chain, bound to the user's Semaphore commitment
  5. User proves eligibility to any dApp via zero-knowledge proof