Building with zkTLS: A Developer's Guide to Protocol Integration
Privacy verification tools comparison
This guide emerged from our work at Stormbit, where we're building infrastructure for global lending markets. Stormbit enables programmable, structured credit at scale through RWA-backed loans and zkTLS-powered trust-based lending, bridging DeFi's liquidity with TradFi's demand.
While implementing zkTLS solutions to verify off-chain data while preserving privacy (a critical function for next-generation lending), we've gained valuable insights about the various protocol implementations that we're sharing to help other developers make informed decisions.
What is zkTLS ?
Imagine an internet where every data interaction carries inherent proof of authenticity — this vision defines the verifiable web. zkTLS empowers users with cryptographic control over digital engagements. The true revolution lies not in the cryptographic algorithms themselves, but in their capacity to restore user sovereignty over online experiences.
With zkTLS, we can validate the authenticity and integrity of data without exposing personal privacy. This technology is precisely applied in Stormbit to verify off-chain data (e.g., bank statements and credit scores) while keeping details confidential, achieving verifiable yet invisible compliance.
Beyond its applications in DeFi, this technology holds transformative potential across multiple domains. Notable examples include:
- Combating fake reviews: Web proofs can restrict reviews to verified purchasers or users, ensuring only those who have genuinely interacted with a product, service, or location can submit feedback. For instance, platforms like Trustpilot could leverage web proofs to authenticate that reviewers have actually transacted with or used the business they are evaluating. This would drastically reduce fraudulent reviews and manipulation, elevating platform credibility.
- Resume verification automation: Employment platforms could automate credential validation and candidate-job matching. Today, rampant dishonesty in resumes forces companies to rely on inefficient manual checks — contacting universities and past employers to confirm details. Web proofs would streamline and secure this process, eliminating human error and revolutionizing the sector.
To realize this vision, zkTLS must overcome the limitations of traditional verification methods. Let's first examine these conventional approaches before diving into how zkTLS innovates
Three main approaches
Let's consider how user data verification might work without zkTLS. Two conventional approaches come to mind, both with significant limitations:
- Server-Side Verification Interfaces: This would require all data providers to implement new authentication and user authorization APIs. While technically possible, achieving widespread adoption across diverse services is highly impractical.
- Forwarding HTTPS Responses: While HTTPS ensures secure communication between a user and a server, forwarding session data (e.g., responses) to third parties compromises trustworthiness and risks exposing sensitive user information.
Both approaches have limited feasibility. Now, let's explore how zkTLS addresses these challenges through its specific mechanisms:
- Tee
The basic idea here is to use a tamper-proof CPU (e.g., Intel SGX, AMD SEV) to make HTTP requests. Because no entity — not even the owner of the TEE — can tamper with operations within the TEE, you can verify the data communicated within it. To produce "TEE-TLS," encrypted login credentials or authentication tokens are provided to the TEE service provider, which logs into the target website and securely stores responses. The TEE then generates a cryptographic signature proving data authenticity and provenance. This method is currently driven by the Clique team.
Workflow
User sends request to TEE provider
TEE logs into target server
Fetches response in TEE
TEE generates cryptographic signature
User receives signed proof
- Strength: Highly efficient, with minimal computational and networking overhead.
- Weakness: Security fully depends on hardware integrity and provider reliability.
As Dr. Andrew Miller at the University of Illinois has demonstrated through years of TEE breaches (primarily targeting Intel SGX), these systems are not perfect. Large-scale solutions relying solely on TEEs must address this challenge, especially in high-stakes scenarios like KYC (Know Your Customer) compliance.
While TEEs offer hardware-backed security, their reliance on centralized infrastructure raises concerns. Let's explore a more decentralized alternative.
- Proxy
The proxy-based approach simplifies zkTLS implementation by using intermediaries to facilitate secure communication. The proxy sits between the user and the target website, mediating HTTPS traffic. Since the proxy lacks decryption keys (only the user possesses them), it cannot modify received data.
Workflow
User sends request via Proxy
Proxy forwards request to target server
Fetches response and forwards to user
Proxy logs encrypted data
ZKP is generated locally by the user
- Strength: Fast execution and compatible with consumer devices.
- Weakness: Target servers may detect proxy IP addresses and block requests, and potential man-in-the-middle attacks on the proxy level.
The proxy model balances efficiency and decentralization, but IP detection remains a bottleneck. This leads us to a third approach combining cryptographic guarantees.
- MPC
The Multi-Party Computation (MPC) model in zkTLS introduces a third-party "Notary" that shares part of the session key with the user. This key is necessary for encrypting and decrypting TLS communications. Users must cooperate with the Notary to decrypt or encrypt data, preventing unilateral data manipulation. At the session's conclusion, the user creates a cryptographic commitment (hash of the data) and sends it to the Notary for blind signing.
Workflow
User sends request to target server
Third-party Notary shares session key
User + Notary encrypt/decrypt data
User generates cryptographic commitment
Notary signs commitment
- Strength: High security; target servers cannot detect Notary involvement.
- Weakness: Computational overhead and latency.
Comparative Analysis: use case & tech stack
Below is a comparison of how Reclaim, zkPass, Primus, and Opacity Network implement these approaches:
From this comparison, we observe distinct trade-offs between security, flexibility, and integration complexity. The star rating for integration complexity reflects a combination of development time and required tooling - more stars indicate a more streamlined developer experience with fewer external dependencies and setup requirements.
Primus
Primus offers unified APIs, allowing developers to choose between Proxy and MPC modes based on application requirements. Its "garble-then-prove" technique improves communication efficiency by 14x and runtime performance by 15.5x compared to traditional MPC models (Wunderlich, 2025).
- Tools: JavaScript SDK and Primus Chrome Extension required for verifying and proof generation.
- Integration: Customizable via Developer Hub.
Use Cases:
- Identity verification (PoH, KYC reuse)
- Financial proofs (on/off-chain assets)
- Academic credential validation
ZkPass
zkPass Protocol employs Hybrid Mode, which seamlessly switches between Proxy Mode and MPC 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, zkPass switches to operate in MPC Mode. Meanwhile the zkPass protocol employs the VOLEitH technique, ensures swift and efficient proof generation directly in the browser and device.
- Tools: JavaScript SDK and zkPass TransGate Extension required for verifying and proof generation.
- Integration: Custom schemas via Developer Tools. Requires zkPass Schema validator browser extension when creating new schema.
Use Cases:
- Identity verification (PoH, KYC reuse)
- Financial proofs (on/off-chain asset & activities)
- Academic credential validation (Education degree and transcript verification)
- Medical record sharing and insurance claims
- Social media (Identity Verification on Social Media, Decentralized Reputation Systems, Privacy-Preserving Ad Targeting.)
Reclaim
Reclaim Protocol employs a proxy-based model for zkTLS, which simplifies implementation and reduces computational overhead. This model introduces a trust assumption, as the proxy acts as an intermediary between the prover and verifier. While this approach is computationally efficient, it raises considerations around trust models. Reclaim implements cryptographic measures to address potential concerns, with theoretical security guarantees of 10^-40 probability of compromise (Wunderlich, 2025).
Developers can leverage AppClips and InstantApps integrations (Reclaim Verifier iOS, Reclaim Verifier Android) with plans for a browser extension in the future. The protocol supports numerous data sources and offers integration options for various web and mobile platforms. While well-suited for many verification use cases, applications requiring maximum decentralization may need to evaluate the proxy-based architecture carefully (Charlene's Substack, 2025).
- Cross-platform: Web & Mobile SDK
- Tools: No user-side installations required, verifications all happen in mobile side.
- Integration: Creating new integration through the developer tool with AI-assisted generation for custom providers.
Use Cases:
- Identity verification (PoH, KYC reuse)
- Transportation (ride-sharing history)
- Financial proofs (on/off-chain asset & activities)
- E-commerce (purchase history)
Opacity Network
Opacity Network combines TEE and MPC approaches in its architecture, with nodes operating within Intel SGX enclaves. The protocol also utilizes Eigenlayer AVS for additional security measures (Wunderlich, 2025).
This design aims to address potential vulnerabilities in other zkTLS models by implementing multiple security layers - hardware isolation through TEEs and cryptographic verification through a decentralized network of validators. Their approach creates a system where staked operators provide verification services, with economic incentives designed to maintain protocol integrity.
- Provides Mobile SDK for iOS, Android and cross-platform frameworks (Flutter/React Native), with verification processes occurring within the mobile application environment.
- Supports integrations through their partnership program, with available options listed in the Developer Portal.
Use Cases:
- E-commerce (purchase history)
- Social media (Ownership)
- Financial proofs (on/off-chain asset & activities)
- IP Ownership (digital assets like code, designs, and artwork)
- Real-World Interactions (Verifying attendance at events, confirm geo-locations, and authenticate reviews, adding credibility to platforms that bridge digital and physical interactions.)
Demo
Try it yourself! We've built a demo application where you can interact with these protocols. Install the required browser extensions mentioned in this guide before trying the demo.
Here is a case in Kaggle competition to verify user's verification status and performance tier, which is provided in Kaggle's GetCurrentUser endpoint. The request is triggered automatically after login. Except for Opacity, all three protocols support customized integration.
You can explore the full demonstration at the GitHub repository.
Customized integration:
- Primus: Follow the instruction in New Template in Developer Hub, it will be the simplest one during customized integration. In the following screenshot it only shows performanceTier template, verificationStatus can be created as the same way.
- zkPass: the new integration requires to fill a form, and the most complex part is the schema
- json, zkPass provide some official examples, can also reference our kaggle one:
Sample Code
{
"issuer": "Kaggle",
"desc": "Kaggle is a data science competition platform and online community for data scientists and machine learning practitioners under Google LLC.",
"website": "https://www.kaggle.com",
"APIs": [
{
"host": "www.kaggle.com",
"intercept": {
"url": "api/i/users.UsersService/GetCurrentUser",
"method": "POST"
},
"assert": [
{
"key": "performanceTier",
"value": "CONTRIBUTOR",
"operation": "!="
}
],
"nullifier": "id"
}
],
"HRCondition": ["Performance tier > CONTRIBUTOR"],
"tips": {
"message": "Please login with your kaggle account."
}
}
For the verificationStatus, the schema is almost same:
Sample Code
..."assert": [ { "key": "verificationStatus", "value": "USER_VERIFICATION_STATUS_UNVERIFIED", "operation": "=" }],...
The developer tool configuration should be like this, during the development process Domain is the localhost.
Reclaim: developer can follow the Video Guide, step by step. You can Search Kaggle Verification Status, Kaggle Performance Tier Provider in the provider market
dApp
To integrate theses protocols, you can follow the official documents to finish the proof generation process, also can add customize business logic. You can also check the flow in our source code demo.
Primus: generated the proof from the Primus Extension, you can add verified condition from JS code side
Sample Code
const request = primusZKTLS.generateRequestParams(attTemplateID, userAddress);const workMode = "proxytls"; // you can switch the work mode by yourselfrequest.setAttMode({ algorithmType: workMode,});const attConditions = [ [ { field: "performanceTier", op: "!=", value: "CONTRIBUTOR", }, ],];request.setAttConditions(attConditions);
The signature can be verified on chain, the parameters passed into the chain is same as the output of sdk call startAttestation
Sample Code
const provider = new ethers.JsonRpcProvider( process.env.NEXT_PUBLIC_SEPOLIA_RPC_URL);const contract = new ethers.Contract(primusAddress, primusABI, provider);try { const tx = await contract.verifyAttestation(attestation); console.log("Transaction:", tx);} catch (error) { console.error("Error in verifyAttestation:", error);}
zkPass: generated the proof from the TransGate Extension, the verified condition must be configured in during schema definition process.
Sample Code
... "assert": [ { "key": "performanceTier", "value": "CONTRIBUTOR", "operation": "!=" } ],...
The signature can be verified on chain, the parameters are needs to be formatted
Sample Code
const provider = new ethers.JsonRpcProvider( process.env.NEXT_PUBLIC_SEPOLIA_RPC_URL);const contract = new ethers.Contract(zkPassAddress, zkPassABI, provider);try { const tx = await contract.verify({ taskId: taskIdHex, schemaId: schemaIdHex, validator: validatorAddress, allocatorSignature, }); console.log("Transaction:", tx);} catch (error) { console.error("Error in verifyAttestation:", error);}
reclaim: generated the proof from the Reclaim Verifier mobile app, dApp started a session and waiting for the callback
Sample Code
await reclaimProofRequest.startSession({ onSuccess: async (proofs) => { console.log("Verification success", proofs); }, onError: (error) => { console.error("Verification failed", error); },});
As Reclaim doc mentioned, the verified condition can be configured in JS code. but no detail explanation or example, for now haven't figured out how to implement it.
The signature can be verified on chain, the parameters are need to be restructured.
Sample Code
try { const provider = new ethers.JsonRpcProvider( process.env.NEXT_PUBLIC_SEPOLIA_RPC_URL ); const contract = new ethers.Contract(reclaimAddress, reclaimABI, provider); const tx = await contract.verifyProof({ claimInfo: { provider: proof.claimData.provider, parameters: proof.claimData.parameters, context: proof.claimData.context, }, signedClaim: { claim: { identifier: proof.claimData.identifier, owner: proof.claimData.owner, timestampS: proof.claimData.timestampS, epoch: proof.claimData.epoch, }, signatures: proof.signatures, }, }); console.log("Transaction:", tx);} catch (error) { console.error("Error in verifyAttestation:", error);}
Opacity Network, you can reference official react native demo.
Key points:
- Dynamic response schema is not supported very well, only zkPass can provide a better user experience.
- Condition configuration in zkPass and Primus, can only support simple logic, for the complex logic involve multiple response fields can only be implemented with js code.
- During Reclaim verifying process, recommend to use instance app instead of downloading from App Store.
Conclusion
As Web3 continues to mature, zkTLS is positioned to become the backbone of privacy-preserving verification across the internet. We anticipate that within the next few years, these technologies will form the foundation of most identity and credential systems, bridging traditional finance and decentralized applications with unprecedented security and privacy guarantees.
Opacity Network implements a hybrid approach combining Trusted Execution Environment (TEE) and MPC technologies, reinforced by EigenLayer AVS for economic security. The platform provides mobile SDK integration options for iOS, Android, and cross-platform frameworks. While preset integrations are available through their developer portal, custom integration solutions can be accessed through their partnership program, making it an option for applications that prioritize hardware-backed security with decentralized validation mechanisms.
Primus and zkPass share similar web-based integration approaches using browser extensions, but with a key differentiation: Primus empowers developers to choose between Proxy and MPC architectures based on their specific application scenarios and service integration requirements. Both solutions currently face a common limitation – they can only verify data from API responses. This creates challenges for applications using Server-Side Rendering (SSR), where critical data might be embedded in HTML structures.
Reclaim Protocol now supports data extraction from both API responses and HTML content through its developer tool. While it offers pre-built connectors and support for numerous blockchain networks, HTML extraction can still present challenges for certain use cases. Reclaim is planning to release a browser extension soon, which should help address some of these limitations while maintaining its strengths in mobile integration.
Recommendations for Developers
When choosing a zkTLS solution for your project, consider the following:
- For mobile-native applications: Reclaim and Opacity Network offer the most streamlined integration experience, with Reclaim providing additional flexibility through its cross-platform support.
- For web applications: Primus and zkPass provide superior developer experiences when most verifications need to happen directly in the browser. Their browser extension-based approaches eliminate the need for additional mobile app dependencies.
- For contract integration: All protocols follow similar patterns for on-chain verification, primarily focusing on signature verification. The differences in implementation complexity lie mainly in the client-side integration rather than the smart contract side.
The decision should ultimately be guided by your specific application requirements, target platform, and the trade-offs between security models and user experience that best align with your project goals.
Ready to implement zkTLS in your application? Start with our demo repository or contact Stormbit to explore custom integration solutions for your specific needs.
To learn more about what Stormbit is doing in the zkTLS and DeFi space, follow us on X/Twitter.
References
- https://paragraph.com/@vinny/opacity-network-deepdive
- https://paragraph.com/@lemniscap/what-will-the-verifiable-web-look-like
- https://theaiinsider.tech/2024/10/19/zkpass-announces-12-5m-series-a-funding-to-drive-zktls-oracle-protocol/
- https://minaprotocol.com/blog/looking-towards-2025
- https://www.gate.io/learn/articles/zk-tls-unlocking-crypto-consumer-apps/7509
- https://www.opacity.network/
- https://finance.yahoo.com/news/series-funding-secures-12-5m-150000888.html
- https://medium.com/@wunderlichvalentin/zktls-unlocking-crypto-consumer-apps-9fe66f2af42e
- https://www.gate.io/learn/articles/zk-tls-shaping-the-future-of-secure-data-transmission/4466
- https://medium.com/zkpass/zktls-the-cornerstone-of-verifiable-internet-da8609a32754
- https://charlenenicer.substack.com/p/camping-with-zktls
- https://markaicode.com/zk-rollup-interoperability-2030-cross-l2-standards/
- https://blog.reclaimprotocol.org/posts/zk-in-zktls
- https://www.shoal.gg/p/zktls-verifiable-data-composability
Building with zkTLS: A Developer's Guide to Protocol Integration
Privacy verification tools comparison
This guide emerged from our work at Stormbit, where we're building infrastructure for global lending markets. Stormbit enables programmable, structured credit at scale through RWA-backed loans and zkTLS-powered trust-based lending, bridging DeFi's liquidity with TradFi's demand.
While implementing zkTLS solutions to verify off-chain data while preserving privacy (a critical function for next-generation lending), we've gained valuable insights about the various protocol implementations that we're sharing to help other developers make informed decisions.
What is zkTLS ?
Imagine an internet where every data interaction carries inherent proof of authenticity — this vision defines the verifiable web. zkTLS empowers users with cryptographic control over digital engagements. The true revolution lies not in the cryptographic algorithms themselves, but in their capacity to restore user sovereignty over online experiences.
With zkTLS, we can validate the authenticity and integrity of data without exposing personal privacy. This technology is precisely applied in Stormbit to verify off-chain data (e.g., bank statements and credit scores) while keeping details confidential, achieving verifiable yet invisible compliance.
Beyond its applications in DeFi, this technology holds transformative potential across multiple domains. Notable examples include:
- Combating fake reviews: Web proofs can restrict reviews to verified purchasers or users, ensuring only those who have genuinely interacted with a product, service, or location can submit feedback. For instance, platforms like Trustpilot could leverage web proofs to authenticate that reviewers have actually transacted with or used the business they are evaluating. This would drastically reduce fraudulent reviews and manipulation, elevating platform credibility.
- Resume verification automation: Employment platforms could automate credential validation and candidate-job matching. Today, rampant dishonesty in resumes forces companies to rely on inefficient manual checks — contacting universities and past employers to confirm details. Web proofs would streamline and secure this process, eliminating human error and revolutionizing the sector.
To realize this vision, zkTLS must overcome the limitations of traditional verification methods. Let's first examine these conventional approaches before diving into how zkTLS innovates
Three main approaches
Let's consider how user data verification might work without zkTLS. Two conventional approaches come to mind, both with significant limitations:
- Server-Side Verification Interfaces: This would require all data providers to implement new authentication and user authorization APIs. While technically possible, achieving widespread adoption across diverse services is highly impractical.
- Forwarding HTTPS Responses: While HTTPS ensures secure communication between a user and a server, forwarding session data (e.g., responses) to third parties compromises trustworthiness and risks exposing sensitive user information.
Both approaches have limited feasibility. Now, let's explore how zkTLS addresses these challenges through its specific mechanisms:
- Tee
The basic idea here is to use a tamper-proof CPU (e.g., Intel SGX, AMD SEV) to make HTTP requests. Because no entity — not even the owner of the TEE — can tamper with operations within the TEE, you can verify the data communicated within it. To produce "TEE-TLS," encrypted login credentials or authentication tokens are provided to the TEE service provider, which logs into the target website and securely stores responses. The TEE then generates a cryptographic signature proving data authenticity and provenance. This method is currently driven by the Clique team.
Workflow
User sends request to TEE provider
TEE logs into target server
Fetches response in TEE
TEE generates cryptographic signature
User receives signed proof
- Strength: Highly efficient, with minimal computational and networking overhead.
- Weakness: Security fully depends on hardware integrity and provider reliability.
As Dr. Andrew Miller at the University of Illinois has demonstrated through years of TEE breaches (primarily targeting Intel SGX), these systems are not perfect. Large-scale solutions relying solely on TEEs must address this challenge, especially in high-stakes scenarios like KYC (Know Your Customer) compliance.
While TEEs offer hardware-backed security, their reliance on centralized infrastructure raises concerns. Let's explore a more decentralized alternative.
- Proxy
The proxy-based approach simplifies zkTLS implementation by using intermediaries to facilitate secure communication. The proxy sits between the user and the target website, mediating HTTPS traffic. Since the proxy lacks decryption keys (only the user possesses them), it cannot modify received data.
Workflow
User sends request via Proxy
Proxy forwards request to target server
Fetches response and forwards to user
Proxy logs encrypted data
ZKP is generated locally by the user
- Strength: Fast execution and compatible with consumer devices.
- Weakness: Target servers may detect proxy IP addresses and block requests, and potential man-in-the-middle attacks on the proxy level.
The proxy model balances efficiency and decentralization, but IP detection remains a bottleneck. This leads us to a third approach combining cryptographic guarantees.
- MPC
The Multi-Party Computation (MPC) model in zkTLS introduces a third-party "Notary" that shares part of the session key with the user. This key is necessary for encrypting and decrypting TLS communications. Users must cooperate with the Notary to decrypt or encrypt data, preventing unilateral data manipulation. At the session's conclusion, the user creates a cryptographic commitment (hash of the data) and sends it to the Notary for blind signing.
Workflow
User sends request to target server
Third-party Notary shares session key
User + Notary encrypt/decrypt data
User generates cryptographic commitment
Notary signs commitment
- Strength: High security; target servers cannot detect Notary involvement.
- Weakness: Computational overhead and latency.
Comparative Analysis: use case & tech stack
Below is a comparison of how Reclaim, zkPass, Primus, and Opacity Network implement these approaches:
From this comparison, we observe distinct trade-offs between security, flexibility, and integration complexity. The star rating for integration complexity reflects a combination of development time and required tooling - more stars indicate a more streamlined developer experience with fewer external dependencies and setup requirements.
Primus
Primus offers unified APIs, allowing developers to choose between Proxy and MPC modes based on application requirements. Its "garble-then-prove" technique improves communication efficiency by 14x and runtime performance by 15.5x compared to traditional MPC models (Wunderlich, 2025).
- Tools: JavaScript SDK and Primus Chrome Extension required for verifying and proof generation.
- Integration: Customizable via Developer Hub.
Use Cases:
- Identity verification (PoH, KYC reuse)
- Financial proofs (on/off-chain assets)
- Academic credential validation
ZkPass
zkPass Protocol employs Hybrid Mode, which seamlessly switches between Proxy Mode and MPC 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, zkPass switches to operate in MPC Mode. Meanwhile the zkPass protocol employs the VOLEitH technique, ensures swift and efficient proof generation directly in the browser and device.
- Tools: JavaScript SDK and zkPass TransGate Extension required for verifying and proof generation.
- Integration: Custom schemas via Developer Tools. Requires zkPass Schema validator browser extension when creating new schema.
Use Cases:
- Identity verification (PoH, KYC reuse)
- Financial proofs (on/off-chain asset & activities)
- Academic credential validation (Education degree and transcript verification)
- Medical record sharing and insurance claims
- Social media (Identity Verification on Social Media, Decentralized Reputation Systems, Privacy-Preserving Ad Targeting.)
Reclaim
Reclaim Protocol employs a proxy-based model for zkTLS, which simplifies implementation and reduces computational overhead. This model introduces a trust assumption, as the proxy acts as an intermediary between the prover and verifier. While this approach is computationally efficient, it raises considerations around trust models. Reclaim implements cryptographic measures to address potential concerns, with theoretical security guarantees of 10^-40 probability of compromise (Wunderlich, 2025).
Developers can leverage AppClips and InstantApps integrations (Reclaim Verifier iOS, Reclaim Verifier Android) with plans for a browser extension in the future. The protocol supports numerous data sources and offers integration options for various web and mobile platforms. While well-suited for many verification use cases, applications requiring maximum decentralization may need to evaluate the proxy-based architecture carefully (Charlene's Substack, 2025).
- Cross-platform: Web & Mobile SDK
- Tools: No user-side installations required, verifications all happen in mobile side.
- Integration: Creating new integration through the developer tool with AI-assisted generation for custom providers.
Use Cases:
- Identity verification (PoH, KYC reuse)
- Transportation (ride-sharing history)
- Financial proofs (on/off-chain asset & activities)
- E-commerce (purchase history)
Opacity Network
Opacity Network combines TEE and MPC approaches in its architecture, with nodes operating within Intel SGX enclaves. The protocol also utilizes Eigenlayer AVS for additional security measures (Wunderlich, 2025).
This design aims to address potential vulnerabilities in other zkTLS models by implementing multiple security layers - hardware isolation through TEEs and cryptographic verification through a decentralized network of validators. Their approach creates a system where staked operators provide verification services, with economic incentives designed to maintain protocol integrity.
- Provides Mobile SDK for iOS, Android and cross-platform frameworks (Flutter/React Native), with verification processes occurring within the mobile application environment.
- Supports integrations through their partnership program, with available options listed in the Developer Portal.
Use Cases:
- E-commerce (purchase history)
- Social media (Ownership)
- Financial proofs (on/off-chain asset & activities)
- IP Ownership (digital assets like code, designs, and artwork)
- Real-World Interactions (Verifying attendance at events, confirm geo-locations, and authenticate reviews, adding credibility to platforms that bridge digital and physical interactions.)
Demo
Try it yourself! We've built a demo application where you can interact with these protocols. Install the required browser extensions mentioned in this guide before trying the demo.
Here is a case in Kaggle competition to verify user's verification status and performance tier, which is provided in Kaggle's GetCurrentUser endpoint. The request is triggered automatically after login. Except for Opacity, all three protocols support customized integration.
You can explore the full demonstration at the GitHub repository.
Customized integration:
- Primus: Follow the instruction in New Template in Developer Hub, it will be the simplest one during customized integration. In the following screenshot it only shows performanceTier template, verificationStatus can be created as the same way.
- zkPass: the new integration requires to fill a form, and the most complex part is the schema
- json, zkPass provide some official examples, can also reference our kaggle one:
Sample Code
{
"issuer": "Kaggle",
"desc": "Kaggle is a data science competition platform and online community for data scientists and machine learning practitioners under Google LLC.",
"website": "https://www.kaggle.com",
"APIs": [
{
"host": "www.kaggle.com",
"intercept": {
"url": "api/i/users.UsersService/GetCurrentUser",
"method": "POST"
},
"assert": [
{
"key": "performanceTier",
"value": "CONTRIBUTOR",
"operation": "!="
}
],
"nullifier": "id"
}
],
"HRCondition": ["Performance tier > CONTRIBUTOR"],
"tips": {
"message": "Please login with your kaggle account."
}
}
For the verificationStatus, the schema is almost same:
Sample Code
..."assert": [ { "key": "verificationStatus", "value": "USER_VERIFICATION_STATUS_UNVERIFIED", "operation": "=" }],...
The developer tool configuration should be like this, during the development process Domain is the localhost.
Reclaim: developer can follow the Video Guide, step by step. You can Search Kaggle Verification Status, Kaggle Performance Tier Provider in the provider market
dApp
To integrate theses protocols, you can follow the official documents to finish the proof generation process, also can add customize business logic. You can also check the flow in our source code demo.
Primus: generated the proof from the Primus Extension, you can add verified condition from JS code side
Sample Code
const request = primusZKTLS.generateRequestParams(attTemplateID, userAddress);const workMode = "proxytls"; // you can switch the work mode by yourselfrequest.setAttMode({ algorithmType: workMode,});const attConditions = [ [ { field: "performanceTier", op: "!=", value: "CONTRIBUTOR", }, ],];request.setAttConditions(attConditions);
The signature can be verified on chain, the parameters passed into the chain is same as the output of sdk call startAttestation
Sample Code
const provider = new ethers.JsonRpcProvider( process.env.NEXT_PUBLIC_SEPOLIA_RPC_URL);const contract = new ethers.Contract(primusAddress, primusABI, provider);try { const tx = await contract.verifyAttestation(attestation); console.log("Transaction:", tx);} catch (error) { console.error("Error in verifyAttestation:", error);}
zkPass: generated the proof from the TransGate Extension, the verified condition must be configured in during schema definition process.
Sample Code
... "assert": [ { "key": "performanceTier", "value": "CONTRIBUTOR", "operation": "!=" } ],...
The signature can be verified on chain, the parameters are needs to be formatted
Sample Code
const provider = new ethers.JsonRpcProvider( process.env.NEXT_PUBLIC_SEPOLIA_RPC_URL);const contract = new ethers.Contract(zkPassAddress, zkPassABI, provider);try { const tx = await contract.verify({ taskId: taskIdHex, schemaId: schemaIdHex, validator: validatorAddress, allocatorSignature, }); console.log("Transaction:", tx);} catch (error) { console.error("Error in verifyAttestation:", error);}
reclaim: generated the proof from the Reclaim Verifier mobile app, dApp started a session and waiting for the callback
Sample Code
await reclaimProofRequest.startSession({ onSuccess: async (proofs) => { console.log("Verification success", proofs); }, onError: (error) => { console.error("Verification failed", error); },});
As Reclaim doc mentioned, the verified condition can be configured in JS code. but no detail explanation or example, for now haven't figured out how to implement it.
The signature can be verified on chain, the parameters are need to be restructured.
Sample Code
try { const provider = new ethers.JsonRpcProvider( process.env.NEXT_PUBLIC_SEPOLIA_RPC_URL ); const contract = new ethers.Contract(reclaimAddress, reclaimABI, provider); const tx = await contract.verifyProof({ claimInfo: { provider: proof.claimData.provider, parameters: proof.claimData.parameters, context: proof.claimData.context, }, signedClaim: { claim: { identifier: proof.claimData.identifier, owner: proof.claimData.owner, timestampS: proof.claimData.timestampS, epoch: proof.claimData.epoch, }, signatures: proof.signatures, }, }); console.log("Transaction:", tx);} catch (error) { console.error("Error in verifyAttestation:", error);}
Opacity Network, you can reference official react native demo.
Key points:
- Dynamic response schema is not supported very well, only zkPass can provide a better user experience.
- Condition configuration in zkPass and Primus, can only support simple logic, for the complex logic involve multiple response fields can only be implemented with js code.
- During Reclaim verifying process, recommend to use instance app instead of downloading from App Store.
Conclusion
As Web3 continues to mature, zkTLS is positioned to become the backbone of privacy-preserving verification across the internet. We anticipate that within the next few years, these technologies will form the foundation of most identity and credential systems, bridging traditional finance and decentralized applications with unprecedented security and privacy guarantees.
Opacity Network implements a hybrid approach combining Trusted Execution Environment (TEE) and MPC technologies, reinforced by EigenLayer AVS for economic security. The platform provides mobile SDK integration options for iOS, Android, and cross-platform frameworks. While preset integrations are available through their developer portal, custom integration solutions can be accessed through their partnership program, making it an option for applications that prioritize hardware-backed security with decentralized validation mechanisms.
Primus and zkPass share similar web-based integration approaches using browser extensions, but with a key differentiation: Primus empowers developers to choose between Proxy and MPC architectures based on their specific application scenarios and service integration requirements. Both solutions currently face a common limitation – they can only verify data from API responses. This creates challenges for applications using Server-Side Rendering (SSR), where critical data might be embedded in HTML structures.
Reclaim Protocol now supports data extraction from both API responses and HTML content through its developer tool. While it offers pre-built connectors and support for numerous blockchain networks, HTML extraction can still present challenges for certain use cases. Reclaim is planning to release a browser extension soon, which should help address some of these limitations while maintaining its strengths in mobile integration.
Recommendations for Developers
When choosing a zkTLS solution for your project, consider the following:
- For mobile-native applications: Reclaim and Opacity Network offer the most streamlined integration experience, with Reclaim providing additional flexibility through its cross-platform support.
- For web applications: Primus and zkPass provide superior developer experiences when most verifications need to happen directly in the browser. Their browser extension-based approaches eliminate the need for additional mobile app dependencies.
- For contract integration: All protocols follow similar patterns for on-chain verification, primarily focusing on signature verification. The differences in implementation complexity lie mainly in the client-side integration rather than the smart contract side.
The decision should ultimately be guided by your specific application requirements, target platform, and the trade-offs between security models and user experience that best align with your project goals.
Ready to implement zkTLS in your application? Start with our demo repository or contact Stormbit to explore custom integration solutions for your specific needs.
To learn more about what Stormbit is doing in the zkTLS and DeFi space, follow us on X/Twitter.
References
- https://paragraph.com/@vinny/opacity-network-deepdive
- https://paragraph.com/@lemniscap/what-will-the-verifiable-web-look-like
- https://theaiinsider.tech/2024/10/19/zkpass-announces-12-5m-series-a-funding-to-drive-zktls-oracle-protocol/
- https://minaprotocol.com/blog/looking-towards-2025
- https://www.gate.io/learn/articles/zk-tls-unlocking-crypto-consumer-apps/7509
- https://www.opacity.network/
- https://finance.yahoo.com/news/series-funding-secures-12-5m-150000888.html
- https://medium.com/@wunderlichvalentin/zktls-unlocking-crypto-consumer-apps-9fe66f2af42e
- https://www.gate.io/learn/articles/zk-tls-shaping-the-future-of-secure-data-transmission/4466
- https://medium.com/zkpass/zktls-the-cornerstone-of-verifiable-internet-da8609a32754
- https://charlenenicer.substack.com/p/camping-with-zktls
- https://markaicode.com/zk-rollup-interoperability-2030-cross-l2-standards/
- https://blog.reclaimprotocol.org/posts/zk-in-zktls
- https://www.shoal.gg/p/zktls-verifiable-data-composability
Building with zkTLS: A Developer's Guide to Protocol Integration
Privacy verification tools comparison
This guide emerged from our work at Stormbit, where we're building infrastructure for global lending markets. Stormbit enables programmable, structured credit at scale through RWA-backed loans and zkTLS-powered trust-based lending, bridging DeFi's liquidity with TradFi's demand.
While implementing zkTLS solutions to verify off-chain data while preserving privacy (a critical function for next-generation lending), we've gained valuable insights about the various protocol implementations that we're sharing to help other developers make informed decisions.
What is zkTLS ?
Imagine an internet where every data interaction carries inherent proof of authenticity — this vision defines the verifiable web. zkTLS empowers users with cryptographic control over digital engagements. The true revolution lies not in the cryptographic algorithms themselves, but in their capacity to restore user sovereignty over online experiences.
With zkTLS, we can validate the authenticity and integrity of data without exposing personal privacy. This technology is precisely applied in Stormbit to verify off-chain data (e.g., bank statements and credit scores) while keeping details confidential, achieving verifiable yet invisible compliance.
Beyond its applications in DeFi, this technology holds transformative potential across multiple domains. Notable examples include:
- Combating fake reviews: Web proofs can restrict reviews to verified purchasers or users, ensuring only those who have genuinely interacted with a product, service, or location can submit feedback. For instance, platforms like Trustpilot could leverage web proofs to authenticate that reviewers have actually transacted with or used the business they are evaluating. This would drastically reduce fraudulent reviews and manipulation, elevating platform credibility.
- Resume verification automation: Employment platforms could automate credential validation and candidate-job matching. Today, rampant dishonesty in resumes forces companies to rely on inefficient manual checks — contacting universities and past employers to confirm details. Web proofs would streamline and secure this process, eliminating human error and revolutionizing the sector.
To realize this vision, zkTLS must overcome the limitations of traditional verification methods. Let's first examine these conventional approaches before diving into how zkTLS innovates
Three main approaches
Let's consider how user data verification might work without zkTLS. Two conventional approaches come to mind, both with significant limitations:
- Server-Side Verification Interfaces: This would require all data providers to implement new authentication and user authorization APIs. While technically possible, achieving widespread adoption across diverse services is highly impractical.
- Forwarding HTTPS Responses: While HTTPS ensures secure communication between a user and a server, forwarding session data (e.g., responses) to third parties compromises trustworthiness and risks exposing sensitive user information.
Both approaches have limited feasibility. Now, let's explore how zkTLS addresses these challenges through its specific mechanisms:
- Tee
The basic idea here is to use a tamper-proof CPU (e.g., Intel SGX, AMD SEV) to make HTTP requests. Because no entity — not even the owner of the TEE — can tamper with operations within the TEE, you can verify the data communicated within it. To produce "TEE-TLS," encrypted login credentials or authentication tokens are provided to the TEE service provider, which logs into the target website and securely stores responses. The TEE then generates a cryptographic signature proving data authenticity and provenance. This method is currently driven by the Clique team.
Workflow
User sends request to TEE provider
TEE logs into target server
Fetches response in TEE
TEE generates cryptographic signature
User receives signed proof
- Strength: Highly efficient, with minimal computational and networking overhead.
- Weakness: Security fully depends on hardware integrity and provider reliability.
As Dr. Andrew Miller at the University of Illinois has demonstrated through years of TEE breaches (primarily targeting Intel SGX), these systems are not perfect. Large-scale solutions relying solely on TEEs must address this challenge, especially in high-stakes scenarios like KYC (Know Your Customer) compliance.
While TEEs offer hardware-backed security, their reliance on centralized infrastructure raises concerns. Let's explore a more decentralized alternative.
- Proxy
The proxy-based approach simplifies zkTLS implementation by using intermediaries to facilitate secure communication. The proxy sits between the user and the target website, mediating HTTPS traffic. Since the proxy lacks decryption keys (only the user possesses them), it cannot modify received data.
Workflow
User sends request via Proxy
Proxy forwards request to target server
Fetches response and forwards to user
Proxy logs encrypted data
ZKP is generated locally by the user
- Strength: Fast execution and compatible with consumer devices.
- Weakness: Target servers may detect proxy IP addresses and block requests, and potential man-in-the-middle attacks on the proxy level.
The proxy model balances efficiency and decentralization, but IP detection remains a bottleneck. This leads us to a third approach combining cryptographic guarantees.
- MPC
The Multi-Party Computation (MPC) model in zkTLS introduces a third-party "Notary" that shares part of the session key with the user. This key is necessary for encrypting and decrypting TLS communications. Users must cooperate with the Notary to decrypt or encrypt data, preventing unilateral data manipulation. At the session's conclusion, the user creates a cryptographic commitment (hash of the data) and sends it to the Notary for blind signing.
Workflow
User sends request to target server
Third-party Notary shares session key
User + Notary encrypt/decrypt data
User generates cryptographic commitment
Notary signs commitment
- Strength: High security; target servers cannot detect Notary involvement.
- Weakness: Computational overhead and latency.
Comparative Analysis: use case & tech stack
Below is a comparison of how Reclaim, zkPass, Primus, and Opacity Network implement these approaches:
From this comparison, we observe distinct trade-offs between security, flexibility, and integration complexity. The star rating for integration complexity reflects a combination of development time and required tooling - more stars indicate a more streamlined developer experience with fewer external dependencies and setup requirements.
Primus
Primus offers unified APIs, allowing developers to choose between Proxy and MPC modes based on application requirements. Its "garble-then-prove" technique improves communication efficiency by 14x and runtime performance by 15.5x compared to traditional MPC models (Wunderlich, 2025).
- Tools: JavaScript SDK and Primus Chrome Extension required for verifying and proof generation.
- Integration: Customizable via Developer Hub.
Use Cases:
- Identity verification (PoH, KYC reuse)
- Financial proofs (on/off-chain assets)
- Academic credential validation
ZkPass
zkPass Protocol employs Hybrid Mode, which seamlessly switches between Proxy Mode and MPC 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, zkPass switches to operate in MPC Mode. Meanwhile the zkPass protocol employs the VOLEitH technique, ensures swift and efficient proof generation directly in the browser and device.
- Tools: JavaScript SDK and zkPass TransGate Extension required for verifying and proof generation.
- Integration: Custom schemas via Developer Tools. Requires zkPass Schema validator browser extension when creating new schema.
Use Cases:
- Identity verification (PoH, KYC reuse)
- Financial proofs (on/off-chain asset & activities)
- Academic credential validation (Education degree and transcript verification)
- Medical record sharing and insurance claims
- Social media (Identity Verification on Social Media, Decentralized Reputation Systems, Privacy-Preserving Ad Targeting.)
Reclaim
Reclaim Protocol employs a proxy-based model for zkTLS, which simplifies implementation and reduces computational overhead. This model introduces a trust assumption, as the proxy acts as an intermediary between the prover and verifier. While this approach is computationally efficient, it raises considerations around trust models. Reclaim implements cryptographic measures to address potential concerns, with theoretical security guarantees of 10^-40 probability of compromise (Wunderlich, 2025).
Developers can leverage AppClips and InstantApps integrations (Reclaim Verifier iOS, Reclaim Verifier Android) with plans for a browser extension in the future. The protocol supports numerous data sources and offers integration options for various web and mobile platforms. While well-suited for many verification use cases, applications requiring maximum decentralization may need to evaluate the proxy-based architecture carefully (Charlene's Substack, 2025).
- Cross-platform: Web & Mobile SDK
- Tools: No user-side installations required, verifications all happen in mobile side.
- Integration: Creating new integration through the developer tool with AI-assisted generation for custom providers.
Use Cases:
- Identity verification (PoH, KYC reuse)
- Transportation (ride-sharing history)
- Financial proofs (on/off-chain asset & activities)
- E-commerce (purchase history)
Opacity Network
Opacity Network combines TEE and MPC approaches in its architecture, with nodes operating within Intel SGX enclaves. The protocol also utilizes Eigenlayer AVS for additional security measures (Wunderlich, 2025).
This design aims to address potential vulnerabilities in other zkTLS models by implementing multiple security layers - hardware isolation through TEEs and cryptographic verification through a decentralized network of validators. Their approach creates a system where staked operators provide verification services, with economic incentives designed to maintain protocol integrity.
- Provides Mobile SDK for iOS, Android and cross-platform frameworks (Flutter/React Native), with verification processes occurring within the mobile application environment.
- Supports integrations through their partnership program, with available options listed in the Developer Portal.
Use Cases:
- E-commerce (purchase history)
- Social media (Ownership)
- Financial proofs (on/off-chain asset & activities)
- IP Ownership (digital assets like code, designs, and artwork)
- Real-World Interactions (Verifying attendance at events, confirm geo-locations, and authenticate reviews, adding credibility to platforms that bridge digital and physical interactions.)
Demo
Try it yourself! We've built a demo application where you can interact with these protocols. Install the required browser extensions mentioned in this guide before trying the demo.
Here is a case in Kaggle competition to verify user's verification status and performance tier, which is provided in Kaggle's GetCurrentUser endpoint. The request is triggered automatically after login. Except for Opacity, all three protocols support customized integration.
You can explore the full demonstration at the GitHub repository.
Customized integration:
- Primus: Follow the instruction in New Template in Developer Hub, it will be the simplest one during customized integration. In the following screenshot it only shows performanceTier template, verificationStatus can be created as the same way.
- zkPass: the new integration requires to fill a form, and the most complex part is the schema
- json, zkPass provide some official examples, can also reference our kaggle one:
Sample Code
{
"issuer": "Kaggle",
"desc": "Kaggle is a data science competition platform and online community for data scientists and machine learning practitioners under Google LLC.",
"website": "https://www.kaggle.com",
"APIs": [
{
"host": "www.kaggle.com",
"intercept": {
"url": "api/i/users.UsersService/GetCurrentUser",
"method": "POST"
},
"assert": [
{
"key": "performanceTier",
"value": "CONTRIBUTOR",
"operation": "!="
}
],
"nullifier": "id"
}
],
"HRCondition": ["Performance tier > CONTRIBUTOR"],
"tips": {
"message": "Please login with your kaggle account."
}
}
For the verificationStatus, the schema is almost same:
Sample Code
..."assert": [ { "key": "verificationStatus", "value": "USER_VERIFICATION_STATUS_UNVERIFIED", "operation": "=" }],...
The developer tool configuration should be like this, during the development process Domain is the localhost.
Reclaim: developer can follow the Video Guide, step by step. You can Search Kaggle Verification Status, Kaggle Performance Tier Provider in the provider market
dApp
To integrate theses protocols, you can follow the official documents to finish the proof generation process, also can add customize business logic. You can also check the flow in our source code demo.
Primus: generated the proof from the Primus Extension, you can add verified condition from JS code side
Sample Code
const request = primusZKTLS.generateRequestParams(attTemplateID, userAddress);const workMode = "proxytls"; // you can switch the work mode by yourselfrequest.setAttMode({ algorithmType: workMode,});const attConditions = [ [ { field: "performanceTier", op: "!=", value: "CONTRIBUTOR", }, ],];request.setAttConditions(attConditions);
The signature can be verified on chain, the parameters passed into the chain is same as the output of sdk call startAttestation
Sample Code
const provider = new ethers.JsonRpcProvider( process.env.NEXT_PUBLIC_SEPOLIA_RPC_URL);const contract = new ethers.Contract(primusAddress, primusABI, provider);try { const tx = await contract.verifyAttestation(attestation); console.log("Transaction:", tx);} catch (error) { console.error("Error in verifyAttestation:", error);}
zkPass: generated the proof from the TransGate Extension, the verified condition must be configured in during schema definition process.
Sample Code
... "assert": [ { "key": "performanceTier", "value": "CONTRIBUTOR", "operation": "!=" } ],...
The signature can be verified on chain, the parameters are needs to be formatted
Sample Code
const provider = new ethers.JsonRpcProvider( process.env.NEXT_PUBLIC_SEPOLIA_RPC_URL);const contract = new ethers.Contract(zkPassAddress, zkPassABI, provider);try { const tx = await contract.verify({ taskId: taskIdHex, schemaId: schemaIdHex, validator: validatorAddress, allocatorSignature, }); console.log("Transaction:", tx);} catch (error) { console.error("Error in verifyAttestation:", error);}
reclaim: generated the proof from the Reclaim Verifier mobile app, dApp started a session and waiting for the callback
Sample Code
await reclaimProofRequest.startSession({ onSuccess: async (proofs) => { console.log("Verification success", proofs); }, onError: (error) => { console.error("Verification failed", error); },});
As Reclaim doc mentioned, the verified condition can be configured in JS code. but no detail explanation or example, for now haven't figured out how to implement it.
The signature can be verified on chain, the parameters are need to be restructured.
Sample Code
try { const provider = new ethers.JsonRpcProvider( process.env.NEXT_PUBLIC_SEPOLIA_RPC_URL ); const contract = new ethers.Contract(reclaimAddress, reclaimABI, provider); const tx = await contract.verifyProof({ claimInfo: { provider: proof.claimData.provider, parameters: proof.claimData.parameters, context: proof.claimData.context, }, signedClaim: { claim: { identifier: proof.claimData.identifier, owner: proof.claimData.owner, timestampS: proof.claimData.timestampS, epoch: proof.claimData.epoch, }, signatures: proof.signatures, }, }); console.log("Transaction:", tx);} catch (error) { console.error("Error in verifyAttestation:", error);}
Opacity Network, you can reference official react native demo.
Key points:
- Dynamic response schema is not supported very well, only zkPass can provide a better user experience.
- Condition configuration in zkPass and Primus, can only support simple logic, for the complex logic involve multiple response fields can only be implemented with js code.
- During Reclaim verifying process, recommend to use instance app instead of downloading from App Store.
Conclusion
As Web3 continues to mature, zkTLS is positioned to become the backbone of privacy-preserving verification across the internet. We anticipate that within the next few years, these technologies will form the foundation of most identity and credential systems, bridging traditional finance and decentralized applications with unprecedented security and privacy guarantees.
Opacity Network implements a hybrid approach combining Trusted Execution Environment (TEE) and MPC technologies, reinforced by EigenLayer AVS for economic security. The platform provides mobile SDK integration options for iOS, Android, and cross-platform frameworks. While preset integrations are available through their developer portal, custom integration solutions can be accessed through their partnership program, making it an option for applications that prioritize hardware-backed security with decentralized validation mechanisms.
Primus and zkPass share similar web-based integration approaches using browser extensions, but with a key differentiation: Primus empowers developers to choose between Proxy and MPC architectures based on their specific application scenarios and service integration requirements. Both solutions currently face a common limitation – they can only verify data from API responses. This creates challenges for applications using Server-Side Rendering (SSR), where critical data might be embedded in HTML structures.
Reclaim Protocol now supports data extraction from both API responses and HTML content through its developer tool. While it offers pre-built connectors and support for numerous blockchain networks, HTML extraction can still present challenges for certain use cases. Reclaim is planning to release a browser extension soon, which should help address some of these limitations while maintaining its strengths in mobile integration.
Recommendations for Developers
When choosing a zkTLS solution for your project, consider the following:
- For mobile-native applications: Reclaim and Opacity Network offer the most streamlined integration experience, with Reclaim providing additional flexibility through its cross-platform support.
- For web applications: Primus and zkPass provide superior developer experiences when most verifications need to happen directly in the browser. Their browser extension-based approaches eliminate the need for additional mobile app dependencies.
- For contract integration: All protocols follow similar patterns for on-chain verification, primarily focusing on signature verification. The differences in implementation complexity lie mainly in the client-side integration rather than the smart contract side.
The decision should ultimately be guided by your specific application requirements, target platform, and the trade-offs between security models and user experience that best align with your project goals.
Ready to implement zkTLS in your application? Start with our demo repository or contact Stormbit to explore custom integration solutions for your specific needs.
To learn more about what Stormbit is doing in the zkTLS and DeFi space, follow us on X/Twitter.
References
- https://paragraph.com/@vinny/opacity-network-deepdive
- https://paragraph.com/@lemniscap/what-will-the-verifiable-web-look-like
- https://theaiinsider.tech/2024/10/19/zkpass-announces-12-5m-series-a-funding-to-drive-zktls-oracle-protocol/
- https://minaprotocol.com/blog/looking-towards-2025
- https://www.gate.io/learn/articles/zk-tls-unlocking-crypto-consumer-apps/7509
- https://www.opacity.network/
- https://finance.yahoo.com/news/series-funding-secures-12-5m-150000888.html
- https://medium.com/@wunderlichvalentin/zktls-unlocking-crypto-consumer-apps-9fe66f2af42e
- https://www.gate.io/learn/articles/zk-tls-shaping-the-future-of-secure-data-transmission/4466
- https://medium.com/zkpass/zktls-the-cornerstone-of-verifiable-internet-da8609a32754
- https://charlenenicer.substack.com/p/camping-with-zktls
- https://markaicode.com/zk-rollup-interoperability-2030-cross-l2-standards/
- https://blog.reclaimprotocol.org/posts/zk-in-zktls
- https://www.shoal.gg/p/zktls-verifiable-data-composability
