Today the world has become heavily digital-first even as AI and AI-adjacent integrations impact all our interactions and experiences. Privacy and security concerns have become more pressing now than ever before. Among the emerging technologies that address and try to deal with all this, Zero-Knowledge Transport Layer Security or zkTLS has caught the attention. Let’s take a deep dive. What is zkTLS? As the name suggests this is a hybrid protocol combining two components: zk: Refers to one of the most popular and highly effective privacy-preserving technique in use in blockchain technology — zero-knowledge proofs (ZKPs). It is a cryptographic method involving two parties, where the prover convinces the verifier that a piece of information is known without having to reveal it. TLS: Refers to a critical part of HTTPS (Hypertext Transfer Protocol Secure) providing encryption and authentication mechanisms to secure data transmission between client and server. Fun fact: Not all implementations of TLS attestations use ZKPs as focus is on verifiability rather than mere privacy, but still the name zkTLS has etched its name as one of crypto’s newest privacy primitives. Bottomline: In tandem with confidential computing, zkTLS enables data provenance and encryption, even tapping into previously unusable data. Oasis, with a focused privacy-first approach and production-ready confidential EVM, Sapphire, has been working with leading zkTLS projects, including PoCs, e.g. onboarding Reclaim Protocol with its ecosystem. How zkTLS works? In simple terms, it allows a user or a server to demonstrate that data fetched via a TLS-secured connection, like an API call to a bank’s server, is authentic, and no extra information is exposed in the process. So, zkTLS will generate a proof like zk-SNARK confirming that data was fetched from a specific server (identified by its public key and domain) via a legitimate TLS session, without exposing the session key or plaintext data. The process flow is something like this: The client and the server connect over TLS (“TLS handshake”), establishing a secure session with encryption and server authentication. zkTLS captures session details (e.g., encrypted data and server certificate) and processes them in a zk-SNARK circuit tailored to TLS constraints. The circuit output will produce the proof verifying the data’s authenticity and source, keeping sensitive details hidden. This proof is recorded on a blockchain for decentralized verification. Let’s now take a quick look at the models. MPC-based Here, zkTLS modifies the standard TLS handshake by introducing a network of nodes that collaborate to produce a multi-party key replacing the browser-generated key. With browser consulting these nodes to generate a shared key through an MPC protocol, it is ensured no single party knows the entire key. The shared key is used for encrypting and decrypting requests and responses as the browser and all nodes cooperate on every instances of operation. This model enhances security but the the trade-off is networking complexity and overhead due to persistent node coordination. TEE-based Here, zkTLS leverages Trusted Execution Environments — tamper-proof secure enclaves within CPUs that act like a black box and can securely handle HTTPS requests. All sensitive data such as authentication tokens are encrypted and sent to the service provider’s TEE, where decryption happens internally without any exposure to the provider or external systems. The TEE logs in on behalf of the user and securely processes the response, providing cryptographic guarantees about the integrity of the request and response. This model is very efficient but the trade-off is dependency on TEE hardware and trust reliance on manufacturer security, e.g. Intel SGX or TDX. Proxy-based Here, zkTLS uses HTTPS proxies as intermediaries which forward encrypted traffic between the browser and the website, and then observe the data exchange. It is the proxy that provides attestations about the encrypted requests and responses, confirming they originated from the browser or the website. Finally, the browser generates a ZKP allowing decryption of the received data, and since the shared key is not revealed, privacy is ensured. This model eliminates the trade-offs of the other two models but has its own challenge — having to trust that the proxy is not malicious. Key takeaways of zkTLS zkTLS is a game-changer for web3 and its implications are best understood when we understand the two-pronged problem is solves. For a web2 user, HTTPS means there is end-to-end encryption. However, this isn’t provable. Also, TLS itself is unverifiable. And, no privacy is guaranteed. zkTLS brings verifiability to the table as the proof it generates validates the data or its origin and verifies the transfer. Another benefit of this technology is data privacy. To those who are thinking this is just like pulling API data and putting it on-chain, the distinction is tangible. APIs can be easily disabled, but with an ongoing HTTPS connection, zkTLS ensures continuous data access. Simply stated, this enables any web2 data to be used on a blockchain in a verifiable and permissionless way. Key use cases of zkTLS in crypto DeFi Lending Real world example: 3Jane Identity Verification Real world example: Nosh Privacy-Preserving Oracles Real world example: TLS Notary Verifiable Airdrops Real world example: ZKON Final word on zkTLS is that its design space is vast and full of potential as it evolves by solving current challenges like scalability, compatibility with varied web systems, and dependence on existing oracle networks. But the promise is real as indicated by the various real world examples, already in production with many more being explored. And the result we have been seeing and, as the space grows and evolves, look forward to gives hope that web2 — web3 interactions between the internet and the blockchain would also drive mass adoption. Resources: Oasis blog Reclaim blog Oasis x Reclaim Originally published at https://dev.to on September 23, 2025. Exploring zkTLS As A Way To Build A Verifiable and Private Web3 was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this storyToday the world has become heavily digital-first even as AI and AI-adjacent integrations impact all our interactions and experiences. Privacy and security concerns have become more pressing now than ever before. Among the emerging technologies that address and try to deal with all this, Zero-Knowledge Transport Layer Security or zkTLS has caught the attention. Let’s take a deep dive. What is zkTLS? As the name suggests this is a hybrid protocol combining two components: zk: Refers to one of the most popular and highly effective privacy-preserving technique in use in blockchain technology — zero-knowledge proofs (ZKPs). It is a cryptographic method involving two parties, where the prover convinces the verifier that a piece of information is known without having to reveal it. TLS: Refers to a critical part of HTTPS (Hypertext Transfer Protocol Secure) providing encryption and authentication mechanisms to secure data transmission between client and server. Fun fact: Not all implementations of TLS attestations use ZKPs as focus is on verifiability rather than mere privacy, but still the name zkTLS has etched its name as one of crypto’s newest privacy primitives. Bottomline: In tandem with confidential computing, zkTLS enables data provenance and encryption, even tapping into previously unusable data. Oasis, with a focused privacy-first approach and production-ready confidential EVM, Sapphire, has been working with leading zkTLS projects, including PoCs, e.g. onboarding Reclaim Protocol with its ecosystem. How zkTLS works? In simple terms, it allows a user or a server to demonstrate that data fetched via a TLS-secured connection, like an API call to a bank’s server, is authentic, and no extra information is exposed in the process. So, zkTLS will generate a proof like zk-SNARK confirming that data was fetched from a specific server (identified by its public key and domain) via a legitimate TLS session, without exposing the session key or plaintext data. The process flow is something like this: The client and the server connect over TLS (“TLS handshake”), establishing a secure session with encryption and server authentication. zkTLS captures session details (e.g., encrypted data and server certificate) and processes them in a zk-SNARK circuit tailored to TLS constraints. The circuit output will produce the proof verifying the data’s authenticity and source, keeping sensitive details hidden. This proof is recorded on a blockchain for decentralized verification. Let’s now take a quick look at the models. MPC-based Here, zkTLS modifies the standard TLS handshake by introducing a network of nodes that collaborate to produce a multi-party key replacing the browser-generated key. With browser consulting these nodes to generate a shared key through an MPC protocol, it is ensured no single party knows the entire key. The shared key is used for encrypting and decrypting requests and responses as the browser and all nodes cooperate on every instances of operation. This model enhances security but the the trade-off is networking complexity and overhead due to persistent node coordination. TEE-based Here, zkTLS leverages Trusted Execution Environments — tamper-proof secure enclaves within CPUs that act like a black box and can securely handle HTTPS requests. All sensitive data such as authentication tokens are encrypted and sent to the service provider’s TEE, where decryption happens internally without any exposure to the provider or external systems. The TEE logs in on behalf of the user and securely processes the response, providing cryptographic guarantees about the integrity of the request and response. This model is very efficient but the trade-off is dependency on TEE hardware and trust reliance on manufacturer security, e.g. Intel SGX or TDX. Proxy-based Here, zkTLS uses HTTPS proxies as intermediaries which forward encrypted traffic between the browser and the website, and then observe the data exchange. It is the proxy that provides attestations about the encrypted requests and responses, confirming they originated from the browser or the website. Finally, the browser generates a ZKP allowing decryption of the received data, and since the shared key is not revealed, privacy is ensured. This model eliminates the trade-offs of the other two models but has its own challenge — having to trust that the proxy is not malicious. Key takeaways of zkTLS zkTLS is a game-changer for web3 and its implications are best understood when we understand the two-pronged problem is solves. For a web2 user, HTTPS means there is end-to-end encryption. However, this isn’t provable. Also, TLS itself is unverifiable. And, no privacy is guaranteed. zkTLS brings verifiability to the table as the proof it generates validates the data or its origin and verifies the transfer. Another benefit of this technology is data privacy. To those who are thinking this is just like pulling API data and putting it on-chain, the distinction is tangible. APIs can be easily disabled, but with an ongoing HTTPS connection, zkTLS ensures continuous data access. Simply stated, this enables any web2 data to be used on a blockchain in a verifiable and permissionless way. Key use cases of zkTLS in crypto DeFi Lending Real world example: 3Jane Identity Verification Real world example: Nosh Privacy-Preserving Oracles Real world example: TLS Notary Verifiable Airdrops Real world example: ZKON Final word on zkTLS is that its design space is vast and full of potential as it evolves by solving current challenges like scalability, compatibility with varied web systems, and dependence on existing oracle networks. But the promise is real as indicated by the various real world examples, already in production with many more being explored. And the result we have been seeing and, as the space grows and evolves, look forward to gives hope that web2 — web3 interactions between the internet and the blockchain would also drive mass adoption. Resources: Oasis blog Reclaim blog Oasis x Reclaim Originally published at https://dev.to on September 23, 2025. Exploring zkTLS As A Way To Build A Verifiable and Private Web3 was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story