The TACEO:OPRF Service
In our previous post Foundations of Private Shared State, we explored the vision of Private Shared State (PSS) and the services around it. Bringing that vision to life begins with recognition: the ability for a system to deterministically acknowledge a user or entity across interactions, without linking their actions to their identity across different services. This is the cornerstone of any private identity system, private payment rail, or private agent network.
Achieving this “recognition without exposure” requires a new primitive: the Oblivious Pseudorandom Function (OPRF).
Today, we’re introducing our deployed implementation of that primitive: our Verifiable Threshold OPRF Service TACEO:OPRF. This cryptographic recognition layer is built for the era of Private Shared State, enabling decentralized systems to issue provably unique, unlinkable identifiers that remain private and secure even if a user’s key is compromised.
The Problem: The Fragility of Single-Secret Privacy
Modern privacy systems built on zero‑knowledge proofs, such as PSE’s Semaphore, have set a high bar for anonymous yet accountable actions online. Users can prove group membership or signal anonymously in ways that seem cryptographically unbreakable. Yet, this protection often rests on a single user-held secret key.
The Architectural Weakness
If that single secret key is ever leaked or compromised, protection is lost. Every past nullifier (one-time anonymous tags preventing double actions) can be recomputed. An attacker can then link a person’s entire history together, destroying a lifetime of accumulated privacy.
This weakness makes it difficult to build long-running identity systems for digital ecosystems. Pseudonyms or credentials that persist across months or years need to accumulate reputation, access rights, or attestations while remaining unlinkable to the real person. In financial systems, credit history or risk scores rely on persistent records. Privacy-preserving systems need cryptographic consistency to maintain these long-lived pseudonyms without relying on identity disclosure.
The question we asked was simple: How can a privacy system remain reliable and durable even if a user’s own secret becomes compromised?
The Solution: Verifiable Threshold OPRF (vOPRF)
The insight was to shift from a one-secret model to a two-secret model for generating nullifiers. The TACEO Network is the first to implement this model in a production-ready, decentralized service.
A nullifier is produced not from a single user secret but by jointly using:
- A user’s key (the client secret), and
- A server secret held collectively by nodes in a distributed (MPC) network.

This change fundamentally breaks the linkage problem. Even if a user’s key leaks, an attacker cannot reconstruct any of the nullifiers they’ve used historically; the missing, network-held server component closes that door.
To avoid creating a new trusted operator, we distribute the server key via Threshold Multiparty Computation (MPC). No individual node ever learns the full secret, and no single operator can hold custody over user privacy.
The Three Necessary Properties of PSS Recognition
Achieving Private Shared State requires a cryptographic primitive that provides three seemingly conflicting properties simultaneously:
- Determinism: Participants must reach the same result for the same inputs, ensuring the shared state stays consistent.
- Unlinkability: Outside observers (and even cooperating nodes) cannot connect one nullifier result to another.
- Verifiability: Everyone can verify the computation’s correctness without trusting the participants.
The Verifiable Threshold Oblivious Pseudorandom Function (vOPRF) is the cornerstone that makes this possible.
The Cryptography Behind It
At the core of this design is an Oblivious Pseudorandom Function.
A pseudorandom function (PRF) produces outputs that appear random, though they actually are generated by a keyed, deterministic process. However, in our context, we need to ensure that the server does not learn any information about the client’s input while still allowing the client to receive the output.
An oblivious PRF (RFC: https://www.rfc-editor.org/info/rfc9497) allows a client (the user) and an MPC network to jointly compute a pseudorandom output that depends on both of their secrets, without revealing either one.
OPRF Protocol Flow
The protocol looks like this:
- The user blinds their input and sends it to the MPC network.
- Each MPC node applies its secret share to that blinded input.
- The results are combined into one deterministic output.
- The user unblinds the final result, which becomes their nullifier seed—unique, unpredictable, and unlinkable to prior actions.

The entire process is oblivious: the network learns nothing about the user’s input or the resulting output. For the user, this output becomes their nullifier seed; unique, unpredictable, and unlinkable to prior actions.
TwoHashDH OPRF
We base our protocol on the fairly well known TwoHashDH OPRF, which works as follows:

- Client Pre-Process: The client hashes its input into an elliptic curve point and blinds it with a random value to fully hide the query.
- Server Computation: On receiving the resulting query point , the MPC server network multiplies its secret key onto the curve point, returning (performed collaboratively via threshold MPC).
- Client Post-Process: The client unblinds the response by multiplying the inverse of , yielding . Finally, they hash this result again to produce the final OPRF output.
The protocol has the advantage of being fairly simple and performant. The protocol’s linearity in the server secret key makes a threshold version trivial. This simplicity allows us to select any number of servers , and any threshold of how many parties need to participate. The parameter allows us to trade off robustness (allowing servers to fail) for collusion resistance (requiring parties to collude to leak ).
Adding Verifiability
Crucially, TACEO:OPRF is a verifiable OPRF (vOPRF). This means the client can prove that the correct OPRF key was used in the evaluation.
To achieve this, the OPRF servers publish a discrete logarithm commitment to their key, . They then generate a proof showing that and the response point have the same discrete logarithm in respect to the base points and respectively. This proof is essentially an extension of a classic Schnorr proof.
We give the protocol in the following, while ignoring some checks (e.g., valid non zero curve points) in the verifier for simplicity.
Anyone familiar with Schnorr proofs might realize that the only difference in this discrete logarithm equality proof to a Schnorr proof is the presence of two commitments R1 and R2 instead of just one.
Threshold Discrete Logarithm Equality Proof
In the literature, standard techniques of adding verifiability to a threshold TwoHashDH OPRF require each of the servers to create its own individual equality proof. This is undesirable as it forces the final SNARK (proving correctness of the overall nullifier creation) to scale with .
Instead, we thresholdize the discrete logarithm equality proof itself. We adapt secure threshold signature schemes (like FROST) to our setting. This approach keeps the final proof compact and efficient, requiring only a two-round protocol where each server only communicates with the client. It easily scales to a larger number of parties, such as 30 OPRF servers.
You can refer to our more technical writeup for details on this protocol. In short, we implement a two-round protocol, where each server only has to communicate with the client. The proposed protocol keeps the same relaxed requirements on the threshold as discussed above and can easily scale to a larger number of parties, such as 30 OPRF servers.
Key Generation and Management for the OPRF Servers
Since the OPRF secret is equal to a private signing key in a threshold signature, we can reuse existing threshold key generation algorithms for our purposes as well. In the deployed setup we opt to modify the PedPoP protocol and make it fully verifiable onchain. In other words, communication between the OPRF servers happens via a smart contract, and each party gets assurance (due to the usage of zero-knowledge proofs), that each message posted on chain by each party was done correctly. You can again refer to our technical writeup for details on this protocol.
Furthermore, this protocol allows us to:
- Reshare the existing shares to a new set of parties, making changes in the OPRF server providers easier.
- Re-randomize the shares of , making the protocol more robust against long-term attacks, where attackers try to steal the shares from multiple parties. We, thus, suggest to refresh the shares at fixed intervals.
This TACEO:OPRF design ensures:
- Deterministic randomness: Given the same inputs, the same nullifier is produced, essential for preventing replay or double‑use, while remaining unlinkable.
- Brute‑force resistance: No single node or external attacker can recompute outputs; no one holds the full secret.
- Verifiability: Each computation is accompanied by a Zero‑Knowledge Proof of correctness.
These properties make privacy persistent.
Deployment and Performance
Our Verifiable Threshold OPRF is live and operational, designed to be used with any number of parties and any threshold , with only client-to-server communication required. This setup allows us to fully distribute the OPRF service to a worldwide setting while still keeping practical response times.
The first customer integration is scheduled to go live by the end of this month—marking the service’s initial rollout in a large‑scale, real‑world environment (More on this soon…).
It’s a major step, the TACEO:OPRF Service now protects user identity while guaranteeing nullifier uniqueness and verifiability across live deployments.
Example Latency Analysis
The service runtime is determined by three factors:
- Client-side Authentication: The client prepares a use-case-dependent Zero-Knowledge Proof (in a real‑world infrastructure example, this takes ≈1 second on a mobile phone).
- Network Communication: The two round trips between the client and the -furthest responding server.
- OPRF Server Computation: The pure computation time of the OPRF servers.
To be more concrete, consider a deployment with 13 globally distributed OPRF servers (AWS m7a.4xlarge instances) and a trusted client in Graz, Austria. We measured the network round‑trip times (RTTs) to each server (measured using AWS speedtest). The RTTs, listed below, are ordered from the lowest to the highest latency.
| Server location | RTT (ms) | Server location | RTT (ms) |
|---|---|---|---|
| Frankfurt | 45 | South Africa | 205 |
| London | 54 | Sao Paulo | 256 |
| Tel Aviv | 95 | Seoul | 266 |
| Bahrain | 129 | Singapore | 274 |
| Canada | 136 | Hong Kong | 297 |
| US: Ohio | 145 | Sydney | 307 |
| Mumbai | 156 |
We measured the server computation time to be approximately 2.6 ms (with 1.9 ms spent on verifying an authentication proof). The total latency is calculated as: 2×RTT of t-furthest server+2.6 ms.
| Threshold t | t-furthest RTT (ms) | Total Latency (ms) |
|---|---|---|
| 7 () | 156 (Mumbai) | 156 ⋅ 2+2.6 = 314.6 |
| 9 () | 256 (Sao Paulo) | 256⋅2+2.6= 514.6 |
TACEO:OPRF as a Foundational Primitive
The implementation of a fast, verifiable, and threshold-based OPRF opens up new possibilities beyond simple identity nullification.
The OPRF itself is a fundamental cryptographic building block with direct applications in several advanced privacy primitives.
For those building in the decentralized and confidential space, the TACEO:OPRF service now offers a robust and ready-to-use component for constructing complex systems.
Specifically:
- Private Set Intersection (PSI): OPRFs are the most efficient primitive for PSI protocols, where two parties (e.g., a client and a service) want to find the intersection of their private data sets (e.g., matching contacts or records) without revealing the non-intersecting elements. The OPRF’s output provides a collision-resistant, oblivious hash of their inputs, allowing them to compare encoded values without exposing the raw data.
- Augmented Password-Authenticated Key Exchange (aPAKE): Protocols like OPAQUE use OPRFs as the core engine for generating a secure, server-side credential based on a user’s password. This ensures that the server can never see the user’s raw password, nor can an attacker recover the password even if the server’s database is entirely compromised. This is a long sought-after upgrade from traditional password hashing.
- Key-Blinding Schemes: OPRFs enable robust, verifiable token issuance schemes (like those you see in anonymous rate-limiting or credential services). They allow the client to obtain a cryptographically signed token that is blinded from the server, meaning the server cannot link the token it signs to the token the client later redeems.
Projects can now leverage our deployed network to handle the complex MPC and ZK requirements of the OPRF evaluation, focusing instead on assembling these larger primitives for their own use cases, such as verifiable private key recovery, or secure data matching without sharing inputs.
If your project involves blind key derivations, confidential credential issuance, or provably unique-but-anonymous access control, the TACEO:OPRF is the durable cryptographic foundation you need.
… & Beyond
Beyond the foundational primitive and live system, we are also exploring broader applications of this architecture:
- Digital ID / zkPassport: Extending the OPRF layer to prevent identity issuers, such as credential authorities, from tracing on‑chain usage by the individuals they verified.
- Random ID generation: Using the OPRF as the foundation for a protocol that generates deterministic yet unlinkable IDs, where only the owner of a “secret ID” can prove knowledge of the corresponding “random on‑chain ID.”
- Autonomous AI agents: Providing autonomous agents with persistent cryptographic identities that accumulate reputation and interact on‑chain without exposing their internal state or control keys — similar in spirit to Cloudflare’s work on anonymous credentials for rate‑limiting bots and agents without compromising privacy (Meunier, Patton, Heimberger, Faz‑Hernández, Cloudflare Blog).
These directions allow privacy‑conscious systems to anchor persistent, interaction‑capable pseudonyms on‑chain without exposing the link between secret and public identities. They remain active areas of research and prototyping.
Toward a More Durable Privacy Layer
With TACEO:OPRF, we deliver the first operational service of our computational model; one where recognition, verification, and coordination happen on encrypted state, not exposed data.
The service resolves a long‑standing structural gap in privacy systems: how to maintain continuity and accountability without identity disclosure or central trust. By distributing both custody and verification across independent nodes, it guarantees that recognition can remain private, cryptographically enforced, and auditable at the same time. This is one of the core services that defines the Private Shared State architecture: a verifiable network fabric where secrets stay secret, outcomes stay consistent, and trust derives from computation itself.
As TACEO Network expands: with services like TACEO:OMap for confidential storage and TACEO:Proof for verifiable execution, these primitives will interlock into an ecosystem layer for privacy‑preserving coordination at global scale, the foundation on which private identity, private payments, and private AI will be built.
Join us
We invite you to join us in building the next generation of privacy-preserving applications.
The TACEO team is actively collaborating with partners across payments, identity, and AI to leverage the power of PSS. If you have a mission-critical use case that requires verifiable, confidential collaboration, contact us today to explore how the TACEO Network can become the trusted computing fabric for your data.
Further Reading:
- A Threshold Network for “Human Keys” to solve privacy and custody issues. Ethereum Research | Nanak Nihal Khalsa, and Human Network Whitepaper
- Anonymous credentials: rate-limiting bots and agents without compromising privacy. Cloudflare blog | Thibault Meunier, Christopher Patton, Lena Heimberger, Armando Faz-Hernández
- Web2-ID Nullifiers using vOPRF. PSE | Magamedrasul Ibragimov
- The Semaphore project. PSE
- A Nullifier Protocol Based on a Verifiable, Threshold OPRF. TACEO | Daniel Kales, Roman Walch
- Oblivious Pseudorandom Functions (OPRFs) Using Prime-Order Groups. RFC 9497 | IETF
Acknowledgements
Thanks to Philipp Sippl (World Foundation) and Paolo D’Amico (Tools for Humanity) for collaboration, and to Sebastian Ramacher (AIT - Austrian Institute of Technology), Omid Mir (AIT - Austrian Institute of Technology) and Magamedrasul Ibragimov (PSE - Privacy Stewards of Ethereum) for providing thoughtful feedback.
Additional links
- Check out the TACEO:OPRF Github
- Follow TACEO on X for the latest news