Defining Privacy in MPC from the Operator's Seat
Soda Labs co-founder Avishay Yanai on garbled circuits, the FHE comparison, and what MPC privacy requires
The business (aka smart contract) owner decides what privacy looks like, and who's allowed to see what.
When I wrote about the three architectures of confidentiality on public blockchains last month (Tempo's permissioned Zones, Aztec's privacy-by-default L2, Zama's confidential L1), I deliberately set multi-party computation aside. This is because MPC is not a fourth pillar of that comparison; it sits underneath the others. Tempo Zones use threshold MPC for operator key management, Zama's key-management committee is itself a 13-node MPC quorum, and Aztec's research roadmap flags MPC-based hybrids as a long-term direction.
So MPC needed its own treatment. To anchor that conversation I sat with Avishay Yanai, co-founder and CEO of Soda Labs and one of the cryptographers behind gcVM. We spent the first stretch on the protocol work the team has been iterating on for years. Then he said something that moved the conversation onto different ground.
"The business (aka smart contract) owner decides what privacy looks like, and who's allowed to see what," Yanai told me. "If the user agrees to the service, they agree to the terms. It's no different from any other service on the internet."
It's a sharp distinction. In ordinary services, the terms are set in advance: what gets logged, what's shared with payment processors, and what's reachable by subpoena. Users agree to those terms, or don't use the service. What's missing is verifiability. The user has no way to check that the provider actually behaves the way the terms say. But when privacy is a property of the cryptographic infrastructure, what the operator promised and what the system does become the same thing. The beauty of blockchains, and smart contracts in particular, is that anyone can check who gets to see what and when.
The four-party stack
In any transaction with privacy implications, there are typically four parties looking at the data, with different levels of access and different reasons for being there.
Stablecoin issuers are the most legible example of operator-defined posture in production. Circle and Tether issue dollar-pegged stablecoins. Both have built the controls that let them blacklist, freeze, or block. Circle's policy is to act only on court orders or law enforcement requests; CEO Jeremy Allaire defended the position publicly in April after critics argued the company should have frozen $230 million in stolen Drift Protocol funds in real time. Tether's policy is to freeze proactively, often within hours of a reported exploit. The privacy posture is not a property of the cryptography. It is a choice the operator makes, and remakes, every time the question comes up.
The first is the regulator. For institutions handling money, and increasingly for institutions handling regulated data more broadly, disclosure to regulators is mandatory and non-negotiable. This is the layer Allaire was invoking when he said Circle "follows the rule of law": the operator's privacy posture must be compatible with subpoena.
Then there is the AML and KYC partner. These are typically external service providers the operator contracts with to monitor for illicit activity. The operator chooses them, but once selected, they have a defined level of visibility, often more than the operator expects, less than full plaintext.
The less discussed party is the real-time security provider, a category of firms including Chainalysis's Hexagate, Hypernative, and Ironblocks, which monitor smart contract activity in real time and can block suspicious transactions before execution, typically by integrating as a required co-signer on the contract. "These services give us real-time security on smart contracts," Yanai said. "They can monitor what's going on. And if there is some illicit activity, they can freeze that transaction." These services are operationally critical and increasingly common in institutional deployments.
Then there is the user's chosen counterparty. This is the layer most user-centric privacy conversations focus on, but in institutional contexts it sits at the bottom of the disclosure stack, after the regulator, the AML partner, and the real-time security provider, seeing only what the operator has agreed to share.
The cryptographic infrastructure question, when reframed through this stack, is whether the architecture lets the operator define the privacy posture cleanly across all four layers, or whether it forces the operator into a single posture the technology dictates. Yanai's argument is that privacy infrastructure has to be operator-defined from the ground up.
Privacy means different things
The four-party stack is one cut at the privacy problem. Yanai also offered a layered taxonomy of what privacy actually means depending on who's asking.
For individuals, he distinguished between cypherpunks and normies. "Cypherpunks care very much about their privacy," he said. "They don't want to give it to anyone except for being stored on their phone." Normies, he argued, are the majority. "They also do care a lot about privacy, but they're pragmatic about it. They'll extend trust to a provider once it's earned: a track record over time, a clear and credible commitment not to share or sell their data; much the way you'd judge any service you rely on. As an example, Anthropic's commitments to its enterprise customers are that kind of signal." He's quick to add that the cypherpunk ideal is one he shares, even if everyone, cypherpunks included, has to trust providers some of the time today. "If you're using Gmail, then Google has all the emails that you have. I'd genuinely love a future where you don't have to rely on any provider that's seen some of your information. We're just not there yet, but it's a direction worth pushing toward."
For institutions, the distinction shifts. What gets called "privacy" can mean two structurally different things. There's privacy of the data itself, hiding the values being computed on. And there's anonymity of the actor, hiding who's doing the computing. These are different cryptographic problems.
Yanai's example was a trading firm. "Trading companies want to do trades on a trading desk or other public venues, but they don't want the position they take to reveal their strategy, their alphas. The property they want is more of anonymity, rather than privacy of the data itself, as the data itself (orders and amounts) is what forms the market in the first place, and enables price discovery. Visibility there has a clear value. What they want hidden is who's behind it."
Privacy infrastructure has to handle both, and has to let the operator choose which one applies for which use case. This is the second sense in which "operator-defined" matters. Different applications may require different cryptographic guarantees. The architecture has to be flexible enough to compose them.
"MPC is a name of a problem, not a solution"
That sentence, said almost in passing during our conversation, reframes the category. Perhaps because it is a three-letter acronym, multi-party computation is usually pitched as if it's a competitor to FHE, ZKPs, and TEEs.
Yanai pushed the point further. Discussing the FHE-based projects Zama, Inco, Fhenix, he wrote: "Under the hood they are all MPC protocols, except that part of their protocol is solved around an FHE scheme. It's not a pure FHE solution as might be assumed by the audience. Similarly, there are MPC protocols that are based on other encryption schemes."
Production FHE systems for blockchain rely on threshold MPC for key management and re-encryption; Zama's KMS is itself a 13-node MPC committee. The FHE versus MPC framing has been load-bearing in the discourse, but the production systems on the FHE side of that line are themselves MPC underneath, with FHE as a sub-protocol used for one specific operation.
If MPC is a problem-class — compute this thing without revealing the inputs — then asking "should we pick MPC or FHE?" is the wrong question. The right question is about what privacy problem are we solving, and which techniques fit.
For the institutional version of the problem mapped above involving selective disclosure, layered visibility, and programmable permission, Yanai argues garbled circuits with public auditability is the technique that fits, because a regulator can see what regulators must see, an AML partner can see what compliance requires, and the chosen counterparty sees what the operator agreed to share. And anyone outside that perimeter can verify, cryptographically, that the computation was carried out faithfully without seeing any of the underlying values. That last property is the one that distinguishes Yanai's choice from the federated key-management committees of MPC-with-FHE systems and from the hardware-attested supply chain of TEE-based approaches.
The reframe also explains why the vendor benchmark wars feel exhausting. The same definitional gap runs through every X is N times faster than Y comparison. Different techniques solve different versions of the privacy problem. Comparing them on raw throughput is comparing the wrong thing. The question for a builder is not "what's fastest." It's: what security and disclosure posture do I need to support, and which technique can support that posture at the throughput my use case requires?
Why garbled circuits, specifically
Yanai's PhD was at Bar-Ilan under Yehuda Lindell, Benny Pinkas and Carmit Hazay, three of the central figures in academic MPC research, and he spent five years at VMware Research before co-founding Soda. His pre-Soda publication record runs across garbled circuits, threshold ECDSA, threshold Paillier, and private set intersection. He is, in other words, a working cryptographer who knows the alternatives. The choices in gcVM are downstream of that familiarity, by no means a default to the one familiar tool.
Soda's deployment record adds a secondary credential. gcEVM has powered COTI's V2 mainnet since March 2025, and is the underlying cryptography for COTI's selection as a Pioneer in the European Central Bank's Digital Euro program in May 2025. A pilot with Chainlink Labs runs in parallel, enabling privacy-preserving policy enforcement (like rate limiting) over a distributed cross-ledger bridge like Chainlink's CCIP. Yanai has shipped production cryptography in regulated environments, an altogether different kind of credential than academic publication.
When pressed on why he chose garbled circuits as the specific technique to tackle this version of the privacy problem, Yanai's answer offered four reasons.
Integration. Garbled circuits, as Yanai's team has implemented them, allow the system to run on NIST-standard cryptographic primitives, specifically AES, the encryption scheme that has been "battle-tested for 25 years (FIPS 197, November 2001)," in his words. The other major techniques in the category don't share this property. ZK constructions typically require specialized new hash functions and elliptic-curve pairings; secret-sharing-based MPC has its own primitive stack; FHE has many variants (TFHE among them) that rely on a variety of lattice-based assumptions, which haven't yet had three decades of adversarial scrutiny, particularly not in production. The practical consequence is that a garbled-circuit client can be built on top of OpenSSL, the cryptography library that is already ported to essentially every operating system, every cloud platform, every smartphone OS, every embedded device. "It makes it possible to integrate everywhere, from cloud machines through smartphones to IoT," Yanai added. For a project thinking about cross-platform deployment over a five- to ten-year horizon, the difference between ships with the OS and requires custom client cryptography is one to hang onto.
Flexibility. Yanai cited two specific examples. Garbled circuits enabled gcVM to support full EVM compatibility, including private operation on 256-bit integers, which are the standard width for ERC-20 token values. Without native 256-bit arithmetic, every operation has to be decomposed into smaller pieces, which compounds throughput cost and complicates contract logic. The second example is newer and worth flagging: gcVM supports an anonymous token primitive, achieved through what cryptographers call an Oblivious Pseudorandom Function (OPRF). The construction lets a user prove they hold a token without revealing which one. This is the cryptographic basis for the trading-firm anonymity case mentioned earlier. It's how a position gets unlinked from an identity without unlinking the position from the venue.
Throughput. Garbled-circuit MPC supports a clean separation between pre-computation and real-time work, where the real-time portion is, in Yanai's phrasing, "super light." The implementation in gcVM has nodes called garblers producing garbled circuits ahead of time, which evaluators then assemble, soldered together, when transactions arrive, in real-time. The architectural point is that the most expensive cryptographic work happens offline, decoupled from user latency. This is what gets the system to a measured 83 confidential transactions per second on standard cloud hardware, with a projected 400-500 cTPS once the offline pipeline is fully optimized.
Deployment economics. Garbled-circuit MPC, in Yanai's design, runs on standard machines. It does not require GPUs, FPGAs, ASICs, or a special board design. This is a non-trivial point. Some FHE roadmaps depend on GPU acceleration to reach institutional throughput; some ZK roadmaps depend on dedicated proving hardware. Each of those creates supply-chain dependencies and cost structures to evaluate. A cryptography stack that runs on commodity cloud instances has a different unit economics, particularly at the validator and operator layers where decentralization implies multiplication of nodes.
These properties together describe what Yanai called "a similar rubric as a privacy coprocessor." The claim points to a shift within Soda's own product line. Soda's first product, gcEVM, is an L2 (the architecture COTI runs on), where privacy is an integral property of the chain itself. Soda "Bubble," the newer product, belongs to a different category: a privacy coprocessor, in the same family as systems like Zama's, where privacy isn't baked into a chain but offered as a service an operator composes into its existing stack. The distinction matters because it broadens what Soda is, not only the cryptography embedded in L2s but an infrastructure any operator can adopt without migrating to a new chain.
The most concrete instance of this framing currently shipping is Soda's private ERC-20 self-service issuance. The construction lets the owner of any existing ERC-20 deploy a parallel private ERC-20 contract on their token, with users free to shield, transfer privately, and unshield at will. Yanai confirmed the system is built and ready, though it has not yet been publicly announced.
What's still being figured out
In Soda's design, validators verify that the MPC computation was carried out correctly without ever seeing the underlying plaintext or holding any key shares. The cryptographic property at work is public auditability — a guarantee in the gcVM construction that correctness holds even if every participating party in the computation colludes. Yanai grounded the assumption: "The assumptions garbled circuits are based on are the existence of pseudorandom functions, as well as correlation-robust hash functions, both considered weak assumptions ('weak' here means 'good,' as in fewer things to rely on). The vast majority of modern cryptographic systems are based on these assumptions." Public auditability requires an additional homomorphic commitment scheme, "where it relies on a different assumption, which is also very common. It's the same assumption we use when we browse the internet, like Diffie-Hellman, or when we sign with ECDSA."
The economic model that makes the validator role attractive to independent third parties is, at this stage, an open question.
What he's building toward
Asked where he wanted the technology to go over the next five years, Yanai's answer was: "Ideally, it will be a prolific network of MPC nodes that can serve most of the financial activity on blockchains."
Yanai stated that other domains, like healthcare, joint genomic analysis between research institutions, the kinds of cross-organizational data sharing MPC has been theoretically applicable to since the 1990s, are less attractive as a business not because the cryptography is wrong but because the use cases don't repeat. "We felt that in the other domains, there is not yet a repeatable use case where we can build something and then it will be used over and over," he said. "The business will not be very scalable. But on blockchains, we have a lot of structure in transactions, and therefore we can build one thing very, very well, and then it will be used over and over."
The decades-long assumption in academic MPC research has been that the most important applications are joint computation across disjoint parties like hospitals, research consortia, and banks sharing patterns without sharing data. Those applications still exist. But Yanai's argument is that the business of MPC graduates first where the use case is repeatable. Token transfers, trades, and settlement repeat. The blockchain category is, on this account, less the destination of MPC than the entry point, the place where an applied cryptography company can build infrastructure once and have it consumed many times.
What that implies, downstream, is an MPC infrastructure layer structurally different from a smart-contract platform or a privacy-focused L2. It's a service. The operator chooses to use it, defines a privacy posture on top of it, and integrates it into their existing stack rather than migrating to it. The adoption question in five years may not be which privacy-preserving computation architecture do you adopt, but which coprocessor do you compose with your existing infrastructure.
What the market actually demands, if Yanai is right, is privacy from the operator's seat that is selective, layered, programmable, defined by the business and consumed by the user.
