Cowrie Research

zkpass

3 min read

zkPass

  • Name: zkPass
  • URL: https://docs.zkpass.org/overview/introduction
  • Category: zkTLS web-data attestation middleware / schema-driven proof protocol / proof-orchestration network
  • Summary: zkPass is schema-driven web-proof middleware. The interesting part is not the zkTLS label. It is the operator stack around schemas, allocator nodes, validator nodes, domain binding, and TransGate distribution.
  • What it does:
    • Frames itself as a decentralized oracle protocol that turns private HTTPS-accessed data into verifiable proofs without requiring OAuth APIs, API keys, or trusted intermediaries
    • Uses zkTLS built from 3P-TLS plus hybrid zero-knowledge techniques so users can prove claims about private web data while keeping the raw data local
    • Ships a developer flow around zkPass DevHub, where a project receives an appid and one or more schema IDs tied to a configured DApp domain
    • Uses the TransGate browser extension / mobile app as the client-side proving surface, with a JS SDK that launches proof sessions from a DApp
    • Has allocator nodes that return signed task metadata and validator nodes that join the 3P-TLS flow, verify the resulting proof, and sign the final result
    • Defines proofs through JSON schemas that specify the target website, intercepted API requests, extraction paths, assertions, and a required nullifier for uniqueness / sybil-resistance use cases
    • Supports optional wallet-address binding and both onchain and offchain verification flows for the returned result
    • Documents a DAO / token layer in which the Swiss-association-governed protocol uses ZKP for governance, settlement, validator collateral, fee burns, and buybacks
  • Key claims:
    • The core mechanism is not just prove a website fact with ZK. zkPass explicitly inserts allocator nodes, validator nodes, schemas, DevHub app/domain configuration, and TransGate distribution into the proof flow. Those are the real operational and governance surfaces.
    • The schema system is especially important. Developers choose the HTTPS endpoint, request interception rule, extracted response fields, assertion logic, and nullifier path. That means proof authorship is partly schema authorship, not just cryptography.
    • The docs make the proving workflow concrete: the SDK gets task information from an allocator node, passes it to TransGate, the user logs into the data source, TransGate detects the relevant API calls, then TransGate, the validator node, and the data source establish 3P-TLS before proof generation and validation.
    • The required nullifier is analytically valuable because zkPass treats uniqueness and anti-sybil use as first-class outputs. The docs say the nullifier is hashed with MPC-generated randomness inside the ZK circuit so the raw identifier is not disclosed to the validator.
    • The DevHub/project layer also matters. Schemas are project-scoped, domain-matched, and immutable after creation except for deletion. That means developer-platform governance quietly shapes which proofs exist and how safely they are deployed.
    • zkPass cleared the bar because it contributes a distinct web-proof comparison layer: more node-orchestrated and schema-platform-driven than a pure zkTLS primitive, but more reusable and lower-level than a single application-specific identity product.
  • Whitepaper: zkPass publishes a technical whitepaper in its docs; the strongest primary materials in this pass were the official introduction, whitepaper, JS-SDK / schema docs, and official GitHub materials collected in ../whitepapers/zkpass-primary-sources-2026-05-14.md.
  • Sources:

Internal linkages

Control surface

  • The leverage sits in schema authorship, allocator logic, validator selection, domain binding, and verifier defaults.

  • So treat zkPass as proof-orchestration middleware, not as a generic cryptography note.

  • Last reviewed: 2026-05-30 UTC

Graph View

Backlinks