Have you noticed more calls and messages from unknown senders—someone “just trying to help”? Often it’s a scammer or an ad-bot that sounds just like a human. We’re at the beginning of a reality where what you see or hear online may not be real. Are we prepared?

Early systems like CAPTCHA¹ (Eurocrypt ’03) were built on a simple idea: give the user a task that’s easy for humans but hard for machines. For a while they worked. Today they’re essentially broken. LLMs and other ML tools can defeat CAPTCHAs at scale—for example, Akirabot², an OpenAI-based tool, was used to hit 420,000 sites with spam by bypassing CAPTCHAs. We can no longer rely on humans being “smarter” than bots.

And personhood isn’t only “am I human?” Online we also need relationship-backed trust, reputation, membership in a community, or context-specific endorsements—age verification, attestations, “who vouches for you”—and all of that should preserve privacy. Yet many current approaches are ad-hoc and privacy-hostile. Mobile driver’s licenses (mDLs) can let the verifier query the DMV on every check, so the DMV can see and record every verification. Discord had over 70,000 government IDs stolen, then required government ID for “adult” content. Worldcoin’s global biometric system has been called a “privacy nightmare” and has faced shutdowns or strict limits in Spain, Bavaria, Hong Kong, and Kenya. So: how do we prove personhood without handing over the keys?

In this blog we explain our recent work³: we show how to construct proofs of personhood so that humans can prove their reputation and credentials online in a privacy-preserving way. The design is decentralized—no reliance on centralized parties for setup—and we use zero-knowledge (ZK) proofs so people can prove what they need without leaking the rest. This work contributes to the vision of the First Person Network⁴: a global infrastructure for real people and real trust, with no intermediaries. Below we walk through a typical protocol with a running example and highlight the key ideas and security requirements at each stage. No prior work considers the goal of constructing efficient zk proofs for this setting.

Stage I: Getting a Personhood Credential

Someone has to vouch that you’re a real person before you can vouch for others. We call these vouchers issuers: organizations everyone can look up and trust. They might be your local DMV, a passport office, or even a loyalty program. In practice, many personhood systems use government-issued IDs (passports, mobile driver’s licenses) as the “one person, one credential” anchor—and our protocol supports that.

Alex is a ride-share driver. Alex goes to a government authority (say, the DMV or a passport office) and gets a personhood credential (PHC) that attests to some facts about him—for example:

att = {
  Name = Alex
  Occupation = Driver
  License type = Commercial
  Date of birth = 1990-05-15
}

The authority has a public key that anyone can check. Alex provides his own public key and these attributes, proves he owns the provided key, and goes through the issuance flow. At the end, he holds a credential that he can verify himself using the authority’s public key. No one can fake that credential—that’s our first guarantee:

But wait—privacy. If Alex used the same public key with every issuer, then different issuers could link his requests together and learn more about him than he intended. We don’t want that. So we require:

The fix: Alex derives a different-looking public key for each issuer from his secret key and that issuer’s public key—so each key looks unrelated to the others. To each issuer he only shows this derived key; they can’t tell it’s the same person going to another issuer. He proves in zero knowledge that the derived key was computed correctly, without revealing his master secret.

A quick note on trust. How does the issuer know Alex’s details are real? In the real world, that’s the issuer’s job (e.g. the DMV checks your documents). For added robustness, we allow for the fact that issuers can sometimes be fooled: we attach a confidence parameter to each issuer. When someone later checks a credential, they can weigh who issued it. The protocol still keeps privacy and security even when we don’t assume every issuer is perfect.

Stage II: Vouching for Others (Verifiable Relationship Credentials)

Once you have a personhood credential, you can vouch for someone else in a way that others can check. We call these verifiable relationship credentials (VRCs). Think of them as signed, checkable endorsements. We refer to these VRC issuers as vouchers, to distinguish them from issuers, who only issue PHCs.

Back to our example. Carol is a passenger who just had a great ride with Alex. She has her own personhood credential (from the government or another issuer). She wants to endorse Alex by saying:

st = "Is a good driver."

She doesn’t want every endorsement to be linkable to the same “Carol.” So she uses a context-specific key for the ride-share setting. In fact, even issuers cannot link a PHC issuance with an endorsement. Different contexts (ride-share, work, social) get different keys, so no one can tie all her vouchers together.

Alex has the same kind of privacy need: he doesn’t want every passenger who vouches for him to see that he’s the same driver across all of them. So he uses a fresh receiver key for this interaction, derived from Carol’s context key. Different passengers see different keys; they can’t link Alex across his VRCs.

Carol only reveals what she chooses—for example, just her name—and the rest of her attributes stay hidden. She uses her credential to create a VRC bound to Alex’s receiver key and the statement “Is a good driver.” Anyone can check that the VRC is valid and that the keys were derived correctly (via zero-knowledge proofs), without learning Carol’s or Alex’s secrets. One more guarantee:

Stage III: Proving Your Reputation (Without Revealing Everything)

Alex has collected several “good driver” endorsements from passengers. Now he wants to prove to someone—the ride-share platform, or a new passenger—that he has that reputation, without handing over every VRC he’s ever received. That would be slow and would leak more than needed. Instead, he produces a zero-knowledge proof: one short proof that backs up his claim.

The proof shows, in zero knowledge, that: (1) he holds three valid VRCs, (2) each says “Is a good driver,” (3) they come from three different vouchers (so not one person vouching three times), (4) each VRC was issued by a voucher with a valid PHC from a trusted issuer (or approved issuer set), and (5) all of the VRCs were issued to the same receiver, namely Alex, without revealing his secret key. He sends this proof plus the identities of the issuers (so the verifier can decide how much to trust them). The verifier checks the proof and can accept or reject the claim.

Privacy in this step: The verifier only learns the claim (“three passengers said I’m a good driver”) and whatever issuer info is needed to calibrate trust. They do not learn Alex’s full set of VRCs, his keys, or any attributes he didn’t choose to reveal.

Wrapping Up

This post conveys the flow and the guarantees of our system without the full formal machinery. We refer the reader to our paper³ for the full definitions, constructions, and experiments.

In our paper we present an early prototype showing that zero-knowledge proofs for this setting can be practical. We leave further efficiency improvements for future work. Additionally, going forward, we aim to add support for legacy credentials in our system. We also want to support proving membership in a community where trust is defined by being directly connected to a trust anchor or to a sufficient number of other members in the community.

References

As threshold encryption moves from theory into production—especially in systems like blockchains—two practical bottlenecks quickly become dominant:

1. Setup friction (DKG “setup tax”).
   Traditionally, without assuming a trusted dealer, threshold encryption relies on a distributed key generation (DKG) protocol. A global secret key is generated jointly by the quorum, and each user learns a share. DKG works, but it comes with significant engineering and security headaches: multiple interactive rounds, complex failure modes, attribution of misbehavior, and challenges with churn and asynchrony. Just as importantly, DKG tends to lock in the quorum and threshold, making membership effectively static. In settings where the quorum should evolve dynamically, re-running DKG on every membership change becomes a recurring operational cost—the “setup tax” that makes threshold encryption hard to deploy at scale.

2. Decryption scalability.
   Standard threshold decryption requires per-ciphertext collaboration: each committee member locally computes a partial decryption, and any $t$ partial decryptions can be combined to recover the plaintext. This is perfectly fine for a small number of ciphertexts, but it becomes a scaling bottleneck when the system needs to decrypt many ciphertexts, such as in blockchain mempool privacy where large batches of encrypted transactions may need to be opened together.

Based on a novel approach using witness encryption¹, ², our team has been working on a new vision for threshold encryption that removes the setup tax and makes decryption scalable when many ciphertexts are involved. Two lines of work capture this direction: silent setup and batched threshold encryption.

Silent Setup

Silent setup, introduced in our Crypto 2024 work³, replaces interactive setup with a non-interactive procedure.

Instead of running a DKG, each user locally generates a public/secret key pair $(\mathsf{pk},\mathsf{sk})$ and publishes $\mathsf{pk}$. That is the entire setup. While each user’s published public-key material grows with the maximum number of users supported, this cost is incurred only once.

This unlocks a much more flexible deployment model: a sender can choose the quorum and threshold on the fly, and derive an encryption key for that chosen quorum using only the published public keys of its members. Any $t$ members of the selected quorum can then collaborate to decrypt—preserving the threshold guarantee without the operational burden of DKG.

Batched Threshold Encryption

In a second line of work⁴, we introduce batched threshold encryption (BTE), designed to make threshold decryption scalable for large batches.

In the common case where a batch of $B$ ciphertexts is encrypted to the same quorum, BTE ensures that the size of each user’s partial decryption does not depend on $B$. This enables applications like an encrypted mempool in blockchains: users encrypt transactions under a quorum, and once a set of transactions is selected for inclusion in a block, a threshold of miners can collaboratively decrypt them by broadcasting partial decryptions. Crucially, those partial decryptions remain small—even when decrypting a large batch of transactions.

BTE has since seen improvements⁵, and a recent work⁶ obtains a BTE scheme that also supports silent setup—bringing these two threads of the new vision together.

Working with us

We’re excited about what silent setup and batched threshold encryption make possible: threshold encryption that is substantially easier to deploy and continues to perform at the scales demanded by modern distributed systems.

If you’re interested in deploying silent setup, batched threshold encryption, or related threshold-encryption infrastructure in your application, we’d love to talk—whether you’re exploring early prototypes or preparing for production deployment.

For more information contact us.

References