TLShare: Private Authenticated MPC and FHE Inputs Over TLS

Part 6: TLShare Applications

This is the final blog post in our TLShare series. The previous blogs are: *part 1, [part 2](https://medium.com/@jimouris/evolving-zktls-privacy-preserving-computation-from-decentralized-oracles-1aa29bf51c5d), [part 3](https://medium.com/@jimouris/evolving-zktls-privacy-preserving-computation-from-decentralized-oracles-3dae623ea166), [part 4](https://medium.com/@jimouris/tlshare-private-authenticated-mpc-and-fhe-inputs-over-tls-17dc71c33011), and [part 5](https://medium.com/@jimouris/tlshare-private-authenticated-mpc-and-fhe-inputs-over-tls-96e426968cd9).*

Today, we’re focusing on the unique applications that TLShare unlocks.

Clients often have valuable personal data scattered across different companies and organizations. They may wish to leverage this private data to gain personal insights or even be compensated for submitting their data to train AI models. Private computation enables the utilization of sensitive information such as financial transactions, health records, or behavioral data while ensuring data privacy and regulatory compliance. However, ensuring data authenticity and provenance is a fundamental challenge in private computation. While multiparty computation (MPC) and fully homomorphic encryption (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. 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 private computation introduces logistical and operational complexities, rendering this approach impractical.

This is where zkTLS shines; it minimizes these logistical and operational problems since no changes are needed on TLS servers (i.e., organizations and institutions).

Applications of TLShare

We introduce three categories of applications:

1. Single Client, Multiple Sources,
2. Multiple Clients, Single Source,
3. Multiple Clients, Multiple Sources,

and describe them along with motivating applications below.

1. Single Client, Multiple Sources

Let us take a mortgage application as an illustrative example of the Single Client, Multiple Sources class. A client applying for a mortgage needs to demonstrate their financial health to a 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. This process is repeated with multiple lending institutions to assess different interest rates, with each institution potentially asking for more personal information.

Although using private 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 the 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 private computation and input their data. Of course, as we mentioned in the beginning, the client cannot just “input their data” directly to MPC/FHE servers, as they may have incentives to lie about their data (e.g., misreport a credit score or a bank statement).

Single Client, Multiple Sources: TLShare for financial applications.

As demonstrated in the figure above, with TLShare, clients can verifiably import their data from multiple TLS connections into a coalition of private computation servers, prove to the private computation servers that the imported data is authentic and valid, and keep the data private. After the verification is successful, it is business as usual. The private computation servers can run any computation (e.g., machine learning inference) over the private data and assess the financial health and mortgage eligibility of the client. Finally, they can share the result with lenders and financial institutions, which can then issue mortgages without having seen the clients’ private data.

2. Multiple Clients, Single Source

Next, let’s focus on a trading application (tickr.app) as an example of the Multiple Clients, Single Source class. Traders who want to build an audience and monetize their insights face a core verification problem¹ with centralized exchanges (CEXs), like Binance. Traders might be highly profitable, but they have no reliable way to prove it. There is no on-chain footprint to audit, and most followers are understandably skeptical. As a result, CEX traders often struggle to build trust with their communities or monetize their alpha.

Tickr is a platform where creators prove and monetize their edge, and followers make informed moves based on real performance. The “Tickr Leaderboard” is a public, provable record of trading performance. Creators are ranked by real performance, setting a new standard for trust in trading, and each trader can get compensated for their alpha:

Screenshot from creators’ page in the tickr.app platform.

Although you have probably connected the dots already, platforms like Tickr are a prominent application of TLShare and, in general, what we call blind provable interfaces (BPI).²

Multiple Clients, Single Source: TLShare for centralized exchange.

As demonstrated in the figure above, multiple clients connect to a single source (e.g., Binance) using TLShare and import their data to a private computation cluster for further computation (e.g., secure aggregation, statistics).

3. Multiple Clients, Multiple Sources

Last but not least, the most elaborate applications of TLShare rely on multiple clients and multiple sources, where multiple users contribute data from different sources into a joint secure computation. Our motivating application for this scenario is the Boston Women’s Workforce Council (BWWC) study that measured wage gaps across demographic groups (e.g., race and gender, or inequality of opportunity for women and minority-owned small businesses).

The BWWC study measured wage disparities across demographic groups (including race, gender, and level of seniority) within a metropolitan region. This study is accomplished by executing aggregation workflows on input data (provided directly by a large number of individual employer organizations) that contains wage information broken down by demographic attributes; the aggregated output is then disclosed in public reports. This type of study requires input from various entities: local employers, government tax records, payroll providers, and survey data from individuals. Traditional approaches, such as centralized collection of the plaintext input data by a trusted third party, are not acceptable to data contributors due to the inherent risks (to both employees and employers) of data exposure. Employing MPC to minimize data exposure risks is viable but involves manual data entry that may introduce errors without careful interface design and costly user training, and does not inherently provide any mechanism for verifying the accuracy of the data. These drawbacks can limit the scale of such studies and invite skepticism about data accuracy.

Multiple Clients, Multiple Sources: TLShare for large-scale verifiable analytics.

TLShare mitigates these drawbacks by leveraging multiple clients, each independently collecting authenticated data in an automated and scalable manner from authoritative TLS endpoints (e.g., payroll APIs, employer HR systems, municipal databases, and so on). Finally, the sensitive data (e.g., reported compensation amounts, employment statuses, and demographic attributes) is verifiably imported into a downstream secure computation. The downstream analysis can compute statistics (e.g., histograms of compensation ranges broken down by demographic attributes or wage ratios between demographic groups), perform regressions, or even train federated models, all without revealing any party’s individual records.

Dimitris Mouris, Manuel Santos, Miguel de Vega, Andrei Lapets Nillion

Xiang Xie Primus Labs

PS: We’d love to hear your thoughts on other applications that TLShare unlocks!

References

[1] Santos, M. B., Mouris, D., Xie, X., de Vega, M., & Lapets, A. (2025). TLShare: Private Authenticated MPC and FHE Inputs Over TLS. Cryptology ePrint Archive. https://eprint.iacr.org/2025/1434

[2] Tickr: Building Trust in Trading Performance, https://x.com/buildonnillion/status/1953443020860223806, tickr.app.

[3] From APIs to BPIs: Min-maxing the use of Sensitive Data, https://x.com/buildonnillion/status/1956346452210299020