Part 1: Problems and Opportunities
TLS is the protocol that enables secure data exchange between clients and servers by allowing the client to verify the authenticity of the data received from the server. However, a client cannot use the data received from a TLS connection to provide any type of guarantee to third parties. The integration of Web2 data into Web3 ecosystems has long been a challenge due to data provenance, privacy concerns, and security constraints. Providing data provenance in Web3 allows consuming Web2 data in a verifiable way, i.e., we know where data originated from and that they are authentic and have not been tampered with. Historically, decentralized applications (dApps) have relied on traditional oracles to access off-chain information. However, these solutions have primarily catered to public data, leaving private data underutilized and often inaccessible due to security risks.
zkTLS
has emerged as a cryptographic protocol designed to solve this problem, acting as a verifiable bridge between private Web2 data and the decentralized world. By leveraging zero-knowledge proofs (ZKPs), zkTLS enables users to prove claims about their private data to third parties while ensuring its authenticity and provenance, without revealing the data itself. This unlocks new potential for Web3 applications that require real-world data, such as decentralized finance (DeFi), digital identity, and privacy-preserving analytics. For example, a user could prove their bank balance meets a certain threshold without revealing the exact amount, allowing them to participate in an on-chain lending protocol. Other examples include enabling a verified proof of employment without exposing salary details, unlocking new financial services in DeFi, ensuring that medical institutions can securely attest to a patient’s health status without disclosing sensitive details, etc. Note, however, that in all these use cases, zkTLS allows to only prove a statement about the private data, and not fully harness the data itself.
Several zkTLS models exist as described in this excellent overview of zkTLS approaches; see 
for more details. We briefly outline these approaches here:
- TEE Model: This model uses trusted execution environments (TEEs) to process private data within secure hardware, introducing trust assumptions in the hardware provider.
- Proxy Model: This model relies on a trusted proxy to mediate communication and prove data authenticity. It has issues with centralization risks and potential proxy censorship.
- 2PC Model: A two-party computation (2PC) approach ensures that data remains encrypted between a prover and a single verifier. However, this setup is less practical than other approaches.
- Hybrid Model: Attempts to combine aspects of TEEs, proxies, and 2PC to balance trade-offs. However, these hybrid solutions still face practical limitations, such as high computation costs, reliance on trusted intermediaries, and inefficiencies in real-world deployments.
- Multi-Notary Model: Recently, a multi-notary zkTLS system was proposed to reduce collusion, censorship, and availability risks
.
Unfortunately, although each of these models presents promising advancements, none provides a fully decentralized and trust-minimized approach for private data computation within Web3 applications. To date, oracles have been categorized into two primary models:
- Public-to-Public Oracles: These oracles import publicly available data such as stock prices, weather forecasts, or sports results into smart contracts.
- Private-to-Public Oracles: These systems allow a statement about private data to be used on-chain while maintaining privacy. Note that zkTLS falls under this Private-to-Public Oracles category. For example, users can generate ZKPs to attest to specific data properties (e.g., proving they are over 18 without revealing their birthdate).
While both models serve essential roles, they fall short when dealing with general-purpose computations over private data. There is only so much one can achieve with public data or a simple public true/false statement about private data. A far more powerful approach would allow extracted private Web2 data to be used privately while preserving its verifiable authenticity and provenance. In other words, the current landscape lacks a robust framework for securely utilizing private data in a verifiable manner; what’s missing is a Private-to-Private Oracle for decentralized applications. To help visualize this better, we present the different types of oracles in the table below:
Filling the Gap: From zkTLS to Blind Computation with Data Provenance
A major missing piece in the puzzle is the ability to process private data in a decentralized manner while preserving verifiable authenticity and provenance. This is where Nillion’s blind computation combined with zkTLS comes in. Instead of relying on a single verifier to check a property about private data from a ZKP, we propose importing private data into blind computation that ensures data provenance and, at the same time, can use the private data for any computation. This way, we can enable private data from multiple TLS servers to be integrated together in the same blind computation. In this model:
- The data of the TLS connection is cryptographically protected and imported into blind computation, allowing any form of computation (e.g., aggregations, statistics, AI, etc.) to occur on the private data without exposing it.
- Private data from multiple TLS connections can now be combined for more elaborate applications (see example below).
Let’s dive into it! Clients often have valuable personal data scattered across different companies and organizations. They may wish to leverage this data using blind computation (e.g., MPC network, FHE, etc) to gain insight or power AI-driven applications while preserving privacy. Blind computation enables the utilization of sensitive information such as financial transactions, health records, or behavioral data while ensuring data privacy and regulatory compliance. Clients are motivated to participate for various reasons, such as earning financial incentives from AI use cases or accessing computation outcomes, such as applying for a mortgage or contributing to health research. However, ensuring data authenticity and provenance is a fundamental challenge in blind computation. While MPC and FHE protocols are designed to protect the privacy of participants’ inputs during computation, they do not inherently verify the truthfulness or origin of the data provided. This limitation can lead to scenarios where participants may intentionally misreport or falsify their data. Addressing this issue requires integrating mechanisms that ensure data authenticity, such as obtaining data directly from trusted sources that manage and maintain the data. These sources include financial institutions, streaming platforms, e-commerce websites, healthcare providers, federal agencies, and other entities that generate or hold authentic, user-specific data. However, compelling these organizations to directly contribute data to a blind computation introduces logistical and operational complexities, rendering this approach impractical. This is where zkTLS shines; it can minimize these logistical and operational problems since no changes are needed on the TLS server.
Let us take a mortgage application as an illustrative example. A client applying for a mortgage needs to demonstrate their financial health to the lending institution, which traditionally requires sharing sensitive documents such as bank statements, tax returns, credit reports, citizenship cards, and pay stubs, exposing a significant amount of personal information. To make matters worse, this process is repeated with multiple lending institutions to assess different interest rates with each institution potentially asking for more personal information. Although using blind computation between institutions (e.g., banks, tax authorities, and employers) directly to assess mortgage eligibility seems like an obvious solution, in reality, it hides many caveats. One of the biggest challenges is MPC/FHE adoption due to the technical and operational complexities, as well as substantial integration efforts, ongoing maintenance, and potential disruptions to their existing systems. In addition, the client must give their individual consent to each of these institutions to participate in the blind computation and input their data. Alternatively, the client may input their data directly to MPC/FHE servers, but as the client may have incentives to lie about their data (e.g., misreport a credit score or a bank statement), this hinders MPC/FHE adoption. These barriers make it impractical for many organizations to actively contribute data, even when such collaboration could yield valuable insights.
Enter Nillion. We propose a Private-to-Private Oracle, as shown in the image above, that allows clients to:
- import their data from multiple TLS connections into a coalition of blind computation servers,
- prove to the blind computation servers that the imported data are authentic and valid, and
- keep the data private.
- Optionally, the client can also keep the TLS server connection private from the blind computation servers and provide k-anonymity guarantees (e.g., connected to one out of k banks but not disclose which one).
In the depicted example above, the blind computation network is used to determine if the client is eligible for a mortgage by combining bank statements, credit reports, pay stubs, tax reports, citizenship cards, etc, all from different sources while keeping all the data private. Some applications may further require multiple clients (i.e., provers) to import their data into the same blind computation session, enabling computation over the joint data of multiple clients. This use case is not feasible with zkTLS alone because MPC/FHE allows for computations that yield generic outputs beyond simple True/False statements (that zkTLS is limited to). Additionally, blind computation enables combining data from multiple TLS connections within a single computation, something that’s not possible with zkTLS.
At Nillion, we are researching the foundation for the next generation of verifiable, decentralized data processing using Private-to-Private Oracles. Combining zkTLS with multiple verifiers enables a secure, private, and trustless ecosystem where private data can be seamlessly utilized in Web3 applications. At the same time, this enormous flexibility comes with performance challenges, which we’re working towards minimizing. This approach not only enhances security and privacy but also opens new possibilities for industries that require strong data integrity guarantees. Whether in finance, healthcare, or AI, blind computation with zkTLS ensures that real-world private data can be securely used in decentralized applications without compromise. Keep an eye out for our Parts 2 and 3!
References
- “Proving new worlds with zkTLS” Telah.vc, 1 Apr. 2025, https://telah.vc/zktls
- “zkTLS — The Cornerstone of Verifiable Internet” Medium, 17 Dec. 2024, https://medium.com/zkpass/zktls-the-cornerstone-of-verifiable-internet-da8609a32754
- “Multiparty Notaries for zkTLS” TACEO Blog, 6 Feb. 2025, https://blog.taceo.io/mpc-zktls/
Follow @BuildOnNillion on X/Twitter for more updates like these