Pluto brings accessible cryptography to all application developers through the use of Web Proofs.

Zero-knowledge proofs are a complicated subject. It might take a background in advanced cryptography, theoretical computer science and mathematics to learn exactly 

 these zero-knowledge proofs (’ZKPs’) work. 

But ZKPs are really just another set of tools in a developer’s toolkit. 

Developers shouldn’t need to be cryptographers to use ZKPs in their applications, 

the same way developers can use hash functions without needing to understand the constructions of those hash functions.

In this primer, we’ll help you think through ZKPs from first principles, starting from the ‘

The explanations that are commonly used to describe ZKPs — from 

prove your age to a bartender without showing ID

rather than what you might do with this stuff once you’ve got it.

As an application developer thinking about how to build the next big application, it can be easy to miss the forest for the trees. The trees are all of the cryptography jargon, the advanced mathematics, 

and the ‘how’ of constructing a ZKP. 

But the forest is the ‘why’ — why would I even want to use this stuff in the first place?

Missing the forest for the trees, lunarpunk style — DALL-E

As far as tools in a developer’s toolkit go, ZKPs are a Swiss army knife. ZKPs can be used to:

Bring offchain state transitions onchain —

 ZK rollups bundle up transactions and bring the output of those transactions onchain.


 — Developers can do arbitrary computation offchain on some data, and then bring that verifiably-computed data onchain. Essentially, the “copy, paste” action, but for computation.


Bring prior onchain history back onchain —

 Developers can grab prior blockchain history and bring it back onchain to be used in smart contracts. This is the ‘state proofs’ category of ZKPs. 


data, either bringing blockchain data from one blockchain to another, or bringing the history of a blockchain back up to the top of the chain.  But ZKPs are much more expressive than just moving and verifying data on a blockchain.  

ZKPs can also be used as one approach to prove arbitrary data from internet sources in a verifiable way. We call these ‘Web Proofs’. 

, like ‘people that live in Florida', without revealing any other personal details.

A proof that you reached a certain rating (like >4.5 stars) on a platform (like Uber or Airbnb) without disclosing the personal details of your interactions on these services.

A proof that you have some badge, item, or accomplishment in a certain online game.

A proof that you received a certain type of email from a certain sender.

A proof that you have achieved certain financial milestones, like $X in a savings account or $Y in retirement accounts.

A proof of educational achievements or certifications.

You can think about  Web Proofs  as combining a ‘Proof of Data Existence’ plus a ‘Proof of Data Integrity’, rolled up into one useful package. And the generalization of all of these examples into a single holistic description of Web Proofs:

Proofs of arbitrary data served to end users by any internet server.

Besides ZKPs, there are other approaches to Web Proofs, but those come with slightly different trust assumptions. 

Regardless of whether a ZKP is being used to create a Web Proof or not, a ZKP itself has certain guarantees.

 is created, then that proof can be verified onchain, with the chain itself acting as the autonomous verifier of the proof’s correctness, or the proof can be verified independently offchain. So a more apt general description of ZKPs is that they enable developers to (1) perform a computation, (2) credibly commit to the correctness of that computation, and (3) share a succinct proof that any party can use to verify its correctness. All of this can be accomplished while preserving the privacy of the data, which was used as input for the computation.

And this is the answer to the question of ‘why use ZKPs at all?’ — ZKPs are an incredibly expressive tool for developers. ZKPs enable verifiable movement of arbitrary data across the internet, onchain or offchain, and using these tools effectively unlocks a bunch of cool stuff that developers can build for users.

That’s what we’re all here for, right? Build cool stuff that people will use?

Yes, build cool stuff. But how is this even possible?

Well, the data that ZKPs verify — blockchain data or otherwise — is really just a 

This flips the script on our traditional notions of online interactions with other users or with the applications that we use day-to-day. The data is there, fully operational and verifiable and real, but it is shrouded from prying eyes by the ZKP, preserving privacy while ensuring data integrity.

For the purpose of an application developer, the proofs can be just as good as the underlying data. 

If your application should only grant access to those users that own a certain token… A proof that a user owns that token is just as good as checking the user’s balances yourself.

If your application needs to anonymize users for 

… A proof that a user belongs to a certain set of people, like the first 10,000 people to join Farcaster, is just as good as checking every one of the first 10,000 Farcaster joiners manually.

If your application wants to add in a reputation score based on how many positive Uber reviews a user has… A proof that a user has a high Uber rating is just as good as reading all of the user’s Uber reviews yourself.

In fact, the proofs are not ‘just as good’ as the underlying data — in many ways, having the proof is 

 than having all of the underlying data. Verifying a single proof of a user’s token balance is much more privacy-preserving than checking the user’s address yourself, and verifying a single proof of a user’s Farcaster ID is much faster and more efficient than going through all of the IDs yourself.

And verifying the proof of a user’s Uber rating onchain 

lets developers transfer trust from Uber into a smart contract

, where it can be used and accessed by other onchain applications.

That last point is an important one. While ZKPs have plenty of non-blockchain potential, bringing ZKPs of offchain data onchain represents our best chance at breaking down the Web2 data silos. 

So if you are an application developer that wants to use verifiable offchain data in your application, potentially in a privacy-preserving manner, ZKPs are the tool for you. 

We’ll walk through one in-depth example to demonstrate how ZKPs generally, and ZKPs for Web Proofs specifically, can expand the design space for onchain applications. 

Imagine an open communications protocol, where anyone can interact with the core protocol but different client implementations built on top of the protocol can choose what experience their users get. These clients differentiate themselves via their bespoke moderation of certain content, or their feature set and user experience, or really anything in-between. (This general idea might 

You are an entrepreneur building one of the clients on top of this open protocol. The appeal of your implementation over the others is that you are going to fix the onslaught of spammy posts from bots and airdrop farmers. So before users can post on your service, they will have to prove some reputation that shows that they aren’t bots or airdrop farmers. 

But you don’t want to just use ‘Sign in with Google’ — anyone can make a Google account, so bad actors will just make new accounts, and the spammy posts and phishing links will continue! No, that just won’t work. Instead, you’re going to take a scrappy approach and bootstrap reputation using other data sources. 

You’re going to ask users to show that they have achieved at least 2 (or 3, or 1, or 6 — ultimately, this is your call) of the following characteristics:

The user has received 5 positive reviews from drivers on Uber or Lyft

The user has received 3 positive reviews from hosts on Airbnb or VRBO

The user has completed a Coinbase identity verification

The user has verified their identity credentials using 

The user has sold at least $100 worth of items via a Shopify storefront

The user has an educational degree from one of the top 10,000 global universities

The user has at least 2 blog posts published on Medium or Substack before the year 2023

The user has had an active Spotify or Apple Music account for 2+ years 

Using Web Proofs, users can prove that they meet at least 2 of these characteristics. End users can prove these statements on their own devices (like their mobile phone or their personal laptops) and just show you a proof — and that’s it. They’re in. 

What did we achieve with this? Well, the burden for a bot farm or a motivated troll has just gotten a lot harder. On Twitter, we are told that the bot problem can be solved by charging us $8 a month. But as long as these bots / trolls can make more than $8 a month by scamming or phishing users, then it still makes sense for these bad actors to pay the $8 for verification! With this Web Proofs-powered reputation check, the challenge for bots and troll farms gets much much harder.

See, what we are really trying to do here is (1) make it hard for bad actors to create multiple fake accounts, (2) leverage the existing anti-sybil / anti-bot infrastructure of other companies, and (3) cover 99% of the surface area with 1% of the work. You could create a brand new identity verification product from scratch… or you could just borrow reputation from other internet sources and go back to building the application you wanted to build in the first place.

One of the most exciting applications of ZKPs is that onchain applications can get practical guarantees about the characteristics of their users without asking users to open up their entire digital history to the application. 

If you want to learn the intimate details of the ‘how’ — how to construct a ZKP from scratch — there are many great resources:

These resources can help guide you deeper down the path of the advanced cryptography and mathematics required to create ZKPs from scratch. 

But our goal at Pluto is to unlock the ‘why’ and to abstract the cryptographic complexity away for application developers. So to recap:

ZKPs can be used in many contexts, and many people are experimenting with onchain and offchain ZKP use cases. 

The ‘Web Proof Techniques’ series covers the technical implementations of various Web Proof protocols. This article focuses on TLSNotary — future articles in the series will cover Origo and TEEs.

This article is a comprehensive introduction to the 

 group with modern cryptographic components.

 are productionizing TLSN to enable smart contract developers to take advantage of any off-chain data sources in their smart contracts in a service that we are calling 

If you were to share the contents of your TLS transcript with a third party, that party would have no way to detect whether the transcript had been forged with faulty data. TLSN is a protocol for 

— data with proof of origination from some particular server.

Why would you read this article instead of the well written 

 This article aims to cover TLSN first from high level, then to give the requisite mathematical background to understand the protocol. We'll start off with a basic background of the architecture of TLSN, and provide design motivation, before opening each box and visiting cryptographic details.

We will assume a working background knowledge of the basic workings of TLS¹.

TLS (or Transport Layer Security) is a protocol for encrypting and authenticating communication between two parties: a Client (described elsewhere in this post as the Prover) and a Server. TLS Notary is a protocol that allows the Client to prove Data Provenance to a third party; in other words, TLS demonstrates that the Client honestly obtained the data from the Server, and did not interfere with the contents. 

The TLS Notary protocol aims to achieve the following properties:

 - the protocol should demonstrate that TLS transcript is not a forgery by the client

 - the protocol should authenticate the identity of the server via certificate chain verification--a valid transcript with a fake 

 - the Client should not have to sacrifice the privacy of their data or credentials to a third party

³ - The protocol should avoid enshrining a single service provider as intermediary

We'll begin with a simplified picture of TLSN, and work towards the complete architecture.

A simplified TLSN architecture with minimal cryptography

Figure 1 — a man-in-the-middle simplification of TLS Notary

In Figure 1, we introduce two new parties to the TLS Protocol: a 

, who observes and stores encrypted traffic between the Client and Server, and a 

, who is interested to verify the contents of the Client-Server transcript.

In this flow, the Proxy observes traffic between the Client and Server, and saves the encrypted TLS transcript. 

At the end of the session, the Client sends the Proxy:

 for the session, held by Client and Server

 the certificate chain, attesting to the Server's identity

 the TLS transcript with the Client's symmetric key

 the decrypted transcript, or signs the subset of the transcript that the client wants to share

The Proxy-signed TLS transcript data may then be passed to the verifier. The verifier checks the Proxy's signature, and is thereby convinced of 

Besides the sacrifice of privacy, the Proxy is an 

. The intermediary role of the Proxy bottlenecks the service, potentially limiting overall network traffic. Finally, a compromised Proxy may collude with a client to deceive the verifier. 

In the following sections, we will discuss how the TLS Notary architecture resolves these issues. First, a brief interlude to introduce the active cryptographic component in TLSN, multi-party computation.

 is the cryptographic problem of how to compute a function 

, each with knowledge of their corresponding private input to the function. Parties are interested in the output 

, but would also like to avoid leaking information about their secret data.

, where each party obtains some "share" of a secret shared by everyone; e.g. additive shares 

, where parties hold the shares, but neither party knows the value of 

, in some way the preserves the mathematical structure of the following step

if the output is not already in plaintext (i.e. if homorphic encryption is employed), a final 

 step may be required to obtain the result

In the context of TLSN, MPC is applied to constrain the Client's ability to exchange messages with the server. A secondary party, termed the Notary, performs MPC with the Client to 

 messages. Because of the privacy preserving nature of MPC, the Notary prevents the Client from forging messages, without ever observing the messages the client sends.

In a few sections, we'll put our cryptography hats on to discuss the mathematics of Garbled Circuits MPC, but first we'll update our simplified architecture model of TLS Notary, employing MPC.

In the updated architecture picture, we replace the Proxy server with a MPC partner for the client, who shall be called the Notary. The Notary performs MPC with the Client to perform TLS protocols, including key exchange, encryption, authentication, and decryption. However, via MPC, the Notary 

 of the Client's transcript, thereby preserving Client privacy.

Recall from prior discussion that the TLS Notary protocol aims to achieve:

 - The protocol should avoid enshrining a single service provider as intermediary

We've already discussed how client privacy is obtained. The protocol may be rendered 

 by allowing the Verifier to accept transcripts produced with other Notaries than the Pluto Notary. We are also investigating the security-performance trade-off of further decentralizing the Notary, from 2-party Client-Notary computation to 3-or-more-party Notary computation.

 of the Server's identity is obtained identically to our simplified protocol: by verification of the Certificate chain providing the Server's public key.

 is obtained by a cryptographic technique called 

. Blind signatures allow the Notary to sign commitments to the Client's messages. This prevents the client from later forging the content of their message, while the Notary never observes message plaintexts.

Blind signatures are also constructed over commitments to the Server's identification; that is, the Notary also never directly observes the identity of the Server.

We close our high level discussion of the TLS Notary Protocol with a mini-spec of the TLS Notary protocol, that we will expand on in greater depth in the next post.

Preprocessing step: Client and Notary perform Oblivious Transfer pre-processing, to allow for faster online proof computation.

Prior to Key Generation: Client obtains Server's public key and certificate chain, proving Server public key authenticity.

Key Generation: Client and Notary generate ephemeral key shares of the TLS shared secret (premaster key), for encryption and authentication with the server

Encryption and Authentication: Client wants to send a message to the server. Client and Notary use 2-party computation to encrypt and authenticate the message. Notary blind-signs the message, and client sends the encrypted message to the server.

Client and Notary use 2-party computation again to decrypt and authenticate the Server's message. These two steps repeat until the client's session is complete.

Proof generation: At the end of the protocol, the Client possesses a certificate chain of the server's identity, and the TLS transcript with signatures from the Notary. A proof may be generated to verify succinctly correctness of the signatures and certificate chain.

We may discuss selective disclosure in a further post.

In this post, we gave a high-level description of TLS Notary, starting with a simplified architecture and progressing through towards an overview of the TLS Notary protocol that includes multi-party computation.  

In a follow-on post, we will examine the protocol from a mathematical lens. If you’re interested in working on TLS Notary, 

¹We may write a primer on TLS in the future, but have not yet.
²The term 

, used elsewhere, refers to the combination what we term Authenticity and Provenance.
³Non-Proprietary gets at the point that the service provider should be replaceable; but the term Non-Proprietary is slightly misleading. I came up with these terms on the fly, don't read them as gospel.

Pluto is on a mission to solve the challenges of today’s blockchain applications using applied cryptography. Our master plan is to unlock affordable, spam-free, fraud-free, and private-from-your-peers financial and identity rails for the world.

Concretely, this mission means that we are building low cost, easily programmable proofs of data provenance. These proofs are key to solving broader problems, such as sybil attacks, spam, data privacy and more. Extending this technology, we are building infrastructure for cheaply contextualizing transactions with real world data.

Today, we are announcing our first step down that path: Web Proofs.

Web Proofs demonstrate authenticity of, and access to external data sources, like data from Uber, Shopify, your banking provider, an e-mail client, or any other internet server. This gives blockchain developers access to internet data in their on-chain applications. It is a new primitive enabled by powerful cryptography including Multi-Party Computation (MPC) and Zero Knowledge Proofs (ZKPs). Web Proofs unlock the internet for blockchain developers.

Web Proofs could be used to prove that a company achieved sustainability metrics by buying climate credits, that a contribution was made to an open source repository on Github, or even that the Taylor Swift concert ticket you bought didn’t come from a scalper. In each case, a user will be able to use our Web Proof service to create a proof of the data, which is then verifiable onchain, or even by other web applications. 

Read more about how Web Proofs work in our series on how Web Proofs work — 

Our Web Proof launch consists of three main components: The web & mobile SDK, the Pluto hosted proof generation infrastructure, and the onchain verifier. Our SDKs allow developers to easily integrate Web Proofs into your application front end, and to simply integrate onchain Web Proof verification. 

At launch, a handful of Web Proof types will be accessible. Developers will be able to incorporate proofs of Venmo Transactions, Reddit posting history, and Amazon purchase history. If you have a request for specific data, please reach out to us. Over time, we will add more flexible and generic tools for Web Proof generation, supporting an ever widening range of developer needs.

Our SDK and Testnet verifiers will launch in the coming months. Until then, developers can: 

Try the demo to see how the Web Proofs work

Sign up to be an early user of Web Proofs via our ➡️ 

. We are offering product and design support to our earliest partners

Read our blog and our documentation to further dive into Web Proofs and the technologies that come soon after

Pluto is built by a small team of experienced product, engineering, and operating leaders from places like Stripe, Y Combinator-funded startups, Uber, Aztec, and Hubspot. We’ve built tools in crypto for the last several years, and deeply understand the challenges developers face when dealing with advanced cryptography due to the state of available tools today.

We’re building a company that will lead the way in solving these problems for the next generation of useful blockchain applications. What we uniquely bring to this challenge is our expertise in existing financial and technology systems, as well as expertise in the cryptographic tools of this new financial system.

We’re backed by some of the most thoughtful, experienced investors in crypto: Geometry, Variant, Nascent, and Figment Capital, and pioneering angel investors.

Our passion to solve these problems stems from our shared experiences in building the internet as it currently exists. We have played a role in building the current system, and we desire for better.

We live in the information age. Information is power. Power is preserved through surveillance. Applications in the information age are driven by network effects to centralize power, disincentivizing application interoperability, while surveilling application users to monetize attention to the greatest possible extent. 

We envision an interoperable and private internet, where data is not siloed into surveilled walled gardens, but instead may be controlled by user intent. A world where trust is not gated by the reputability of a few corporations, but can be attained by any person with a cryptographic proof of the authenticity of their data. 

Compounding these challenges is the advent of AI. AI is a powerful tool, but it can also be a tool for accelerating the rate at which information centralizes, generating unlimited synthetic data. We need tools for proving the authenticity of data, preserving 

Cryptography gives the world the capacity to distribute power equitably, rather than centralizing trust in the hands of a few. With advanced cryptography, we can tear down data moats, disrupt the attention economy, derail centralization, and defend ourselves against surveillance. 

However, today’s usage of cryptography in blockchains is limited and full of challenges. We’ve seen these challenges play out in the last several years — poor usability, spam, scams, fraud, a lack of privacy, and exploits. For the blockchain industry to have any hope of fixing the things that are broken with the internet, we 

We are the every-developer. We are building cryptographic tools to place in the hands of developers, so that we may together construct the technology to build a better internet. 

Pluto builds tools to supercharge blockchain applications with the power of internet data

Web Proofs let developers bring web2 data onchain

Our Web Proofs SDK and Testnet will launch in the coming months

To get notified of Pluto’s launch, sign up 

 is a Rust implementation of a collection of cryptographic primitives inspired by 

. This is technical content aimed at demonstrating theoretical properties of applied cryptography alongside a concrete application in a programming language well-suited for cryptography.

 is constructed from first principles so there is no assumed knowledge of external libraries or verbose dependancies (other than 

). Much of the code here is not optimized in efforts of mathematical transparency and simplicity. 

This work serves as a toy implementation of cryptographic primitives to help cultivate an understanding of the implementation details — therefore, much of the code is not optimized, not secure, and is not intended for commercial use. We started with implementing primitives to build KZG proofs and then kept building additional primitives from there. An outline of this content is presented below. 

Finite Fields are a core primitive used extensively in cryptography. This library has a Finite Field module. We use this to define a field of prime order 

, which we use as our base field in our KZG construction. Note that this prime came from 

100 \equiv -1, 50 \equiv  -\frac{1}{2}, 20 \equiv  -\frac{1}{5} 

The first curve group is defined over our base field. The library also supports the field extension 

 (we will explain this rationale later in the elliptic curve section) for our KZG construction. It’s common to denote the curve group over the field extension as 

. In order to build the extensions in general, we needed a polynomial module.

Polynomials are a ubiquitous construction with many applications. We use our polynomial module for our extension fields, Reed-Solomon encodings, and polynomial commitment schemes. A polynomial commitment scheme is another core cryptographic primitive that allows a prover to commit to a polynomial in a way that its evaluations at any point can be efficiently verified by others, ensuring the polynomial’s integrity. This is used later in our KZG polynomial commitment scheme.

Elliptic curves are beautiful primitives used both in asymmetric cryptography as well as zero-knowledge proofs. In asymmetric cryptography, elliptic curves provide a high level of security with relatively small key sizes, making them more efficient and faster than traditional methods like 

. We also use elliptic curves in pairing-based cryptography with KZG proofs. We support a handmade curve library with elliptic curve point addition over a finite field. We use a pairing-friendly curve in our KZG commitments of the form 

. We say the number of points in the largest elliptic curve group is the 

For our KZG construction the base field is 

, and the scalar order of our curve group is 

a point in our first cyclic curve subgroup 

and maps them to a third group such that a pairing:

 are both of the of same order (e.g., they have the same scalar field which implies they are isomorphic). The pairing is a map between these different subgroups. If this is not immediately clear, that is okay — give it some time. We will go into more details. 

Now that we have a rough idea of the abstract structure of a pairing, let’s look into how to construct  

To construct pairing friendly curves, we start by finding the first curve group’s scalar field. The scalar field of a curve is the curve order, or the amount of points in the cyclic group generated by our generator. For our curve group 

. Now that we have the curve scalar field we can find the curves 

The embedding degree is defined as the smallest number 

 such that our curve order (size of scalar field) 

, so the embedding degree of our first curve group is 

 with this new embedding degree and our second curve group over this extension field. All of the elliptic curve points of order 17 can be found using coordinates from 

. We have documented the pairing in detail in the 

In KZG, we need a trusted setup in the form of a 

. We generate an SRS from the generators of our two isomorphic curve groups 

. The SRS is a list of points on our two curves. The number of points in the SRS from 

 is  greater than or equal to the number of constraints we want to prove (degree of the polynomial we are proving), and the number of elements in the SRS from the second curve group 

 is greater than or equal to the degree of our masking divisor polynomial. We then pick a random number in our curve scaler field 

 is both the number of gates and number of coefficients in our polynomial. Once we have the SRS, we can make commitments that are both binding and hiding for our polynomials assuming the setup was created properly. We first commit to our polynomial that we want to prove by multiplying the coefficients of our polynomial with the points in our SRS and then adding them together to get a single point in our first curve group. 

 coefficient of the polynomial. We then pick a value to evaluate our polynomial at 

 with and the result of the evaluation of this polynomial 

. Note that our polynomial has the same order of our curve 

. We then commit to the evaluation and call the the result 

The pairing check then takes these inputs and checks these two pairings are equal while utilizing the bilinear properties of the pairing to achieve multiplication, while preserving hiding properties.