State of zk-TLS

Why it matters, how it works, real use cases, and what’s next.

Key Insights

  • The internet today is concentrated within the walled gardens of a handful of Web2 platforms.
  • zk-TLS makes all user data on Web2 platforms verifiable, enabling users to port their data to any 3rd party or smart contract without permission from the Web2 platform. It puts the user back at the center of the value exchange.
  • Because the data has been verified, zk-TLS enables other companies to build and stack economic incentives directly atop and across previously siloed data stacks with user permission.
  • With ~95% of internet activity secured by TLS, zk-TLS offers a wide range of potential use cases and is one of the most critical pieces enabling the vision of a sovereign and composable internet.
  • We anticipate the first zk-TLS use cases to find product-market fit (PMF) in 2025 and widespread adoption to occur in 2028 and beyond.

Why We Need zk-TLS

Example zk-TLS Use Cases
Figure 1. Example zk-TLS Use Cases

The original vision for the internet was to be open and composable. Initially, Web2 platforms encouraged composability and offered API access to attract users and developers. However, as network effects solidified, their focus shifted to value extraction, leading to walled gardens that lock in user data. Twitter, once an advocate for composability, restricted API access before its IPO in 2013, cutting off developers overnight. Currently, Facebook blocks migration of friends or messages to other platforms, Uber keeps driver ratings siloed internally, and LinkedIn provides minimal export data of connections.

Web2 Platforms Extract Value Against Users' Interests Over Time
Figure 2. Web2 Platforms Extract Value Against Users' Interests Over Time

Web2 platforms control user data because Transport Layer Security (TLS), the protocol that secures communication between a website and a user, relies on two-way signing that cannot be independently verified.

Zero-knowledge Transport Layer Security (zk-TLS) hacks this system, enabling third parties to verify user data without requiring the consent of Web2 platforms. With user permission, any exposed data (even under password) can now be verified by third parties. In other words, all user data across the internet is now verifiable and portable.

With ~95% of activity on the internet utilizing the TLS protocol, zk-TLS holds the potential to completely upend Web2, breaking trillion-dollar monopolies and returning full data ownership to users.

Imagine receiving free Taylor Swift tickets by sharing your Spotify listening history and Starbucks reward points directly with Taylor Swift’s team. Today, this is bogged down by coordination among parties and royalties. With zk-TLS, Taylor’s team could verify you’re a top 0.01% superfan and that you’ve ordered her branded Christmas creamsicle latte (not real) without involving Spotify or Starbucks, with the whole process automated by smart contracts.

What if you aggregated all your entertainment data across streaming services (Hulu, Disney+, Netflix), music (Apple Music, Spotify), short-form video (YouTube Shorts, TikTok), and social media (Instagram, Facebook, VSCO)? Verifiable data could unlock novel experiences, monetization opportunities, and cross-platform rewards. A game developer could offer in-game perks by verifying you watched their Twitch streams, posted on Instagram, and listened on Spotify.

Using zero-knowledge proofs (ZKPs), users can cryptographically prove they meet conditions to 3rd parties without sharing underlying data, maximizing privacy and security. From social media to AI to invoice factoring, the possibilities are vast.

In this report, we dive into zk-TLS architecture, survey emerging providers and applications, highlight promising use cases, and provide insight into where the space is heading.

Background

zk-TLS Progress Timeline
Figure 3. zk-TLS Progress Timeline

zk-TLS represents the culmination of decades of cryptographic innovation. Its journey in crypto began in 2014 with TLSNotary (TLSN), developed largely by Ethereum researchers. TLSN verified data provenance (origin) but faced scalability challenges due to server cooperation and lack of privacy guarantees.

In 2019, Cornell researchers introduced DECO, which utilized ZKPs to verify data authenticity without server involvement and enabled privacy-preserving, selective data sharing. To fully scale, further advances in ZKPs and multi-party computation (MPC) were needed—advances that paved the way for zk-TLS.

Initial DECO Whitepaper
Figure 4. Initial DECO Whitepaper

Breakthroughs from 2020–2023 in ZK and cryptography made commercial-grade zk-TLS viable, spurring numerous companies with different approaches. We anticipate first PMF by 2025 and broader adoption from 2028 onward.

How Does zk-TLS Work

At a high level, zk-TLS providers validate data sent between a user/client and a server/website within a TLS handshake. The validator verifies both provenance (where the data comes from) and authenticity (correctness) without access to sensitive user info like passwords or even the data itself.

High Level zk-TLS Architecture
Figure 5. High Level zk-TLS Architecture

Broad approaches:

  • MPC schemes (e.g., Opacity, Primus)
  • Proxy-based approaches (e.g., Reclaim, Pluto)
  • Trusted Execution Environment (TEE)-based architectures (e.g., Clique)

Remember: the goal of zk-TLS is to verify that a user logged in correctly and the server returned the appropriate information.

zk-TLS Multi-Party computation (MPC) Architecture
Figure 6. zk-TLS Multi-Party computation (MPC) Architecture

MPC Architecture

In the MPC approach, a trusted node called a notary conducts the login with the user. MPC allows multiple parties to compute without any single party subverting the system (think a door with two locks that require two different keys). If the MPC scheme isn’t correctly implemented with the notary, the notary won’t attest to the data.

To increase security, MPC-based zk-TLS providers like Opacity leverage EigenLayer’s economic security via an AVS. If a notary colludes with a user to fabricate data, it can be slashed for attesting to an impossible claim—adding economic incentives atop TEE and protocol safeguards.

Opacity's Multi-Party-Compute
Figure 7. Opacity's Multi-Party-Compute

Proxy Architecture

The proxy approach uses the browser’s proxy feature: the browser routes messages via a validator node acting as an HTTPS proxy. The node sees all encrypted messages between server and client (not their plaintext), and can sign which messages come from where. The client then produces a ZK proof that the correct information was accessed and fits certain criteria (e.g., bank balance > $10,000).

zk-TLS Proxy Architecture
Figure 8. zk-TLS Proxy Architecture

At scale, sites can block obvious proxy nodes (e.g., if a bank sees thousands of sessions from one IP). Residential IP providers exist but raise uptime/reliability concerns and attack surfaces (a malicious client acting as the residential proxy could attempt to fake proofs).

Other Implementations / TEE

A minimalist approach relies on Trusted Execution Environments (TEEs)—secure areas within a processor. A user encrypts credentials; the TEE decrypts inside its enclave, performs the TLS handshake, fetches data, and returns signed data or a ZK proof. This approach relies on hardware trust; vulnerabilities in hardware or new, less-tested TEEs could expose risk. Some providers combine approaches (e.g., running MPC inside TEEs plus rotating node selection).

zk-TLS TEE Architecture
Figure 9. zk-TLS TEE Architecture

zk-TLS Use Cases

zk-TLS use cases
Figure 10. zk-TLS Use Cases

zk-TLS puts users at the center of the value exchange. Because data is verified, developers can layer incentives and economic activity across previously siloed stacks, with user permission.

Entertainment & Media

Users could run decentralized tournaments with escrowed funds; winners present a zk-TLS proof to a smart contract to withdraw. Developers can reward player actions (e.g., watch hours, comments on Twitch) with granular, verifiable incentives. Unified media experiences become possible across streaming and music services.

AI, Agents & Intents

The data problem: Large models are shifting to synthetic data; small models need domain-specific real data but can’t cut huge access deals. zk-TLS enables low-cost, verifiable data access from private sources, boosting small-model competitiveness.

Agents & intents: Intent systems need to verify actions (including Web2 interactions). zk-TLS lets agents confirm, for example, that a bet on a platform meets criteria before acting—enabling multi-step, cross-source workflows with privacy.

Invoice Factoring

Today, verification is manual and risky (sharing passwords). zk-TLS allows a company to submit a proof of invoice delivery without revealing credentials, enabling faster, automated underwriting and even on-chain settlement via smart contracts.

zk-TLS Unlocks DePIN

High-P DePINs struggle with verification (location and tamper resistance). Example: Daylight Energy aggregates DERs; zk-TLS (e.g., via Opacity’s MPC) helps verify monthly energy expenditure and cross-check against sensors, reducing fraud and accelerating growth.

Web2 Vampires: Nosh & Teleport

Gig-economy platforms take large fees (e.g., rideshare ~44%). DePIN alternatives (e.g., Nosh, Teleport) can charge less (Teleport ~15%) but must maintain quality. zk-TLS lets drivers port verifiable ratings and data from Uber/Lyft/DoorDash without exposing sensitive info—bootstrapping supply while preserving standards.

More Efficient Use Case: Earnifi

Payday loans and instant transfers impose high costs. Earnifi uses zk-TLS (via Opacity) and crypto rails to sync real-time payroll data (with consent), reducing charge-offs from 6.3% to 0.3% and enabling inclusive, fast access—potentially real-time payment streaming as proofs mature.

Earnifi's Workflow Compared to Traditional EWA Providers
Figure 11. Earnifi's Workflow Compared to Traditional EWA Providers

Aggregating Data: Icebreaker

Icebreaker builds a decentralized LinkedIn using Reclaim’s proxy-based zk-TLS to import entire networks under user control. Early data: users average ~1,300 contacts imported; platform totals >50,000 imports—suggesting strong viral potential if invites are enabled.

Social Media Megalith: Daisy

Daisy pays influencers for boosting each other’s sponsored content (likes, comments, reposts). zk-TLS enhances attribution using private metrics only visible to account owners and enables verification in exclusive/paid groups—driving 10–20× traffic and 25–50% lower CPA in early tests.

Challenges

  • Scalability: Proxy approaches may be blocked at scale; large “vampire” use cases remain to be proven in production.
  • Incumbent response: Well-funded Web2 platforms may mount technical and legal challenges.
  • Familiarity gap: ZK tech is still niche; many Web2 teams need education and tooling to integrate.

Conclusion

zk-TLS holds the promise to upend Web2 by giving users ownership over their data—unlocking portability, new incentive layers, and privacy-preserving verification across the internet. The tech is early, but 2025 could see first PMF, opening the door to mass adoption in the years ahead. zk-TLS is a must-watch space.

Get a PDF version of this annual report:

State of zk-TLS by Escape Velocity

📄 Download Annual Report