# Get Started ## Welcome to the zkPass Documentation Library #### New Here? Start with [What is zkPass](https://medium.com/zkpass/reintroducing-zkpass-an-identity-infrastructure-for-the-decentralized-society-based-on-mpc-zkp-4023683c718e)
IntroductionOverview of the fundamental principles, and methodologies of zkPass./pages/rKPHavTViuhoMxZLClIW
Use CasesPotential use cases that can be built on top of zkPass./pages/IuBRWffEAWACZtoDlNJ0
User GuidesGeneral instructions for users to attest anything on zkPass ecosystem apps./pages/sT03x0LJ94zjGz9poKHf
Developer GuidesA comprehensive tutorial for developers on how to leverage zkPass tech./pages/Nso4mL9jTbbC4agIpVwy
*This page is currently undergoing updates. If you need assistance with any missing information, please reach out to us via or*[ *join our community*](https://discord.gg/zkpass)*.* # User Guidelines To ensure a smooth and secure experience when using applications integrated with the zkPass TransGate-SDK, please refer to the following platform-specific instructions and recommendations. ## 🖥️ Desktop (Windows / macOS) **Recommended Setup:** * **Browser**: Latest version of **Google Chrome** or **Brave** * **Wallet**: [MetaMask](https://metamask.io/download/) browser extension (ensure it is installed, unlocked, and connected) ::: warning When you’re setting up a wallet, be sure to: ✅ Download and install only the latest version from their official source. ✅ Back up and keep your recovery phrases safe. ❌ Never share your recovery phrases with anyone, under any circumstances. ::: **Usage Instructions:** **Option1: Install the** [**TransGate**](https://chrome.google.com/webstore/detail/zkpass-transgate/afkoofjocpbclhnldmmaphappihehpma?utm_source=ext_sidebar\&hl) **on Google Extension Store** ::: warning Please kindly note that **DON’T** install any **Transgate Extensions** obtained from third-party channels. This measure ensures that all installed extensions have undergone proper vetting and are up to our standards. Stick to [**official link** ](https://chrome.google.com/webstore/detail/zkpass-transgate/afkoofjocpbclhnldmmaphappihehpma?utm_source=ext_sidebar\&hl)and protect your personal accounts securely. :::
::: tip **IMPORTANT!** Please refrain from installing extensions from third-party sources. We cannot take responsibility for any problems that may occur as a result of installing such extensions. Stick to zkPass official link and trusted sources for a secure browsing experience. ::: 1. Open the application link in your browser. 2. When prompted, approve the wallet connection via MetaMask. 3. Grant permissions for pop-ups and cross-site cookies (if disabled, verification flow may be blocked). 4. Log in the data source like usual, zkPass verification will run in-browser; please **do not close the tab** during the process. ::: warning **Notes:** * **Ad blockers or privacy extensions** may interfere with wallet communication. Disable them temporarily if issues occur. * Refresh the page if any UI components fail to load after connecting. ::: **Option2: Scan the QR Code and finish the process on mobile. 👇** ## 📱 iOS (iPhone) **✅ Instant Access via App Clip (No App Installation Required)** zkPass SDK is fully supported through Apple’s **App Clip** experience, offering a seamless and secure verification process with no installation needed. **Instructions:** 1. Open the zkPass-integrated dApp link in **Safari** or scan the associated **QR code**. 2. An App Clip card will appear — tap **“Open”** to launch the zkPass verification flow. 3. You will be guided through wallet connection and data verification within the App Clip environment. 4. Complete the process and return to the main dApp. No persistent app or background services will remain. **Requirements:** * iOS 14.3 or later * Safari or camera access (for QR codes) * Ensure App Clips are enabled under iOS Settings → App Clips ::: warning **Notes:** * Wallet connection will be handled in-session. MetaMask or WalletConnect will be triggered as needed. * All processes are sandboxed and privacy-preserving per Apple’s App Clip policies. ::: ## 📱 Android Devices Required: Install [TransGate App](https://play.google.com/store/search?q=transgate\&c=apps) from Google Play Store On Android, zkPass SDK operates via a native client—**TransGate**—to ensure secure communication and proof generation. **✅ Recommended Method: Chrome Browser + MetaMask Mobile App** 1. Open the application link in Chrome or another Chromium-based browser. 2. Upon wallet connection request, select **MetaMask** or via WalletConnect. 3. Approve all requests in MetaMask and return to the original browser tab to complete verification. **⚠️ MetaMask In-App Browser (Android):** * Due to system-level restrictions, MetaMask’s in-app browser **does not fully support dApp redirects** or advanced authentication features. * Use a standalone browser for better stability. ::: warning **The TransGate Android app currently supports Android 12 and above.**\ If your device isn’t compatible, using the Mise + TransGate extension is the recommended alternative below: ::: 1. **Open Mise Browser**\ Download Mise from if you haven't already. 2. **Go to the Extension Page**\ Open this link in Mise:\ 👉 [TransGate on Chrome Web Store](https://chromewebstore.google.com/detail/zkpass-transgate/afkoofjocpbclhnldmmaphappihehpma) 3. **Click "Add to Chrome"**\ Confirm the prompt and wait for the installation to finish. 4. **Verify Installation**\ After installation, you should see the TransGate icon in the top-right corner of your browser. Visit any zkPass-supported page to start using it. ::: danger ***Important Reminder:*** to ensure the efficient use of computational and gas resources, it is advisable not to use multiple addresses to attest the same schema with the same account. Doing so will overwrite previous attestations, resulting in unnecessary resource consumption without yielding additional rewards. ::: # VRS Verifiable Reputation Score (VRS): A Coverage-Penalized Multi-Source Reputation Scoring Framework ### Purpose & Vision The **Verifiable Reputation Score (VRS)** was first introduced as a proof-based mechanism to recognize authenticity, contribution, and engagement across the zkPass ecosystem.\ It quantifies how complete and credible your digital identity is across multiple verified data sources, while preserving privacy through zero-knowledge proofs.\ Higher scores grant greater access and priority in ecosystem participation, ensuring that credibility and genuine contribution are rewarded alongside timing. ### Quick Start Access the VRS module at [portal.zkpass.org](https://portal.zkpass.org/), where users can connect wallets, verify data sources, and view their computed Verifiable Reputation Score in real time. #### **What you get** A personal VRS ranging from 0 to 100 determines your $ZKP allocation priority on Kaito Capital Launchpad. Users with higher scores receive preferential access to allocations under the campaign rules. #### What you need 1. A wallet such as [MetaMask](https://metamask.io/download/). 2. TransGate on your device.\ • Desktop Chrome installs the [TransGate extension](https://chrome.google.com/webstore/detail/zkpass-transgate/afkoofjocpbclhnldmmaphappihehpma?utm_source=ext_sidebar\&hl).\ • iOS uses TransGate via app-clip. **No need to download any apps.**\ • Android installs the [TransGate app](https://play.google.com/store/search?q=transgate\&c=apps) from Google Play. 3. A few eligible accounts to verify such as Binance, LinkedIn, GitHub, Duolingo, or Kaito Yap. **We recommend using the desktop web version for the smoothest experience.** #### How to verify on desktop web 1. Install the[ TransGate Chrome extension](https://chrome.google.com/webstore/detail/zkpass-transgate/afkoofjocpbclhnldmmaphappihehpma?utm_source=ext_sidebar\&hl). 2. Open the [zkPass Portal page](https://portal.zkpass.org/). 3. Connect your X account → Pick a source and select Verify → A new tab opens the source site → Sign in as usual. 4. Click Start in the popup, a zero-knowledge proof generates locally within seconds. Your VRS updates automatically. No gas fee is required. #### How to verify on mobile iOS 1. Open the [zkPass Portal page](https://portal.zkpass.org/) in the in-app browser flow. 2. Connect your X account and sign in to each source when prompted and tap Start. 3. Return to see the Verified status and updated VRS. Android 1. Install TransGate from [Google Play.](https://play.google.com/store/apps/details?id=com.zkpass.transgate\&hl=en\&pli=1) 2. Open the [zkPass Portal page](https://portal.zkpass.org/) in any wallet. 3. Connect your X account, sign in to a source, tap Start, then return to view the updated VRS. ::: tip #### Privacy and security Proofs are generated locally. Raw personal data does not leave your device. Verifiers receive only cryptographic attestations. ::: ### **Core Principal** VRS isn’t about popularity, wealth, or social ranking.\ It’s about **proof density** - how many aspects of your digital footprint have been independently verified, and how consistent they are. * A single Binance KYC attestation may prove you’re a real person. * A LinkedIn or GitHub profile shows professional authenticity. * A Duolingo streak or Kaito YAP credential reflects learning or contribution. Together, these form your **verifiable identity fabric**.\ The more complete and trustworthy that fabric becomes, the higher your VRS. #### **Conceptual Design** The VRS is derived from zkPass’s open-source *Coverage-Penalized Multi-Source Reputation Framework*, designed to fairly evaluate users based on both **what they’ve proven** and **what they’ve yet to prove**. It consists of five layers: | Layer | Purpose | What It Does | | ---------------------- | ----------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | Feature Normalization | Handle raw metrics (e.g., followers, balances, account age) |

Map heterogeneous data to 0–1 range using log scale, SoftClip, and Boolean mapping

A Coverage-Penalized Multi-Sour…

| | Per-Source Aggregation | Combine features within one source | Weighted sum based on feature importance | | Cross-Source Weighting | Aggregate scores from multiple sources | Assign global weights (e.g., KYC > Social) without re-normalizing missing sources | | Weighted Coverage | Compute how complete your proofs are | Evaluate coverage ratio across all expected sources | | Nonlinear Penalty | Apply soft discount for missing data | Use exponent α > 1 to intensify incompleteness penalty | #### **Mathematical Formulation** Let ***S***i​ be the score of source i, and ***W***i​ its global weight.\ Let ***A*** be the set of sources a user has verified. $$ (1) Raw Aggregation:Rraw=∑i∈AWiSi $$ $$ (2) Coverage Ratio:C=∑i∈AWi∑iWi $$ $$ (3) Final Score with Penalty:VRS=100×Rraw×Cα $$ Where α>1 controls how aggressively incomplete coverage reduces your score.\ Example: with C=0.8,α=1.5, only 83.7 % of the value is retained #### **Score Interpretation** | Score | Meaning | Typical Profile | | ------ | ------------------------- | -------------------------------------- | | 0–30 | Limited Proof | Only 1–2 basic verifications | | 30–60 | Partial Identity | Some key proofs (KYC + social account) | | 60–80 | Verified User | Multiple dimensions covered | | 80–90 | High Credibility | Strong proofs with minor gaps | | 90–100 | Fully Verifiable Identity | Complete and consistent proof set | #### **Examples**
Connected ProofsCoverage Ratio CApprox. VRS
Twitter + Duolingo0.4≈ 45
Binance KYC + LinkedIn0.6≈ 70
Binance + OKX + LinkedIn + GitHub0.8≈ 85
Binance + OKX + LinkedIn + GitHub + Duolingo1.0≈ 95–100
#### **Properties** * **Boundedness:** All scores strictly within \[0, 100]. * **Monotonicity:** Adding new proofs or improving quality never lowers VRS. * **Weighted Fairness:** High-impact sources (KYC, verified identity) carry greater influence. * **Coverage Sensitivity:** Missing major sources penalized more than minor ones. * **Nonlinear Incentivization:** Penalty strength tuned by α to motivate completeness. * **Interpretability:** Every layer (feature → source → aggregate → coverage) is auditable. * **Extensibility:** Supports temporal decay, confidence weighting, or residual mixing without breaking consistency. #### **How to Increase Your VRS** 1. **Connect More Core Proofs** - Verify across financial, social, and skill dimensions. 2. **Maintain Account Quality** - Older, active, verified accounts score higher. 3. **Diversify Your Sources** - Cover both Web2 and Web3 identities. 4. **Stay Consistent** - VRS updates as your proof ecosystem evolves. #### Algorithmic Implementation (Pseudocode) ```python def compute_vrs(sources, alpha=1.5): """ sources: list of dicts with fields {weight, score, provided} """ total_weight = sum(s["weight"] for s in sources) provided = [s for s in sources if s["provided"]] coverage = sum(s["weight"] for s in provided) / total_weight quality = sum(s["weight"] * s["score"] for s in provided) vrs = 100 * quality * (coverage ** alpha) return round(vrs, 2) ``` #### **Open Framework & Future Extensions** The VRS framework is open for developers and projects to integrate.\ Future modules may include: * **Temporal Decay:** recent proofs weighted higher. * **Confidence Scores:** sources with cryptographic attestations weighted more. * **Federated Aggregation:** cross-domain proof composition without data sharing. By aligning economic incentives with verifiable identity strength, VRS lays the foundation for the **Proof Economy** - where reputation becomes a liquid, portable, and provable asset. #### Open Access & Disclaimer The Verifiable Reputation Score (VRS) framework is open and transparent by design.\ All algorithms, weight parameters, and pseudocode are publicly auditable and available for developers to reference or extend.\ The open-source implementation is maintained on GitHub:\ 👉 ::: tip All calculations are performed client-side; no personal or raw data leaves the user’s device.\ zkPass does not store, collect, or process any private information related to VRS computation.\ The framework is intended for informational and research purposes and should not be interpreted as a financial or investment rating. ::: # Introduction What is zkPass and what makes it stand out ### What is zkPass zkPass is a decentralized oracle protocol that transforms private internet data into verifiable proofs on-chain. Built on **zkTLS** — a novel integration of 3P-TLS and Hybrid-ZK cryptography — zkPass enables users and applications to prove facts derived from any HTTPS website without requiring OAuth, API keys, or trusted intermediaries. Through zkPass, individuals can selectively prove attributes across a wide range of data domains, including: * **Legal identity** (passport, driver’s license, national ID) * **Financial records** (account balances, transaction history, credit scores) * **Healthcare information** (medical records, prescriptions, genetic data) * **Social and behavioral data** (social media accounts, activity proofs) * **Professional and educational background** (employment history, diplomas, certifications) * **Digital activity and assets** (gaming accounts, loyalty programs, real-world assets) All proofs are generated locally in the user’s browser or device, ensuring that raw personal data is never exposed or transmitted. These verifiable proofs can be integrated into a broad spectrum of use cases spanning **AI, DePIN, digital identity (DID), DeFi lending, governance, compliance, and beyond**. ### Why zkPass zkPass introduces a new verification paradigm that addresses the limitations of existing identity and data solutions: 1. **Privacy-Preserving**\ Sensitive user data never leaves the device. Proofs reveal only the attributes required for verification. 2. **Verifiable Integrity**\ zkTLS extends the standard TLS protocol into a three-party model, ensuring the provenance and authenticity of private data. 3. **Universal Compatibility**\ Works with any HTTPS website, without requiring OAuth APIs, commercial licenses, or custom integrations. 4. **Anti-Cheating**\ Template-based verification ensures that client requests and server responses cannot be manipulated. Users cannot falsify achievements or credentials. 5. **Efficient Proof Generation**\ Powered by the **VOLE-in-the-Head (VOLEitH)** algorithm, zkPass enables millisecond-level proof generation directly on local devices, producing proofs that remain publicly verifiable. 6. **Trustless Attestations**\ Decentralized MPC nodes verify data integrity before a proof is accepted, guaranteeing that zkSBTs and attestations cannot be forged. ### Public vs. Private Data zkPass is designed to bridge the gap between **publicly accessible information** and **private, user-controlled data**: * **Public Data**: Information already open and accessible, such as census statistics, weather data, or government-published records. While useful for transparency, this data typically lacks individual-level granularity and is not privacy-sensitive. * **Private Data**: Personally identifiable or sensitive information that belongs to individuals or organizations, such as identity documents, bank records, medical histories, or proprietary business data. Private data is subject to strict legal protections and requires cryptographic guarantees before it can be shared or validated. zkPass provides the cryptographic framework for turning private data into **privacy-preserving proofs of authenticity**, allowing both public and private data to become part of a verifiable, interoperable digital ecosystem. # Technical Overview Introducing Hybrid mode of zkTLS oracle protocol v2.0 This document describes the zkPass oracle protocol from a technical perspective. It presents the underlying cryptographic components and specifies the building blocks used to construct the zkPass protocol. The zkPass protocol is meticulously designed to serve as a private data oracle, leveraging Vector Oblivious Linear Evaluation (VOLE) to create efficient commitments, commonly referred to as VOLE-Based Zero-Knowledge Proofs (VOLE-ZK). Specifically, beyond the use of SoftSpokenOT for Oblivious Transfer (OT), the security integrity of the zkPass protocol is intimately tied to the robustness of the VOLE-in-the-Head (VOLEitH) technique. zkPass operates in a Hybrid Mode, which combines Proxy Mode and MPC Mode, allowing the protocol to adapt to various network conditions and server restrictions without compromising performance or security. This design ensures flexibility in data-sharing scenarios, whether a server supports direct client requests or has stricter security policies. ## Overview While Transport Layer Security (TLS) provides secure access to private data, it doesn't allow users to prove to third parties that the data genuinely came from a specific website. Existing solutions either require unwanted trust assumptions or server modifications, effectively locking users' data at its source. The zkPass protocol addresses this issue by extending TLS into a Three-party TLS (3P-TLS) to prevent cheating and protect privacy, enabling secure data sharing without needing assistance or permission from the data holder. The zkPass protocol involves three entities: the Prover (**P**), the Verifier (**V**), and the DataSource (TLS Server as **S**). Departing from conventional methods, **P** utilizes their access token to directly pinpoint and extract their data from **S**. **P** then generates a Zero-Knowledge Proof (ZKP) for the **V**'s inspection. This procedure ensures that **V** remains oblivious to the **P**'s personal data. To actualize this architecture, we integrate **3P-TLS, MPC**, and **Non-Interactive Zero Knowledge (NIZK)** technologies. We have designed and implemented the zkPass protocol in two modes: 1. **Proxy Mode**: In this mode, **P** communicates with **S** through **V** as a proxy. 2. **MPC Mode**: In this mode, both **P** and **V** act as a client to communicates with **S**. These two modes collectively form **Hybrid Mode**, providing zkPass with the flexibility to operate efficiently across various scenarios. Typically, the zkPass protocol operates efficiently in Proxy Mode. However, a small number of TLS servers do not support this mode, meaning they block the same account's requests originating from different IP addresses. In such cases, our protocol switches to operate in MPC Mode. ## Proxy Mode In Proxy Mode, we propose having **V** act as a proxy between **P** and **S**. In this setup, **P** communicates with **S** through **V**, which allows **V** to record the traffic for later verification. The modified protocol flow is designed to maintain security while improving efficiency. ### Flow and Security Properties The protocol flow is as follows: 1. Three-Party Handshake: **P**, **V**, and **S** engage in a 3P-TLS handshake. This handshake establishes cryptographic parameters and ensures mutual authentication among the parties. 2. Prover's Key Share Commitment: After the handshake, **P** commits to her key share $$K\_p$$. This commitment prevents **P** from altering her key share later in the protocol. **P** must commit to her key share $$K\_p$$​ before learning the complete session key $$K$$. This commitment binds **P** to her key share, ensuring she cannot manipulate the session to produce fraudulent proofs later on. 3. Verifier Reveals Key Share: **V** reveals his key share $$K\_v$$ ​ to **P**. With both key shares, **P** computes the full session key $$K=K\_p+K\_v$$. 4. Session Continuation: **P** uses the session key $$K$$ to continue the TLS session with **S**. **V**, acting as a proxy, records all traffic between **P** and **S**. 5. Proof Generation: After the session concludes, **P** proves statements about the recorded session to **V.** To verify server identity, during the three-party handshake, **V** can verify **S**'s identity by checking the server's signature over a fresh nonce, as per standard TLS procedures. Verifier integrity and privacy are maintained because, under the assumption that TLS is secure, a malicious **V** cannot compromise the integrity and privacy of the TLS session between **P** and **S**. Ensuring Prover integrity requires certain network assumptions. **V** must maintain a reliable connection to **S** throughout the session and ensure that the **P** cannot tamper with the messages exchanged between **V** and **S** such as those executed through BGP hijacking. Since attacks like BGP are difficult to execute in practice and are already mitigated by ICP and CSP, these network assumptions are generally acceptable and can be considered negligible in practical scenarios. The Proxy Mode in the zkPass protocol enhances efficiency and performance by simplifying the communication flow and eliminating the need for intensive cryptographic computations after the handshake phase. Since no complex cryptographic operations are required during the rest of the session, the protocol becomes faster and more efficient due to the reduced cryptographic workload. While this approach is more universal, it introduces an additional trust assumption for the proxy and requires not only a ZK solution that’s affordable for the client, but also special magic tricks to bypass the data source’s WAF. ### VOLEitH Protocol VOLEitH is the most suitable and client affordable ZKP Protocol for authorizing TLS. We have implemented the protocol using SoftSpokenOT\[ROY22], VOLE-ZK\[YSWW21] and Fiat-Shamir transform\[FS87]. #### VOLE In order to construct the zkPass protocol, we introduce the VOLEitH to create an interactive argument system. This system is then made non-interactive using the Fiat-Shamir transform and its security is proven within the Random Oracle Model (ROM). zkPass uses VOLE correlations over a finite field $$F\_{2^k}$$ , to use as a form of linearly homomorphic commitment scheme. A VOLE correlation of length is defined by a random global key $$Δ ∈ F\_{2^k}$$ , a set of random bits $$u\_i ∈ F\_{2^k}$$, random VOLE tags $$v\_i ∈ F\_{2^k}$$ and VOLE keys $$q\_i ∈ F\_{2^k}$$ such that: $$ q\_i = u\_i \* \Delta + v\_i \quad for \space i = 0,...,\ell-1. $$ The values $$u\_i$$ and $$v\_i$$ should be known only to **P**, while $$q\_i$$ and $$∆$$ should be given to **V**. A VOLE correlation can be seen as committing **P** to the random bits $$u\_i$$ via a linearly homomorphic commitment scheme. The scheme is hiding, because the random $$v\_i$$ mask $$u\_i$$ in the **V**'s values $$q\_i$$, and the scheme is binding, because opening to a different value $$u^′\_i$$ requires **P** to come up with a tag $$q^′\_i = u^′\_i ∗ Δ + v^′\_i$$ but then **P** would have successfully guessed $$∆ = (v^′\_i − v\_i)/(u^′\_i − u\_i)$$, which can only happen with probability $$2^{−k}$$. A VOLE correlation can be created with a secure two-party protocol, in zkPass protocol, however, since we want to obtain ZKP that are publicly verifiable, we instead use the VOLEitH technique \[BBD+23]. Here, **P** first generates its values $$u\_i$$ , $$v\_i$$ and commits to them using a special type of VOLE commitment. The commitment is set up such that **V** can later send to **P** the random key $$∆$$, after which, **P** can send an opening that allows **V** to learn its $$q\_i$$ values, such that equation holds for $$∆$$, and nothing more. It is important that $$∆$$ is only given to **P** after running the main steps of the ZKP, since as soon as $$∆$$ is known, the binding property of the homomorphic commitments is trivially broken. #### VOLEitH Commitment The main building block of our VOLEitH approach is the technique of committing to a vector of N pseudo-random seeds by deriving them from a tree of length-doubling PRGs. This is also known as the GGM construction, which builds a puncturable PRF from a PRG \[GGM84, KPTZ13,BW13, BGI14]. We model this as an all-but-one vector commitment scheme, where **P** commits to N seeds by sending a single hash value, and can later open N − 1 of them with only $$O(logN)$$ communication. To open all-but-one of the seeds, say all except index $$sd\_j$$ , **P** takes the siblings of all nodes on the path from the root to leaf $$j$$ (excluding the root node) and sends these to **V**, together with the commitment $$com\_j$$ . **V** can then reconstruct every $$sd\_i$$ for $$i \ne j$$ using the sibling nodes, and also has enough information to compute the hash value $$h$$ and check the original commitment. Then we start converting vector commitments to VOLE, to obtain our desired VOLE commitments, **P** starts by committing to τ all-but-one vector commitments. After send the vector commitments, the next step is to convert each vector commitment into a length-$$l$$, small-field VOLE correlation in $$F\_{2^k}$$ , This involves first expanding each of the seeds $$sd\_0, . . . , sd\_{N−1}$$ (committed in the vector commitment) using a PRG, to obtain $$N$$ strings $$r\_0, . . . , r\_{N−1} ∈ {0,1}^l$$, and then computing in $$F\_{2^k}$$: $$ u=\sum\_{i=0}^{N-1}r\_i, v=\sum\_{i=0}^{N-1}i\*r\_i $$ where $$i$$ is encoded as an element of $$F\_{2^k}$$. To see how this can be used to get a VOLE correlation, consider a **V** who later learns seeds $$sd\_i$$ for all $$i \ne j$$, for some index $$j∈ {0, . . . , N − 1}$$ (viewed as an $$F\_{2^k}$$ element). **V** can compute: $$ q=\sum\_{i=0}^{N-1}(j-i)\*r\_i = j^\*\*u-v $$ After doing this for each of the vector commitments, **P** has $$l$$ small and independent VOLE correlations. Denote these as $$u\_i$$，$$V\_i$$ for $$i = 0, . . . , τ − 1$$, where we now view $$V\_i$$ as a matrix in $${0, 1}^{l∗k}$$ , instead of a vector in $$F\_{2^k}$$ . **V** will eventually learn ($$Δ\_i ,Q\_i$$) such that: $$ Q\_i = V\_i + (\delta\_0\*u\_i...\delta\_{k-1}\*u\_i) $$ where $$δ\_0, ..., δ\_{k−1}$$ is the bit decomposition of $$∆$$. After this **P** must send correction values so that the VOLEs can be fixed to use the same $$u$$ value. Finally we make a VOLE Consistency Check to ensure that all $$u$$ values are corrected in right ways. #### VOLEitH Proof System The VOLE-ZK is an interactive ZKP in the VOLE-hybrid model. It is based on the Line-Point Zero-Knowledge Paradigm\[DIO21]. For the zkPass protocol, we use the QuickSilver protocol to prove boolean circuits satisfaction. As QuickSilver is an interactive proof system, it is described here as a protocol executed between two parties: **P** and **V**. And we will convert it into the NIZK eventually. We have VOLE Commitments at last step, **P** first get $$χ\_i$$ from Fiat-Shamir transformation and then **P** calculates the $$∑ u\_i$$ ∗ $$χ\_i$$ and $$∑ v\_i$$ ∗ $$χ\_i$$ for all the inputs and gates in circuit, and later get $$Δ$$ from Fiat-Shamir then open all the vector commits and $$∑ u\_i$$ ∗ $$χ\_i$$ , $$∑ v\_i$$ ∗ $$χ\_i$$ , to **V**, **V** reconstructs the GGM Trees to obtain VOLE instances and calculate $$∑ q\_i$$ ∗ $$χ\_i$$ then check: $$ \sum q\_i\*\chi\_i = \sum u\_i\*\chi\_i \* \Delta + \sum v\_i\*\chi\_i $$ If the equation equal then circuit satisfied. At this point, we have successfully completed all protocol implementations. ### Why VOLEitH ZK systems like SNARKs are less suitable for authorizing TLS data because they involve intensive cryptographic computations, such as large-scale exponentiations and complex pairing operations. These operations require substantial computational resources and memory, leading to time-consuming proof generation that is often unaffordable for clients. Additionally, SNARKs typically require a trusted setup phase, which introduces potential security risks. While they may be acceptable for very small data sizes, they are inefficient and impractical for the typical data sizes found in TLS communications. In contrast, VOLE-ZKs are much more efficient. They naturally handle the linear computations, enabling fast and low-overhead, which makes them more suitable for authorizing TLS data. They avoid the need for a trusted setup and do not require large memory or extensive calculations for proof generation, making them affordable for clients. However, VOLE-ZK proofs are interactive, necessitating the verifier's continuous online presence and potentially introducing risks of collusion. To overcome these challenges, the zkPass protocol employs the VOLEitH technique, transforming the VOLE-ZK protocol into a non-interactive form. This ensures swift and efficient proof generation directly in the browser and device, addressing the limitations of both traditional SNARKs and VOLE-ZKs. By doing so, zkPass combines the efficiency of VOLE-ZK proofs with the convenience of non-interactivity, making it a practical and secure solution for authorizing TLS data. ## MPC Mode In MPC Mode, we have implemented the protocol using a hybrid approach that combines ZKP and MPC technologies for 3P-TLS. **P** and **V** work together as a single client to establish secure communication with **S**. They achieve this through a series of stages based on the elliptic curve Diffie-Hellman (ECDH) protocol, enhanced with MPC and OT techniques. ### Three-Party Handshake The first stage of the protocol is a three-party handshake between **P**, **V**, and **S**, where they work together to generate the pre-master key. **P** and **V** each receive a share of this key using Oblivious Linear Evaluation (OLE) based Multiplicative-to-Additive (MtA) or Additive-to-Multiplicative (AtM) schemes, which support additive homomorphism. The pre-master key is divided, with **P** and **V** each getting one half, while **S** retains the full key. To ensure authenticity and prevent the client from impersonating fake websites, after the client and server exchange greetings, the server provides its certificate. During the key exchange phase, the server also signs the public key with its private key from the certificate. This allows **V**, within the client, to verify the certificate and signature, confirming the server's identity and establishing trust in the data source. The second stage of the protocol is key derivation, where **P** and **V** work together using Garbled Circuit (GC) to generate two session keys from the pre-master key: the encryption key (enc\_key) for data protection and the message authentication code key (mac\_key) for data integrity. Notably, **V** only holds a share of the mac\_key and has no access to the enc\_key, ensuring that **V** cannot view **P**’s private information. **P** also holds a share of the mac\_key, giving access to identity-related data but without the ability to tamper with it. Any tampering can be detected by verifying the authenticity of messages using the mac\_key. The MPC algorithm in zkPass has been significantly optimized in several areas, including communication time, hash functions for the Garbler and Evaluator, OT operations, and memory copying. These improvements have increased efficiency by more than threefold. A new AES128 proof method has also been introduced, reducing the number of blocks by 300 times and speeding up Garbler/Evaluator execution by tenfold. zkPass uses Silent OT, minimizing offline network communication during OT generation. For GC, zkPass implements Three Halves Make a Whole and Stacked GC, which reduces the size of the Garbled Tables, leading to less communication and faster execution. Overall, these optimizations have greatly reduced the runtime of the entire MPC process, making zkPass much more efficient. ### ZKP In the final stage of the zkPass protocol, the client creates a ZKP for public verification. After the 3P-TLS phase, the prover obtains the complete data and uses the VOLEitH process to generate a proof. Since this step is similar to the process used in proxy mode, we won’t go into the details here. ### Why Not Prioritize MPC Mode The performance overhead of MPC Mode is significant, mainly due to the truth table (TT) in GC. Every block of application data must be encrypted using a TT, which greatly increases both computational and bandwidth requirements. For a single TLS session, there's a fixed cost of 20MB, plus 8MB per 1KB of outgoing data and 32KB per 1KB of incoming data. For a typical 1KB request and 100KB response, the prover would need to upload around 32MB, making this approach impractical for regular use. Additionally, MPC Mode isn't necessarily more secure than Proxy Mode because it still relies on a "trusted notary", similar to a proxy. A malicious notary could cache session data and collude with a compromised client. Since the server's decrypted key is hidden for privacy, external verification is impossible, meaning collusion or manipulation could go unnoticed. While MPC mode reduces some trust assumptions, it doesn't fully eliminate them, so it isn't inherently more secure. Given these issues, while MPC Mode provides some cryptographic advantages and may be useful for small requests, its high performance overhead and limited security benefits make it no better than a well-designed and decentralized proxy. Its resource demands and impracticality for everyday use restrict its real-world application. Therefore, we only reserve this mode as a backup for TLS servers that block requests from the same account when coming from different IP addresses. ## Summary The zkPass protocol distinguishes itself by combining advanced cryptographic techniques to achieve secure, efficient, and privacy-preserving data sharing. By extending TLS into a three-party protocol and integrating VOLEitH for Non-Interactive Zero-Knowledge (NIZK) proofs, zkPass effectively addresses both security and performance challenges. Its **Hybrid Mode**, which seamlessly switches between **Proxy Mode** and **MPC Mode**, allows the protocol to adapt to various network environments and server policies without compromising efficiency or security. Proxy Mode ensures high performance with minimal cryptographic overhead, while MPC Mode takes over when certain servers block requests from multiple IP addresses, maintaining privacy and security. The use of VOLEitH further enhances efficiency by avoiding the heavy computational and memory demands of traditional cryptographic systems like SNARKs. Optimized cryptographic computations and communication flows make zkPass highly scalable, ensuring that the protocol remains practical for real-world applications without sacrificing security or speed. # Technical Whitepaper Updated: May 22, 2023 Read the [PDF version](https://docsend.com/view/5wdg66beu7m95jf3) here ## Prelude This whitepaper is tailored to technically proficient readers interested in integrating zkPass into their development stacks and who want to understand this technology’s reasoning and strategic decisions. It aims to provide insight into the conceptual frameworks that drive zkPass, making it valuable for developers involved in component creation, tool development, or building businesses around zkPass within the broader ecosystem. ## Abstract In this whitepaper, we introduce the zkPass protocol, an innovative cryptographic structure leveraging the power of three-party Transport Layer Security (TLS), Multi-Party Computation (MPC), and Interactive Zero-Knowledge Proof (IZK). The ubiquity of HTTPS has facilitated users to access private data with robust end-to-end confidentiality and integrity. However, a shortfall exists in that they cannot inherently substantiate to third parties that the data originated from a specific website. To rectify this, we propose the zkPass protocol. This empowers users to convincingly demonstrate that data accessed via HTTPS was obtained from a particular website, asserting statements about this data within a zero-knowledge context, thereby preserving privacy and averting the exposure of sensitive information. Serving as a conduit between Web 2.0 and Web 3.0, the zkPass protocol liberates private data from the confines of centralized web servers, paving the way for seamless migration into a decentralized era. ## Notation and Preliminaries • Prover(P): or user, or client who is required to generate proof for their statement. • Verifier(V): or platform, which is responsible for verifying the Prover’s statement. • Node(N): zkPass Node, is a part of the protocol execution used to verify the authenticity and integrity of the Prover’s private data. • DataSource(S): stands for https server, is the trusted data source that owns the Prover’s data. ## 1 Overview of Solution In the traditional data validation and confirmation process, the Prover submits their information to the Verifier. The Verifier, in turn, retrieves this data and performs authentication checks in collaboration with the DataSource. Thus, the Verifier serves merely as an intermediary or broker in this model. Each party faces unique challenges in this scenario: for the Prover, there’s a risk of disclosing excessive personal information; for the DataSource, while it’s a trusted data provider, it’s incapable of offering personalized verification services; and for the Verifier, they’re privy to all the customers’ private data, gaining total access, which presents significant potential risks of data leakage. We propose a new approach that repositions these three entities, positioning the Prover between the Verifier and the DataSource. Rather than the traditional method, the Prover uses their access token to directly locate and retrieve their data from the DataSource, subsequently generating a Zero-Knowledge Proof (ZKP) for the Verifier to check. This process ensures the Verifier remains unaware of the Prover’s personal information. In order to implement this structure, we incorporate 3P-TLS, MPC, and IZK technologies. ### **1.1 3P-TLS** Transport Layer Security (TLS) is the secure protocol for HTTPS, supported by almost all DataSources. It is a two-party protocol designed for client/server structure. We have built the 3P-TLS protocol based on elliptic curve DH protocol and combined it with MPC and Oblivious Transfer(OT) to prevent cheating. ### **1.2 MPC** One challenge we face is that the Prover may forge proof information provided by the DataSource to deceive the Verifier. The solution to this problem is through MPC, where both Prover and Verifier hold half of a session MAC key, which is a data integrity key used to maintain data integrity. Since the Prover cannot forge or tamper with information responses provided by the DataSource, and it cannot deceive the Verifier. MPC can also prevent the Verifier from knowing any private information about the Prover. During MPC handshake, there is no encryption key (data confidentiality key) for the Verifier, so it cannot decrypt any data and therefore does not know any private information for the Prover. ### **1.3 IZK** After obtaining information from the DataSource, Prover needs to prove certain statements of the response in a secure and private manner. We use Zero-Knowledge Proofs(ZKP) to achieve this goal. More specifically, we use interactive commit and prove zero-knowledge proofs(ICP-ZKP) to deal with the large scale of circuit. Prover gives the commitment as $$d = commit(m, r)$$, where $$m$$ is the message and $$r$$ is the randomness. Then Verifier check $$T/F= verify(m, r, d)$$. $$d$$ wouldn't reveal any information about $$m$$, and Prover can't find different $$m$$and $$m'$$ (and $$r$$ and $$r'$$) such that $$verify(m, r, d) = verify(m', r' , d) = T$$. During the protocol, Prover needs to commit its private witness, then prove the input wires and the computation of gate one by one, and continue to commit the output wires until the final one. ## **2 TLS** ### **2.1 Overview** TLS is one of the most widely used protocols for secure communication over the Internet. It encrypts data from plaintext to ciphertext and vice versa, providing data security and privacy by encrypting traffic to prevent sensitive data from being leaked by third parties. The process consists of two sub-protocols: handshake and record layer. The goal of the first sub-protocol is to negotiate a secure key between two endpoints, while the second uses an agreed key to protect communication. ### **2.2 Handshake** We refer to the endpoint initiating the connection as the ”client,” while the term ”server” denotes the responding endpoint. Additionally, we define the ”transcript” as the comprehensive record of all messages exchanged over the connection up until the point of analysis. The Handshake protocol itself can be divided into three distinct phases: the key exchange phase, the authentication phase, and the key derivation phase. #### Key exchange phase The protocol is started by the client sending a ClientHello to the server, containing the cryptographic algorithms supported by the client. The server replies with a ServerHello, containing the cryptographic algorithms selected from those offered by the client and a Diffie-Hellman public key. When the initial exchange is concluded, the two endpoints perform a Diffie-Hellman key exchange using the keys specified in the Hello messages. #### Authentication phase Starting from the server, the endpoints exchange their certificates (ServerCertificate) and a signature on the transcript using the key specified on them (ServerCertificateVerify). Finally, they send an HMAC on the transcript using the MAC keys obtained from the key derivation (ServerFinished and ClientFinished). The client uses the first key, the server uses the second one. The endpoints verify all the signatures and the MAC provided by the other endpoint. If any check fails, the connection is closed. #### Keys Derivation phase At the end of the Handshake, the endpoints feed the new messages of the transcript into the key derivation function. The key derivation function maintains an internal state, therefore all its outputs depend on the The key exchange phase. At the end, the parties obtain application keys(encrypted keys/MAC keys). From that moment, the Record layer protects the client-toserver flow through those keys. As it was proven in the authentication phase, all the values output by the Handshake are computationally independent, even slight modifications in the transcripts input in the key derivation function would lead to completely different and unpredictable outputs. #### 3P Handshake To illustrate the 3P handshake, we first assign specific roles to the three parties involved: the Prover (P) and Node (N) jointly act as the Client, while the DataSource (S) assumes the role of the Server. This handshake process is based on the fundamental principle of Diffie-Hellman key exchange. Given the Client’s public key, all participating parties should be capable of computing a secretsharing of the exchanged secret. It is crucial to emphasize that if any party gains access to the exchanged secret, it could compute the symmetric keys and engage in unrestricted communication with the client. Therefore, to design a secure multiparty Diffie-Hellman protocol, it is essential for the parties to possess a secret-shared private key. It is worth noting that the public key does not require confidentiality. The protocol proceeds as follows:
### 2.3 The Record Layer The Record layer provides fragments as application data, which signifies the actual communication between the two endpoints. User-sensitive information is contained within this application data, usually in the form of HTTP requests/responses, and is encrypted/authenticated using the application keys. The security of this system is maintained if each party keeps their respective application keys private. This ensures the protection of user data throughout the communication process, minimizing the potential risks of data leakage and unauthorized access. #### **Multi-Record** TLS is performed on streams, and the data in those streams are put into one or more fragments (of max 2^14 bytes). Client message boundaries are not preserved in the record layer (i.e., multiple client messages of the same ContentType MAY be coalesced into a single TLSPlaintext record, or a single message MAY be fragmented across several records). This means that we need to authenticate all records.
#### **Multi-Response** In specific usage scenarios, it may be necessary for the Prover to retrieve information from multiple responses originating from different APIs, potentially requiring multiple TLS sessions with a single data source. This implies that the Prover would need to perform multiple rounds of MPC and ZKP. To handle this situation efficiently and reduce overhead, we propose leveraging the same handshake session. HTTP keep-alive is a mechanism designed to reuse the same connection for multiple HTTP requests and responses. This inherently reduces the number of TLS handshakes, as only one TLS handshake is performed per TCP connection. In other words, with HTTP keep-alive, a single TCP and TLS handshake can accommodate multiple HTTP requests. Consequently, we can transmit different application data pertaining to various requests within a single TLS session. Furthermore, resuming the TLS session allows the Prover and the DataSource to utilize the same set of keys. The TLS protocol provides a method for session resumption known as Session Tickets, as defined in [RFC 5077](https://tools.ietf.org/html/rfc5077). The server can utilize a key rotation algorithm to encrypt and decrypt tickets using different keys over time. Additionally, the server can send new tickets to the client after each successful resumption. By implementing this standard, we can ensure an efficient and secure data retrieval process.

Figure 1: Resuming TLS Session with Session Ticket

### 2.4 Additional Explanation The content we’ve presented here partially explains TLS. We still need to cover numerous additional procedures and features in this discussion. For a more comprehensive understanding and deeper insight into these topics, we highly recommend referring [RFC5246 ](https://www.rfc-editor.org/rfc/rfc5246)and [RFC8446](https://www.rfc-editor.org/rfc/rfc8446), specific internet standards that provide detailed information about the various aspects and applications of TLS. ## 3 MPC ### 3.1 OT The OT protocol is a technique first introduced by Rabin in 1981. Coupled with Garbled Circuits (GC), it can facilitate secure Multi-Party Computation (MPC) protocols. Parties involved in secure computation employ OT to establish a secure communication channel or to exchange encrypted data. This allows them to construct the GC and execute the computation without exposing sensitive information. To illustrate our protocol, we’ll concentrate on the chosen 1-out-of-2 OT, often called standard OT, though it can easily be extended to 1-out-of-N OT. There are two roles for OT: sender and receiver. Specifically, the sender has two messages $$m0$$ and $$m1$$, the receiver has an index $$c\in\left{0, 1\right}$$ and the receiver wants to receive the sender's $$c-th$$ message without letting the sender know $$c$$. At the same time, the sender wants to ensure that the recipient can only receive one of these two messages.
In practice, we often let $$m\_1=m\_0 ⊕ Δ$$ , such that$$m\_c=m\_0 ⊕ c\* Δ$$, we call it correlated OT. Following shows the detail to implement basic OT based on Diffie-Hellman key exchange:

Figure 3: The Simplest Protocol for Oblivious Transfer

Given that OT serves as a prerequisite for both Garbled Circuits (GC) and Interactive ZeroKnowledge Proofs (IZKP), and considering our need for large-scale utilization of OT, we require an efficient methodology for generating OT instances that are optimally cost-effective. Additionally, to ensure adequate security of the entire zkPass protocol, it’s crucial that our OT protocol possesses active security. In the following section, we detail the OT protocol we are utilizing, which requires merely 128 basic OT instances. This approach eliminates the need for costly public key encryption for basic one-time passwords and aids in distributing network and computational load effectively, thereby optimizing our protocol’s overall efficiency and security.
#### 3.2 GC GC is an encryption protocol that facilitates secure computation between two parties. It allows two participants, who may not trust each other, to jointly evaluate a function on their respective private inputs without necessitating a trusted third party. For the GC protocol, the function to be evaluated must be defined as a Boolean circuit. The function underlying this, such as the comparison function in the millionaire problem, is presented as a Boolean circuit with two input gates. Both parties are aware of this circuit. What follows is an illustration of the GC workflow. A component of a garbling scheme $$G = (G\_b, E\_n, D\_e, E\_v, e\_v)$$. The function $$G\_b$$ maps $$f$$ and $$k$$ to $$(F, e, d),$$ where strings encode the garbled function, encoding function and decoding function. With $$e$$ and $$x$$ one can compute the garbled input $$X=E\_n(e, x)$$; with $$F$$ and $$X$$ one can compute the garbled output $$Y = E\_v(F, X)$$; knowing $$d$$ and $$Y$$ allows for recovery of the final output $$y = D\_e(d, Y)$$, which must be equal to $$e\_v(f, x)$$.

Figure 4: Foundations of Garbled Circuits

Considering that both the Prover and the Node maintain their respective private keys during the key exchange phase of the 3P handshake, both parties need to use their own private keys to compute the Pre-Master Secret (PMS). This PMS is then further derived into a session key. We employ Garbled Circuits (GC) for this calculation. Below, we detail the specific implementation of GC as used in zkPass.
## 4 IZK In Non-interactive Zero-Knowledge (NIZK) Proof systems, such as zk-SNARK and zk-STARK, computations are represented as circuits, and the gate constraints within the circuit are depicted as a set of polynomials. If a computation requires multiple circuits, all these circuits need to be amalgamated into a single, large circuit that is then submitted. Despite the trust assumptions associated with this approach, it necessitates a very large memory space which is typically not feasible within browser environments. To tackle the issue, we employ VOLE (Vector Oblivious Linear Evaluation)-based IZKP. Its linear nature allows us to submit circuits individually, effectively balancing memory size. Moreover, IZKP doesn’t require a trusted setup, thereby enabling the generation of zero-knowledge proofs in a browser environment. ### 4.1 VOLE VOLE is the arithmetic counterpart of string OT. Concretely, the VOLE functionality is a two-party functionality that takes a pair of vectors from the sender $$P\_0$$, and allows the receiver $$P\_1$$ to learn a chosen linear combination of these vectors. More formally, given a finite field $$F$$, the VOLE functionality takes a pair of vectors $$(u, v) \in F\_n \times F\_n$$from $$P\_0$$ and a scalar $$x\in F$$ from $$P\_1$$. It outputs $$w = ux + v$$ to $$P\_1$$. We will also consider a randomized version of VOLE where the sender’s inputs $$(u, v)$$ are picked at random by the functionality and delivered as outputs to the sender. The deterministic VOLE functionality can be easily reduced to the randomized one analogously to the reduction of OT to random OT. Below is how we generate the VOLE instanances:
### 4.2 ICP-ZKP We employ ICP-ZKP, a variant of interactive protocols that primarily uses symmetric key operations, thus achieving high efficiency and scalability. It can process millions of gates per second and manage large circuits consisting of billions of gates. The protocol includes a method for associating commitment schemes with proof commitment values. The commitment scheme actually serves as an Information-Theoretic Message Authentication Code (IT-MAC). This can be efficiently implemented using VOLE, and its homomorphic properties help to reduce the cost associated with addition gates. The functionality of the ICP-IZK is described as follows:
### 4.3 Circuit Factory #### **Bristol Fashion Circuit** We utilize Bristol-style circuits, which are composed of AND, XOR, and INV gates. The format is defined as follows:
#### Modular Circuit When it comes to Modular Circuit design, the size of the response from the DataSource isn’t always certain and can be approximately 1k. This implies that the scale of the whole circuit for authentication and assertion can be quite large, containing millions of gates. For a browser-like system, this is impractical to load the circuit and provide proof due to the significant memory consumption. However, we can notice that the main circuit is not just a combination of many sub-circuits, but certain sub-circuits are reused repeatedly during the evaluation. Therefore, we can construct a proof system in a modular manner by connecting small specialized ”gadget” circuits in a lightweight fashion. Thanks to the schema of ICP-ZK, we can recycle the memory: once a certain modular circuit is no longer needed in the calculation, all parties can remove the promise of that circuit from the memory. From a theoretical perspective, modular circuit designs are flexible and reusable. If a computation naturally presents different ”components”, a general-purpose scheme will homogenize them into a single representation, which might lead to performance overhead. Thanks to the schema of ICP-ZK, we can recycle the memory: once a particular modular circuit is no longer needed in the calculation, all parties can remove the promise of that circuit from memory With a CP scheme one can prove statements of the form "$$commit(x)$$ contains $$x$$ such that $$R(x, w)$$" where $$commit(x)$$ is a commitment. To see how the CP capability can be used for modular composition consider the following example of sequential composition in which one wants to prove that $$\exists w, z = h(x, w)$$, where $$h(x, w) = g(f(x, w), w)$$. Such a proof can be built by combining two CP systems $$Πf$$ and $$Πg$$ for its two building blocks, i.e., respectively $$f$$ and $$g$$: the prover creates a commitment $$commit(y)$$ of $$y$$, and then uses $$Πf(resp, Πg)$$to prove that "$$commit(y)$$ contains $$y = f(x, w)$$ ($$resp$$ contains $$y$$ such that $$z = g(y, w)$$". Here is what we have done for the sub circuit generation:

Figure 5: Sub Circuit Generation

#### **Authentication of Response** The authentication is to check whether the corresponding HMAC is correct. HMAC is defined as follows:
From a definition perspective, HMAC proof must have two hash operations. In IZKP, the cost of hashes (usually sha256) is high because the response length is uncertain. We need to make some optimizations. Our optimization exploits the Merkle–Damgård structure. Suppose $$b\_1$$and $$b\_2$$ are two correctly sized blocks. Then $$H(b\_1 || b\_2)$$ is computed as $$f\_H(f\_H(S\_i, b\_1), b\_2)$$ where $$f\_h$$ denotes the one-way compression function of $$H$$, and $$S\_i$$ is the initial state for each round of compression. Based on the above analysis, we separate the HMAC to 4 steps: * Outer hash state: $$Outer\_{hs} = f\_H(S\_i, k' \oplus opad)$$ * inner hash state: $$Inner\_{hs} = f\_H(S\_i, k'\oplus ipad)$$ * Inner hash: $$Inner\_h = f\_H(Inner\_{hs}, R)$$ * $$HMAC = f\_H(Outer\_{hs}, Inner\_h)$$ Revealing the outer hash state or inner hash state would not reveal $$k'$$ since the $$f\_H$$ is assumed to be one way. So during the 3P handshake, node can reveal the $$Inner\_{hs}$$ to Prover, Prover can use $$Inner\_{hs}$$ as public signal and his $$R$$ as the witness to generate proof that:$$π = ZK-PoK\left{R, Inner\_{hs}: Inner\_h=f\_H(Inner\_{hs}, R)\right}$$. $$Inner\_h$$ also needs to be committed. Then the node commits the $$Outer\_{hs}$$, so the check of $$HMAC$$ can be out of the ZK circuits which can significantly reduce cost. Now we will reduce the number of hash operations in HMAC to one. We can create a circuit: #### **Parse Response** In IZK, parsing JSON poses a significant computational burden. The syntax tree of each node contains numerous potential branches, and the parser must traverse each branch. Consequently, as the length of the JSON string increases, the total number of branches grows exponentially. This exponential growth makes ZKP circuits designed for parsing JSON documents impractical due to their sheer size. However, in practical scenarios, JSON structures typically do not contain sensitive information. The response from the data source often exhibits a similar structure across different users, with user-specific sensitive data typically represented as scalar JSON values. Consequently, we can alleviate this issue by performing JSON parsing outside of the circuit.
#### **Assert Response** As we have got the ind\[n], so the value must be at the index E\[n] + 1, so it could be extracted by the wire from E\[n] + 1 and E\[n] + Len(value), the Len is the bit length function for value. Then we could check Assert(R, E\[n] + 1, E\[n] + Len(value)）= 1 To facilitate proof of assertions, we utilize a primitive query circuit called Assert. It is designed to easily provide proof of various assertions. Since each case may have different assertions, constructing a large combination circuit with specific query selectors is not feasible. Such an approach would make the main circuit excessively large and difficult to maintain. To address this, our circuit factory offers a range of common circuits. Enterprise users can choose and combine these circuits to fulfill their specific requirements. Currently, we provide support for the following assertion circuits: * equal or not equal * greater/less than or equal * include/all different * average * sum * arithmetic with scalar * order * regexp/like * logical operation * between or out of range ## 5 Benchmark We conducted a performance evaluation of the complete protocol implementation using specific hardware setups. The Prover was executed on a MacBook Pro 15-inch Mid 2015, equipped with 16GB of 1600MHz DDR3 memory and a 2.5GHz Intel Core i7 processor. This configuration closely resembles the actual user environment. On the other hand, the Verifier was deployed on an AWS c6a.2xlarge instance, which offers 8 virtual CPUs and 16GB of memory (GiB). **Browser:** `MacBook Pro 15-inch Mid 2015, 16G Mem 1600 MHz DDR3, 2.5GHz Intel Core i7.` **Server:** `aws c6a.2xlarge 8vCPU 16GiB Mem.`
## 6 Future Direction The fields of MPC and ZK related technologies are constantly evolving, with significant advancements being made each year. To ensure the continuous optimization of the zkPass protocol, we are actively staying abreast of the latest technologies. Here are some noteworthy references that we are considering: \[FNO14], \[NNOB11], \[HK20], \[HYDK22], \[ADST21], \[BDOZ10], \[FKL+21], \[DIO20], \[JKO13], \[GAZ+21]. **OT.** Traditional OT protocols like IKNP/KOS15 which we use at current time requires security parameter $$λ$$ bits of communication for each OTHowever, we propose building a new maliciously secure OT extension based on VOLE which only needs $$λ/k$$ bits. for any $$k$$, at the expense of requiring $$2^{k-1}/k$$ times the computation. **GC.** Existing GC evaluation methods such as \[ZRE14] and \[KS08] evaluate GC functions gateby-gate using encrypted truth tables. The GC evaluator decrypts the corresponding output label based on input labels. However, interactive protocols offer more sophisticated techniques. For example, we can expose a (masked) private value to a party, allowing them to perform local computation and feed the resulting cleartext value back into the MPC. **IZK.** VOLE-based IZK(\[WYKW20]/\[YSWW21]) suffers from high communication overhead, often linear to the circuit size. We are constructing a new ZK protocols with communication sublinear to the circuit size, while maintaining a similar level of computational efficiency. ## Reference \[1] KOS15 \[2] GZBW22 \[3] JKO13 \[4] DIO21 \[5] FKL+21 \[6] BDOZ11 \[7] BCGI18 \[8] ADST21 \[9] HYDK21 \[10] HK20a \[11] YSWW21 \[12] FNO15 \[13] NNOB12 \[14] SGRR19 \[15] IKNP03 # Use Cases Proof of everything with zkPass zkPass extends verifiability across the digital world by transforming sensitive Web2 data into cryptographic proofs that are portable, privacy-preserving, and universally verifiable. Built on the zkTLS protocol, zkPass creates a trust layer where information can prove itself without being exposed, bridging the gap between Web2 institutions and Web3 applications. The use cases of zkPass can be organized into ten domains, each addressing critical challenges where authenticity, privacy, and interoperability are essential:
🪪 Identity and CompliancePrivacy-preserving KYC, AML, and eligibility verification across financial and regulated services./pages/EoFxaHMrCE9xq0Gaoaxj
💹 Finance and GovernanceProofs of assets, transactions, and unique identities enabling compliant DeFi, fair governance, and automated insurance claims./pages/BiAfc7cuKxiwCqLjV3X3
🌐 Reputation and AchievementsConversion of Web2 achievements, professional records, and experience into verifiable credentials usable across ecosystems./pages/2EGMCf6gPBSS7wZqQCjH
🏥 Industries and SocietySecure proofs for healthcare, education, social networking, and gaming, ensuring authenticity without data exposure./pages/zUKrSui6JspRQCLwSn01
🤖 AI and Data EconomyAuthentic, privacy-protected data inputs for AI models and agents, supporting trustworthy and regulated AI systems./pages/an4Cl8K2jNMizkvBtxnQ
⚡ DePIN and Machine EconomyVerifiable machine-to-machine interactions and device usage proofs anchoring the decentralized infrastructure economy./pages/AT2Vyza4KM1yLPGOujax
📦 Supply Chain and Enterprise DataCryptographic verification of supply chain documents, compliance attributes, and enterprise records./pages/6SSNf4qgsXTi1UDFupEm
🏛️ Government and Public ServicesEfficient, privacy-first verification for welfare distribution, tax compliance, and digital identity./pages/LKK3ASa4S7urLA02r0Fl
📰 Content AuthenticityProvenance and authorship proofs for media, creative works, and AI-generated content, safeguarding digital trust./pages/qi6hE98rgwds2XIOXdwR
🔗 Extended Ecosystem IntegrationCross-industry interoperability where proofs generated once can be reused across finance, enterprise, AI, and Web3 protocols.https://zkpass.org/ecosystem
#### Strategic Impact Across these domains, zkPass consistently replaces the need to disclose raw data with cryptographic attestations rooted in authoritative sources. This delivers three transformative outcomes: * **For individuals**: sovereignty over personal and professional data, with control over what is disclosed and where. * **For enterprises and institutions**: reduced liability, compliance efficiency, and assurance of data authenticity. * **For ecosystems**: new classes of applications where trust and privacy are not trade-offs but complementary guarantees. zkPass positions itself as the universal verification layer of the digital era. By embedding verifiability into the fabric of online interaction, it enables an internet where authenticity is native, privacy is preserved, and trust is grounded in mathematics rather than intermediaries. # Identity and Compliance Identity verification and regulatory compliance are two of the most demanding areas in digital infrastructure. Existing approaches depend heavily on centralized intermediaries that store sensitive personal data, creating significant risks of privacy leakage, data breaches, and regulatory inefficiency. zkPass, through its zkTLS protocol, offers a cryptographically verifiable yet privacy-preserving alternative. By enabling individuals to prove compliance attributes directly from authoritative Web2 sources, zkPass allows institutions and applications to validate what matters while ensuring that raw data never leaves the user’s control. #### Limitations of Traditional Identity Systems * **Data exposure**: KYC service providers require storage of documents such as passports, bank statements, or proof of residence, creating high-value targets for attackers. * **Redundancy and inefficiency**: Users repeat the same KYC processes across multiple platforms, while enterprises bear duplicated compliance costs. * **Regulatory mismatch**: Current frameworks often force a binary model: either full disclosure of user data or complete exclusion from services. * **User resistance**: Privacy-conscious individuals are increasingly unwilling to entrust sensitive information to centralized intermediaries, especially in Web3 ecosystems. #### zkPass Approach zkPass transforms the compliance model by embedding verifiability into the TLS layer. When a user connects to a regulated Web2 source — such as a government ID system, a bank portal, or an exchange account — zkTLS enables the generation of a zero-knowledge proof that confirms the required compliance attributes without revealing the underlying documents. This proof is portable, reusable, and verifiable on-chain or off-chain. Core properties: * **Selective disclosure**: Only the required attributes (for example, “over 18,” “EU resident,” or “non-US person”) are revealed. * **Local proof generation**: Computation occurs on the user’s device, ensuring that raw credentials are never transmitted. * **Cross-domain interoperability**: Proofs generated once can be applied across multiple applications and ecosystems, reducing redundant verification. * **Regulatory auditability**: Proofs are cryptographically verifiable, ensuring institutions can meet compliance requirements with higher assurance than document scans. #### Applications **zkKYC** * Account onboarding for centralized and decentralized exchanges, meeting AML and CTF standards without document exposure. * Permissioned DeFi platforms where users must prove jurisdiction or residency constraints. * Institutional counterparty verification in lending or derivatives markets, enabling compliance without sacrificing privacy. **Eligible Access** * Accredited investor verification using bank statements, tax filings, or government registries, proven via zkTLS without disclosing the full documents. * Employment or university enrollment verification for gated research platforms, academic communities, or professional DAOs. * Region-specific service access (for example, streaming, gaming, or fintech apps) that enforces compliance with local regulations without precise geolocation tracking. #### Strategic Impact By replacing document exposure with cryptographic attestations, zkPass redefines identity and compliance as a verifiable service rather than a centralized data-collection practice. This model balances the requirements of regulators, enterprises, and users: * **For regulators**: verifiable compliance without reliance on weak document scans. * **For enterprises**: reduced liability from data breaches and lower compliance costs. * **For users**: strong privacy guarantees and control over personal data. This establishes zkPass as a foundational infrastructure for compliant digital interaction, where trust is enforced by mathematics rather than institutional custody of identity data. # Finance and Governance Finance and governance are domains where the integrity of data and the assurance of compliance directly determine system stability. Traditional infrastructures rely on centralized verification and opaque processes, leaving room for fraud, inefficiency, and lack of trust. zkPass, powered by zkTLS, introduces a verifiable proof layer that allows financial and governance systems to operate with cryptographic certainty while preserving user privacy. #### Limitations of Existing Models * **Financial systems**: Credit scoring, collateral assessment, and transaction history validation depend on centralized bureaus and intermediaries, which expose users to data leakage and bias. * **DeFi ecosystems**: Smart contracts lack access to verified off-chain financial data, limiting innovation in lending, derivatives, and compliance-aware products. * **Governance**: DAOs and community systems face Sybil attacks and vote manipulation due to the absence of reliable identity and reputation proofs. * **Insurance**: Claims rely on lengthy manual processes and document submission, which increase operational costs and enable fraud. #### zkPass Approach zkTLS enables the transformation of financial and governance-critical data into zero-knowledge proofs that are portable, tamper-proof, and verifiable across domains. Users connect to authoritative Web2 sources — banks, trading platforms, payroll systems, government databases — and generate proofs locally, ensuring data validity without exposing the underlying records. Core properties: * **Proof of assets and liabilities**: Demonstrate asset balances, transaction history, or income without disclosing account details. * **Fraud-resistant governance**: One-person-one-vote models supported by verified unique identity proofs. * **Programmable compliance**: Smart contracts can enforce jurisdictional or eligibility requirements by consuming zkPass proofs. * **Automated claim validation**: Insurance companies can verify claims against authenticated sources (airlines, hospitals, banks) without requesting raw documents. #### Applications **Finance (DeFi and CeFi)** * Collateral verification for DeFi lending based on verified CEX balances or bank account statements. * Proof of trading history for compliance or credit assessment in derivatives markets. * Proof of reserves for centralized exchanges and custodians, enhancing market trust. * Regulatory-friendly DeFi products that integrate jurisdictional or KYC-based access control. **Governance and Voting** * DAO governance systems that ensure voters are unique, verified participants without revealing identity. * Quadratic voting and weighted governance based on verifiable reputation or on-chain achievements derived from Web2 credentials. * Community airdrops and incentive distribution designed to resist Sybil attacks. **Insurance Claim** * Automated travel insurance payouts validated through airline delay data or flight records. * Health insurance claims confirmed through proofs derived from hospital records without exposing sensitive details. * Property or vehicle insurance claims verified against authenticated ownership and incident reports. #### Strategic Impact By embedding verifiable financial and governance proofs into digital infrastructure, zkPass achieves: * **For financial institutions**: enhanced compliance and reduced exposure to fraud and false reporting. * **For DeFi protocols**: access to new markets and institutional adoption through compliance-ready primitives. * **For governance systems**: credible decision-making processes with built-in Sybil resistance. * **For insurers**: faster claims processing, lower operational costs, and reduced fraud. This positions zkPass as a universal verification layer for finance and governance, aligning transparency, privacy, and regulatory trust within a single protocol framework. # Reputation and Achievements Reputation is a critical dimension of trust in both digital and real-world ecosystems. From professional credentials to gaming achievements and community contributions, individuals and organizations build reputational capital that influences access, opportunity, and credibility. Yet most reputation systems are siloed, unverifiable, and vulnerable to manipulation. zkPass, through zkTLS, enables reputation and achievements to be captured as verifiable proofs from authoritative Web2 sources and made portable across Web3 and institutional contexts. #### Limitations of Current Reputation Models * **Fragmentation**: Achievements and credentials are locked within closed platforms such as universities, employers, or gaming providers, without interoperability. * **Manipulation**: Reputation scores on Web2 platforms are often inflated by bots, fake reviews, or unverifiable claims. * **Privacy leakage**: Sharing full resumes, certificates, or transcripts exposes sensitive personal data that may be unnecessary for verification. * **Lack of composability**: On-chain reputation systems are limited to Web3-native interactions, ignoring the vast body of verifiable Web2 data. #### zkPass Approach zkPass redefines reputation as a cryptographic asset. By connecting to Web2 platforms via zkTLS, users can generate proofs of achievements, credentials, or history that are portable, privacy-preserving, and verifiable anywhere. Instead of exporting raw resumes or certificates, zkPass enables selective proofs that reveal only what is necessary for the interaction. Core properties: * **Verifiable authenticity**: Credentials originate from authoritative Web2 sources such as universities, gaming platforms, or professional networks. * **Selective disclosure**: Proofs disclose only the required claim (for example, “completed advanced course,” “achieved level 50,” “employed at company X”), without revealing unrelated information. * **Composability**: Reputation proofs can be aggregated across domains and reused across ecosystems, forming a cumulative profile. * **Resistance to Sybil attacks**: By grounding achievements in real, verifiable accounts, zkPass prevents the creation of fake identities or inflated reputation. #### Applications **On-chain Achievements** * Academic records: Verified proofs of course completion, degrees, or certifications from platforms such as Coursera, edX, or universities. * Professional milestones: Employment history or contributions on LinkedIn or GitHub transformed into verifiable on-chain credentials. * Lifestyle and consumer engagement: Travel history, brand memberships, or loyalty points exported as reputation assets. * Gaming achievements: Verified progression or rankings from Web2 gaming platforms such as Steam or Epic used as credentials in Web3 gaming ecosystems. **Experience Checks** * Recruitment: Employers can verify work experience or academic background without requesting raw transcripts or CVs. * Freelancing and gig economy: Platforms such as Upwork or Fiverr can integrate zkPass to ensure that listed skills and work history are backed by cryptographic proofs. * DAO and community tasks: Communities can restrict task allocations or rewards to contributors with verified skill sets or credentials. #### Strategic Impact By converting Web2 reputation into portable, verifiable credentials, zkPass enables: * **For individuals**: control over personal achievements and the ability to selectively disclose them across platforms. * **For enterprises**: reliable hiring, collaboration, and credential verification without costly manual checks. * **For Web3 ecosystems**: stronger reputation systems that go beyond wallet activity and integrate real-world achievements. This redefines reputation as a cryptographic primitive that is reusable, interoperable, and privacy-preserving, unlocking new forms of trust across digital and physical economies. # Industries and Society Beyond finance and identity, zkPass extends into broader societal and industrial domains where data authenticity is critical yet privacy protection is equally essential. Sectors such as healthcare, education, social networking, and gaming manage vast amounts of personal information and behavioral records. Traditionally, these domains face trade-offs between trust, interoperability, and privacy. With zkTLS, zkPass enables sensitive data to prove itself without being exposed, creating new pathways for secure digital transformation. #### Limitations of Current Systems * **Healthcare**: Medical records and prescriptions are siloed and sensitive, with high barriers to sharing due to privacy and regulatory constraints. * **Education**: Diplomas, transcripts, and research outputs are prone to forgery and lack standardized verification mechanisms. * **Social networking**: Platforms are overwhelmed by bots and fake accounts, while real users lack portable identity proofs across ecosystems. * **Gaming**: Anti-cheat systems and account validation depend on intrusive monitoring, while achievements remain trapped in closed platforms. #### zkPass Approach zkPass integrates with authoritative Web2 systems to generate verifiable proofs that attest to the authenticity of healthcare data, academic credentials, social accounts, and gaming records. Proofs are generated locally, ensuring sensitive data never leaves the user’s device, and can be consumed by both Web3 applications and institutional systems. Core properties: * **Regulatory alignment**: Proofs preserve compliance with strict data-protection regimes such as HIPAA or GDPR. * **Cross-domain utility**: Credentials from healthcare, education, and social platforms can be reused across industries without exposing raw data. * **User control**: Individuals selectively disclose achievements or eligibility attributes while retaining custody of sensitive records. * **Fraud resistance**: Proofs are cryptographically tied to authoritative sources, preventing falsification or manipulation. #### Applications **Medical and Healthcare** * Proof of diagnosis or prescription for clinical trials or pharmaceutical access programs without revealing full medical history. * Health insurance claims verified against hospital or pharmacy records, reducing fraud and processing delays. * Remote healthcare platforms verifying patient eligibility for treatments or services. **Education and Research** * Diplomas, course completions, and certifications transformed into cryptographic proofs consumable by employers, DAOs, or grant programs. * Research outputs and publications validated against academic platforms, ensuring citation integrity and authorship verification. * Scholarship or program eligibility verification without exposing full academic transcripts. **Social Networking** * Proof of authentic accounts on platforms such as Twitter, LinkedIn, or Facebook without sharing raw account data. * Bot resistance for DAOs, airdrops, or community platforms by verifying unique, real-world-linked identities. * Reputation building by linking verified social achievements with Web3 profiles. **Gaming** * Verification of in-game achievements or account status across Web2 platforms (Steam, Epic, console networks) for Web3 interoperability. * Anti-cheat systems using cryptographic account proofs rather than intrusive behavioral monitoring. * Cross-platform progression, allowing users to carry verified reputation and achievements between games or ecosystems. #### Strategic Impact By extending into healthcare, education, social networking, and gaming, zkPass demonstrates the universality of verifiable data. * **For healthcare and education**: trusted credentialing without undermining privacy. * **For social platforms**: a defense against Sybil attacks and fake accounts, strengthening digital trust. * **For gaming ecosystems**: new economic models based on verified achievements and fair participation. These domains illustrate how zkPass transforms sensitive human data into verifiable, privacy-preserving digital assets. In doing so, it establishes the foundation for a society where authenticity and privacy are not competing demands but mutually reinforcing principles. # AI and Data Economy Artificial intelligence systems depend on vast amounts of data, yet most data sources are unverified, fragmented, and prone to manipulation. Current AI pipelines lack the ability to distinguish between authentic and falsified information, creating risks of bias, fraud, and adversarial attacks. zkPass introduces a verifiable data layer for AI. By using zkTLS, sensitive Web2 data can be transformed into zero-knowledge proofs that certify authenticity and integrity without revealing the underlying content. This enables AI agents and models to consume reliable inputs while protecting user privacy. **Limitations of current AI data pipelines** * Reliance on unverified or crowd-sourced datasets vulnerable to manipulation. * Inability to use sensitive but high-value data (healthcare, finance) due to privacy constraints. * Lack of standardized provenance and auditability across AI models. **zkPass approach** * Proof generation from authoritative Web2 sources such as banks, hospitals, or education platforms. * Selective disclosure of attributes needed for AI inference without exposing entire records. * Cryptographic audit trails ensuring training data and real-time inputs are tamper-resistant. **Applications** * Financial AI advisors consuming verified transaction histories while preserving user confidentiality. * Healthcare AI systems accessing verified diagnoses or treatment eligibility proofs for clinical decision support. * AI agents in commerce and social networks consuming verifiable identity and behavior proofs to avoid fraud. **Strategic impact**\ zkPass provides the cryptographic foundation for “Verifiable AI,” ensuring that intelligent systems operate on data that is both authentic and privacy-preserving. This unlocks regulated, high-stakes use cases where AI adoption has so far been limited by trust and compliance barriers. # DePIN and Machine Economy Decentralized Physical Infrastructure Networks (DePIN) rely on devices and machines to generate data that is used for payments, reputation, and coordination. Without trustworthy verification, these systems are exposed to falsified reports, double-counting, and manipulation. zkPass enables device-generated data to be cryptographically verifiable. By embedding zkTLS at the device gateway or cloud API, machine interactions can produce zero-knowledge proofs of usage, availability, or performance. **Limitations of current DePIN systems** * Dependence on centralized APIs or unverifiable self-reports from devices. * Fraud in usage metrics such as fake bandwidth, storage, or energy contributions. * Difficulty in establishing reliable machine-to-machine settlements. **zkPass approach** * TLS-based attestation of device data, transformed into zero-knowledge proofs. * Local proof generation at edge gateways or device APIs, preventing manipulation. * Interoperable proofs consumable by blockchains, DAOs, and marketplaces. **Applications** * Verifiable proofs of energy consumption and delivery in decentralized power grids. * Authentic bandwidth or storage usage proofs in decentralized cloud networks. * Verified EV charging sessions, enabling fair rewards in charging infrastructure networks. * IoT-enabled supply chain sensors providing cryptographic proofs of environmental conditions. **Strategic impact**\ By anchoring machine data in verifiable cryptographic proofs, zkPass acts as the trust layer for the machine economy. This ensures that incentives, settlements, and governance in DePIN systems are based on authentic inputs rather than unverifiable claims. # Supply Chain and Enterprise Data Global supply chains and enterprise systems manage sensitive commercial information ranging from invoices to certificates of origin. Current verification methods depend on centralized registries and paper-based audits, which are costly, slow, and vulnerable to forgery. zkPass introduces cryptographic verification for enterprise and supply chain data, enabling selective disclosure of compliance attributes without exposing full documents. **Limitations of current supply chain systems** * Paper-based certificates subject to forgery and duplication. * Limited interoperability between enterprise systems and regulators. * Data silos preventing real-time verification across logistics networks. **zkPass approach** * zkTLS proofs generated directly from enterprise systems such as ERP, logistics platforms, or customs databases. * Selective disclosure of compliance attributes such as “organic certified,” “origin country = Japan,” or “batch temperature maintained.” * Proofs portable across regulators, partners, and end-users. **Applications** * Authenticity verification of luxury goods, pharmaceuticals, or critical components. * Compliance proofs for carbon accounting, environmental standards, or labor certifications. * Trade finance verification of invoices, bills of lading, and letters of credit without exposing sensitive details. **Strategic impact**\ zkPass enables global supply chains to achieve transparency without compromising commercial confidentiality. This strengthens trust between enterprises, regulators, and consumers while reducing fraud and compliance costs. # Government and Public Services Governments are digitizing identity, taxation, and welfare distribution, but adoption is limited by privacy concerns and lack of interoperability. Citizens are forced to disclose full personal data to access services, creating inefficiency and vulnerability to misuse. zkPass enables verifiable yet privacy-preserving interactions between citizens and public institutions. Through zkTLS, official government portals become sources of cryptographic proofs that can be reused across multiple services. **Limitations of current government systems** * Heavy reliance on centralized ID registries and document storage. * Privacy risks from mass surveillance or data breaches. * High administrative costs due to redundant verification processes. **zkPass approach** * zkTLS proofs generated from e-government portals such as tax systems, healthcare registries, or digital ID databases. * Attribute-based disclosure, proving eligibility or status without revealing unnecessary details. * Cross-institution interoperability, reducing administrative duplication. **Applications** * Proof of eligibility for social welfare programs without revealing full income history. * Verification of tax compliance for businesses interacting with regulators. * Digital passport or driver’s license proofs consumable by both online and offline services. **Strategic impact**\ zkPass allows governments to deliver efficient, privacy-respecting digital services. For citizens, this ensures dignity and data sovereignty. For states, it enhances trust, reduces fraud, and lowers administrative burdens. # Content Authenticity In the digital era, misinformation and synthetic media (such as deepfakes) undermine trust in content. Current watermarking or centralized verification schemes are insufficient to guarantee authenticity across platforms. zkPass introduces cryptographic content verification. By embedding zkTLS proofs at the point of publication or data origin, media and digital assets can carry cryptographically verifiable attestations of authenticity and provenance. **Limitations of current content verification** * Watermarking and metadata can be stripped or manipulated. * Centralized registries are vulnerable to censorship or compromise. * Users cannot independently verify whether content originated from an authentic source. **zkPass approach** * zkTLS integration with publishing platforms, enabling proofs of authorship or source at the moment of release. * Content provenance linked to authoritative domains (e.g., news outlets, creative platforms) without exposing underlying data. * Verifiable proofs portable across platforms, applications, and storage layers. **Applications** * News and journalism: readers verify that articles or videos were published by authentic media outlets. * Creative industries: digital art, music, or film assets carry verifiable proofs of origin, complementing NFT frameworks. * AI-generated content: proofs distinguishing synthetic outputs from human-authored materials. **Strategic impact**\ zkPass provides the infrastructure for a verifiable media ecosystem, where authenticity is established cryptographically rather than by institutional trust. This safeguards democratic processes, creative industries, and digital discourse against manipulation. # JS-SDK ## Overview Welcome to the zkPass Software Development Kit (SDK) documentation. This SDK is designed to help third-party Decentralized Applications (DApps) integrate seamlessly with the zkPass TransGate browser extension or app. With the SDK, developers can easily connect their DApps to zkPass, enabling users to privately and selectively validate data on any HTTPS website within the web3 ecosystem. The SDK provides support for standard functionalities, including trust verifications for legal identity, financial records, healthcare information, social interactions, work experience, education, and skill certifications. Furthermore, it continually expands its capabilities, with additional features anticipated in future updates. The following instructions are applicable to web DApps based on JavaScript. ## Why zkPass JS-SDK? The zkPass JS-SDK provides a convenient and efficient way for developers to integrate zkPass into their applications. * Privacy-Preserving Verification: the SDK facilitates the integration of zkPass into web applications, allowing users to selectively and privately validate their data. * Verifiability through 3P-TLS: the SDK helps developers seamlessly implement this 3P-TLS for secure data verification. * Compatibility with HTTPS Websites: the SDK is designed to be compatible with any HTTPS website, making integration straightforward for developers and no additional APIs or licenses are required, simplifying the adoption process. * Anti-Cheating Mechanisms: the SDK assists in implementing these anti-cheating mechanisms, ensuring the authenticity, integrity, and validity of the data. * Memory-Efficient Zero-Knowledge Proofs: the SDK leverages VOLE-based IZK to achieve millisecond-level ZKP generation locally in the browser environment that contributes to the memory efficiency of the verification process. * Versatile Application Scenarios: the SDK can be applied in various scenarios, including decentralized identity passes, DeFi lending protocols, healthcare data marketplaces, and other use cases where trust and privacy are crucial. ## Core Concepts #### Schema A Schema is a JSON-formatted file that defines the mapping of specific HTTP responses for the zkPass verification system. Additional details can be found in the [schema section](/developer-guides/js-sdk/schema). #### TransGate TransGate, consisting of a Chrome extension, Android app/Instant app, and iOS app/Clip, enables the secure and seamless transfer of private data between web2 and web3 environments. It operates on the client side, using the zkPass protocol to ensure a smooth and secure user experience when transferring data to various destinations. #### Allocator Node The allocator node generates verification task metadata, randomly selecting a validator for subsequent verification with the user. Once the task is generated, it uses its private key to sign the metadata and returns the metadata along with the signature. #### Validator Node The validator node plays a crucial role in the verification process. It participates in 3P-TLS and receives the zk-proof generated by the TransGate, verifies its authenticity, and then returns the final verification result along with its signature. Essentially, the validator node acts as an independent authority, ensuring the integrity and validity of the verification process before providing the outcome to the DApp. ## Role of JS-SDK
The SDK serves as a bridge connecting the DApp and TransGate. It dispatches events to the event listener of TransGate, which then processes the event in its handler and returns the result to the SDK. Once the DApp receives the verification result from the SDK, it has the option to transform the result into an on-chain Identity, such as zkSBT, or store it off-chain for future use. # How It Works The Extension JS-SDK serves as a bridge connecting your DApp to the TransGate extension, enabling seamless zk verification capabilities for DApp. The diagram below illustrates the workflow of the verification process and the role/function of the JS-SDK in the entire process.
1. **User Prepares Verification:** * The user begins by visiting the DApp and prepares the required verification based on a specified schema. 2. **DApp Initiates SDK:** * The DApp activates the SDK, initiating the verification process using the provided schema data. 3. **SDK Connects to Allocator Node:** * The SDK connects to the allocator node using the appid and schemaId to retrieve task information. The allocator node validates the parameters and returns the relevant task details. 4. **SDK Communicates with TransGate Extension:** * The SDK transfers the task information to the zkPass TransGate extension. After confirming the parameters, the extension opens the designated data source website mentioned in the schema. 5. **User Login to Data Source:** * The user logs in to the data source website using their username and password. 6. **Verification Process Initiates:** * When the extension detects API requests as defined in the schema, the user starts the verification process. 7. **Establishment of 3P-TLS:** * The extension, validator node, and data source server establish a secure 3P-TLS connection. 8. **Generation of zk-Proof:** * After receiving the response from the data source, the extension generates a zk-proof and sends it to the validator node. 9. **Validator Node Verification:** * The validator node verifies the zk-proof and returns the final verification result. 10. **Result Sent to Extension:** * The extension receives the result and sends it back to the DApp through the SDK. 11. **DApp Validation:** * Finally, the DApp validates the result and proceeds with the next steps based on its specific requirements. # Quick Start You can read [A Comprehensive Guide to Verifying Private Data with zkPass](https://medium.com/@jovells.appiah/a-comprehensive-guide-to-verifying-private-data-with-zkpass-0be35afec44a) before start to integrate zkPass TransGate-JS-SDK. ### Register and Config the Project in zkPass DevHub *** Login [**zkPass DevHub**](http://dev.zkpass.org), connect the wallet.
Create a new project, enter project information.
After "Create", a project is created with an appID.
Click on 'Add Schema' and choose the schema category.
Choose a base schema (the base schema is a default template of schema without assertions).
Config the assertions based on the requirements.
After 'Submit', a schema is created automatically with an unique schemaId for the project.
Developers can add multiple schemas for the project. ::: info Once the schema is successfully created, it cannot be modified but can be deleted. Please carefully review before submitting. ::: ### Integrate TransGate JS-SDK *** Developers can install the package using either [NPM](https://www.npmjs.com/package/@zkpass/transgate-js-sdk) or [Yarn](https://yarnpkg.com/package?name=@zkpass/transgate-js-sdk) **Using NPM** ``` npm install @zkpass/transgate-js-sdk ``` **Using Yarn** ``` yarn add @zkpass/transgate-js-sdk ``` Integrate the TransGate JS-SDK with your project ```javascript const verify = async () => { try { // The appid of the project created in dev center const appid = "8fb9d43c-2f24-424e-a98d-7ba34a5532f5" // Create the connector instance const connector = new TransgateConnect(appid) // The schema id of the project const schemaId = "516a720e-29a4-4307-ae7b-5aec286e446e" // Launch the process of verification // When running the TransGate SDK on a PC, if the user has not installed TransGate, // a QR code will pop up. The user can scan it using the TransGate App on their // phone to complete verification (iOS users can directly use the system scanner) // or install TransGate from the Google Play Store. On mobile DApps, // TransGate will automatically invoke the TransGate App. // If it is not installed, the user will be prompted to install it. const res = await connector.launch(schemaId) //If you want to bind the user's address with the proof, the `launch` function //also accepts a second parameter, which is the user's wallet address. const address = "0xD038048D1AE4c04dF2759F33BFda969999999641" const responseWithAddress = await connector.launch(schemaId, address) // verifiy the res onchain/offchain based on the requirement } catch (error) { console.log('transgate error', error) } } ``` ::: info TransGate download link is ::: ::: info Please make sure the domain of DApp matches the configuration of the project in dev center. ::: ### Validate the result *** After receiving the verification result(`res`in code block), developers should validate it. You can refer to [API References](/developer-guides/js-sdk/api-references#instance-methods) and [Generate proof and verify the result](/developer-guides/js-sdk/generate-proof-and-verify-the-result) for more information. # Generate proof and verify the result After running Transgate through the SDK, a proof will be returned. You can verify it locally or on-chain. We currently support the EVM ecosystem and the Solana ecosystem. # EVM ### How to generate the proof with EVM? ```javascript const generate = async (schemaId: string, appid: string) => { try { // The appid of the project created in dev center const appid = "8fb9d43c-2f24-424e-a98d-7ba34a5532f5" // Create the connector instance const connector = new TransgateConnect(appid) // Check if the TransGate extension is installed // If it returns false, please prompt to install it from chrome web store const isAvailable = await connector.isTransgateAvailable() if (isAvailable) { // The schema id of the project const schemaId = "516a720e-29a4-4307-ae7b-5aec286e446e" // Launch the process of verification // This method can be invoked in a loop when dealing with multiple schemas const res = await connector.launch(schemaId) // If you want to send the result to the blockchain, please add the wallet address as the second parameter. // const res = await connector.launch(schemaId, address) // verifiy the res onchain/offchain based on the requirement } else { console.log('Please install TransGate') } } catch (error) { console.log('transgate error', error) } } ``` ::: info The result includes two signatures: the allocator signature and the validator signature. Developers should verify both signatures based on the other returned fields. ::: ### Verify Allocator Signature #### Encode the allocator message struct ```javascript import Web3 from "web3" const web3 = new Web3() const { taskId } = res //return by Transgate const taskIdHex = Web3.utils.stringToHex(taskId) const schemaIdHex = Web3.utils.stringToHex(schemaId) const encodeParams = web3.eth.abi.encodeParameters( ["bytes32", "bytes32", "address"], [taskIdHex, schemaIdHex, validatorAddress] ) const paramsHash = Web3.utils.soliditySha3(encodeParams) ``` #### Recover the allocator address ```javascript const signedAllocatorAddress = web3.eth.accounts.recover(paramsHash, allocatorSignature) ``` #### Check if the signed allocator address is registered. The current allocator address is fixed. ```javascript return signedAllocatorAddress === "0x19a567b3b212a5b35bA0E3B600FbEd5c2eE9083d" ``` ### Verify Validator Signature #### Encode the validator message ```javascript import Web3 from "web3" const web3 = new Web3() const { taskId, uHash, publicFieldsHash, recipient } = res //return by Transgate const taskIdHex = Web3.utils.stringToHex(taskId) const schemaIdHex = Web3.utils.stringToHex(schemaId) const types = ["bytes32", "bytes32", "bytes32", "bytes32"] const values = [taskIdHex, schemaIdHex, uHash, publicFieldsHash] //If you add the wallet address as the second parameter when launch the Transgate if (recipient) { types.push("address") values.push(recipient) } const encodeParams = web3.eth.abi.encodeParameters(types, values) const paramsHash = Web3.utils.soliditySha3(encodeParams) ``` #### Recover the validator address 
const signedValidatorAddress = web3.eth.accounts.recover(paramsHash, validatorSignature)
#### Verify if the signed validator address matches the address assigned by the allocator ```javascript return signedValidatorAddress === validatorAddress ``` ::: info Here, we've only given the reference code for off-chain verification. However, the result can also be verified on-chain. ::: # Solana Only supports SDK version 0.2.0 and above. ### How to generate the proof with Solana? ```javascript const generate = async (schemaId: string, appid: string) => { try { //check if you install the Phatom wallet if (!("phantom" in window)) { return alert("Please install Phantom wallet") } const provider = window.phantom?.solana const resp = await provider?.connect() //connect wallet const account = resp.publicKey.toString() //The appid of the project created in dev center const appid = "39a00e9e-7e6d-461e-9b9d-d520b355d1c0" //The schemaId of the project const schemaId = "c7eab8b7d7e44b05b41b613fe548edf5" const connector = new TransgateConnect(appid) const isAvailable = await connector.isTransgateAvailable() if (!isAvailable) { return alert("Please install zkPass TransGate") } const res = (await connector.launchWithSolana(schemaId, account)) as Result } catch (err) { alert(JSON.stringify(err)) console.log("error", err) } } ``` ::: info The result includes two signatures: the allocator signature and the validator signature. Developers should verify both signatures based on the other returned fields. ::: ### Verify Allocator Signature #### Encode the allocator message struct ```javascript import { Buffer } from "buffer" import secp256k1 from "secp256k1" import * as borsh from "borsh" import sha3 from 'js-sha3' //Attest struct for Solana const SolanaTask = { struct: { task: 'string', schema: 'string', notary: 'string', }, } const { taskId, allocatorSignature, validatorAddress } = res //return by Transgate const sig_bytes = hexToBytes(allocatorSignature.slice(2)); const signatureBytes = sig_bytes.slice(0, 64); const recoverId = Array.from(sig_bytes.slice(64))[0]; const plaintext = borsh.serialize(SolanaTask, { task: taskId, schema: schema, notary: validatorAddress, }); const plaintextHash = Buffer.from(sha3.keccak_256.digest(Buffer.from(plaintext))); ``` #### Recover the allocator address ```javascript const signedAllocatorAddress = secp256k1.ecdsaRecover(signatureBytes, recoverId, plaintextHash, false); ``` #### Check if the signed allocator address is registered. The current allocator address is fixed. ```javascript return signedAllocatorAddress === "69e7d686e612ab57e3619f4a19a567b3b212a5b35ba0e3b600fbed5c2ee9083d" ``` ### Verify Validator Signature #### Generate the validator message ```javascript import { Buffer } from "buffer" import secp256k1 from "secp256k1" import * as borsh from "borsh" import sha3 from "js-sha3" //Attest struct for Solana const Attest = { struct: { task: "string", schema: "string", nullifier: "string", recipient: "string", publicFieldsHash: "string", }, } const { taskId, uHash, validatorAddress, schema, validatorSignature, recipient, publicFieldsHash } = res //return by Transgate const sig_bytes = hexToBytes(validatorSignature.slice(2)) //skip the 0x const signatureBytes = sig_bytes.slice(0, 64) const recoverId = Array.from(sig_bytes.slice(64))[0] const plaintext = borsh.serialize(Attest, { task: taskId, nullifier: uHash, schema, recipient, publicFieldsHash, }) const plaintextHash = Buffer.from(sha3.keccak_256.digest(Buffer.from(plaintext))) ``` #### Recover the validator address ```javascript const signedValidatorAddress = secp256k1.ecdsaRecover(signatureBytes, recoverId, plaintextHash, false); ``` #### Verify if the signed validator address matches the address assigned by the allocator ```javascript return signedValidatorAddress === validatorAddress ``` ::: info Here, we've only given the reference code for js verification. However, the result can also be verified on Solana. ::: # Ton Only supports SDK version 0.3.0 and above. ### How to generate the proof with Ton? ```typescript import { useTonWallet } from "@tonconnect/ui-react" const wallet = useTonWallet() const generate = async (schemaId: string, appid: string) => { try { //check if you connect the Ton wallet if (!wallet) { return alert("Please connect the wallet") } // TON address for the Wallet const address = wallet.account.address //The appid of the project created in dev center const appid = "39a00e9e-7e6d-461e-9b9d-d520b355d1c0" //The schemaId of the project const schemaId = "c7eab8b7d7e44b05b41b613fe548edf5" const connector = new TransgateConnect(appid) const isAvailable = await connector.isTransgateAvailable() if (!isAvailable) { return alert("Please install zkPass TransGate") } const res = (await connector.launchWithTon(schemaId, address)) as Result } catch (err) { alert(JSON.stringify(err)) console.log("error", err) } } ``` ::: info The result includes two signatures: the allocator signature and the validator signature. Developers should verify both signatures based on the other returned fields. ::: ### Verify Allocator Signature #### Encode the allocator message struct ```typescript import { Address as TonAddress, beginCell } from '@ton/ton'; import { signVerify } from '@ton/crypto'; const { taskId, allocatorSignature, validatorAddress } = res //return by Transgate const taskCell = beginCell() .storeBuffer(Buffer.from(taskId, 'ascii')) .storeBuffer(Buffer.from(schema, 'ascii')) .storeBuffer(Buffer.from(validatorAddress, 'hex')) .endCell(); ``` #### Verify the allocator signature ```typescript //task pub key is fixed const TonTaskPubKey = "6ab539926d899a69385d8c5a35bd8c3e650dbd0a0c5e3e9a3cca15867e11d884" //The result of the signature verification needs to return as true. const taskVerify = signVerify(taskCell.hash(), Buffer.from(allocatorSignature, 'hex'), Buffer.from(TonTaskPubKey, 'hex')); ``` ### Verify Validator Signature #### Generate the validator message ```javascript import { Address as TonAddress, beginCell } from '@ton/ton'; import { signVerify } from '@ton/crypto'; const { taskId, uHash, validatorAddress, schema, validatorSignature, recipient, publicFieldsHash } = res //return by Transgate const attestationCell = beginCell() .storeRef( beginCell() .storeBuffer(Buffer.from(taskId, 'ascii')) .storeBuffer(Buffer.from(schema, 'ascii')) .storeBuffer(Buffer.from(uHash.slice(2), 'hex')) .endCell(), ) .storeAddress(TonAddress.parse(recipient)) .storeRef(beginCell().storeBuffer(Buffer.from(publicFieldsHash.slice(2), 'hex')).endCell()) .endCell(); ``` #### Verify the validator address ```typescript //The result of the signature verification needs to return as true. const attestationVerify = signVerify( attestationCell.hash(), Buffer.from(validatorSignature.slice(2), 'hex'), Buffer.from(validatorAddress, 'hex'), ); ``` ::: info Here, we've only given the reference code for js verification. However, the result can also be verified on Ton. ::: # Schema A schema comprises two primary components: * API requests required based on verification conditions * Grammar paths from the API responses for extracting the fields needed for verification * Assertion for the verification Here is a example regarding the TikTok: The request looks like: ```bash curl 'https://www.tiktok.com/passport/web/account/info/' \ ...... -H 'cookie: _tt...faf' \ ...... --compressed ``` The response looks like: 
{
  "data": {
    "user_id": 7*****************7,
    "user_id_str": "7*****************7",
    "odin_user_type": 12,
    ...
    "create_time": 1690168843,
    ...
    "app_id": 1459,
    "is_employee": false,
    "external_employee_platform": ""
  },
  "message": "success"
}
The verification involves checking whether the account creation date is prior to August 2023(timestamp is 1690848000000). So the schema looks like: ```json { "category": "Social", "issuer": "Tiktok", "desc": "TikTok is a video-sharing app that allows users to create and share short-form videos on any topic.", "website": "https://www.tiktok.com", "APIs": [ { "host": "www.tiktok.com", "intercept": { "url": "passport/web/account/info/", "method": "GET" }, "assert": [ { "key": "data|create_time", "value": "1690848000", "operation": "<" } ], "nullifier": "data|user_id_str" } ], "tips": { "message": "When you successfully log in, please click the 'Start' button to initiate the verification process." } } ``` ::: info The `nullifier` is a required element in the schema, serving to indicate a unique identifier for the user in the data source. It is the witness and will be hashed with a random number generated by MPC in zk circuit to ensure the nullifier's value remains undisclosed to the validator. Developers can use the hash of nullifier to prevent Sybil attacks. ::: In [zkPass dev center](https://dev.zkpass.org), we have preset schemas for user to choose and config. Developers have the flexibility to design their own personalized schemas and seamlessly integrate them into their projects. Further details can be found in the [Custom Schema](/developer-guides/js-sdk/schema/custom-schema) section, providing comprehensive information on how to create and implement customized schemas for your specific needs. # Custom Schema Developers have the flexibility to create customized schema files tailored to their specific business needs, in addition to using the default schema. This enables them to fully leverage the capabilities of zkPass, ensuring seamless data verification from specified sources. For instance, a developer from a decentralized web3 job recruitment platform might want users to verify: * Their work experience from [Upwork](https://www.upwork.com/) * Their payroll statement from [UOB bank](https://www.uob.com.sg) In order to achieve this, the developer can create two schemas utilizing the APIs provided by [`Upwork`](https://www.upwork.com/) and [UOB bank](https://www.uob.com.sg). To generate a valid schema, developers must adhere to the established schema standards. Here is a typical schema example, demonstrating "Quora Account Owner": ```json { "issuer": "Quora", "desc": "The platform to ask questions and connect with people who contribute unique insights and quality answers.", "website": "https://www.quora.com/stats", "APIs": [ { "host": "www.quora.com", "intercept": { "url": "graphql/gql_para_POST", "method": "POST", "query": [ { "q": "UserStatsContentQuery", "verify": true } ] }, "assert": [ { "key": "data|viewer|__typename", "value": "Viewer", "operation": "=" } ], "nullifier": "data|viewer|uid" } ], "HRCondition": [ "Quora Account Owner" ], "tips": { "message": "When you successfully log in, please click the 'Start' button to initiate the verification process." } } ``` Below is a detailed definition of the schema: * **issuer**: Name of data source, such as Twitter, Discord, etc. * **desc**: A detailed description of the schema. * **website**: Webpage link containing the specified APIs that return the data requiring verification. When a user initiates verification, the TransGate extension will display this page in the browser tab. * **APIs**: The RESTful APIs that return the specified data that needs to be verified. It is an array, meaning it can contain a series of APIs. * **host**: The host for the API. * **intercept**: Defines detail information of the API. The TransGate extension will perform 3P-TLS for the API that is defined here. * **url**: Absolute path for the URL of the API. * **method**: HTTP method for the API. * **query**: Refer to query parameters in the HTTP request header. * **key and value**: Specify the key and value for the query. For instance, in the URL `https://...?needBalanceDetail=true`, it should be defined as `"needBalanceDetail": "true"`. * **verify**: If the key and value need to undergo zero-knowledge verification, the value should be true or false. * **header**: Refer to header parameters in the HTTP request header. * **key and value**: Specify the key and value for the header. For instance, header `graphql-operation: AvatarMenuQuery`, it should be defined as `"graphql-operation": "AvatarMenuQuery"`. * **verify**: If the key and value need to undergo zero-knowledge verification, the value should be true or false. * **body:** Refer to body in the HTTP request. * **key and value**: Specify the key and value for the body. * **verify**: If the key and value need to undergo zero-knowledge verification, the value should be true or false. * **assert**: Defines the verification conditions. * **key**: Selector for the verified data field in JSON. Keys are separated by "|". * **value**: The value is used for comparison with the data associated with the key defined above. * **operation**: The assertion condition should be one of the following: >, <, =, >=, <=, !=, in, contains. * **nullifier**: Selector for the unique identifier field in JSON in the data source, such as uid, id, etc. * **HRCondition**: Descriptions for each assertion. * **tips**: User tips which is displayed in the bottom right corner of the data source website. Developers can refer to [existing schemas](https://github.com/zkPassOfficial/zkPass-tutorial-examples/tree/main/schemas) as a guide to create their customized schemas adhering to the established standards. After crafting the schema, developers can utilize the [zkPass-Schema-Validator Chrome extension](https://chromewebstore.google.com/detail/kpcbjghknfclbkejkdllpjhhheppaoca) along with the data source website to validate it. Once successfully validated, developers can deploy the schema within the[ zkPass dev center](https://dev.zkpass.org) for integration into their projects. # Quick Start for Creating Custom Schema ### Login zkPass dev center and create custom schema *** Login in [zkPass dev center](https://dev.zkpass.org), create a project and add a schema.
Click on "Add Custom Schema". If you haven't installed the [zkPass Schema Validator](https://chromewebstore.google.com/detail/kpcbjghknfclbkejkdllpjhhheppaoca), please click "install" to install the extension first.
Enter the schema name, select the category, paste your custom schema into the JSON schema field, and then click "Check Schema." The website specified in your schema JSON will be opened.
If the schema validation is successful, you will observe the 'Check Pass' button at the bottom.
Upon clicking the 'Check Pass' button, you will be redirected back to the [zkPass dev center](https://dev.zkpass.org) and presented with a success modal. Then, you can submit your schema.
Congratulations, you have successfully generated the schema. You can now seamlessly integrate it into your project.
If the schema validation is failed, you will observe the 'Check Error Message' button at the bottom.
Upon clicking the 'Check Error Message' button, you will be redirected back to the [zkPass dev center](https://dev.zkpass.org) and presented with a error modal. Then, you can correct your schema based on error messages.
### Tips for writing a schema json file on Chrome *** Open the website you are targeting, navigate to the page containing the desired information, right-click on the page, and choose "inspect."
Select the "Network" tab, then refresh the page to capture all the HTTP requests. You can use the "Fetch/XHR" tag to filter the RESTful APIs.
Locate the APIs that provide the desired information. Click on each of them, then click "Headers" tabs to review the request details to identify the **host** and **intercept** for the schema.
Click "Preview" tag to review the response details to identify the **assert** and **nullifier** for the schema.
# API References ### **Constructor** > TransgateConnect(appid) #### **Parameters** > `appid`(string) - project appid ### **Instance Methods** * `isTransgateAvailable`() - Whether the user has installed the TransGate extension. * `launch(schemaId, address)` - Initiate the validation of the schema corresponding to the schemaId then return the result. * **Parameters** * `schemaId`(string) - The schema ID that added in the project. * `address`(string) - Optional, specify a user address to be included in the final proof, confirming its relevance or ownership. * **Return** * `allocatorAddress`(string) - The address of the allocator node. * `allocatorSignature`(string) - Signature of the task meta data by the allocator node. * `publicFields`(Object) - Values of public fields defined in schema. * `publicFieldsHash`(string) - Hash of public field values. * `taskId`(string) - Unique id of the task allocated by the allocator node. * `uHash`(string) - Hash value of user unique id in the data source. * `validatorAddress`(string) - The address of the validator node. * `validatorSignature`(string) - The signature of the verification result by the allocator node. * `recipient`(string) - Optional, when calling the `launch` function and passing in the address, it will return this value. # Error Handling During the verification process, if an error occurs, the JS-SDK will throw the error. The following list describes the possible error throws from JS-SDK.
Error CodeDescription
100000The verification node does not match the node assigned to the task.
100001The user does not installed the TransGate
100002Illegal appid
100003Schema id dose not exist
100004Request task info error
100005Can not connect the verify node
110001User do not meet the requirements
110002The user canceled the verification
110003An unexpected error was encountered
DApps should catch the error and handle it appropriately. # References Extension JS-SDK: Examples: [https://github.com/zkPassOfficial/zkPass-tutorial-examples](https://github.com/zkPassOfficial/zkPass-tutorial-examples/tree/main) # Integration on Intract Quest ## Introduction [Intract](https://www.intract.io/) is a gamified Web3 rewards platform designed to integrate with existing marketing strategies and campaigns, aiming to boost user engagement and loyalty. It offers a variety of tools to help businesses increase sales, encourage user-generated content, and enhance brand engagement through gamified marketing campaigns. Users participate in quests to explore new Web3 projects and earn rewards, making it an effective tool for user acquisition and community engagement​. Intact has integrated zkPass as a ZK Attestation oracle. This integration enhances Intract's capabilities by allowing it to leverage zkPass's zero-knowledge proof technology for secure and private data verification. zkPass enables users to attest to various types of data (like identity, financial records, or social interactions) without exposing the underlying information, ensuring privacy and integrity. ## Prerequisites * Intract Account: Ensure you have an active [Intract account](https://docs.intract.io/v/product-guide/getting-started/set-up-your-community-hub) and enable to enter [project dashboard](https://app.intract.io/app/campaign/quests). * Knowledge of Zero-Knowledge Proofs (ZKPs): Familiarity with ZKPs and their applications in Web3 is beneficial. Free free to check the [Technical Overview](https://github.com/teddypudgy/zkPass-documentation/blob/main/overview/technical-overview/README.md) of zkPass to understand the technoloies we use. ### Step-by-Step Guide #### 1. Setting Up Your Campaign on Intract **1.1. Access the Project Dashboard** * Log in to your Intract account and navigate to the [project dashboard](https://app.intract.io/app/campaign/quests). **1.2. Create a New Campaign** * Click on "Create Campaign" and fill in the necessary details such as campaign name, description, and objectives. #### 2. Configure zkPass Attestation Schemas **2.1. Define Attestation Requirements** * Specify the types of data you want to verify (e.g., CEX KYC, balance, identity, trading history, VIP levels). * Set the zero-knowledge proofs required for the attestation. **2.2. Select Attestation Schema** * Configure the attestation parameters within the Intract platform. * You can refer to the schema available in the [zkPass attestation market](https://portal.zkpass.org/attestation/market) and contact the [Support Team](https://t.me/aytoast) to add it to the options list.
**2.3. Design the Quest** * Structure the quest steps to guide users through the attestation process. * Define the rewards for completing the attestation. #### 3. Launch the Quest * Review the quest details and attestation settings. * Test and make the quest live for users to participate. ### Conclusion Leveraging zkPass Attestation in Intract provides a secure and private way to verify user data, enhancing the overall user experience and trust in your platform. By following this guideline, you can effectively implement and manage zkPass attestations, ensuring successful and engaging campaigns. For more detailed information on specific steps, please refer to the [Intract documentation](https://docs.intract.io/v/product-guide). # ZKP Introducing $ZKP, the Utility Token of the Verifiable Internet $ZKP is launching across multiple global trading venues. Listing availability may vary by exchange and jurisdiction. Please refer only to zkPass official channels for confirmed and up-to-date information. Users should interact **only** with the verified $ZKP contract addresses published by zkPass. zkPass will never request private keys, seed phrases, or off-platform transfers. Any unofficial links or contracts should be treated as unsafe. **Verified Contract Addresses** **Ethereum (Mainnet)**\ **BNB Smart Chain (BSC)**\ **Base (Mainnet)**\ $ZKP is a standard ERC-20 token. All cross-chain deployments follow LayerZero’s OFT standard, ensuring a unified total supply, consistent state across supported networks, and secure omni-chain messaging. Please verify the contract addresses above when integrating or interacting with the token.
The internet has always been built on information, but not on verifiable truth. For decades, online data has been visible rather than verifiable. Screenshots can be forged, credentials fabricated, and trust has relied on assumption instead of proof. zkPass and its zkTLS protocol redefine this foundation. For the first time, private Web2 data such as financial records, identity attestations, learning streaks, or travel histories can be transformed into cryptographic proofs that are portable, privacy-preserving, and verifiable across networks. At the center of this verifiable data economy stands $ZKP, the native utility token that enables settlement, validation, and coordination within the zkPass ecosystem. ## Token Overview * Ticker: $ZKP * Token Standard: ERC-20 * Total supply: 1,000,000,000 * Supply Type: Fixed, no inflation * Deflationary Model: Portion of settlement fees burned to keep supply deflationary. * Buyback Mechanism: DAO-led periodic buybacks funded by protocol revenue. ### Token Utility 1. **Settlement Medium**\ $ZKP is the native functional unit required for proof settlement and verifier execution within the zkPass ecosystem. 2. **Validator Collateral**\ Validators post $ZKP as operational collateral to ensure network correctness, uptime, and reliability. 3. **Network Credits**\ $ZKP operates as on-chain credits for recording and accounting network contributions, including verifiable computation and integrations. 4. **Service Access**\ Used by enterprises and developers to interface with zk-native verification APIs and privacy-preserving data infrastructure. 5. **Cross-System Verifiability and Governance**\ $ZKP supports decentralized coordination and acts as the trust layer linking verifiable systems, while sustaining audits and other non-profit maintenance activities. ### Token Allocation and Vesting Schedule
* **Community — 48.5%**\ \&#xNAN;*(12.5% unlocked at TGE, 6% vesting linearly over the first 3 months, and 30% vesting monthly over 5 years starting from TGE)*\ Allocated for ecosystem growth, including verifiable airdrops, network incentives, community sales, exchange-related marketing, and strategic partnerships. * **Early Investors — 22.5%**\ \&#xNAN;*(12-month cliff followed by 18-month linear vesting)*\ Allocated to strategic and institutional partners who supported early-stage protocol development. * **Core Contributors — 14%**\ \&#xNAN;*(24-month cliff followed by 24-month linear vesting)*\ Reserved for founding members, engineers, researchers, and key operational contributors driving the zkPass network. * **DAO Treasury — 10%**\ \&#xNAN;*(5-year linear vesting)*\ Dedicated to long-term network sustainability, governance, ecosystem grants, and emergency reserves. * **Liquidity — 5%**\ \&#xNAN;*(100% unlocked at TGE)*\ Reserved for market liquidity provision and network bootstrapping.
At launch, circulating supply is limited to community participation and liquidity, with 0% unlocked for the team or investors. ### The Credibility Flywheel → Web2 and Web3 converge, unlocking vast data universes.\ → Data moves through privacy-preserving verification.\ → Verified interactions create real utility and new applications.\ → Utility drives adoption by users and enterprises across ecosystems.\ → Adoption fuels validator participation and network incentives.\ → Growing value accelerates integrations and data onboarding.\ → Each new data source restarts the cycle, faster, stronger, and broader. Each rotation compounds utility, liquidity, and credibility,\ turning trust into energy and energy back into trust. zkPass is not just building a product.\ It is engineering a self-sustaining trust economy for the digital world,\ the coordination layer for every system that must prove before it can act. ### Conclusion The Verifiable Internet is emerging. zkPass provides the cryptographic infrastructure that transforms private data into verifiable proof without revealing its contents. $ZKP enables this coordination by serving as the functional medium for settlement, verification, and protocol participation. From visible data to verifiable truth, $ZKP is the coordination layer that makes it possible. ::: info #### Disclaimer $ZKP is a utility token used exclusively within the zkPass network for operational purposes such as proof settlement, validator staking, and community participation. It does not represent equity, ownership, or profit rights in any entity and is not intended for investment or speculation. Availability of $ZKP may be limited in certain jurisdictions, including the United States. All governance and protocol administration are conducted under zkPass DAO, a non-profit Swiss Association responsible for ecosystem stewardship. ::: # Governance zkPass DAO Governance Framework **Version 1.0 – December 2025**\ **Jurisdiction:** Swiss Association (Zurich, Switzerland)\ **Entity:** zkPass DAO Association **Governance Portal**: *** zkPass DAO is organised as a Swiss Association under Articles 60 et seq. of the Swiss Civil Code. The Association is established as a non-profit governance entity with the purpose to: * steward the zkPass protocol and its on-chain and off-chain treasury; * safeguard the long-term interests of the zkPass community; and * provide a transparent, accountable governance framework for protocol decisions, ecosystem incentives, and strategic direction. The Association does not engage in commercial operations and does not operate as an exchange, investment fund, or custodian. Its role is coordination and governance, not profit generation. ### Governance Philosophy: Proof-Based Participation zkPass DAO is founded on the principle that participation and influence should also be earned through verifiable contribution, not only capital dominance. Traditional DAO governance has repeatedly faced structural issues: * governance captured by token concentration alone; * sybil attacks and unverifiable identities; * meaningful contributors remaining underrepresented. zkPass DAO is designed to address these challenges by anchoring governance to both capital & verifiable participation, using zkPass proofs and reputation signals instead of social noise or capital alone. At the centre of this framework is $ZKP, a coordination token used to: * participate in governance decisions; * align treasury deployment with ecosystem growth; and * connect protocol development with community incentives. Capital matters, but credibility, contribution, and verifiable action matter alongside it. ### Organisational Structure The governance of zkPass DAO is structured into clearly defined bodies with limited and well-scoped authority: **General Assembly (Members / Token Holders)** * Comprises Association members and, functionally, $ZKP holders participating in governance. * Approves major protocol parameters, treasury allocations, and structural changes. **Core Contributor Committees** * zkPass DAO currently operates under a progressive decentralization model. * Founding contributors execute day-to-day operations and treasury mandates as approved by governance. * Responsibilities will transition over time to broader, community-elected structures as participation scales. **Advisory Council** * A small group of external advisors providing non-binding guidance on risk, compliance, and strategy. * Holds no unilateral authority over treasury or protocol contracts. **Treasury Multisig Committee** * Controls the on-chain treasury via a 4-of-5 multisignature Safe wallet. * Signers are selected by governance and represent different functional domains. * The committee’s role is purely executory: it cannot allocate funds without DAO approval. This structure ensures that no single founder or company controls the DAO, and all authority is derived from governance decisions. ### Governance Process **Proposal Initiation** Proposals may be submitted by: * any address holding at least **100,000 $ZKP** at the applicable Snapshot block; or * Core Contributors acting within their authorized scope under the DAO’s progressive decentralization framework. Proposal submission rights are managed through Snapshot configuration and DAO-appointed roles. Governance-Qualified Participants (GQPs) do **not** possess independent proposal submission rights by default and participate primarily through discussion and voting. All proposals must satisfy DAO-defined quality, eligibility, and moderation requirements and are published publicly prior to voting. **Discussion & Voting** * Each proposal remains open for a minimum of 7 days for discussion and voting. * Community members may provide feedback and commentary through Snapshot or governance forums. * Core Contributors may provide non-binding technical, security, legal, or financial assessments. * Proposal authors may clarify or refine context without altering fundamental intent or execution scope. Voting is conducted via Snapshot or on-chain mechanisms as specified in the proposal. Voting power is primarily determined by $ZKP holdings, with optional reputation-based mechanisms applied only where explicitly defined. **Execution** Upon meeting quorum and approval thresholds: * execution is performed by the Treasury Multisig Committee or other authorized executors; * execution strictly follows the approved proposal; and * all execution transactions are publicly disclosed and auditable. The execution body holds no discretionary authority beyond implementing approved outcomes. ### Voting Model **Baseline Rule** * 1 $ZKP = 1 vote for standard governance actions. **Proof-Based Governance Layer** zkPass introduces an additional governance dimension: * addresses may accrue verifiable proofs based on sustained contributions; * reputation may adjust voting weight or enable reputation-gated votes; and * sybil resistance is enhanced through zkPass off-chain proofs without revealing personal data. Reputation-informed mechanisms are opt-in, explicitly scoped, and proposal-specific, and do not override quorum or approval requirements. ### Quorum & Approval Thresholds **Proposal Classification** Proposals are classified as **Standard Proposals** or **High-Impact Proposals**. **Standard Proposals** Routine or operational decisions that are low-risk or reversible, including: * non-critical protocol parameter changes; * ecosystem grants and programs within approved budgets; * contributor onboarding and working groups; * community initiatives and partnerships; and * governance process improvements without constitutional impact. **High-Impact Proposals** Decisions materially affecting treasury integrity, governance structure, or legal status, including: * major treasury reallocations above defined thresholds; * changes to quorum, voting rights, or governance mechanisms; * amendments to constitutional documents; * changes to legal structure or jurisdiction; * material changes to $ZKP token economics; and * dissolution, merger, or transfer of protocol control. **Quorum Requirements** A proposal is valid if **either** of the following quorum conditions is met: * At least **4% of the circulating $ZKP supply** participates in the vote. * At least **1,000 Governance-Qualified Participants (GQPs)** cast a vote. **Governance-Qualified Participants (GQPs)** GQPs are a restricted subset of zkPass-verified participants whose proofs demonstrate sustained and governance-aligned contributions, including: * zkPass-verified authors producing eligible content; * protocol contributors and maintainers; * ecosystem integration partners; * DAO-recognized contributors or working group members; and * participants meeting defined reputation or VRS-based thresholds. Low-engagement or purely transactional actions (e.g. airdrop claims or single proofs) do **not** qualify. Eligibility criteria are defined in the Governance Charter and may be updated through governance. Each GQP counts as one vote for the purpose of participant-based quorum only. **Approval Thresholds** Once quorum is met: * **Standard Proposals:**\ Require a simple majority (≥ 50%) and may satisfy quorum via either mechanism. * **High-Impact Proposals:**\ Require a supermajority (≥ 67%) and must satisfy the **token-based quorum**. Participant-based quorum supports governance continuity but does not replace token-weighted safeguards for high-impact decisions. ::: info Exact quorum thresholds, participant definitions, and approval requirements are specified in the Governance Charter and may be adjusted over time through a valid governance process. ::: ### Treasury Management & Controls **Treasury Structure** * Secured via a 4-of-5 multisignature Safe wallet. * Designed to balance decentralization and operational efficiency. **Signer Composition** * Technology Representative * Operations Representative * Legal / Association Representative * Ecosystem Representative * Community Representative (DAO-elected) **Execution Constraints** * Transactions may only be executed following DAO-approved proposals. * Limited operational allowances are defined and capped by policy. **Controls & Transparency** * Transactions executed only after DAO approval. * Limited operational allowances are capped by policy. * All treasury addresses are public. * Periodic reports disclose inflows, outflows, runway, and allocation categories. Treasury funds are used exclusively to support the ecosystem. ### Compliance Positioning & Role of $ZKP From a regulatory and listing-review perspective: * zkPass DAO is a non-profit Swiss Association focused on coordination and governance. * $ZKP is a governance and coordination token, not equity and not a claim on profits or assets. * DAO participation is voluntary, and influence is earned through verifiable contribution, not promised returns. #### Closing Statement By anchoring governance in verifiable participation rather than assumption, zkPass DAO aims to demonstrate a higher standard for decentralized coordination, one that balances decentralization, accountability, and regulatory awareness while remaining community-driven. # VAAP Today, we are excited to announce the launch of the **Verifiable Application Acceleration Program (VAAP),** a global initiative to empower developers, enterprises, and protocols to build the next generation of verifiable applications on zkPass. This program is backed by $5.5M allocated from our Q2 2025 strategic private round, supported by a group of visionary Web3 investors who believe in the future of the Verifiable Internet. ### Why VAAP? Over the past two years, zkPass has grown into the leading verifiable data infrastructure: * **1M+ unique attested users** across multiple integrations * **200M verifiable computations (TVC)** completed * **80+ ecosystem integrations** spanning DeFi, social, gaming, DePIN, and AI * Trusted by global platforms including **Binance, Coinbase, Duolingo, Uber, and LinkedIn** This momentum makes it clear: the time has come to move beyond protocol foundations and accelerate **real-world adoption** through verifiable applications. ### What is a Verifiable Application? Not another dApp. A **verifiable application** is any system that runs on **proofs instead of promises**. Instead of trusting screenshots, disclosures, or centralized APIs, applications consume cryptographic attestations that guarantee both privacy and integrity. * **zkKYC** lets users prove regulatory compliance without exposing personal records. * **Under-collateralized lending** allows borrowers to demonstrate income or account balances without handing over bank statements. * **Prediction markets** settle outcomes on-chain based on verifiable real-world data rather than centralized feeds. * **Financializing learning data** turns a Duolingo streak, a GitHub commit history, or an online certification into a verifiable digital asset. * **Parametric insurance** enables payouts based on weather or flight data proven directly from Web2 sources. * **Reputation-driven advertising** makes campaigns target audiences based on verifiable reputation, not on leaked or harvested profiles. Verifiable applications redefine what data means. Data is no longer a static entry locked inside a database or exposed to intermediaries. * It becomes **portable**, able to move across systems with integrity preserved. * It becomes **private**, revealing only what is necessary and nothing more. * It becomes **liquid**, usable as an economic primitive in financial, social, and AI-native ecosystems. This is the foundation of the **Verifiable Internet**: a world where applications no longer process raw data, they process **truth**. ### What VAAP Offers The **VAAP framework** provides full-stack acceleration for builders: * **Technology enablement**: direct access to zkPass SDKs, DevHub, and Schema Market incentives for rapid proof integration * **Go-to-market support**: distribution through the zkPass partner network, co-marketing, and ecosystem exposure * **Enterprise and compliance support**: connections to institutions, exchanges, and advisory partners to accelerate adoption * **Funding alignment**: strategic co-investment opportunities for projects with strong proof-of-business ### Commitments for VAAP Projects In joining VAAP, projects are expected to reinforce the zkPass ecosystem by: * Building with **commercial orientation** and clear revenue models * Contributing back via **protocol revenue sharing** * Driving **$ZKP adoption** across settlement, access, or staking models * Designing **verifiable-first**, where proofs are the foundation of trust ### Looking Ahead As we continue to scale, we believe **verifiable data is the missing trust layer of the internet**. With zkTLS, any developer can transform web data into proofs that preserve both privacy and integrity. The Verifiable Application Acceleration Program gives us and our partners - the platform, resources, and alignment to make verifiable applications the new standard. *** 🌍 **Applications for VAAP are now open.** 👉 Apply here: Let’s build the Verifiable Internet together. # Introduction Introducing the zkPass × Binance Wallet Booster Campaign zkPass has officially joined the **Binance Wallet Booster Program**, inviting users to earn from a **30,000,000 $ZKP** reward pool distributed across multiple phases. Powered by zkPass protocol, participants can complete social tasks, generate **private, verifiable proofs** directly from their Binance Wallet - proving facts without exposing any data. *** ### **Campaign Structure** The campaign spans both **Pre-TGE and Post-TGE** phases, distributing a total of **30,000,000 $ZKP (3 % of total supply)** across several rounds.
Phase 1: November 5 (10:00 UTC) → December 3 (10:00 UTC)【Ended】 * **Allocation:** 10,000,000 $ZKP (1 % of total supply) * **Unlock:** Fully redeemed and 100% unlocked at TGE * **Focus:** User onboarding & Client-side zkproof experience
Phase 2: April 28 (10:00 UTC) → May 11 (10:00 UTC)【Ended】 * **Allocation:** 5,000,000 $ZKP (0.5 % of total supply) * **Unlock:** Fully redeemed and 100% unlocked at TGE * **Focus:** User onboarding & $ZKP delegation program
* **Phase 3:** Jun 11 - Jun 25 2026 【Coming】 * **Allocation:** 5,000,000 $ZKP (0.5 % of total supply) * **Unlock:** Fully redeemed and 100% unlocked after Phase 4 campaign ends * **Focus:** User onboarding & $ZKP delegation program
Cover image
Phase 1 Tutorial/pages/3VUNe0nhdTAGuti73r70/files/H5vUxKH3JYhQReaIR4WB
Phase 2 Tutorial/pages/KyCzW1vSXFQ9VIfrlM6q/files/jFrf3if0Sq4WSg7PtdSA
Phase 3 Tutorial/pages/JDIyZSTYRx3a85owdswZ/files/H5vUxKH3JYhQReaIR4WB
###
What is zkPass? zkPass is a zkTLS oracle protocol that enables users to generate zero-knowledge proofs from Web2 data sources (such as Binance, Duolingo, or LinkedIn) without revealing private information. It makes Web2 data verifiable on-chain.
What is the zkPass × Binance Wallet Booster Program? The Booster Program is a multi-phase campaign where Binance Wallet users can complete social, proof-based, or delegation tasks to earn rewards in $ZKP.\ Each phase focuses on different aspects of zkPass technology and network participation.
Who can join the campaign? This campaign is open to **Binance Keyless Wallet** users with **≥ 61 Alpha Points.** You can check your Alpha Points under the **“Alpha”** tab in the Binance Wallet app.
How do I get a Binance Keyless Wallet? If you’re using a regular Binance Wallet, simply open your app → **Profile → Keyless Wallet → Create.** Follow the guided steps; setup takes under a minute.
Do I need to hold any tokens to join? It depends on the phase: * **Phase 1:** Some tasks require generating verifiable proofs, which may require a small amount of **BNB** (\~$0.3) for gas fees. * **Phase 2:** Delegation tasks require **$ZKP** (≥ 150 or ≥ 300 ZKP from different tasks). You’ll also need a small amount of **BNB** for gas.
How long does verification take? * **Phase 1 proof tasks:** Usually within seconds. * **Phase 2 delegation tasks:** Verified automatically once the delegation transaction is confirmed on-chain. If status does not update, refresh the Booster page or reconnect your wallet.
How are rewards distributed? * **Equal Split Pools:** Shared equally among qualified users. * **Lucky Draw:** Randomized allocations for users who complete all tasks. * Rewards unlock according to the campaign phase rules. Reward mechanics: All rewards are credited **directly to your Binance Keyless Wallet** after each phase concludes.
My tasks failed, what should I do? Try the following steps: * Ensure your wallet is connected * Check your internet connection * Update your app to the latest version * Clear cache and retry * For persistent issues, visit zkPass Support on Discord
Is my data ever exposed to zkPass or Binance? Never. * **Phase 1:** All proofs are generated **locally on your device** using zkPass’s VOLEitH algorithm. No data is transmitted or stored. * **Phase 2:** Delegation is an **on-chain action**; only the delegation amount and validator choice are recorded on-chain. Neither zkPass nor Binance has access to your underlying Web2 credentials or personal data.
Where can I get support? For any questions or troubleshooting, join the official community: * Discord:
### **About zkPass** zkPass is building the **Verifiable Internet** through its zkTLS oracle protocol - enabling users to generate cryptographic proofs from private Web data (e.g. Binance, LinkedIn, Duolingo, and more) without revealing the underlying information. It powers use cases across DeFi, AI, identity, reputation, and data validation, with over 200 million verifiable computations completed to date. * 🌐 Website: * 🕊 X (Twitter): [@zkPass](https://twitter.com/zkPass) * 💬 Discord: # Phase 1 Tutorial: zkPass Booster Campaign Phase 1 Learn how to complete all tasks in the **zkPass × Binance Wallet Booster Campaign** and unlock your share of **10,000,000 $ZKP** rewards. This step-by-step guide will walk you through joining the campaign, completing both social and proof tasks, and verifying your results on Binance Wallet. *** ### **1 – Join the Campaign** 1. Open the **Binance Wallet App** on your mobile device. 2. Navigate to **Discover → Booster**, or tap the **zkPass** banner on the homepage. 3. Tap **Join Campaign** to activate participation. 4. Your **task dashboard** will appear automatically. You’ll see two categories of tasks: * **Social Tasks:** Follow [zkPass](https://x.com/zkPass) on X and repost the [campaign announcement](https://x.com/zkPass/status/1986038386214486326). * **Proof Tasks:** Complete three verifiable proof missions using zkPass for on-chain rewards. Each verified task earns a proportional share of the $ZKP reward pool. ### **2 – Social Tasks (Engage with zkPass on X)** 1. **Follow zkPass on X** – Follow [@zkPass](https://twitter.com/zkPass) to stay updated on campaign news. 2. **Repost the Official Campaign Post** – Repost the [“zkPass × Binance Wallet Booster Program” announcement](https://x.com/zkPass/status/1986038386214486326). After connecting your X account, Binance Wallet automatically verifies both actions. ### **3 – Proof Tasks (Generate Your Proofs with zkPass)** All proof generation happens **locally on your device** through the **zkPass zkTLS protocol**, guaranteeing that **no personal data ever leaves your browser.** #### **Step 1 – Open a Proof Task** * In the campaign dashboard, click **“Complete”** next to any proof task to begin. * You’ll be redirected to the zkPass proof generation interface. #### **Step 2 – Choose Your Proof Schema** Scroll to **“CHOOSE YOUR PROOF SCHEMA”** and select one of the following: 1. **Alpha-Powered zkProof** – Experience zkPass’s VOLEitH proof engine directly inside Binance Wallet. 2. **Wallet Address Proof (≥ $100)** – Verify that your wallet balance equals or exceeds $100 USD without exposing your actual holdings. 3. **Binance Booster Proof (≥ 2 Claims)** – Generate a proof confirming that you’ve successfully claimed rewards from any two previous Binance Booster campaigns (Hemi, OpenLedger, HoloWorld, Astra Nova). #### **Step 3 – Generate Your Proof** 1. Click **Generate Proof** to start computation. 2. zkPass will execute the VOLEitH algorithm locally and produce your zero-knowledge proof within seconds. 3. When finished, you’ll see the confirmation: **✅ Proof generated successfully.** > 💡 Tip: Keep at least $1 in BNB for minimal on-chain gas fees during proof submission. #### **Step 4 – Submit and Return to Binance Wallet** * After proof generation, return to the Binance Wallet Booster page. * The task will show as pending verification until Binance Wallet confirms your zkPass proof on-chain. ### **4 – Verify Your Tasks on Binance** 1. Back on the **Booster Campaign** page, click **Complete** beside each finished proof task. 2. Binance Wallet automatically verifies your zkPass proofs. 3. Once validated, the task status updates to **Completed ✅**, and your reward is queued for distribution. *** ### **Completion & Reward Unlock** * All completed tasks contribute to the **Equal Split reward pool**, distributed evenly among qualified participants. * Users who finish *all* five tasks (2 social + 3 proof) automatically enter the **Lucky Draw Round** to share an additional **3 million $ZKP**. * Phase 1 rewards will be **fully unlocked at TGE**. #### **Quick Reminders** * Proofs are powered by **zkPass - privacy-preserving and verifiable.** * Use only the **Binance Keyless Wallet** for eligibility. * Double-check your balance (≥ $100) before starting Wallet Proof. * If verification fails, refresh the page, reconnect your wallet, or visit zkPass Discord for assistance. *** #### FAQ
Who can join the zkPass Booster Campaign? All **Binance Keyless Wallet users** with at least **61 Alpha Points** are eligible to participate. You can check your Alpha Points in the **“Alpha”** tab inside Binance Wallet.
Do I need any tokens to participate? Yes. * You’ll need at least **$100 in total wallet balance** to complete the **Wallet Balance Proof** task. * Keep around **$1 in BNB** for minimal gas fees when generating or submitting proofs.
What is VOLEitH proof generation? **VOLEitH** is zkPass’s proprietary client-side proof algorithm. It allows you to generate zero-knowledge proofs directly on your device — no downloads, no extensions, and no data ever leaves your browser.
What if I don’t see the “Join Campaign” button or task list? Make sure: * You are using the **latest version** of Binance Wallet. * You are logged in with a **Keyless Wallet account**. * The campaign has officially started (after **Nov 5, 10:00 UTC**). If the issue persists, try refreshing or restarting the app.
How long does proof verification take? Usually **within seconds**. If a task remains pending for more than a few minutes, refresh the campaign page or reconnect your wallet. For persistent issues, contact support via [zkPass Discord](http://discord.gg/zkpass)
I completed a proof but it’s not verified on Binance. What should I do? * Confirm that the proof generation showed “✅ Proof generated successfully.” * Reconnect your wallet and click **Complete** again on Binance Wallet. * If the problem continues, clear cache or switch networks (Wi-Fi → mobile).
What happens if I don’t have enough Alpha Points?1 You won’t be able to join the campaign until you reach **≥ 61 Alpha Points**. Alpha Points are earned through your wallet activity and Alpha token holdings in Binance Wallet.
Can I use a regular Binance Wallet instead of Keyless? No. Only Keyless Wallet users can participate in Booster campaigns. You can create one in Binance Wallet via Profile → Keyless Wallet → Create.
Can I participate with multiple wallets or accounts? Each Binance Keyless Wallet address can participate once per phase. Duplicate submissions or suspicious activity may lead to disqualification.
When will I receive my rewards? All rewards earned in Phase 1 (Nov 5 – Dec 3) will be distributed and fully unlocked at TGE. Future phases may include additional rewards with different vesting conditions.
What is the Lucky Draw? Users who complete all five tasks (2 social + 3 proof) automatically qualify for a random Lucky Draw round. A total of 3,000,000 $ZKP will be shared among winners selected by random draw.
What if I lose connection or close the app during proof generation? You can safely restart the Binance Wallet app and re-open the zkPass proof page. Proofs are computed locally — your progress won’t affect your wallet or privacy. Simply restart the proof process.
Are there any risks or lock-ups? Phase 1 rewards are unlocked at TGE. However, later phases may include a temporary lock-up period defined by zkPass and Binance Wallet. Please review campaign details carefully before participating.
Where can I get help or report issues? For troubleshooting, updates, or general questions, reach out via: Discord: Twitter (X): @zkPass
# Phase 2 Tutorial: zkPass Booster Campaign Phase 2 Welcome to **Phase 2** of the zkPass × Binance Wallet Booster Program. In this phase, eligible users can **delegate $ZKP in Binance Wallet** and earn rewards from a **5,000,000 $ZKP** pool. This guide explains how to join the campaign, complete tasks, and understand the delegation rules inside Binance Wallet. *** ### **1 – Join the Campaign** 1. Open the **Binance Wallet App** on your mobile device. 2. Navigate to **Discover → Booster**, or tap the **zkPass** banner on the homepage. 3. Tap **Join Campaign** to activate participation. 4. Your **task dashboard** will appear automatically. You’ll see two categories of tasks: * **Social Tasks:** Follow [zkPass](https://x.com/zkPass) on X and repost the [campaign announcement](https://x.com/zkPass/status/2049017965342028102). * **Delegation Task:** Delegate $ZKP and keep it delegated for the required holding period. Each verified task contributes to your share of the reward pool. To participate in the delegation task, you may obtain $ZKP from supported exchanges or through the official contract addresses listed below. ::: info BNB Smart Chain (BSC) ::: ### **2 – Social Tasks (Engage with zkPass on X)** 1. **Follow zkPass on X** – Follow [@zkPass](https://twitter.com/zkPass) to stay updated on campaign news. 2. **Repost the Official Campaign Post** – Repost the “[zkPass × Binance Wallet Booster Program](https://x.com/zkPass/status/2049017965342028102)” announcement. After connecting your X account, Binance Wallet automatically verifies both actions. ### **3 – Delegate Your $ZKP** Delegation connects your wallet to the zkPass verifier network. Your delegation amount determines which reward tier you qualify for: | **Requirement** | **Reward Pool** | | -------------------------------------------------------------------------------------------------------------------------- | --------------- | | Apr 28 to May 4 (10AM UTC) Delegate exactly 220 $ZKP and keep it for 7 consecutive days | 1,200,000 $ZKP | | May 4 to May 11 (10AM UTC) Delegate exactly 450 $ZKP for 7 days. Either add 230 to an existing 220, or delegate 450 fresh. | 3,000,000 $ZKP | | Lucky Draw: complete all tasks to qualify | 800,000 $ZKP | Users are verified once the minimum required amount is delegated during the active period. #### **Step 1 – Open the Delegation Task** * On the Booster campaign page, tap **“Complete”** to enter the [delegation flow](https://delegation.zkpass.org). #### **Step 2 – Delegate your $ZKP tokens** * Tap **Delegate** button on the active period's card — the amount is pre-set. * Confirm the on-chain transaction. * Once confirmed, the task will show a **Successful** status. > 💡 Tip: Keep some BNB for gas fees. #### **Important delegation rules (must read)** * **One unified delegate**. All delegated $ZKP is managed as a single balance with a single unlock time — not divided by period. * **Lock period**. Each deposit sets a 7-day lock on your entire balance: * **First deposit**: 7 days from the transaction. * **Deposit during an active lock**: **the lock extends to remaining time + 7 days from the new deposit** — applied to all tokens, including previously delegated ones. * **Deposit after unlock**: a fresh 7-day lock starts. * **Redemption is all-or-nothing**. You must redeem your entire available balance in a single transaction. Partial withdrawal is not supported. * **Early redemption is not possible**. The contract enforces the 7-day lock; you cannot withdraw sooner and therefore cannot lose eligibility by accident. ### **4 – Verify Your Tasks on Binance** * Return to the **Booster Campaign** page and tap **Complete** beside each finished task. * Binance Wallet automatically verifies your social tasks and delegation status. * Once validated, the task status updates to **Completed ✅**. *** ### **Completion & Reward Unlock** * **Rewards are calculated and distributed after Phase 2 ends**, based on the final eligible addresses in each reward pool. * **Period 1 (Apr 28 10:00 UTC to May 4 10:00 UTC):** 1,200,000 ZKP, equal split among all eligible addresses with at least 220 ZKP delegated * **Period 2 (May 4 10:00 UTC to May 11 10:00 UTC):** 3,000,000 ZKP, equal split among all eligible addresses with at least 450 ZKP delegated * **Lucky Draw:** 800,000 ZKP, distributed via randomized selection among eligible addresses *** #### FAQ
Who can join the zkPass Booster Campaign? This campaign is exclusive to **Binance Keyless Wallet** users who meet the **Binance Wallet Booster Program Phase 2** eligibility requirements (including Alpha Points thresholds shown in the Booster UI).
Do I need any tokens to participate? Yes. You need $ZKP on BNB Smart Chain, plus a small amount of BNB for gas. The delegation amount is fixed per period: * Period 1 (Apr 28 07:00 UTC – May 5 07:00 UTC): exactly 220 $ZKP * Period 2 (May 5 07:00 UTC – May 12 07:00 UTC): total of exactly 450 $ZKP (add 230 on top of your Period 1 delegate, or delegate 450 fresh) All $ZKP is locked together as a single delegate — see Delegation Rules for how the 7-day lock works.
What if I don’t see the “Join Campaign” button or task list? Make sure: * You are using the **latest version** of Binance Wallet. * You are logged in with a **Keyless Wallet account**. * The campaign has officially started. If the issue persists, try refreshing or restarting the app.
Can I redeem anytime? No. The contract locks your entire delegated balance for **7 days** after each deposit. Adding more tokens while a lock is active **extends it to remaining time + 7 days on the whole balance** — it does not reset to 7 days. When the lock ends, you must redeem your full balance in a single transaction (no partial redemption). For persistent issues, contact support via [zkPass Discord](http://discord.gg/zkpass)
What happens if I don’t have enough Alpha Points? You won’t be able to join the campaign until you reach **≥ 61 Alpha Points**. Alpha Points are earned through your wallet activity and Alpha token holdings in Binance Wallet.
Can I use a regular Binance Wallet instead of Keyless? No. Only Keyless Wallet users can participate in Booster campaigns. You can create one in Binance Wallet via Profile → Keyless Wallet → Create.
Can I participate with multiple wallets or accounts? Each Binance Keyless Wallet address can participate once per phase. Duplicate submissions or suspicious activity may lead to disqualification.
When will I receive my rewards? Rewards are distributed **after Phase 2 ends**, based on the final eligibility set of each reward pool.
What if I lose connection or close the app during delegation process? You can safely restart the Binance Wallet app and re-open the zkPass delegation page.
Where can I get help or report issues? For troubleshooting, updates, or general questions, reach out via: Discord: Twitter (X): @zkPass
# Phase 3 Tutorial: zkPass Booster Campaign Phase 3 Welcome to **Phase 3** of the zkPass × Binance Wallet Booster Program. In this phase, eligible users can **delegate $ZKP in Binance Wallet** and earn rewards from a **5,000,000 $ZKP** pool. This guide explains how to join the campaign, complete tasks, and understand the delegation rules inside Binance Wallet. *** ### **1 – Join the Campaign** 1. Open the **Binance Wallet App** on your mobile device. 2. Navigate to **Discover → Booster**, or tap the **zkPass** banner on the homepage. 3. Tap **Join Campaign** to activate participation. 4. Your **task dashboard** will appear automatically. You’ll see two categories of tasks: * **Social Tasks:** Follow [zkPass](https://x.com/zkPass) on X and repost the [campaign announcement.](https://x.com/zkPass/status/2064961132851589486) * **Delegation Task:** Delegate $ZKP and keep it delegated for the required holding period. Each verified task contributes to your share of the reward pool. To participate in the delegation task, you may obtain $ZKP from supported exchanges or through the official contract addresses listed below. ::: info BNB Smart Chain (BSC) ::: ### **2 – Social Tasks (Engage with zkPass on X)** 1. **Follow zkPass on X** – Follow [@zkPass](https://twitter.com/zkPass) to stay updated on campaign news. 2. **Repost the Official Campaign Post** – Repost the [“zkPass × Binance Wallet Booster Program” announcement](https://x.com/zkPass/status/2064961132851589486). After connecting your X account, Binance Wallet automatically verifies both actions. ### **3 – Delegate Your $ZKP** Delegation connects your wallet to the zkPass verifier network. Your delegation amount determines which reward tier you qualify for: | **Requirement** | **Reward Pool** | | -------------------------------------------------------------------------------------------------------------------------- | --------------- | | Jun 11 to Jun18 (7AM UTC) Delegate exactly 220 $ZKP and keep it for 7 consecutive days | 1,200,000 $ZKP | | Jun 18 to Jun 25 (7AM UTC) Delegate exactly 450 $ZKP for 7 days. Either add 230 to an existing 220, or delegate 450 fresh. | 3,000,000 $ZKP | | Lucky Draw: complete all tasks to qualify | 800,000 $ZKP | Users are verified once the minimum required amount is delegated during the active period. #### **Step 1 – Open the Delegation Task** * On the Booster campaign page, tap **“Complete”** to enter the [delegation flow](https://delegation.zkpass.org). #### **Step 2 – Delegate your $ZKP tokens** * Tap **Delegate** button on the active period's card — the amount is pre-set. * Confirm the on-chain transaction. * Once confirmed, the task will show a **Successful** status. > 💡 Tip: Keep some BNB for gas fees. #### **Important delegation rules (must read)** * **One unified delegate**. All delegated $ZKP is managed as a single balance with a single unlock time — not divided by period. * **Lock period**. Each deposit sets a 7-day lock on your entire balance: * **First deposit**: 7 days from the transaction. * **Deposit during an active lock**: **the lock extends to remaining time + 7 days from the new deposit** — applied to all tokens, including previously delegated ones. * **Deposit after unlock**: a fresh 7-day lock starts. * **Redemption is all-or-nothing**. You must redeem your entire available balance in a single transaction. Partial withdrawal is not supported. * **Early redemption is not possible**. The contract enforces the 7-day lock; you cannot withdraw sooner and therefore cannot lose eligibility by accident. ### **4 – Verify Your Tasks on Binance** * Return to the **Booster Campaign** page and tap **Complete** beside each finished task. * Binance Wallet automatically verifies your social tasks and delegation status. * Once validated, the task status updates to **Completed ✅**. *** ### **Completion & Reward Unlock** * **Rewards are calculated and distributed after Phase 3 ends**, based on the final eligible addresses in each reward pool. * **Period 1 (Jun 11 7:00 UTC to Jun 18 7:00 UTC):** 1,200,000 ZKP, equal split among all eligible addresses with at least 220 ZKP delegated * **Period 2 (Jun 18 7:00 UTC to Jun 25 7:00 UTC):** 3,000,000 ZKP, equal split among all eligible addresses with at least 450 ZKP delegated * **Lucky Draw:** 800,000 ZKP, distributed via randomized selection among eligible addresses *** #### FAQ
Who can join the zkPass Booster Campaign? This campaign is exclusive to **Binance Keyless Wallet** users who meet the **Binance Wallet Booster Program** eligibility requirements (including Alpha Points thresholds shown in the Booster UI).
Do I need any tokens to participate? Yes. You need $ZKP on BNB Smart Chain, plus a small amount of BNB for gas. The delegation amount is fixed per period: * Period 1: exactly 220 $ZKP * Period 2: total of exactly 450 $ZKP (add 230 on top of your Period 1 delegate, or delegate 450 fresh) All $ZKP is locked together as a single delegate - see Delegation Rules for how the 7-day lock works.
What if I don’t see the “Join Campaign” button or task list? Make sure: * You are using the **latest version** of Binance Wallet. * You are logged in with a **Keyless Wallet account**. * The campaign has officially started. If the issue persists, try refreshing or restarting the app.
Can I redeem anytime? No. The contract locks your entire delegated balance for **7 days** after each deposit. Adding more tokens while a lock is active **extends it to remaining time + 7 days on the whole balance** — it does not reset to 7 days. When the lock ends, you must redeem your full balance in a single transaction (no partial redemption). For persistent issues, contact support via [zkPass Discord](http://discord.gg/zkpass)
What happens if I don’t have enough Alpha Points? You won’t be able to join the campaign until you reach **≥ 61 Alpha Points**. Alpha Points are earned through your wallet activity and Alpha token holdings in Binance Wallet.
Can I use a regular Binance Wallet instead of Keyless? No. Only Keyless Wallet users can participate in Booster campaigns. You can create one in Binance Wallet via Profile → Keyless Wallet → Create.
Can I participate with multiple wallets or accounts? Each Binance Keyless Wallet address can participate once per phase. Duplicate submissions or suspicious activity may lead to disqualification.
When will I receive my rewards? Rewards are distributed **after this phase ends**, based on the final eligibility set of each reward pool.
What if I lose connection or close the app during delegation process? You can safely restart the Binance Wallet app and re-open the zkPass delegation page.
Where can I get help or report issues? For troubleshooting, updates, or general questions, reach out via: Discord: Twitter (X): @zkPass
# FAQ Frequently asked questions list
How does zkPass work? zkPass uses Three-Party TLS (3P-TLS), and Hybrid Zero-Knowledge Proof (Hybrid ZK) for secure data handling. It starts with a three-party handshake among a data source (S), user (P), and zkPass node (V), generating shared session keys with Paillier encryption for security. P and V jointly compute keys for encryption and authentication, with V restricted from accessing the user's private data. The process includes standard TLS steps and prepares for zero-knowledge proofs. zkPass employs a hybrid zero-knowledge approach, merging interactive (VOLE-ZK 23) and non-interactive protocols. VOLE-ZK 23 ensures data origin authenticity and client tamper protection, optimized by SoftSpoken for efficiency and focusing on AND gates for simplicity. For non-interactive zero-knowledge (NIZK), zkPass uses the SNARK framework. Verified results are signed and added to a Merkle tree in the SBT (Soul Bound Token) contract, ensuring efficient, secure, and private validation. **View the** [**Technical Overview**](https://medium.com/zkpass/a-technical-overview-of-zkpass-protocol-e28303e472e9) **to learn more details.**
How does zkPass prove the truth of HTTPS data? The truth of HTTPS data relies on two key aspects: 1. **Integrity of Encrypted Data from Trusted Sources**: During zkPass's MPC network protocol execution, random nodes are selected to establish a "client" connection with the user, facilitating communication with the server, effectively forming a three-party TLS connection. In this scenario, the user possesses shares of both the encryption key and the MAC key, while the nodes only have the remaining portion of the MAC key. Any attempt by users to tamper with data from a trusted source will result in a failure during MAC verification. Consequently, the integrity of data in the three-party TLS connection is ensured. 2. **Conformance of Data Statements to Verifier Requirements**: When assessing the authenticity of data statements, zkPass employs Hybrid ZK technology to safeguard customer privacy. The protocol can only be executed successfully if the data conforms to conditions specified by the template, such as age > 18 or assets < 10000. This ensures that the accuracy and truthfulness of the data are also guaranteed.
How is the credibility of data sources ensured? To ensure the credibility of data sources, the Prover and Node work together as a client to communicate with the server. Once the Client and Server have completed the ***SayHello*** process, the Client will request the server return the certificate. The Node inside the Client can also retrieve the certificate and verify its authenticity to ensure the trustworthiness of the data source.
What are the key advantages of zkPass? ### **1. Privacy-preserving** Prove your private data without uploading any personal privacy details. ### **2.** Verifiable Re-designed the standard TLS protocol into a three-party TLS to ensure provenance of private data. ### **3.** Compatible Seamless compatible with any HTTPS websites, no API or license required. ### **4. Verifiability** The zkPass protocol guarantees private data's verifiability, authenticity, and validity by utilizing decentralized MPC nodes that verify a user's data integrity before generating a zero-knowledge proof (ZKP). As a result, it becomes impossible for anyone to manipulate or tamper with the data while generating zkSBT. ### **5. Anti-Cheating** zkPass's anti-cheating mechanism ensures data integrity and authenticity by using zero-knowledge proofs to verify that client requests and server responses match predefined templates and conditions without accessing or storing private data. ### **6.** Memory-efficiency VOLE-based IZK that realizes millisecond-level ZKP generation locally in the browser environment.
Will zkPass TransGate handle or store user's private data? The zkPass TransGate operates on the client side and does not retain any private data of the Prover. To access the Server, the Prover utilizes their username and password to log in and acquire an access token. This access token enables the Prover to retrieve information from the server via a public interface. The Prover then employs this information to generate Zero-Knowledge Proofs (ZKP) and submits them for on-chain verification. Throughout the entire process, the encrypted key remains inaccessible to the Verifier, thereby ensuring the security and confidentiality of the user's private data.
How can tampering with private data by the prover be prevented locally? zkPass's anti-cheating mechanism ensures the correctness and integrity of data exchanges between clients and servers through zero-knowledge proofs. The main steps include: 1. **Verifying the Correctness of Client's Request**: The client encrypts the request data and ensures that the generated ciphertext matches the expected node ciphertext, preventing tampering. 2. **Validating the Correctness of Client's URL**: Ensuring the URL provided by the client matches the predefined template, verifying the correctness of the request address. 3. **Ensuring the Client Receives the Correct Response**: Comparing the encrypted response data with the node ciphertext to verify the integrity of the response received by the client. 4. **Matching Response Attributes to the Template**: Ensuring that the attributes within the response data align with those specified in the template, verifying the accuracy of the response content. 5. **Validating the Asserted Value’s Correctness**: Checking if the value in the response data satisfies certain conditions specified by the template, ensuring the logical correctness of the response data. Through these steps, zkPass not only guarantees the privacy and security of data verification but also ensures the integrity of client-server communications, preventing malicious tampering and fraudulent activities. More Details: [Anti-cheating mechanisms on zkPass](https://medium.com/zkpass/introducing-the-anti-cheating-mechanisms-on-zkpass-4427d24cbe7d)
How can the issue of duplicate accounts with different addresses be addressed? zkPass addresses the issue of duplicate accounts with different addresses by selecting a unique and private identification field returned by the server. For instance, for Twitter, the "id" field (displayed as the "reset\_id" field in the URL) can be used, and it is hashed before being sent to the blockchain. To handle different addresses with the same verification account, zkPass employs the overlay mode. For instance, if the hash value is detected to be the same, the current address verification will be marked as "pass," while the previously passed address will be marked as "invalid." This mode can also address the scenario where a user has lost their address.
How is the zkPass network distributed? On the early stage of the protocol development, the Nodes are operated by the zkPass team. As the network expands, there is an incentive for the community to participate and join the network until a dynamic equilibrium is attained. If the demand for verification rises, the revenue generated by the protocol and the individual nodes, as well as the number of nodes, will increase accordingly. However, as the number of nodes reaches a certain threshold, the income for each node will decrease, leading to a subsequent decrease in the number of nodes. Ultimately, the network will stabilize and reach a state of equilibrium where the scale of the network is balanced and sustainable.
What if i‘m switching into another wallet address and I want to migrate all my attestations from my own address to the new one? Each account can only mint the same schema once from a single network. you can simply just mint the same schema in the new address to have the attestation from the previous address voided.
::: info **Stay Safe:** Please ensure to install the zkPass TransGate extension from [official link](https://chromewebstore.google.com/detail/zkpass-transgate/afkoofjocpbclhnldmmaphappihehpma) on Google Web Store and use it in a secure network environment. Do not install unofficial tools from unknown sources. Avoid clicking on suspicious links and do not grant permissions to your Web3 wallet without verifying the source. ::: ::: tip **Stay Safe:** zkPass TransGate is developed based on Google Manifest V3 framework, introducing stricter permission management to ensure your private data remains secure and inaccessible to any third party, including zkPass. ::: Feel free to join our [Discord](https://discord.gg/zkpass) to ask more questions. # Roadmap ### Q1 2025 | Core Protocol & Developer Foundations * **zkTLS Protocol Upgrade**: Faster prover speed, reduced memory usage, and mobile-optimized proof generation. * **zkTLS Audits**: Completion of formal verification and multi-firm ZK security audits. * **zkPass SDK v2.0**: Unified SDK with support for web, mobile, and browser extensions. * **Proof UX Toolkit**: Prebuilt modules for verifiable login, proof-of-access, and off-chain reputation. * **DevHub v2**: Enhanced developer hub with schema explorer, real-time analytics, and customizable proof flows. ### Q2 2025 | Proof Applications & Ecosystem Expansion * **Verifiable Data Portal**: Community-curated schema marketplace for Web2 data integrations. * **Consumer Apps Launch**: zk-powered tools including Web2 airdrop verification, DeFi credit scoring, gated airdrops, and sybil-resistant voting. * **zkPass Node Network Expansion**: Browser-based and mobile node clients to scale decentralized proof validation. * **Verifiable Economy API**: SDK modules for tokenizing credentials (Duolingo streaks, GitHub contributions, Uber trips). ### Q3 2025 | Governance & Institutional Pilots * **Zero-Knowledge Compliance Suite**: KYC/KYB solutions enabling fintechs and exchanges to validate identities without exposing private data. * **Enterprise & Institutional Pilots**: Launch MVP of zkPass Institutional Suite with banks, education, and healthcare providers. * **Country Partner Initiatives**: Collaborations with national ecosystems for zk-verifiable credentials (e.g., tax records, university status, proof of work). * **zkPass for Reputation**: Reputation scoring framework combining social, financial, and educational proofs. ### Q4 2025 | Token Launch & Network Maturity * **TGE Launch**: $ZKP Token Generation Event, powering staking, proof incentives, governance, and reputation rewards. * **Token Utility Framework**: Activate $ZKP use cases across staking for node roles, proof verification, schema access, and reward distribution. * **Governance Expansion**: Broaden DAO participation, treasury allocations, and incentive mechanisms for developers and node operators. * **Network Scaling**: Expand throughput and validator coverage for consumer and enterprise-grade adoption. # Terms & Conditions Effective Date: Apr 20, 2025 ### 1. Introduction Welcome to zkPass. These Terms and Conditions (“Terms”) govern your access to and use of the zkPass website [www.zkpass.org](https://www.zkpass.org/?utm_source=chatgpt.com) (the “Site”), the zkPass protocol, software development kits (SDKs), and all related applications, services, or content (collectively, the “Services”). zkPass is a decentralized protocol that enables users to generate verifiable proofs of data ownership and authenticity using zero-knowledge cryptography and 3P-TLS technologies. The protocol is designed so that proofs of data may be disclosed without requiring disclosure of the underlying data itself. By accessing or using the Site or Services, you acknowledge that you have read, understood, and agree to be bound by these Terms, together with our Privacy Policy and any other notices, policies, or guidelines referenced herein. If you do not agree, you must not use the Site or Services. ### 2. Definitions For the purposes of these Terms: * **“zkPass,” “we,” “our,” or “us”** refers to the zkPass Association, a non-profit association established under the laws of Switzerland, and its affiliates. * **“User,” “you,” or “your”** refers to any individual or entity that accesses or uses the Site or Services. * **“Services”** means the zkPass protocol, SDKs, developer tools, applications, websites, and related infrastructure made available by zkPass. * **“Protocol Data”** means zero-knowledge proofs (ZKPs), zkSBTs, cryptographic keys, and other cryptographic artifacts generated by users when interacting with the zkPass protocol. Protocol Data is created locally on the user’s device and not stored by zkPass. * **“Site Data”** means technical information collected when you access the zkPass Site, such as IP addresses, browser type, or cookies, as further described in our Privacy Policy. * **“Materials”** means all content, trademarks, logos, documentation, protocol specifications, interfaces, and source code made available through the Site or Services. * **“Compute Gas Fees”** means computational or cryptographic resource costs associated with certain operations of the zkPass protocol, analogous to gas fees in blockchain networks. * **“Applicable Law”** means all laws, regulations, and rules that apply to your use of the Site or Services, including those relating to blockchain, data protection, export control, and financial compliance. ### 3. Acceptance of Terms #### 3.1 Binding Agreement By accessing, browsing, or using the Site or Services, you agree to be legally bound by these Terms and represent that you have the legal capacity and authority to enter into a binding contract. #### 3.2 Additional Policies These Terms incorporate by reference our Privacy Policy and any other guidelines, notices, or disclaimers published on the Site. By accepting these Terms, you also agree to comply with those additional policies. #### 3.3 Updates to Terms zkPass may amend or update these Terms from time to time. Updates will become effective upon publication on the Site, unless otherwise required by law. Your continued use of the Site or Services following any update constitutes your acceptance of the revised Terms. #### 3.4 No Use if Disagreement If you do not agree with these Terms or any future modifications, you must immediately cease all access to and use of the Site and Services. ### 4. User Eligibility #### 4.1 Age Requirement The Services are intended only for individuals who are at least **18 years of age**. By using the Site or Services, you represent and warrant that you are 18 years or older. #### 4.2 Legal Capacity You represent that you have the full right, power, and authority to enter into and comply with these Terms on behalf of yourself or the entity you represent. #### 4.3 Prohibited Jurisdictions Access to the Services is restricted in jurisdictions where the use of blockchain technology, cryptographic proofs, or digital assets is illegal or otherwise prohibited. A list of supported countries and regions is provided in Section 11 (Service Availability and Jurisdictional Restrictions). If you are located in, or a resident of, a prohibited jurisdiction, you must not use the Services. #### 4.4 Compliance Obligations You are solely responsible for ensuring that your use of the Services complies with all Applicable Laws, including but not limited to data-protection, financial, and export-control regulations in your jurisdiction. ### 5. User Data and Responsibilities #### 5.1 Non-Custodial Protocol zkPass is a **non-custodial protocol**. We do not access, store, or process Protocol Data generated by users. All cryptographic operations, including generation of zero-knowledge proofs, are performed locally on your device or browser. #### 5.2 User Responsibility for Keys and Proofs You are solely responsible for managing your private keys, proofs, and any data submitted or derived through the protocol. zkPass has no ability to recover lost keys or proofs. #### 5.3 Accuracy of Data You are responsible for ensuring the accuracy and completeness of any data you submit to generate proofs. zkPass does not guarantee that any proof or claim will be accepted by third parties. #### 5.4 Risks of Disclosure Once you voluntarily disclose a proof or attestation to a third party, zkPass has no control over its use, storage, or further disclosure. You acknowledge that sharing proofs is entirely at your own risk. #### 5.5 Assumption of Risk By using the Services, you acknowledge and accept the inherent risks associated with blockchain and cryptographic systems, including but not limited to: * Irreversibility of transactions. * Potential bugs or vulnerabilities in smart contracts or cryptographic libraries. * Market volatility affecting the costs of compute gas fees or related digital assets. ### 6. Privacy Policy Reference Your use of the Site and Services is also governed by our **Privacy Policy**, which forms an integral part of these Terms. The Privacy Policy describes in detail: * What information zkPass collects and does not collect. * How technical data and community data may be processed. * How cookies and tracking technologies are used. * Your rights under applicable data-protection frameworks such as GDPR and CCPA. By accepting these Terms, you acknowledge that you have read and understood our Privacy Policy. If you do not agree with the practices described in the Privacy Policy, you must not use the Site or Services. ### 7. Intellectual Property #### 7.1 Ownership All content, designs, trademarks, logos, source code, protocol specifications, documentation, interfaces, and any other intellectual property made available on or through the Site or Services (collectively, the “Materials”) are the exclusive property of zkPass or its licensors, and are protected by applicable intellectual property laws and international treaties. #### 7.2 Limited License Subject to your compliance with these Terms, zkPass grants you a limited, non-exclusive, non-transferable, and revocable license to access and use the Materials solely for personal, informational, and non-commercial purposes. #### 7.3 Restrictions You may not, without prior written consent from zkPass: * Copy, reproduce, modify, or distribute the Materials. * Reverse-engineer, decompile, or disassemble any part of the Services. * Use the Materials for commercial exploitation or derivative works. * Remove or obscure any proprietary notices or trademarks. Any unauthorized use of the Materials constitutes a violation of these Terms and may result in civil or criminal liability. ### 8. User Conduct #### 8.1 Compliance with Laws You agree to use the Site and Services only in compliance with these Terms and all Applicable Laws. #### 8.2 Prohibited Activities You must not, directly or indirectly: * Access, tamper with, or use non-public areas of the Site, Services, or underlying infrastructure. * Interfere with, disrupt, or attempt to compromise the integrity or performance of the protocol, network, or third-party services. * Upload, transmit, or introduce viruses, worms, malware, or malicious code. * Impersonate any person or entity, or misrepresent your affiliation with any individual or organization. * Circumvent, disable, or attempt to exploit the security measures or economic incentives of the protocol. * Engage in abusive behavior, Sybil attacks, or fraudulent activity, including repeated attestations or multi-account manipulation. #### 8.3 Enforcement zkPass reserves the right to investigate and take appropriate action, including suspending access, reporting to regulators, or pursuing legal remedies in response to any violation of these Terms. ### 9. Third-Party Links and Services #### 9.1 External Websites The Site may contain links to external websites, applications, or services that are not owned or controlled by zkPass. zkPass does not endorse, and is not responsible for, the content, policies, or practices of such third parties. #### 9.2 Wallets and dApps Your interaction with wallets, decentralized applications (dApps), or blockchain networks through the Services is governed by the terms and policies of those third parties. zkPass does not control or assume liability for how they process your data or execute transactions. #### 9.3 Data Sources and Integrations zkPass proofs may rely on third-party HTTPS data sources or APIs. zkPass does not guarantee the availability, accuracy, or reliability of such sources and disclaims all liability for errors or interruptions. #### 9.4 User Responsibility You acknowledge and agree that: * Accessing third-party content or services is at your own risk. * You are solely responsible for reviewing and complying with any third-party terms and policies. * zkPass shall not be liable for damages or disputes arising from your use of third-party services. ### 10. Use of Protocols and Fees #### 10.1 Protocol Operations Certain zkPass protocol operations — including but not limited to zero-knowledge proof generation, 3P-TLS sessions, or threshold signature computations — may consume computational or cryptographic resources. #### 10.2 Compute Gas Fees These operations may require the payment of **Compute Gas Fees**, which function similarly to transaction fees on blockchain networks. Compute Gas Fees are incurred by users (“Provers”) when executing protocol-level interactions. #### 10.3 Paymaster Support In certain cases, zkPass or ecosystem partners may subsidize these costs (e.g., via ERC-4337 paymaster mechanisms) to encourage adoption during beta programs, promotional campaigns, or community initiatives. #### 10.4 Resource Integrity The purpose of these fees is to: * Ensure fair and sustainable use of shared resources. * Prevent abuse such as spam or repeated attestations. * Support the long-term economic sustainability of the protocol. #### 10.5 User Responsibility Users are strongly discouraged from submitting duplicate proofs, unnecessary attestations, or attempts to game incentive mechanisms. Such behavior may result in rejection of proofs, overwriting of prior attestations, or loss of resources without compensation. ### 11. Service Availability and Jurisdictional Restrictions #### 11.1 Geographic Availability zkPass makes its Services available only in jurisdictions where blockchain technology, cryptographic proofs, and digital assets are permitted under Applicable Law. The Services are expressly restricted to the following countries and territories: **\[ Albania, Andorra, Angola, Antigua and Barbuda, Argentina, Armenia, Australia, Austria, Azerbaijan, Bahamas, Bahrain, Barbados, Belarus, Belgium, Belize, Benin, Bhutan, Bolivia, Bosnia and Herzegovina, Brazil, Brunei, Bulgaria, Burkina Faso, Burundi, Cabo Verde, Cambodia, Cameroon, Canada, Central African Republic, Chad, Chile, Colombia, Comoros, Costa Rica, Croatia, Cuba, Cyprus, Czechia, Denmark, Djibouti, Dominica, Dominican Republic, East Timor, Ecuador, El Salvador, Equatorial Guinea, Eritrea, Estonia, Eswatini, Ethiopia, Fiji, Finland, France, Gabon, Gambia, Georgia, Germany, Ghana, Greece, Grenada, Guatemala, Guinea, Guinea-Bissau, Guyana, Haiti, Honduras, Hong Kong SAR China, Hungary, Iceland, India, Indonesia, Ireland, Israel, Italy, Ivory Coast, Jamaica, Japan, Jordan, Kazakhstan, Kenya, Kiribati, Kosovo, Kuwait, Kyrgyzstan, Laos, Latvia, Lebanon, Lesotho, Liberia, Libya, Liechtenstein, Lithuania, Luxembourg, Madagascar, Malawi, Malaysia, Maldives, Mali, Malta, Marshall Islands, Mauritania, Mauritius, Macau SAR China, Mexico, Micronesia, Moldova, Monaco, Mongolia, Montenegro, Morocco, Mozambique, Myanmar, Namibia, Nauru, Nepal, Netherlands, New Zealand, Nicaragua, Niger, Nigeria, North Macedonia, Norway, Oman, Pakistan, Palau, Panama, Papua New Guinea, Paraguay, Peru, Philippines, Poland, Portugal, Qatar, Romania, Russia, Rwanda, Saint Kitts and Nevis, Saint Lucia, Saint Vincent and the Grenadines, Samoa, San Marino, Sao Tome and Principe, Saudi Arabia, Senegal, Serbia, Seychelles, Sierra Leone, Singapore, Slovakia, Slovenia, Solomon Islands, Somalia, South Africa, South Sudan, Spain, Sri Lanka, Sudan, Suriname, Sweden, Switzerland, Syria, Taiwan, Tajikistan, Tanzania, Thailand, Togo, Tonga, Trinidad and Tobago, Tunisia, Turkey, Turkmenistan, Tuvalu, Uganda, Ukraine, United Arab Emirates, United Kingdom, United States, Uruguay, Uzbekistan, Vanuatu, Vatican City, Venezuela, Vietnam, Yemen, Zambia, and Zimbabwe. ]** #### 11.2 Prohibited Jurisdictions Access to and use of the Services from any country or territory not explicitly listed above is strictly prohibited. Users who attempt to access zkPass from non-supported jurisdictions do so at their own risk, and zkPass disclaims any liability arising from such use. #### 11.3 Regulatory Compliance * Users are solely responsible for ensuring compliance with local laws, regulations, and restrictions. * zkPass reserves the right to suspend or discontinue Services in any jurisdiction where regulatory or legal risks arise. #### 11.4 Updates to Supported Jurisdictions The list of supported countries and territories may be updated at zkPass’s sole discretion to reflect changes in legal or regulatory conditions. Updates will be effective upon publication on the Site. ### 12. Risk Disclosures By using the Site or Services, you acknowledge and accept the inherent risks associated with blockchain technologies and cryptographic protocols. These include, without limitation: #### 12.1 Protocol and Technical Risks * Transactions and proofs may be irreversible once submitted. * Bugs, vulnerabilities, or exploits may exist in smart contracts, cryptographic libraries, or network infrastructure. * Services may be subject to downtime, delays, or unexpected failures. #### 12.2 Market and Economic Risks * Costs of Compute Gas Fees or related digital assets may fluctuate significantly. * zkPass does not guarantee the economic value or utility of any proofs, attestations, or tokens associated with the protocol. #### 12.3 Third-Party Risks * zkPass relies on third-party data sources, APIs, wallets, and blockchains. Their accuracy, reliability, or availability is not guaranteed. * Users assume all risks associated with reliance on third-party services or integrations. #### 12.4 Legal and Regulatory Risks * The legal status of blockchain and zero-knowledge technologies varies across jurisdictions. * Regulatory changes or enforcement actions may restrict or prohibit the use of zkPass Services in certain regions. * Users are solely responsible for understanding and complying with local regulatory frameworks. #### 12.5 User Responsibility You assume full responsibility for your use of the Services, including securing your private keys, devices, and proofs. zkPass shall not be liable for losses resulting from user error, negligence, or misuse. ### 13. Disclaimer of Warranties #### 13.1 “As Is” Basis The Site and Services are provided on an **“as is”** and **“as available”** basis, without any warranties or representations of any kind, whether express, implied, statutory, or otherwise. #### 13.2 No Implied Warranties To the fullest extent permitted by Applicable Law, zkPass expressly disclaims all implied warranties, including but not limited to: * Merchantability * Fitness for a particular purpose * Non-infringement * Accuracy, reliability, or availability of the Site or Services #### 13.3 Blockchain Risks zkPass makes no warranty that: * The Services will be uninterrupted, secure, or error-free. * Proofs or attestations will be accepted by third parties. * Protocol operations will be immune from cyberattacks, exploits, or network failures. #### 13.4 Jurisdictional Limitations Some jurisdictions do not allow the exclusion of implied warranties. In such cases, certain disclaimers in this Section may not apply to you. ### 14. Limitation of Liability #### 14.1 Exclusion of Damages To the maximum extent permitted by Applicable Law, zkPass, its affiliates, officers, employees, contractors, and licensors shall not be liable for any: * Indirect, incidental, or consequential damages * Special or punitive damages * Loss of profits, business, goodwill, or data Arising out of or in connection with your use of the Site or Services, whether based in contract, tort, negligence, strict liability, or otherwise. #### 14.2 Liability Cap In no event shall the total liability of zkPass for any claim exceed: * The total amount paid by you (if any) for accessing or using the Services in the **12 months** preceding the claim, or * **USD $100**, whichever is lower. #### 14.3 User Responsibility You are solely responsible for securing your devices, private keys, and proofs. zkPass shall not be liable for losses arising from user error, negligence, or misuse of the Services. #### 14.4 Jurisdictional Limitations Certain jurisdictions do not allow limitations of liability for consequential or incidental damages. In such jurisdictions, the exclusions and limitations in this Section shall apply to the maximum extent permitted by law. ### 15. Modifications to Services and Terms #### 15.1 Service Modifications zkPass reserves the right, at its sole discretion, to modify, suspend, or discontinue any part of the Site, Services, or Protocol at any time, including but not limited to: * Technical features or specifications * Supported data types or schemas * Pricing or fee structures * Access methods or interfaces We will make reasonable efforts to notify users of material changes where practicable. #### 15.2 Updates to Terms zkPass may update these Terms periodically to reflect changes in technology, legal requirements, or business operations. The updated Terms will be published on the Site with a revised effective date. #### 15.3 User Acceptance By continuing to use the Site or Services after any update becomes effective, you agree to be bound by the revised Terms. If you do not agree to the updated Terms, you must cease using the Services immediately. ### 16. Termination and Suspension #### 16.1 Suspension of Access zkPass may suspend or restrict your access to the Site or Services, without notice, if we reasonably believe that you have: * Violated these Terms or any Applicable Law. * Engaged in fraudulent, abusive, or harmful conduct. * Compromised the security or integrity of the Services. #### 16.2 Termination of Agreement zkPass may terminate this agreement and your right to access the Services at any time, with or without cause, and without liability. #### 16.3 User Termination You may terminate your agreement with zkPass by ceasing use of the Site and Services. Any obligations or liabilities incurred prior to termination shall survive termination. ### 17. Dispute Resolution and Governing Law #### 17.1 Governing Law These Terms are governed by and construed in accordance with the laws of **Switzerland**, without regard to its conflict-of-law provisions. #### 17.2 Arbitration Any dispute, claim, or controversy arising out of or relating to these Terms, the Site, or the Services shall be resolved through **binding arbitration** administered by the **Swiss Chambers’ Arbitration Institution (SCAI)** in accordance with its rules. * The seat of arbitration shall be **Zurich, Switzerland**. * The language of arbitration shall be **English**. * The arbitral award shall be final and binding on the parties. #### 17.3 Injunctive Relief Nothing in this Section prevents zkPass from seeking injunctive or equitable relief in competent courts to protect its intellectual property or confidential information. #### 17.4 Waiver of Class Actions To the fullest extent permitted by law, you agree to waive the right to participate in any class action, collective action, or representative proceeding against zkPass. ### 18. Force Majeure zkPass shall not be liable for any failure or delay in performance caused by circumstances beyond our reasonable control, including but not limited to: * Acts of God, natural disasters, or extreme weather events. * War, terrorism, or civil unrest. * Labor disputes or strikes. * Government actions, regulations, or legal restrictions. * Internet or telecommunication outages, cyberattacks, or failures of third-party services. In such cases, zkPass’s obligations will be suspended for the duration of the event, and we will make reasonable efforts to mitigate the impact. ### 19. Severability and Waiver #### 19.1 Severability If any provision of these Terms is found to be invalid, unlawful, or unenforceable, the remaining provisions shall remain in full force and effect. #### 19.2 Waiver Failure by zkPass to enforce any right or provision of these Terms shall not constitute a waiver of such right or provision. Any waiver must be in writing and signed by an authorized representative of zkPass. ### 20. Entire Agreement These Terms, together with the Privacy Policy and any other policies, guidelines, or notices expressly incorporated herein, constitute the entire agreement between you and zkPass regarding the use of the Site and Services. They supersede all prior or contemporaneous agreements, communications, and understandings, whether oral or written, relating to the subject matter. If any provision of these Terms is deemed unenforceable, such provision shall be modified only to the extent necessary to render it enforceable, and the remaining provisions shall continue in full effect. # Privacy Policy Effective Date: \[Apr 6 2025] ### 1. Introduction #### Purpose of This Policy This Privacy Policy explains how zkPass (“zkPass,” “we,” “our,” or “us”) handles information relating to your use of our website [www.zkpass.org](https://www.zkpass.org/?utm_source=chatgpt.com) (the “Site”) and our protocol and related services (together, the “Services”). It describes what information we may collect, how that information is used, how it is safeguarded, and what rights you may have under applicable data-protection laws such as the General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA). #### About zkPass zkPass is a decentralized protocol that enables users to generate zero-knowledge proofs (ZKPs) from Web2 data sources through zkTLS. Our protocol is designed to allow individuals to prove facts about themselves—such as legal identity, financial information, educational records, or achievements—without ever disclosing or uploading the underlying documents. By default, zkPass does not collect or store personal data from users of the protocol. #### Scope This Privacy Policy applies to: * Visitors to the zkPass Site. * Users interacting with the zkPass protocol and developer tools, to the extent that technical data is transmitted. * Individuals engaging with zkPass through official communication channels such as mailing lists, forums, or community servers. This Privacy Policy does not apply to: * Third-party wallets, decentralized applications (dApps), or blockchains that may interface with zkPass. * External websites, platforms, or services that may be linked from our Site. ### 2. Definitions For the purposes of this Privacy Policy: * **“Personal Data”** means any information relating to an identified or identifiable natural person, including but not limited to names, identification numbers, location data, online identifiers, or factors specific to physical, physiological, genetic, mental, economic, cultural, or social identity. Under GDPR and certain other laws, IP addresses and cookie identifiers may also be considered Personal Data. * **“Non-Personal Data”** refers to information that does not identify you as an individual, such as aggregated analytics, device types, or anonymized technical logs. * **“Protocol Data”** refers to zero-knowledge proofs, zkSBTs, cryptographic keys, and related information generated and stored locally on a user’s device when interacting with the zkPass protocol. Protocol Data is never collected or retained by zkPass. * **“Site Data”** refers to technical information automatically collected when you visit our Site, such as IP address, browser type, and cookies. * **“Processing”** means any operation performed on data, whether automated or not, including collection, storage, use, disclosure, or deletion. * **“Services”** means the zkPass Site, protocol, developer SDKs, and official community engagement channels. ### 3. Core Privacy Principles zkPass is built on the philosophy of privacy by design. The following principles govern our approach to handling information: 1. **Privacy by Default**\ The zkPass protocol is designed so that users retain custody of their sensitive data at all times. Zero-knowledge proofs are generated locally and never transmitted to zkPass servers. 2. **Minimal Collection**\ zkPass does not collect, process, or store personal identity documents, financial records, healthcare data, or other sensitive user data. Any technical data collected from the Site is limited to what is strictly necessary for functionality, analytics, and security. 3. **Selective Disclosure**\ The zkPass protocol enables users to disclose only the attributes required for a given interaction (for example, “over 18,” “holds a university degree,” “account balance above threshold”) without revealing full underlying data. 4. **User Sovereignty**\ Users control the proofs they generate and decide when and where to disclose them. zkPass does not act as a custodian or central repository of user data. 5. **Transparency and Accountability**\ We are committed to clear communication about what information is collected, why it is processed, and how it is protected. Where applicable, we comply with GDPR, CCPA, and other data-protection obligations. ### 4. Information We Collect zkPass is designed to minimize data collection and to ensure that sensitive user data remains under the control of the user. We distinguish between three categories of information: **Protocol Data, Site Data, and Community Data**. #### 4.1 Protocol Data * zkPass does **not** collect, process, or store personal identity documents, financial records, healthcare information, or educational transcripts. * All **zero-knowledge proofs (ZKPs), zkSBTs, and cryptographic keys** are generated locally on the user’s device through zkTLS. These remain fully under user custody and are not transmitted to zkPass servers. * zkPass does not operate as a data custodian, identity provider, or credential repository. #### 4.2 Site Data When you access our Site, limited technical information may be automatically collected, which may be considered “personal data” under applicable laws: * IP address and approximate geolocation * Browser type, version, and language settings * Operating system and device information * Date, time, and duration of visits * Referring URLs and clickstream activity * Cookie identifiers or equivalent technologies (see Section 7 for details) This data is collected primarily for security, operational, and analytical purposes. #### 4.3 Community and Voluntary Data If you choose to interact with zkPass through official communication channels, we may collect information you voluntarily provide: * **Email subscriptions**: When you sign up for newsletters or mailing lists, we collect your email address and related communication preferences. * **Community servers**: If you join zkPass-managed channels (e.g., Discord, Telegram, Discourse), we may collect your username, account identifier, and any information you voluntarily disclose. * **Events and programs**: If you register for hackathons, beta tests, or ambassador programs, we may process your contact details and participation records. #### 4.4 Sensitive Data * zkPass does not knowingly collect “special categories of data” under GDPR (such as racial or ethnic origin, political opinions, religious beliefs, biometric data, or health data). * If you voluntarily disclose such information in a community forum or event, it will be processed only to the extent necessary for that interaction and at your discretion. #### 4.5 Anonymized and Aggregated Data * We may aggregate Site Data in a way that no longer identifies individual users. * Aggregated data may be used for analytics, protocol improvement, or reporting purposes. ### 5. How We Use Information zkPass applies a principle of minimal processing. Information is collected and used strictly for limited purposes aligned with protocol operation, website maintenance, and community engagement. #### 5.1 Protocol Data * zkPass does not use Protocol Data for any processing. * All ZKPs, zkSBTs, and cryptographic keys remain on the user’s device and are disclosed only by the user to third parties at their discretion. #### 5.2 Site Data We may use technical Site Data for the following purposes: * **Site operation**: To provide core functionality of the Site and ensure availability of resources. * **Security**: To detect, investigate, and prevent fraudulent activity, abuse, or unauthorized access. * **Analytics and improvement**: To analyze aggregated usage patterns, monitor traffic, and improve Site performance. * **Legal compliance**: To comply with obligations under applicable law, including log retention for security purposes. #### 5.3 Community and Voluntary Data We may use community and voluntary data to: * Administer newsletters, announcements, and updates. * Respond to inquiries, support requests, or feedback. * Manage participation in hackathons, grants, reward campaigns, or ambassador programs. * Enforce community standards and prevent abuse. #### 5.4 Exclusions * We do not use collected information for targeted advertising or profiling. * We do not sell or monetize user data. * We do not combine Protocol Data with Site Data or Community Data. ### 6. Legal Basis for Processing (GDPR) Where GDPR applies, zkPass processes information under one or more of the following legal bases: #### 6.1 Consent * When you voluntarily subscribe to newsletters, mailing lists, or community programs, you consent to the processing of the information you provide (such as your email address or username). * You may withdraw consent at any time by unsubscribing or contacting us at ****. #### 6.2 Legitimate Interests * We may process limited Site Data, such as IP addresses and log files, to operate, secure, and improve our Site. * This processing is balanced against your privacy rights and is performed only where necessary to maintain functionality and security. #### 6.3 Legal Obligations * We may retain or disclose information where required to comply with applicable laws, regulations, or governmental requests. * This may include server log retention for cybersecurity compliance or responding to lawful requests by regulators. #### 6.4 Contractual Necessity * If you participate in zkPass-operated programs (for example, hackathons or grants), processing of voluntary information may be necessary to fulfill the terms of your participation. ### 7. Cookies and Tracking Technologies #### 7.1 What Are Cookies Cookies are small text files placed on your device when you access websites. They allow websites to recognize your browser, remember preferences, and analyze traffic. In addition to cookies, we may use similar technologies such as local storage or tracking pixels. #### 7.2 How We Use Cookies zkPass uses cookies and related technologies in a limited manner. These technologies help us: * Ensure the basic functionality and security of the Site. * Understand how the Site is used through aggregated analytics. * Improve user experience by remembering certain preferences. zkPass does not use cookies for behavioral advertising or cross-site tracking. #### 7.3 Categories of Cookies | Category | Purpose | Examples of Data Collected | Retention Period | Can You Disable? | | ---------------------- | --------------------------------------------------------------------------------------------------- | ------------------------------------------- | ---------------- | --------------------------- | | **Strictly Necessary** | Essential for the Site to function properly, such as security and session management. | Session ID, login status, basic preferences | Session only | No (required for operation) | | **Functional** | Enhance usability by remembering your preferences. | Language settings, layout preferences | Up to 12 months | Yes | | **Analytics** | Provide aggregated insights on how users interact with the Site. | IP (anonymized), page views, clickstream | Up to 24 months | Yes | | **Performance** | Monitor errors, performance metrics, and load times. | Error logs, device type, browser info | Up to 12 months | Yes | | **Marketing** | zkPass does not use marketing cookies. If such cookies are introduced, this Policy will be updated. | N/A | N/A | N/A | #### 7.4 Third-Party Cookies Certain service providers (for example, analytics providers or hosting platforms) may place cookies when you access our Site. These third-party cookies are subject to their own privacy policies. We encourage you to review those policies. #### 7.5 Managing Cookies You can manage or disable cookies through your browser settings. Please note that disabling certain cookies may affect Site functionality. For instructions, see: * [Google Chrome Cookie Settings](https://support.google.com/chrome/answer/95647?utm_source=chatgpt.com) * [Mozilla Firefox Cookie Settings](https://support.mozilla.org/en-US/kb/cookies-information-websites-store-on-your-computer?utm_source=chatgpt.com) * [Apple Safari Cookie Settings](https://support.apple.com/guide/safari/manage-cookies-and-website-data-sfri11471/mac?utm_source=chatgpt.com) * [Microsoft Edge Cookie Settings](https://support.microsoft.com/microsoft-edge/delete-cookies-in-microsoft-edge-63947406-40ac-c3b8-57b9-2a946a29ae09?utm_source=chatgpt.com) ### 8. Information Sharing and Disclosure zkPass does not sell or rent your information to third parties. Information may only be disclosed under the following limited circumstances: #### 8.1 Service Providers We may engage trusted third-party service providers to support the operation of our Site and Services. These providers may have access to limited Site Data or Community Data strictly for the purpose of performing services on our behalf, such as: * Hosting and cloud infrastructure (e.g., AWS, Cloudflare). * Analytics and performance monitoring. * Email delivery and community management tools. All service providers are contractually bound to use the information solely for the intended purpose and to apply appropriate security measures. #### 8.2 Legal and Regulatory Compliance We may disclose information when required to comply with applicable laws, regulations, legal processes, or enforceable governmental requests. Examples include: * Responding to law enforcement requests supported by lawful authority. * Retaining server logs for cybersecurity or regulatory compliance. * Meeting obligations under financial, tax, or anti-abuse frameworks applicable to zkPass operations. #### 8.3 Business Transfers In the event of a merger, acquisition, or corporate restructuring involving zkPass, relevant information may be transferred as part of the transaction, subject to equivalent privacy safeguards and this Policy. #### 8.4 Protection of Rights We may disclose information if we believe it is reasonably necessary to: * Protect the safety, rights, or property of zkPass, our users, or the public. * Detect, prevent, or otherwise address fraud, security issues, or misuse of our Services. ### 9. Data Retention zkPass follows a principle of **data minimization** and retains information only for as long as necessary for the purposes described in this Policy. #### 9.1 Protocol Data * zkPass does not retain Protocol Data such as ZKPs, zkSBTs, or cryptographic keys. * These remain exclusively under user control and are never stored on zkPass servers. #### 9.2 Site Data * Technical logs (such as IP addresses and error logs) are retained only for security, troubleshooting, and analytics purposes. * Typical retention period is up to **90 days**, after which data is either deleted or aggregated/anonymized. #### 9.3 Community and Voluntary Data * Contact information provided for newsletters or community programs is retained until you unsubscribe, withdraw consent, or request deletion. * Participation records for hackathons, ambassador programs, or grants may be retained as long as necessary to administer the program and comply with any legal requirements. #### 9.4 Legal Retention Obligations * In certain cases, we may be legally required to retain limited information for a longer period (for example, to comply with applicable accounting, taxation, or regulatory obligations). * When retention is no longer required, data will be securely deleted or anonymized ### 10. International Data Transfers zkPass operates globally. As such, technical and community-related data that we collect may be processed or stored in jurisdictions outside of your country of residence. #### 10.1 Data Locations * zkPass infrastructure may be hosted in multiple regions, including the European Union, the United States, and Asia-Pacific. * Data may be accessed by authorized personnel or service providers located in different jurisdictions for the purposes described in this Policy. #### 10.2 Legal Safeguards (GDPR) Where GDPR applies, and data is transferred outside the European Economic Area (EEA), we implement appropriate safeguards, which may include: * **Standard Contractual Clauses (SCCs)** approved by the European Commission. * **UK Addendum to SCCs** for data transfers from the United Kingdom. * **Swiss equivalents** for transfers from Switzerland. * Additional technical and organizational measures such as encryption and access restrictions. #### 10.3 User Acknowledgment By using our Site or Services, you acknowledge that your non-personal or voluntarily provided community information may be transferred and processed outside your country of residence, subject to the safeguards above. ### 11. User Rights zkPass recognizes that users may have certain rights under applicable data-protection laws, particularly the GDPR (European Union / EEA residents) and the CCPA (California residents). #### 11.1 GDPR Rights If you are located in the European Union, EEA, or Switzerland, you may have the following rights: * **Right of Access**: To request a copy of the data we hold about you. * **Right to Rectification**: To request correction of inaccurate or incomplete data. * **Right to Erasure (“Right to be Forgotten”)**: To request deletion of data where there is no lawful basis for retention. * **Right to Restriction of Processing**: To request a temporary halt on processing under certain conditions. * **Right to Data Portability**: To request a copy of data in a machine-readable format for transfer to another provider. * **Right to Object**: To object to processing based on legitimate interests. * **Right to Withdraw Consent**: Where processing is based on consent, you may withdraw it at any time. #### 11.2 CCPA Rights If you are a resident of California, you may have the following rights: * **Right to Know**: To request information about the categories and specific pieces of personal information collected. * **Right to Delete**: To request deletion of personal information, subject to certain exceptions. * **Right to Opt-Out**: To opt out of the sale or sharing of personal information (note: zkPass does not sell personal data). * **Right to Non-Discrimination**: To be free from discrimination for exercising your CCPA rights. #### 11.3 Exercising Your Rights You may exercise your rights under GDPR or CCPA by contacting us at:\ **Email**: We may need to verify your identity before fulfilling your request. We will respond within the time frames required by applicable law (for example, 30 days under GDPR). #### 11.4 Limitations * As zkPass does not collect or store Protocol Data (such as identity documents or ZKPs), certain rights (such as rectification or portability of those proofs) may not apply. * For Site Data and Community Data, rights will be honored to the fullest extent permitted by law. ### 12. Children’s Privacy #### 12.1 Age Restrictions Our Services are not directed to, and should not be used by, individuals under the age of 18. We do not knowingly collect personal information from children. #### 12.2 Parental Consent If we become aware that we have inadvertently collected personal information from a child without appropriate parental or guardian consent, we will take immediate steps to delete such information. #### 12.3 User Responsibility By accessing or using the Services, you represent that you are at least 18 years of age or that you are accessing the Services under the supervision of a parent or guardian who agrees to this Privacy Policy. ### 13. Data Security zkPass is committed to protecting the integrity and confidentiality of the limited information we handle. Our approach combines technical safeguards, organizational measures, and user education. #### 13.1 Technical Measures * **Encryption**: All traffic between your browser and our Site is secured via TLS encryption. * **Access Controls**: Internal access to logs and community data is strictly limited to authorized personnel. * **Monitoring**: We use monitoring and intrusion detection systems to identify and mitigate threats. * **Data Minimization**: We collect and retain only the minimum amount of data necessary to operate our Site and Services. #### 13.2 Organizational Measures * **Confidentiality**: All team members and service providers with access to data are bound by confidentiality obligations. * **Training**: Staff with access to user-related data receive training on data-protection practices. * **Vendor Management**: Third-party service providers are vetted for compliance with security and privacy standards. #### 13.3 User Responsibilities * **Private Keys**: Users are responsible for safeguarding their private cryptographic keys, which remain under their sole control. * **Device Security**: Users should take appropriate steps to secure their devices, including using strong passwords and enabling system-level protections. * **Disclosure Control**: Users decide when and where to disclose zero-knowledge proofs; zkPass cannot revoke or retract proofs once voluntarily shared. #### 13.4 No Absolute Guarantee While we employ industry-standard measures to secure information, no system can guarantee complete security. Users acknowledge that the use of the internet carries inherent risks, and zkPass cannot fully eliminate those risks. ### 14. Data Breach Notification #### 14.1 Internal Procedures zkPass maintains internal procedures for detecting, investigating, and responding to potential data breaches involving Site Data or Community Data. #### 14.2 Notification to Regulators Where required by applicable law, including GDPR, zkPass will notify the relevant supervisory authority of a personal data breach without undue delay, and in any event within **72 hours** of becoming aware of the breach, unless the breach is unlikely to result in a risk to the rights and freedoms of individuals. #### 14.3 Notification to Users If a breach is likely to result in a high risk to your rights and freedoms, we will notify affected users promptly, providing: * A description of the nature of the breach. * The categories of information affected. * The likely consequences of the breach. * Measures taken or proposed to address the breach. * Guidance on steps you can take to protect yourself. #### 14.4 Exclusions * Protocol Data (such as ZKPs, zkSBTs, or cryptographic keys) is never stored by zkPass, and therefore cannot be subject to a breach of zkPass servers. * If you voluntarily disclose proofs to third parties, zkPass is not responsible for breaches occurring outside our control. ### 15. Third-Party Links and Services #### 15.1 External Links Our Site may contain links to third-party websites, applications, or services. zkPass is not responsible for the privacy practices or content of such external sites. We encourage you to review the privacy policies of any third-party services you access. #### 15.2 Wallets and dApps zkPass may be integrated with wallets, decentralized applications (dApps), or blockchain services operated by third parties. Your interactions with these services are governed by their respective terms and privacy policies. zkPass does not control how they handle your information. #### 15.3 Analytics and Hosting Providers We may use third-party providers for analytics (e.g., website usage statistics) or hosting infrastructure. These providers may collect or process limited technical information as described in Section 4. Such processing is subject to contractual safeguards and the providers’ own privacy policies. #### 15.4 Community Platforms If you engage with zkPass through third-party community platforms (such as Discord, Telegram, or Twitter/X), your use of those platforms is subject to their privacy policies. zkPass does not control how those platforms process your information. #### 15.5 Disclaimer Inclusion of a third-party link or integration does not imply endorsement by zkPass. Your interactions with third-party services are at your own discretion and risk. ### 16. Governance and Applicable Law #### 16.1 Responsible Entity The zkPass protocol is operated by **zkPass Association**, a non-profit association established under the laws of Switzerland. The Association is responsible for governance of the protocol and the administration of this Privacy Policy. #### 16.2 Applicable Law This Privacy Policy and any disputes arising from or relating to it are governed by the laws of **Switzerland**, without regard to conflict of law principles. #### 16.3 Jurisdiction Unless otherwise required by mandatory law, any disputes relating to this Privacy Policy shall fall under the exclusive jurisdiction of the competent courts of **Zurich, Switzerland**. #### 16.4 International Compliance zkPass intends for this Privacy Policy to be interpreted consistently with global data-protection frameworks, including but not limited to: * The **General Data Protection Regulation (GDPR)** of the European Union. * The **California Consumer Privacy Act (CCPA)** and related U.S. state privacy laws. * The **Swiss Federal Act on Data Protection (FADP)**. * Other applicable national or regional privacy frameworks. ### 17. Changes to This Policy #### 17.1 Right to Modify We may update or amend this Privacy Policy from time to time to reflect: * Changes in legal or regulatory requirements. * Evolving industry standards and best practices. * Updates to our technology, Services, or governance structure. #### 17.2 Notification of Changes * Material changes will be communicated prominently on the Site prior to their effective date. * Where legally required, we will obtain your consent before implementing changes that materially affect how we handle your personal data. #### 17.3 Effective Date of Updates Each revised version of this Privacy Policy will be identified by its effective date, which will be updated at the top of the document. #### 17.4 Archival of Previous Versions To ensure transparency, zkPass may maintain an archive of prior versions of this Privacy Policy, which will be available upon request ### 18. Contact Information If you have any questions, requests, or concerns regarding this Privacy Policy or zkPass’s data-handling practices, you may contact us using the following details: * **Email**: ## Conclusion zkPass is designed with **privacy by default** and **verifiability without disclosure** at its core. Unlike traditional services that centralize and monetize user information, zkPass does not collect or store personal identity documents, financial records, or sensitive credentials. All zero-knowledge proofs are generated and remain under the control of the user. This Privacy Policy demonstrates our commitment to transparency, compliance, and security. By setting clear limits on the information we collect, applying strong legal and technical safeguards, and honoring user rights under frameworks such as GDPR, CCPA, and the Swiss FADP, we aim to ensure that zkPass not only advances the future of verifiable data but also upholds the fundamental right to privacy.