#16 - zkTLS and the DECO Protocol

A Conversation with Prof. Fan Zhang of Yale University

By Yavor Litchev and Jay Yu

Key Takeaways:

• TLS secures the Internet, but lacks exportable provenance: TLS protects data in transit, but can’t prove where it came from. zkTLS (as implemented in DECO) fixes that with verifiable, cryptographic proof without needing server changes.

• DECO combines MPC and ZKPs: DECO uses a three-party handshake to split TLS session keys via multi-party computation, preventing session forgery. It then adds zero-knowledge proofs so users can prove facts (“I'm over 21”) without exposing raw data.

• zkTLS is fast, private, and verifiable: Techniques like selective disclosure and context-aware parsing reduce ZK proof costs while maintaining semantic integrity. Hash-based MPC and 2PC optimizations keep protocol performance within practical bounds.

• DECO has inspired multiple practical instantiations of zkTLS: Opacity and Reclaim are leading implementations of zkTLS inspired by DECO with different architectures. Opacity uses MPC, TEEs, and slashing for stronger security. Reclaim trades that for speed, with faster attestations via proxy attestors.

• zkTLS powers real-world apps: Applications include decentralized KYC, credit-based DeFi lending (3Jane), automated background checks (TransCrypts), and loyalty credentialing (e.g., Reclaim + Marriott). zkTLS also unlocks new AI applications, by creating a pipeline for models to safely ingest private user data. It creates a new trust layer for the web, independent of APIs or server cooperation.

Introduction

Transport Layer Security (TLS) is the cryptographic backbone of the modern internet, securing billions of web sessions daily. It guarantees confidentiality and integrity between clients and servers, ensuring that users can safely exchange data with websites. However, TLS has a critical shortcoming: it does not enable users to cryptographically prove to third parties that the data they accessed genuinely came from a specific website. While data is encrypted and authenticated in transit, it lacks exportable provenance: a way to vouch for the authenticity of data after the session ends.

This limitation has stymied applications like private age verification, authenticated financial disclosures, or fair pricing enforcement, especially in contexts like blockchain smart contracts, which require verifiable, third-party data. Existing solutions like trusted hardware (e.g., Intel SGX) or server-side modifications break legacy compatibility or introduce new trust assumptions.

zkTLS, exemplified by DECO [1], solves this by allowing users to generate zero-knowledge proofs about data retrieved over TLS without modifying servers or relying on trusted hardware. In this article, we will first explore the cryptographic foundations of zkTLS, including TLS internals, secure multiparty computation, and zero-knowledge proofs. From there, we will provide a technical walkthrough of zkTLS as envisioned by the DECO protocol, and finally survey real-world use cases and practical deployments that demonstrate the transformative potential of zkTLS.

1 - A Crash Course on the Fundamentals of zkTLS

At its core, zkTLS (Zero-Knowledge TLS) aims to bridge the gap between secure data access and verifiable data provenance. While TLS ensures that communication between a client and server is secure, it does not leave behind cryptographic evidence that the data came from the claimed server. As a result, users are unable to export trustworthy, privacy-preserving attestations of online data, which is a major limitation in an era where data portability and trust minimization are paramount.

Imagine Alice wants to prove to Bob that she is over 18, based on a date of birth retrieved from a government portal. While Alice could show Bob a screenshot or forward the data, Bob cannot verify whether this information truly originated from the government’s website, since TLS protects data in transit but does not sign the content. The same challenge arises in proving financial solvency from a bank account or contesting discriminatory pricing. Screenshots can be forged, and server cooperation is often unavailable or insufficiently trustworthy. zkTLS, specifically through the DECO protocol, tackles this by enabling users to interact with any standard TLS-enabled website, extract data privately, and prove statements about that data to a verifier, all without altering the website or involving trusted execution environments (TEEs).

TLS Protocol [2]

Before we examine the protocol details, it is prudent to first understand TLS as it currently exists, along with some other important cryptographic primitives. TLS is a cryptographic protocol that ensures confidentiality and authenticity during web communications [2]. It consists of two main phases, one of them being a handshake protocol to establish a secure session using asymmetric cryptography and performs key exchange (e.g., via ephemeral Diffie-Hellman). The second main phase is the record protocol, which uses the shared symmetric keys derived from the handshake to encrypt and authenticate subsequent data transmissions. While TLS ensures that Alice receives data from the server securely, it does not provide her with a way to prove to Bob that the data truly originated from the server. Both Alice and the server possess the same symmetric keys, which means Alice can forge TLS messages after the fact, thereby breaking any notion of post hoc authenticity.

Prior approaches to TLS provenance typically fall into two categories: Trusted Hardware Solutions (e.g., Town Crier relies on Intel SGX to sign TLS data) [3], or Server-Side Modifications, where TLS is modified to include signatures on data or enable verifiable logging. The problem with the former solution is that SGX (and TEEs in general) introduce new trust and security risks (e.g., side-channel attacks), whereas the issue with the latter solution is that it requires changes to the server software stack, which greatly limits deployability. DECO, and zkTLS generally, distinguishes itself by being legacy compatible, operating with any TLS server without cooperation or modification.

One of the cryptographic primitives that allows for DECO to function on legacy systems is Multiparty Computation (MPC). Secure Multiparty Computation (MPC) allows two or more parties to jointly compute a function over their inputs without revealing them. In the context of zkTLS, MPC is used to establish shared secrets (specifically, the session keys used in the TLS protocol such that neither party has access to the complete key, and the client (i.e., the prover) cannot forge or tamper with TLS records. DECO achieves this through a three-party handshake in which the prover (Alice) and the verifier (Bob) cooperate to jointly act as a TLS client. They run a two-party protocol to split the session keys between them. For instance, Alice and Bob compute additive shares of the MAC key such that neither knows the full key, but together they enable a valid TLS session. This ensures Alice cannot forge valid TLS traffic after the fact.

Zero-Knowledge Proofs (ZKPs).

Zero-knowledge proofs, another critical cryptographic primitive used in DECO, allow one party (the prover) to convince another (the verifier) that a certain statement is true, without revealing why it’s true or leaking any other information. In DECO, once Alice (the prover) has obtained a response from the server, she generates a cryptographic commitment to the session data. She then uses a zero-knowledge proof to prove the data she received satisfies a desired predicate (e.g., “I am over 18”) without revealing the underlying data (e.g., her birthdate). This allows for privacy-preserving attestations of sensitive information, a fundamental breakthrough for applications like identity verification or decentralized finance.

zkTLS combines these elements as follows:

1. Three-Party Handshake (TLS + MPC): Alice and Bob engage in a handshake with the server, producing shared keys such that Alice alone cannot forge session data. This maintains TLS compatibility.

2. Query Execution and Commitment (TLS + MPC): Alice constructs a TLS query (e.g., an HTTP request) using her private data (like a login credential), and sends it to the server. She commits to the resulting session transcript.

3. Proof Generation (ZKPs): Alice proves in zero knowledge that the session data satisfies a predicate (e.g., account balance > $1000), and that it was obtained from the correct source via a proper TLS session.

This architecture avoids the need for trusted hardware, works with existing web infrastructure, and enables selective disclosure, for instance, revealing that a condition is met without disclosing the underlying data.

The next section of the article will dive deeper into how these components are technically realized in DECO’s protocol, including the construction of the three-party handshake, optimized MPC protocols for query execution, and efficient techniques for generating zero-knowledge proofs on TLS transcripts.

2 - A Technical Deep Dive into the DECO Protocol for zkTLS

At the heart of DECO’s architecture is a clever synthesis of classic TLS security with modern cryptographic techniques such as secure multiparty computation (MPC) and zero-knowledge proofs (ZKPs). This section unpacks each of DECO’s core protocol phases in detail, examining how cryptographic primitives are tailored to preserve data provenance while maintaining compatibility with the existing TLS ecosystem.

A fundamental innovation of DECO is the three-party handshake between the prover (Alice), the verifier (Bob), and an unmodified TLS server. This handshake allows Alice and Bob to jointly participate in a TLS connection to a server such that neither party knows the full cryptographic keys used to authenticate the session. This eliminates the ability of Alice to forge or manipulate TLS session data after the fact, the key foundation for proving provenance.

Source: Original Content

TLS typically establishes a symmetric session key via an ephemeral Diffie-Hellman key exchange. In DECO, this handshake is modified such that the session key — specifically the MAC key (k_MAC) — is additively shared between Alice and Bob:

Here, k_P​ and k_V​ are shares held respectively by Alice (the prover) and Bob (the verifier), with the server S receiving the full key k_MAC​ for encryption and authentication. The process involves two major steps:

1. Ephemeral Diffie-Hellman Key Exchange (ECDHE): Alice and Bob contribute public keys to derive a common secret g^x, without either party learning the full exponent. The server contributes its own ephemeral key g^s, completing the key exchange.
   
   

2. Key Derivation via MPC: Since TLS session keys are derived via a pseudorandom function (PRF) over the Diffie-Hellman output, DECO uses two-party computation (2PC) to compute this derivation jointly. This is a non-trivial task because TLS-PRF is hash-based and lacks algebraic structure, requiring MPC to handle bitwise operations securely.

By ensuring neither party has full control over the MAC key until the session is cryptographically committed, the handshake defends against forgery: Alice cannot modify session content post-hoc without breaking the MAC.

Once the handshake is complete, Alice must construct a valid query to the server and receive the response, all under TLS. The key challenge is that the session keys are now split between Alice and Bob. Hence, even basic TLS operations like MAC generation (in CBC-HMAC) or authenticated encryption (in AES-GCM) must be computed via secure 2PC protocols. For cipher suites using CBC-HMAC (common in TLS 1.2), the record protocol operates by first computing a MAC over the plaintext and then encrypting the message plus MAC. To generate the MAC securely, Alice and Bob compute the inner hash locally on Alice’s side, enabled by giving her a hash of the padded MAC key (i.e., H(k⊕ipad)), which does not leak the key itself due to the one way properties of cryptographic hash functions. They then perform 2PC only for the outer hash, which is short. This reduces the MPC burden significantly, as without this optimization computing HMAC over a large query in MPC would be prohibitively expensive.

For AES-GCM mode, encryption and authentication are combined into a single operation. However, unlike CBC-HMAC, it lacks a commitment property, the ciphertext does not bind to a unique plaintext, which complicates provenance guarantees. DECO supports AES-GCM by using optimized 2PC protocols for AES encryption and polynomial evaluation in Galois fields (for GCM authentication tags).

For performance-critical deployments, DECO also introduces a proxy mode, which is particularly useful for GCM. In this mode, Bob acts as a passive network proxy who relays and logs the traffic between Alice and the server. This simplifies provenance, as Bob witnesses the session directly. However, the security guarantees differ, it shifts trust toward the verifier's honest behavior and is best suited to settings where Bob is semi-trusted.

For the proof generation phase of the protocol that occurs after the server respond to Alice, she wishes to prove to Bob that the data:

1. Came from the server (provenance)

2. Satisfies a desired predicate (e.g., over 18)

3. Without revealing the data itself (privacy)

This is where zero-knowledge proofs (zkPs) come into play. Alice commits to the TLS transcript and proves a statement of the form:

Where:

• k_Enc​ is the encryption key,

• X is the decrypted TLS record,

• Verify ensures MAC correctness,

• Stmt(X) evaluates the predicate.

Generating such proofs over entire transcripts could be computationally prohibitive. DECO addresses this with two optimizations: Selective opening, and two-stage parsing for context integrity. Selective opening means the following: instead of revealing or proving over full session data, Alice can reveal substrings of the TLS response, or redact portions of the message to preserve privacy. For example, she might reveal only a checking account balance, not the full bank statement. This selective opening is proven in zero knowledge using optimized circuits that process only the revealed parts, reducing proof size and cost. However, selective disclosure introduces a risk: Alice could quote a snippet out of context (e.g., showing a $5000 value from a message to customer service rather than the actual bank balance) and therefore prove faulty statements. To prevent such context integrity attacks, DECO introduces two-stage parsing:Local parsing and zero-knowledge proof. In local parsing, Alice parses the full session response to identify where her substring appears within a structured format (e.g., JSON). As for the zero-knowledge proof portion, she proves in ZK that the substring came from the correct structural location in the original document. This is formalized by reasoning over the structure using context-free grammars (the same way in which a compiler reasons if some piece of Python or C code is actually valid code), ensuring that any disclosed fragment is bound to the intended semantic structure.

While the main DECO protocol is ZKP-based, the original paper and interview also discuss a variant based on Trusted Execution Environments (TEEs) like Intel SGX (as was briefly mentioned in Section 1). In this mode, a TLS client runs entirely inside the TEE so as to guarantee that the prover has no access to the session keys. Provenance is thus established by logging or signing the session inside the enclave. This approach benefits from lower computational overhead (only 10–20% slower than native TLS) compared to the orders-of-magnitude cost of ZK proofs. However, it introduces reliance on hardware trust, including vulnerability to side-channel attacks, as well as vendor trust, including firmware, microcode, and remote attestation. While not mutually exclusive, the choice between ZKP-based and TEE-based deployments reflects a tradeoff between performance and trust minimization.

Now that we have a detailed understanding of how DECO functions, it is critical to analyze performance bottlenecks and potential optimizations. Despite the elegance of the construction, DECO’s most significant cost comes during proof generation, especially for complex predicates or long transcripts. The authors of the original paper report 2.85 seconds for the three-party handshake, 2.52 seconds for query execution (2PC), 3-13 seconds for ZKP generation (depending on complexity). As discussed in the interview, DECO uses several clever tricks to keep performance practical. For example, in hash-based MPC, the system doesn’t re-evaluate entire hash chains. Instead, it computes the final compression step and verifies its correctness, saving computation while preserving security. Further improvements may come from faster proof systems (e.g., STARKs, zk-SNARKs with pre-processing), as well as hardware acceleration for the 2PC steps.

3 - Implementations and Applications of zkTLS

DECO Sandbox by Chainlink [4]

The DECO protocol provided us with a foundational architecture for zkTLS. Since then, zkTLS has quickly become a popular concept with many real world applications. At its core, zkTLS enables users to prove facts about their interactions with websites over HTTPS without revealing the full content of the interaction and without server cooperation. For developers, this unlocks a new design space of privacy-preserving authentication, decentralized identity, and verifiable web data extraction. In this section, we explore how zkTLS is currently being deployed, what the developer experience looks like, and how two of the leading providers of zkTLS, Opacity and Reclaim, differ in architecture and trust assumptions, as well as take a look at some of the user-facing applications using zkTLS under the hood.

The original architecture proposed in DECO has been licensed by Chainlink, which has since made a developer sandbox interface for the protocol [4]. This sandbox provides developers with the ability to experiment with DECO-style TLS transcript proofs and witness how multiparty computation and zero-knowledge proofs interact in the context of real HTTPS sessions. Today, a developer interested in building on top of DECO can work with lower-level cryptographic libraries and frameworks such as:

• Rust and C++ for performance-critical MPC operations

• zk-SNARK/STARK systems (like libsnark, circom, or R1CS toolchains) for proving validity over TLS data

• WebAssembly or trusted runtime containers for deployment on consumer devices or smart contract VMs

The long-term vision is to abstract away much of this complexity via SDKs that expose simple APIs like prove_from_website(url, predicate) or verify_proof(proof). While still early, progress is being made toward streamlining these interactions, particularly in industry deployments.

As for practical, commercial implementations, one prominent example is the Opacity Network [5]. Opacity represents one of the most robust and comprehensive deployments of a zkTLS architecture in the wild, as it builds upon the TLSNotary framework and significantly enhances it with a blend of cryptographic techniques [6], including garbled circuits, oblivious transfer, proof by committee, and on-chain verification and slashing mechanisms. Opacity focuses primarily on web2 account attestations, enabling users to prove ownership over accounts on platforms like LinkedIn, Twitter, or a traditional bank, and linking these to a web3 identity, such as an Ethereum wallet. The user doesn’t need the cooperation of the web2 service to do this. Instead, the Opacity network conducts a verifiable TLS session using secure MPC between the user and a notary node. The result is a signed transcript, which is then verified by smart contracts onchain. To mitigate the risk of collusion between a user and a notary, Opacity employs several layers of defense:

• Commit-and-reveal: Users must commit to the value (e.g., account balance) before a notary is assigned.

• Proof by committee: Multiple notaries independently compute identical proofs.

• On-chain logging: Every attempt to prove a value is logged publicly, discouraging manipulation.

• TEE isolation: All notaries must run within Intel SGX secure enclaves.

• Restaking and slashing: Notaries are economically incentivized to behave correctly via Eigenlayer’s AVS, which slashes misbehaving nodes in real time.

• Whistleblowing: Any user who can prove a notary misbehaved gets a share of their slashed stake.

This layered architecture makes Opacity one of the most secure zkTLS systems currently deployed. It excels in environments where users need to prove private attributes from private accounts — for example, demonstrating that they are a verified university student, without revealing their name or email.

However, Opacity's heavy reliance on TEEs introduces some caveats. While SGX helps reduce computational overhead, its side-channel vulnerability remains a known concern. Opacity mitigates this by not solely depending on SGX — instead, SGX is used in tandem with cryptographic and economic safeguards.

Reclaim, another prominent implementation of zkTLS, takes a different approach. Rather than relying on MPC between notaries and users, it leverages a proxy witness model [7]. The core idea is to insert an attestor node as a passive observer during a user’s TLS session. This attestor conducts the TLS handshake on the user’s behalf and then signs a verifiable statement about the session's content, with the result being a portable claim that can be presented to third parties.

Whereas Opacity prioritizes complex multi-party MPC and TEEs, Reclaim’s architecture emphasizes lightweight performance and fast attestations [7]. This makes it especially attractive for verifying public-facing web data (e.g., whether a page includes a particular element), Fast KYC workflows where a single attestor's word is sufficient, and applications where the attestor is semi-trusted (e.g., a government authority or major exchange). To avoid giving the attestor full access to sensitive content like session tokens, Reclaim uses a key-upgrade mechanism where:

1. The user discloses temporary TLS keys to the attestor (without revealing cookies or long-term credentials)

2. The attestor reconstructs the transcript and issues a signed claim

3. The proof is bounded to this ephemeral session and doesn’t grant replay or access

Reclaim acknowledges that collusion between user and attestor is a risk, if they cooperate, they can forge transcripts. To mitigate this, Reclaim suggests the use of subset sampling, where a random group of attestors must validate a claim. However, unlike Opacity, Reclaim does not rely on economic slashing or proof-by-committee by default.

One operational challenge for Reclaim lies in IP-based attestor identification: since servers may notice repeated connections from known attestor IPs, they could rate-limit or block these addresses. This limits the scale at which Reclaim can operate in adversarial environments.

Nonetheless, Reclaim's simplicity and ease of integration make it a compelling zkTLS solution in controlled settings, particularly when the attestor is not adversarial, for instance, a court officer validating a digital document or a bank verifying a certificate of funds.

While Opacity and Reclaim differ in architecture and trust assumptions, they both exemplify the power of zkTLS to turn private TLS sessions into verifiable public claims. Opacity favors a maximalist security model, layering cryptography, TEEs, economic incentives, and redundant computation. Reclaim emphasizes fast attestations, minimal overhead, and real-world pragmatism. Both platforms share the same philosophical foundation: to liberate user data from platform lock-in, empower self-sovereign identity, and eliminate the need for APIs and server-side cooperation.

Reclaim’s Verifiable Loyalty Platform [8]

Today, zkTLS enables a new generation of verifiable, consumer-focused applications ranging from custom-built loyalty programs, on-chain credit scores, to identity verification and automated background checks. Reclaim, for example, has created a prototype demo of how zkTLS can be used to create verifiable loyalty programs. For example, suppose Marriott wants to give a special discount voucher for Star Alliance Gold members. By using Reclaim’s loyalty toolkit [8], users can log into their airline account, and Reclaim will use zkTLS to automatically confirm their membership status, frequent flyer points, and more, and attach these attributes as credentials to the user’s Marriott account. This process thus allows Marriott to verify that users are Star Alliance Gold members and in turn give more targeted discounts.

3Jane Protocol using zkTLS for credit scores [9]

Another use case is using zkTLS to “export” traditional credit scores into the world of DeFi. By default, when a user wants to use an on-chain lending platform such as Aave or Morpho, these loans need to be over-collateralized, as there is no way of knowing ahead of time if the actual user is honest or not. 3Jane, however, creates a credit-based lending platform that pulls a user’s real-world credit score (such as a FICO score) to create undercollateralized loans based on credit, just like a traditional bank loan [9]. Under the hood, 3Jane leverages Reclaim’s zkTLS system to export credit scores, income statements, and bank assets via a Plaid authentication.

Similarly, we can use zkTLS to automate identity verification and background checks. TransCrypts, for example, uses zkTLS to automate the background check process by aggregating information from many different sources into a single platform, accelerating the hiring process without compromising user privacy. With zkTLS, TransCrypts can verify attributes like employment history, educational credentials, or legal clearances by establishing TLS sessions with official data providers (e.g., payroll services, universities, or government databases) and generating attestations without requiring direct API access or data dumps.

With its lightweight yet versatile protocol design, zkTLS can also be integrated with social media platforms. Fan Zhang’s zkLabeler tool provides a lightweight way to add custom, verifiable labels to Bluesky handles [11]. This process can power rich credentialing frameworks, connecting an ORCID ID to a decentralized social media handle, proving voting eligibility without doxxing your address, or verifying financial solvency without exposing transaction history.

Finally, zkTLS can also be used in “protected pipelines” (props) for private data for LLMs and machine learning. A privacy preserving oracle such as DECO can be used to export sensitive personal data – such as electronic health records and financial data – into private models for a more personalized experience [12]. In the “props” framework, zkTLS serves as the secure data sourcing mechanism, allowing ML training and inference pipelines to ingest sensitive deep-web datasets with both privacy and authenticity guarantees, mitigating the risks of fabricated inputs, adversarial manipulation, and direct exposure of personal information.

Conclusion

Throughout this article, we’ve presented an in-depth dive into the conceptual innovations behind zkTLS, the instantiation of the DECO protocol, as well as its wider influence on production-grade zkTLS systems and applications we see today. DECO’s architecture exemplifies a new generation of cryptographic protocols that combine usability, legacy compatibility, and privacy. Through layered security, MPC for integrity, ZKP for privacy, and optionally TEEs for performance, DECO provides a blueprint for authenticated, privacy-preserving data portability across the web.

Fundamentally, zkTLS as pioneered by the DECO protocol provides a simple, intuitive, and versatile way for “exporting” data from one website or application or another. By leveraging the in-built cryptographic security and pervasive adoption of the TLS standard, zkTLS provides a framework to free the Internet from isolated data silos and convoluted APIs, ultimately building a unified access layer for our digital data.

References

[1]

https://www.deco.works/

[2] https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/tls.html

[3] Town Crier: https://eprint.iacr.org/2016/168.pdf

[4] https://deco.chain.link/sandbox

[5]

https://www.opacity.network/

[6] Opacity Network: Trust but Verify | by Vinayak Kurup | Medium

[7] Reclaim_Whitepaper_v2-12.pdf

[8] https://reclaimprotocol.org/loyalty

[9] https://www.3jane.xyz/pdf/whitepaper.pdf

[10]

https://www.transcrypts.com/

[11] zkLabeler: https://x.com/0xFanZhang/status/1942307590899167609

[12] https://arxiv.org/pdf/2410.20522

About the Interviewees

Fan Zhang

Fan Zhang is an Assistant Professor at Yale CS and runs the Decentralized Systems Group. He is broadly interested in computer security and applied cryptography, especially problems in blockchains and smart contracts, user authentication, anonymity, and hardware-assisted trusted execution environments. Fan received his Ph.D. in Computer Science from Cornell University, advised by Prof. Ari Juels, and his bachelor’s degree from Tsinghua University. Fan is also a faculty affiliate of IC3.

Yavor Litchev

Yavor is an undergrad at Stanford pursuing a degree in computer science with a focus on cybersecurity and cryptography. He has previously engaged in research projects relating to secure machine learning and digital signatures with more flexible access structures at MIT PRIMES. More recently, he is researching secure systems and program execution using software fault isolation through the CURIS program. He is currently the cryptography research lead and Financial Officer for the Stanford Blockchain Club.

Jay Yu

Jay is a Junior Partner at Pantera focusing on investments and research, and a Research Advisor to IC3. Previously, he served as President of the Stanford Blockchain Club, and founded the Stanford Blockchain Review. He conducted research on DAOs and trusted execution environments (TEEs) with faculty from Stanford Law and IC3, and was a delegate for Uniswap DAO. Jay graduated from Stanford with a double major in Computer Science and Philosophy, and a minor in French.