zkPass

Summary

zkPass (founded 2022, Sydney) is one of the flagship "zkTLS" experiments: a protocol that turns any HTTPS website into an oracle for private data. A user runs the TransGate browser extension, logs into a site they already use (a bank, exchange, government portal, or social platform), and generates a zero-knowledge proof about the TLS session contents — "my balance exceeds X," "I am KYC'd on this exchange," "I hold this credential" — that can be verified on-chain, without the website's cooperation (no OAuth, no API keys) and without revealing the raw data. The mechanism combines a three-party TLS handshake (3P-TLS) among user, zkPass node, and data source with VOLE-based interactive zero-knowledge proofs, operating in a "hybrid mode" that switches between an MPC mode and a lighter proxy-witness mode. The project ran a pre-alpha testnet from July 2023 (200,000+ waitlist signups, 100,000+ proofs early on), raised ~$15M total including a $12.5M Series A closed May 2024 at a $100M token valuation, and by late 2024 reported 2M+ proofs across 70+ web data sources. Its ZKP token generated in December 2025 on Ethereum, BNB Chain, and Base (LayerZero OFT), with the token intended as settlement for proof execution, validator collateral, and governance. As of mid-2026 the protocol is live and integrated across major EVM chains; the experiment is ongoing.

Design (Mechanism)

• 3P-TLS handshake. A standard TLS session is extended to three parties: Prover (user), Verifier (a zkPass node), and the Data Source (any TLS server). Session keys are secret-shared between Prover and Verifier so that the Verifier can attest that responses genuinely came from the target server, while never seeing the plaintext of the user's data.
• Hybrid mode. In MPC mode, Prover and Verifier jointly act as the TLS client via secure two-party computation — stronger guarantees, heavier computation. In proxy mode, the Verifier sits as a passive proxy recording encrypted traffic between user and server — cheaper and more compatible with real-world network conditions. zkPass shipped MPC first and moved toward proxy-witness as the production default with MPC as fallback.
• VOLE-ZK / VOLEitH proofs. Instead of SNARKs (expensive proving, trusted setup), zkPass uses Vector Oblivious Linear Evaluation–based interactive ZK ("VOLE-in-the-Head") to prove statements about the decrypted response efficiently on consumer hardware, locally in the browser extension.
• Schemas. Community- and team-defined "schemas" specify, per website, which response fields are extracted and what predicate is proven (e.g., balance ≥ threshold). By 2024 there were 200+ schemas over 70+ verified data sources; the app later claimed 100+ supported sites.
• On-chain delivery. Proof results are delivered as attestations verifiable by smart contracts (and mintable as zkSBTs in early versions), consumable on Ethereum L2s and other EVM chains for sybil resistance, undercollateralized-credit signals, KYC gating, and airdrop eligibility.
• Token mechanism. ZKP (1B fixed supply) is the settlement medium for proof/verifier execution; validator nodes post ZKP as collateral; 48.5% of supply is allocated to community with 0% unlocked to team/investors at TGE.

Outcome

Ongoing. zkPass progressed from pre-alpha testnet (July 2023) to a production proof network with reported 2M+ proofs and 70+ data sources by October 2024, institutional backing (Sequoia China, OKX Ventures, Binance Labs seed; Animoca Brands, dao5, Flow Traders, Amber Group in the Series A), and a December 19, 2025 TGE with listings on Kraken, Bybit, KuCoin, Upbit and others. The token launch experienced airdrop-distribution friction and volatility, and the ZK-oracle category remains commercially unproven, but the protocol is live, multi-chain, and actively developed (2025 whitepaper repositions it around "verifiable data, behavior, and credit for humans and agents"). Too early for a final verdict; as an experiment in making Web2 data composable on-chain, it is among the furthest-deployed zkTLS attempts.

Why it worked

• No integration required from data sources. Because zkTLS attests to ordinary TLS sessions, zkPass sidestepped the fatal cold-start problem of earlier identity/oracle designs that needed issuers or APIs to cooperate. Every HTTPS site became a potential oracle on day one.
• Pragmatic cryptography. Choosing VOLE-based interactive ZK over SNARKs made in-browser proving fast enough for real users, and the hybrid proxy/MPC design traded some purity for compatibility with real network conditions — a deliberate engineering compromise that let the product actually ship.
• Rode strong demand-side narratives. Sybil resistance for airdrops, proof-of-reserves-style personal attestations, RWA/credit underwriting, and later AI-agent verification each supplied waves of users and integration partners.
• Credible capital and distribution. Backing from major crypto funds and exchange ecosystems gave it listings, integrations, and legitimacy in a crowded zkTLS field (Reclaim Protocol, Opacity, Pluto, TLSNotary lineage).

Limitations and criticisms

• Trust assumptions are softer than "zk" implies. Proxy mode requires trusting that the verifier node and the user aren't colluding and that traffic interception assumptions hold; MPC mode is stronger but costlier. Critics note production reliance on the proxy-witness model dilutes the trust-minimization pitch.
• Schema fragility. Proofs depend on per-website response formats; sites change HTML/APIs or deploy anti-bot measures at will, making the oracle surface inherently brittle and maintenance-heavy.
• Token-utility uncertainty. Fee settlement in ZKP and validator collateral are plausible but unproven sinks; the Dec 2025 launch saw airdrop congestion, community frustration, and price volatility.
• Attestations validate origin, not truth. zkPass proves what a website said, not what is true — a user with a compromised or complicit data source can still mint an attestation for false content.

Lessons

• Removing the issuer from the loop is the unlock for data oracles. The decade of failed "verified credentials" projects mostly died waiting for issuers; attesting to existing TLS sessions routes around them entirely.
• Cryptographic purity loses to shipping. VOLE-ZK over SNARKs and proxy-mode-by-default were "impure" choices that made the product usable; the projects that insisted on maximal trust minimization mostly stayed in research.
• A zkTLS proof is only as durable as the webpage it parses. Any mechanism built on scraping-with-proofs inherits scraping's brittleness; schema maintenance is a permanent operating cost, not a one-time integration.
• "Verified from source X" is not "true." Downstream protocols must still model the trustworthiness of the data source and the possibility of user-source collusion.

Redesign (EDITORIAL — hypothesis, not fact)

This section is editorial hypothesis, not established fact. A redesigned zkPass would confront the two weakest links directly. First, make the trust model legible and priced: let integrators choose per-attestation between proxy mode, MPC mode, and multi-verifier quorums, with the security tier stamped into the on-chain attestation and fees scaled accordingly — so a lending protocol can demand MPC-grade proofs while an airdrop accepts proxy-grade, instead of one opaque "verified" flag. Second, decentralize schema maintenance with skin in the game: schema authors stake ZKP and earn fees per proof, but get slashed when a schema is shown (via challenge proofs) to mis-parse or to accept spoofable endpoints — converting the brittle scraping surface into an incentivized, self-healing registry, similar to how oracle networks price data-feed reliability. Third, mitigate user-source collusion by favoring aggregate, time-series attestations (e.g., balance held across N sessions over M weeks, cross-corroborated from two independent sources) over single-snapshot proofs. Finally, the token would be more credible as pure fee-settlement-plus-collateral with burned protocol fees, rather than layering governance utility onto an infrastructure primitive whose users mostly never want to hold it.