Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Zama: FHE and The Holy Grail of Blockchain Privacy

Episode Date: August 29, 2025

Blockchains operate as a public ledger, ‘disclosing’ the entire transaction history and associated data to everyone. While verifiability and traceability are key traits, as blockchains gain global adoption, those very features hinder the process. Self custody, on-chain identities, corporate strategies, transaction history, private deals, all represent highly sensitive information that call for provable confidentiality. Fully homomorphic encryption has long been considered the ‘holy grail’ of cryptography as it enables computation to be performed on encrypted data without the need of prior decryption. This basically translates to true end-to-end encryption, both on-chain and off-chain. As cryptographic research advances, so does the scalability and applicability of FHE. As a result of more than 5 years of work, Zama has now released Zama Protocol, which enables confidential smart contracts on top of any L1 or L2 using FHE, without any additional execution burden. By encrypting all ciphertexts with the same public key, FHE ensures composability and seamless integration across different blockchains and applications, making it a true cross-chain confidentiality layer. Through parallel execution, Zama Protocol already surpasses Ethereum’s throughput, yet future roadmap includes open-source development of FPGA & ASIC in order to scale it even further, to accommodate faster, non-EVM chains.Topics covered in this episode:Zama’s progress in FHEZama's confidential blockchain ProtocolSecurity guarantees of MPC coprocessorsMaintaining a healthy operator setSlashing and governanceZama’s throughputOpen-sourcing FPGA & ASIC developmentThe Zama token & its implicationsZama’s public testnetPrivate votingZama fundingRegulationsExpanding use cases beyond blockchainsFuture goals and expectationsEpisode links:Rand Hindi on XZama on XSponsors:Gnosis: Gnosis builds decentralized infrastructure for the Ethereum ecosystem, since 2015. This year marks the launch of Gnosis Pay— the world's first Decentralized Payment Network. Get started today at - gnosis.ioChorus One: one of the largest node operators worldwide, trusted by 175,000+ accounts across more than 60 networks, Chorus One combines institutional-grade security with the highest yields at - chorus.oneThis episode is hosted by Friederike Ernst.

it was too slow to be useful. Couldn't really use it for real applications like AI or blockchain. As a developer, it was too difficult to use. So we solved all of that. FHC today, at least Zama's version of FHC, is 100 times faster than it was when we started a company. It's easy to use as a developer, so you don't have to learn any cryptography,

and you can use it for anything from databases to AI to smart contracts. That's why we decided to build our own protocol, called the Zama Protocol, that enables confidential smart contracts on top of any public blockchain, L1, L2, Solana, EBM, without having to change the actual blockchain itself. So it works exactly the same as if you integrated it natively, but instead of having to run the FHA computation on chain, it's done by what we call a network of co-processors

who act on behalf of the application that's running on Ethereum, for example. Welcome to Epicenter, the show which talks about the technologies, projects and people driving decentralization and the blockchain revolution. I'm Friedricha Ernst, and today I'm speaking with Rand Hindi, who is the CEO of Zama. So Zama works on fully homomorphic encryption in the blockchain space. Before we dive into that, let me tell you about our sponsor this week. If you're looking to stake your crypto with confidence, look no further than course one. More than 150,000 delegators, including institutions like BitGo, Pinterra capital, capital and ledger trust Corace 1 with their assets.

They support over 50 blockchains and are leaders in governance or networks like Cosmos, ensuring your stake, is responsibly managed. Thanks to their advanced MEV research, you can also enjoy the highest staking rewards. You can stake directly from your preferred wallet, set up a white label note, restake your assets on eigenayer or symbiotic or use their SDK for multi-chain staking in your app. Learn more at chorus.1 and start staking today. Hey guys, I want to tell you about NOSIS, a collective of builders creating real tools for real people on the open internet. NOSIS has been around since 2015. In fact, it started as one of Ethereum's very first projects.

And today, it's grown into a whole ecosystem designed to make open finance actually work for everyday people. At the center of it all is NOSIS chain. It's a low-cost, highly decentralized layer one that's compatible with Ethereum and secured by over 300,000 validers. So whether you're building a DAP, experimenting with defy, or working on autonomous agents, NOSIS chain gives you a solid, neutral foundation to build on. But NOSIS is more than just infrastructure. It's also tools that people can actually use. Like circles, for example, lets anyone issue their own digital currency through networks of trust, not banks. And then there's Metri.

It's their smart contract wallet that makes it easy to access circles, manage group currencies, and even spend anywhere Visa is accepted, thanks to their integration, with NOSUSPA. All this is governed by NOSISDAO, where anyone can propose, vote, and help guide the network. And if you want to get involved, running a valid is super easy. All you need is one GNO and some basic hardware. To learn more and start building on the open internet, head to NOSIS. I.O. NOSUS building the open internet one block at a time. Rand, thank you so much for coming back on. Thank you for having me again.

So you joined us last in late 2023, so almost two years ago. And Zama was mostly known as a fully homomorphic encryption research and tooling company. I hope that's a fair description. How has Zama evolved since then over the last two years? Well, let's take a question. So when we started Zama five years ago, we wanted to solve the problems with fully homomorphic encryption, FHE, namely that it was too slow to be useful, that you couldn't really use it for real applications like AI or blockchain, and that as a developer, it was too difficult to use. So we solved all of that. FHE today, at least Zama's version of FHC, is 100 times faster than it was when we started a company. It's easy to use as a developer, so you don't have to learn any cryptography. and you can use it for anything from databases to AI to smart contracts. Our business initially was to sell the technology to other companies

who wanted to use FHE in their own products, in particular companies building confidential blockchain projects. For example, Phoenix, Inco, Shiba are all users of Zama's technology. One thing we realized, though, doing that is there was a number of people reached out to us wanting to build confidential applications on existing public blockchains like Ethereum, base, or Solana. And for that, we didn't really have a solution because our technology had to be integrated in a new chain at the protocol level.

That's why we decided to build our own protocol called the Zama Protocol that enables confidential smart contracts on top of any public blockchain, L1, L2, Solana, EVM, without having to change the actual blockchain itself. So it works exactly the same as if you integrated it natively, but instead of having to run the FHA computation on chain, it's done by what we call a network of co-processors who act on behalf of the application that's running on Ethereum, for example. And so now effectively we've shifted our business from selling technology to other infrastructure companies to providing a protocol that any app developer could use. use to build confidentiality on existing chains. I think there's a lot to unpack here in terms of architecture. So typically what we see is people starting up new chains, kind of like if the existing

chains aren't up to their specification. So tell us about kind of like building this FHE environment on existing chains and how that works on a technical level. So the way that FHE works is you take encrypted data and then you have to basically do FHE computation on the encrypted data. This is very expensive compute-wise. The second problem is if you want to have composability between smart contracts, you need to use the same encryption key, so the same public key, to encrypt all of the data amongst the smart contracts, which means you also need a way to do selective decryption without.

compromising the security of the whole protocol. So those two problems we solved using a network of FHE and MPC co-processors that basically monitor what the application wants to do and does it on behalf of the application. So let's say, for example, I want to do a confidential token transfer. So I want to send you some money on chain, some stable coins. But I don't want people to know how much money I sent you or how much money you have or I have. So you want to keep the balances encrypted on Shane, and you want to keep the amounts encrypted on Shane. The way you do this with the Zama Protocol is you deploy a confidential token contract.

So it's just a regular smart contract on Ethereum, for example. And you specify in your contract that the balances are encrypted and that the amounts are encrypted. And you also define the rules for who's allowed to decrypt the balances. So for example, the user should be able to decrypt their own balances, but you could also start. building some compliance features such that, you know, enabling your accountant to access your balances or whatever, right? What happens, though, is that Ethereum itself wouldn't do the FHA computation or the decryption because it doesn't have the capabilities to do so. Instead, when the smart contract says something like, add this encrypted amount to this encrypted balance,

it emits an event, which is picked up by the Zama co-processors that basically say, oh, someone is asking me to take those two inputs, encrypted inputs, perform this addition, and store the data at this location. So we're effectively decoupling the application logic and the commitment to what's supposed to be done from the actual execution that is happening off-chain in the Zama protocol operators. And by doing that, it means that there is virtually zero slowdown on Ethereum itself, because there is no computation happening there, and everything is offloaded to a network of GPU operators.

Tell us about that network of co-processes and kind of like how I become a part of this and kind of what the security implications are for people who kind of use the confidential blockchain protocol as part of the Ethereum or Solano or whatever stack. There are two components to a protocol. The first component is the FHE operators. They do the FHE computation.

Technically, this can be anyone because the FHC computation is done completely publicly. So there is no private information needed to be an FHE operator. You just take the operation, compute it, and post it to the Zama protocol. Anybody can publicly verify it. So think of it like any blockchain protocol, right? It's a publicly verifiable computation. The part that's more tricky is how do you handle decryption? So the way that we do that is the smart contract can define access control logic in the contract itself.

So it can say, you know, if this condition is true, allow this person to decrypt XYZ value in the contract. This also emits an event, which is picked up by a different set of operators, which actually run a threshold MPC protocol for to decrypt the data, according to what the contract allows them to decrypt. So that MPC protocol, you know, has to hold by definition like a secret, right? The, like basically the pieces of the secret key that allows you to do the decryption. So you cannot have random people run that because otherwise, you know, well, how do you know they're not just cheating? So what we did in the Zama protocol is we basically ran an RFQ, right?

a request for, you know, for operators, where people had to prove that, one, they were able to run infrastructure in a very reliable way because, you know, you don't want people to block the protocol. And secondly, that they already were securing billions in other things. So the people who are going to be running the MPC protocol for Zama are validators with billions at stakes in other protocol, wallet providers that are securing hundreds of billions in assets,

infrastructure companies who are responsible for some of the biggest blockchain projects, custodians who are holding assets for institutional customers. So the idea here is that the limited set of people running the MPC protocol, so 13 operators in the case of Zama, together bring $100 plus billion of reputation security on top of whatever stake they put in the Zanmer Protocol itself. And that's really important, right? Because in the case of Ethereum, you know, I mean, you have, what, a million validators?

They can be anybody. And it doesn't matter because anybody can be a validator. But for MPC protocols, and that's true of all MPC protocols, you can only have a limited number of people participating. And so you have to make sure that those people are the most trusted, reputable companies in the world. So the logic here is that anybody can run an FHE node eventually. It's just publicly verifiable computation.

That's fine. But the number of MPC nodes and operators are going to be limited to very high quality reputable companies. And if they cheat, arguably, they lose more money than they have in Zama because their whole business would fall out. Like, you know, if a tier one custodian cheats in the Zama protocol, they're not going to have many customers left after that. right?

Yeah. Tell us about, so kind of there's 13 of these co-processes in the MPC round. I'd like to mention, by the way, that 13 is more

than any MPC protocol in production has today. If you look at everybody else doing MPC, they have three to five nodes. We have 13, which is already way more than anybody has deployed.

And what's the quorum? So kind of how many people actually need to how many of these entities need to work together in order to kind of decrypt? So you need technically 9 out of 13 to decrypt. What we are working on now is a way to combine zero-in-lawless proofs with the MPC protocol so that each of the MPC nodes has to provide a zero-in-knowledge proof that they've done the MPC computation correctly.

And if you do that, you can actually have, better security because you can have what we call verifiable MPC. You know, one thing about MPC is that, you know, you trust the majority is honest, but you don't have a way to verify who individually might have cheated, right? So in the case of Zama, as long as nine out of 13 nodes have run the computation correctly, then the result is correct. But, you know, if all nine of them have cheated, you don't have a way to know it. And so adding zero knowledge proof to that would be a way to identify

individual cheaters in the MPC protocol and slash them and do whatever appropriate thing you have to do on top of that. But this is an active area of research. So it's not like there is no solution to that today. Just to understand kind of like how much is at stake here. So if nine out of the 13 collude, and I mean, I understand this is unlike the catastrophic failure of the protocol. But what's the worst they can do then? It depends on the application, right? I mean, obviously, if they collude, they could decrypt and see your money, right?

So they could tell how much money you have, which is bad for privacy, but I guess is, you know, financially. The question is kind of like, can they kind of divulge secrets or can they steal money? I think that's kind of like the spectrum we're talking on, right? It depends on the application, right? So if your application uses a decryption of something to trigger some financial, you know, a side effect, then obviously forging a fake decryption could lead to triggering the wrong smart contract logic. So one example where this happens is, let's say you have a confidential token and you

want to bridge it to a non-confidential token. So you want to go from confidential to non-confidential. Someone has to decrypt the amount that needs to be bridged out of the confidential token. right. If I can if I can produce an arbitrary value, technically I could just, you know, bridge out as much money as I want from the bridge contract. But this is a problem that you have with any kind of protocol where you're relying on some kind of, I would say a majority assumption. So that's the reason why you need to work with extremely highly reliable operators. So what we're saying here is, yes, sure, there are 13 of them.

But those 13 operators are trusted, you know, at the tune of $100 plus billion dollars already today. So the stake they bring is huge. I totally understand that. And I think kind of, I mean, we have the same thing kind of for multisix that kind of upgrade layer twos and bridges and so on. So kind of like, I think kind of like I just, I'm not critiquing the setup. per se, I'm just trying to understand what kind of the risk landscape kind of looks like.

Well, see, the thing is that if you think about cryptography, right, there's really only two ways to deal with decryption, right? Or let's say there's only two ways to deal with composability on a shared secret state. One way is have a shared public key and therefore you need a way to do decryption correctly. So that's what we do at Zama. The other way is to basically have interaction. So people just basically do a bunch of transactions to the protocol, you know, to basically commit their own result. So that's actually a good explanation of the difference between FHC-based and ZK-based privacy protocols. ZK-based privacy protocols don't allow you to have computation and composability on the secret state because you cannot compute on a ZK proof, right?

You can only prove you've done something. So if you want composability, you need the different parties involved in the shared computation to basically make a transaction and go back and forth in a protocol. So you're basically doing a bunch of interactions, right? That's okay if the transactions are simple and everybody's online,

but if people are offline, it doesn't work, right? You need everybody to be here to do that. The only way to have composability in an offline asynchronous manner is to use confidential computing, FHET, MPC, which by definition, means you need to use threshold decryption for the decryption. There's just no other solution. It doesn't

exist. That's a universal reality of cryptography today is either you have a bunch of interaction everybody has to be online or you need to have effectively like a decryption network that takes care of doing decryption for people. Yeah. Fully granted. What's the process of replacing one of those 13 entities. So say I have a reputable validator service kind of like that stakes to the tune of I don't know, $5 billion

and kind of I sell it or kind of I get acquired or I just decide to quit. What happens then? Can I kind of like pass on my part of the MPC pie to someone else? Or do I need a new ceremony? Yeah, yeah, yeah. We can do what's called resharing,

which means that you can securely hand over, you know, or change the MPC sets, MPC participant sets. In the Zama protocol, the way that we do this is there are two effectively reasons why you would want to change an operator. Either the operator is no longer available or maybe, you know, they've been too slow and maybe there's like a better one

we can replace them, in which case is just a simple kind of handover that we do based on epochs. So every X months or whatever, we haven't really decided this yet. We effectively look at who have been the least performance operators and we offer people to replace them.

However, in order to be an operator, you must have been running a Zama test net for some time to prove that you've got the DevOps capabilities and that you're not just rich, but you can actually run infrastructure, right? Because this is not just about stake. It's also about capacity to run critical infrastructure. So that's one thing.

The second thing is if an operator gets caught cheated, anybody could basically make a governance proposal asking to either penalize or slash or replace the operator providing some proof that they cheated. So for example, if you're monitoring the NPC network you see, oh, you know, Zama's node has been misbehaving, you just file a governance proposal on the Zama governance Dow, pretty much, saying, I've caught this guy cheating, here's the proof, and this is what I'm suggesting that we do about it,

and then people vote on it. The reason why we go with governance-based proofs, sorry, governance-based slashing is because there's so many reasons why an operator could have made a mistake, right? Maybe the data center went down, or maybe, you know, like there was this software bug that have deployed or something like that. And we want to make sure that we can distinguish between malicious intent and honest mistake. And I think it's not fair to slash the whole stake of someone just because, you know, their data center went down for like an hour.

Right. And you see that in blockchain in general, by the way, Ethereum aside, which is a unique exception, most protocols have flexible, I would say, slashing policies that take into account their reality of running infrastructure in the real world. So again, you know, in our case, we're trying to be extremely pragmatic. What matters to us is that we offer, you know, a very highly reputable, secure protocol doing the best that technology today allows us to do. Cool. Tell us about the incentives for the operators.

So kind of I'm one of those 13 companies that kind of kind of takes part in this MPC pool. What's in it for me? You get rewarded with Zama tokens. So all of those operators have to stake and they get rewarded proportionally to their stake. And also we're thinking about introducing performance based rewards. So effectively, we look at how quickly each of those nodes have responded on average and try to overcompensate those who are very good. Again, you know, the idea is to has sort of a competition for who's providing the best service possible. Token holders can also delegate their stake to those operators.

So in that sense, that protocol is closer to like a delegated proof of stake protocol where you have like a fixed number of validators and then as many people as you want can delegate on them. What's the jurisdictional and geographic distribution of those entities? because kind of like in I mean pretty yeah that's a good this a good point yeah pretty balanced so we the genesis operators are based in Asia Europe and US okay but kind of there's there there's not nine kind of there there's not a threshold of nine kind of like in any one geographic area or jurisdiction no no definitely not I'm just trying to think about it no no there is not

No, there isn't just simply because we have Yeah, we have at least four in both Asia and in the US We do have quite a few operators in Europe But even within Europe, they're not within the same country So I guess it depends if you consider Europe to be one geography Like, you know, is a validator in Switzerland the same as a validator in France I would argue probably not But if you just take out say region

It's pretty balanced actually Okay, quite fantastic Then tell us more about the governance that kind of decides on the slashing policy. So kind of like, say, my data center goes down. Who do I appeal to for mercy? Well, technically, if nobody files something against you, you don't have anything to do. You only get slashed if someone actively proposes to slash you. So we do it the other way around, right?

Like we assume that, you know, you're honest in the sense that, you know, if you've been offline for an hour, that you have a good reason to have been offline for an hour. But if someone doesn't believe that, because, you know, let's say you've been offline three times this month, which is unacceptable because, you know, we expect people to offer 99.9% uptime,

then, you know, someone can say, hey, you've been offline way more than you're supposed to. And then it's on you to prove that this wasn't your fault. Again, like think about it how you would do it in the real, like the real old outside of blockchain, right? in cloud, for example, if you're working with another company as a partner and they fail to abide by whatever agreement you guys had together, you're not immediately punishing them. The first thing you would do is tell them, hey, what's up? Right? You know, like, you know,

can you explain to me why this happened? And then most likely there's a good reason for that. I think one thing that's important to remember is Ethereum itself can only rely on. on proof of stake on chain because the validators are anonymous. You have no idea who's participating in the protocol. In the case of Zama, every single node is publicly known. So you know which company, which entity is running which of the nodes, right? So everybody is completely doxed. And that's why you're able to bring in reputation and off-chain stake as part of the economic

security. And I think this completely changes the way that you think about proof of stake and slash because you're no longer just dealing with some random person internet. You're dealing with a multi-billion dollar entity that has way more to lose than the protocol. Totally granted. And then once I make a proposal to kind of slash someone else, is it just tokenholder voting? Or how do you decide? Yeah.

Token holder voting, basically. With a threshold, obviously, you know, like, you need at least some participation. You don't want someone to propose to slash someone during Christmas and nobody's participating because they're off with their families or something, right? Usual governance-related stuff. But again, we keep governance for critical parts of the protocol. So operators slashing, changing their reward, the mission rates, things that materially change the security of the protocol. Okay. Tell us about the throughput that Zama currently.

supports. I mean, it depends on the application again. For something like confidential payments, where the payments are pretty independent of each other usually, we can scale as much as we want. So I'm pretty confident that by summer next year, 2026, we'll be able to do thousands of confidential transfers per second across multiple different chains. Right now we're going to launch an Ethereum main net first. So the first chain we're targeting is each mainnet.

It's mainnet has limited capacity. Zama, the Zama protocol, can already support more transactions than Ethereum itself can support. So the bottleneck is not FHE. The bottleneck is blockchain. And I think that this is going to be true for virtually every common use case. The only thing FHE is not capable of doing, and by the way, is not designed to do, are things like high frequency, perpetual trading. By the way, there is no cryptography that would give you sub-millis-second order book matching, MPC, FHE, ZK. It's just not how the technology works, right?

I think for that, you need to use something else. Where we see FHE really playing a strong part is anytime you want to do payments, anytime you want to do swaps, lending, so I would say not high-frequency trading type of applications. But importantly, I think

that FHC is going to be used for long-term storage of confidential assets. Because if you look at the landscape of various confidential computing technologies, you've got ZK, T's, MPC, FHE, basically.

FHE is the only one that actually currently offers the highest level security long term. So if you want something that is post-quantam, that is extremely secure, FHE is really the only thing you can use right now. So FHE had a reputation for being slow, right? Where does that come from?

It was slow a long time ago. I think, you know, most people have not really used FHE in practice yet, so that's why they still have this impression. But as I mentioned, we can already go faster than Ethereum. Okay, so granted, Ethereum is not the fastest chain, right? And I think, you know, before Zama can support 10,000, 100,000 TPS, we still have a bit of work. But we're going to get there. FHE increases exponentially performance-wise.

And that's mainly due to a combination of better cryptography, so new techniques that we invent, which is good software, engineers doing good job implementing cryptography, and harder acceleration. So moving from CPU to GPU to FPGAs to ASIC, basically that gives you a 10x every time. So the difference between a CPU and an ASIC is roughly 1,000x cost performance ratio. So, you know, I'll just give you one number. We've done some estimates of what we could get on a single server using ASICs for FHE, right? So just one box, not multi-server, just one box you put in the data center.

we could currently get to 80,000 confidential token transfer per second on a single box within ASIC. So you could run, you could run like, you know, visa three times on a single server in FHE if you're using ASICs. Okay, so kind of currently we're using CPUs and then kind of like you get a factor of 10 for going to GPUs and then another factor of 10 for FPGAs, right? And then another 10 for ASIC. And then what's the timeline for this and what are kind of the bottlenecks that you're introducing? No real bottlenecks. I mean, hardware is hard.

It's in the name, right? So I think, you know, you need quite a bit of time. So moving from CPU to GPU, we've already done that. So the TFHRS library that we use as the backend for the XA protocol works. on both GPU and CPU. We're starting with CPU on Ethereum Mainnet, just because we don't need more than that. We're moving to GPU Q1-26 once we start

supporting other chains than Ethereum Mainnet. So Bay, CBNB, all of these things that require more performance. And then we're going to move to FPGA. So we recently open-sourced what we call the homomorphic processing unit, which is a completely open-source FPGA accelerator, for Zama's FHE technology. So that's going to be the, I would say, blueprint for Zama's ASIC, which is going to take us probably two to three years to build and quite a lot of money, right?

Because, you know, the ASIC we have in mind is a chip as big as a GPU, effectively. So that's very difficult to build. Most likely we're going to probably have multiple failures in the process. So I estimate that it's going to be two to three years of work and $50 to $100 million. It's not impossible. It's just like nobody has done it. So we're the first one to attempt at. Maybe let's dig a little deeper here.

So kind of I think most listeners are familiar with CPUs and GPUs. But tell us about what, how they, how field programmable gate arrays, so FBGAs. and A6 kind of how they evolve from that or kind of how they behave different than a normal GPU. Right. So CPUs and GPUs are programmed like software. So you write C code and then that runs. The GPU runs that in parallel. Think of like matrix operations that can be done massively parallel.

CPU is more, I guess, like branching. logic type of operations. And FPGA doesn't run software. And FPGA, think of it as an array of gates, very crudely speaking, and you're programming the gates, as in you're doing literally low-level electronics saying, this is an end, this is an ore, and I'm going to connect them together with a wire. So it's almost like you're doing raw electronics, but instead of actually, you know, printing the circuit on a chip,

you're using an array of gates to do that. So it's similar to how you would build an ASIC, but you don't actually have to build the ASIC because you have a programmable hardware in a way, right? So FPGA usually is good as a stepping stone towards an ASIC. So you build your FPG accelerator, and then you try to build it in a way, then moving to ASIC will allow you to scale the performance

that the FPGA offers you. So an FPGA typically runs in, you know, a few hundreds of megahertz. Moving to ASIC could be, you know, one, two gigahertz. An FPGA typically has a limited size, because there's like a physical limit to how many stuff you can put on it.

With an ASIC, you could go much bigger and build a huge ship if you wanted to. So the way that we look at things, we look at FPGA as a stepping stone towards ASIC, a blueprint, if you want. Okay. This is a huge investment, right? And you just said that kind of like the idea for how to build this FPGA, you open source that? Yeah. Yeah. I mean, everything we do at Zama, 100% of everything we put in production, the code is open source. And the reason for this is we don't want people to trust us on what's running. We want them to be able to verify what's running. And I think, you know, that's one of the things people don't talk enough about in blockchain. People talk a lot about concerns. census, they talk a lot about, you know, economic security.

For me, I think the most important part of a blockchain is public verifiability. If you cannot verify yourself what has been done, then it's no better than running a Web2 cloud service effectively. Totally granted. I was getting at the economic viability of this. So kind of when you say it's open source, I mean, I can view it and I can review it. But can I also repurpose it? So can I use

does it have a permissive license? For a non-commercial use. If you want to use it commercially, you need to get a license from Zama, or you need to use the Zama protocol or any kind of Zama services, right? So the reason we open source it is not to make it free. We're a commercial company.

We're not a non-profit. The reason we open-source it is so that people can see what's running and not have to trust us when we tell them that this is secure. Cool. We touched on this a little bit. Tell us about the Zama token and what it does. So you already said that kind of like the entities that are involved in the MPC protocol, kind of need to stake them, but give us a bit more context here. Right. So there are two type of operators in the Zama protocol. You have FHE operators that run the FHC computation,

and you have MPC operators that do their threshold decryption. So both of them need to be rewarded in some way. So the way that we do that is that they have to stake Zama tokens and they then receive Zama tokens as a reward. Those Zama tokens they get as a reward are based on an emission rate. So we basically mint Zama tokens to distribute to them prorata of their stake, pro rata of the performance, prorata of the kind of work they did, and so on so forth.

So very vanilla kind of emission. reward type of mechanism. So that's the one first utility of the token. It's literally just people participating and rewarded. The second utility is paying fees on the user side. So every time I want to encrypt or decrypt data and the Zama protocol, I need to pay some Zama tokens. So those Zama tokens are burnt.

So this is like a burn and mint kind of model here. So we burn 100% of the protocol fees and then we mint the rewards for the operators. So the way that we charge for the Zama protocol is based on volume. So the more someone encrypts and decryps, the cheaper the fees actually get for that person. Kind of like you would expect it in a Web2 SaaS product in a way, right? Like the more you use it, the cheaper it gets. We're using the same kind of logic here for effectively the on-chain fees. So it's payment to the protocol fees, it's rewarding the operators, and the turds is voting on governance proposals.

So slashing operators, changing the emission rates, and other things which would be material to the protocol. I mean, don't hope this happens, but kind of say, Sama for some reason kind of goes downhill, right? There's a lot kind of hanging on these tokens and the token governance. So as someone kind of like who's used a Zama-based application on, say, Ethereum Mainnet, what's the worst that can happen to me after the fact if kind of, say, Zama market cap goes way down and someone buys up, you know, 50% of the Zama tokens to kind of do weird governance stuff. I mean, how exposed am I after the fact? That's a good question.

I think this is a generic question about governance attacks on protocols in blockchain, right? I mean, there is nothing really that we're doing on the Zama side that's different. If anything, actually, governance has less of a potential impact than in many protocols where governance could literally drain the treasury of the Dow or something like that. In the case of Zama, you cannot vote to drain the treasury, simply because the treasury is just not something that governance manages in our protocol.

So what you could do is you could slash operators effectively. So you could say, hey, I want to slash this person, I'm going to slash everyone. So it's more of a denial

of service attack that could happen more than it would be like an active draining attack. So there is no financial gain for you to do that unless you're like a Zama competitor who just wants

to take down the Zama protocol. But could I de- decrypt things after the fact? No, no, you couldn't. You wouldn't be able to because even if you slash all operators, someone would need to basically vote to get those operators back in. Right.

So as I mentioned, in order to be an operator, you have to go through like a proving process. You have to prove that you're able to run the protocol and that, you know, you've been, that you're capable of doing it, right? So for you to do an attack like that, first of all, you would need to have introduced publicly enough operators to control the protocol. Right. So somehow you need to have promoted at least nine operators that are trustworthy without the community basically saying, oh, this is an attack.

And then you have to vote without people being like this is an attack. Don't forget, people can always fork if they want to, right? If the whole community says this is completely wrong, technically they could also decide to just take the protocol and then move to like a different set of operators. This would be the worst, worst case scenario. Yeah, but going forward, right? But kind of like backward looking, so kind of like if I have confidential things that are already committed to blockchain, kind of like they hang on the identities of the 13 entities that were the operators at the time. So kind of like if I managed to kind of replace nine of them by cronies by kind of, and I mean, a tax could be fairly cheap if kind of like the market cap tax, right?

So if I manage to kind of subvert the thing, the security is also compromised backwards looking, not just forward looking, right? Yeah, but I mean, think about it logically, though, right? if the market cap is so low that you can just buy up 51% of the supply or whatever then it means by definition that there is no activity on the Zama protocol

like there would be no meaningful amount of money in the protocol at such a low market cap like I don't think we've ever seen a protocol with billions in TDL that has a 10 million market cap so I think there is a bit of like a if the protocol is successful in Wirt attacking, then it's going to be very expensive. And the operators are probably not going to, you know, want to give their stake to some crony.

If the protocol is cheap to attack, it's probably useless anyway. Yeah, no, so kind of my, maybe I'm misunderstanding here, but kind of because the attack can also look backwards, so kind of the current TVL is not a good indicator of how much really is at stake, right? because I can also kind of make an attack on value that's already been processed in the past that's no longer kind of in your TVL measurements. Well, the way to we measure TVL and there's our protocol is how many, how much money is in confidential tokens.

Okay. So that's, you know, I mean, it's not TVL in the sense of defy, it's not like swapping or something like that, it's TVL in the sense that you have, let's say, a stable coin, and then you have a confidential stable coin. How much is in confidential stable coins? The second thing also to remember is operators have a lot of stake in the protocol, right? So their incentive is not to get kicked out. If operators are not making any money, they're not going to be running the Zama protocol,

and the Zama protocol is going to shut down. Like at some point, you know, the whole economic thing is such that either it's economically viable and the operators are going to basically prevent governance of tax just by virtue of having a lot of stake that it could use against it. Or the protocol is not worth anything and there's no operators who are going to be running it. Because the cost for an operator is pretty high. And we're talking, you know, 50 to 100K a year for an MPC node minimum. For an FHE node is more than that even.

So you wouldn't really invest this much in infrastructure unless, you know, there was was profitability in the protocol. And even then, you can only slash operators in your governance proposals. It doesn't mean that you can replace them with whoever you want. Yeah. Okay, maybe let's move on just a little bit. So you're currently live on TestNet, right? So who's building on that public test net at this point?

A bunch of people, Zama itself actually has multiple, I would say, apps that we're building internally. Kind of like, you know, when you buy an iPhone, it comes with Apple apps, right? Apple has a calendar app. Apple has like a browser. And then you can replace and use other apps if you want to, but the iPhone doesn't come empty. Same thing here, when Zama protocol goes to Mainnet, it's not going to come empty. It's going to come with a suite of Zama apps. So for example, we have an app that allows you to run token auctions on chain.

We have an app that we're working on that enables you to do confidential token distribution. But if we look at external people building things, there is a company who's building a self-custodial bank on chain using confidential stable coins as the assets in your bank account. There is another company who's currently building a confidential stable coin. where the on-chain balances amounts, but also the mint and burn, so the on-ramp and off-ramp to the stable coin is confidential. So it allows you, for example, as a company,

to use a stable coin, just like you would use, like, any kind of currency without disclosing anything to everyone. Most of the applications are payments or finance-related, clearly. Because to be honest, I think this is where we see most traction and most need for confidentiality right now. Yeah, with them, the current ecosystem, that's for sure.

I know you've also talked about private voting and things like sealed bid auctions before. When do you see these coming to fruition? Whenever someone wants to build it and thinks that this is relevant, I guess. I think sealed bid auctions we're going to do for sure because I think this is a cool use case. Confidential governance voting, so we are not a governance. We don't build governance apps, right? like this is a whole company, you know, you need, like, you know, there are literally companies doing just that.

So the goal for us would be to convince them to integrate confidentiality into their governance systems is going to happen. Like I think when people realize that the cost of doing things confidentially is not that much higher than non-confidentially and that performances is not a bottleneck, there's really no reason not to do things with confidentiality. Think of it. Think of like how. the internet evolved, right?

HTTP in the beginning was expensive to do encryption. It was difficult to set up, so nobody used it. I think it was 13% or 14% of internet traffic was encrypted with HGPS when Snowden revealed, you know, the whole thing. Today, it's over 95% because it became so cheap and so easy to do that people just do it by default. I think the same thing is going to happen to blockchain. We're going to get to a point where the vast,

vast majority of blockchain transactions are going to be encrypted because why not? You have to remember that the reason why data on chain is public is not a feature. It was needed for public verifiability. But if you now have a way to compute an encrypted data in a publicly verifiable manner, that's what FHE does, then you could actually have public verifiability without having the data publicly disclosed to everyone either. And I think this is a very, very important thing that just wasn't possible at the time when Ethereum launched. Yeah, 100% agree that the transparency is not a feature for most applications.

You recently closed a pretty big series B round. So you raised 57 millions. how does this change your trajectory or does it kind of make a lot of the things that we already talked about initially possible? So things like doing multi-year research for building an ASIC and so on. So where do you plan to spend that money?

Exactly what you said, multi-year research projects. So Zama has consistently been keeping a multi-year runway. I'm very paranoid. Like, you know, I've been in crypto since 2013. I know how quickly things can change. And typically, like, a bear market will last two to three years, right? So I always want to make sure that my company has enough cash

so that we don't have to worry about any kind of short or medium-term market conditions. Our goal is that in four years, the majority of blockchain transactions are encrypted using Zama's technology. through the Zama protocol. Sorry, how much percentage? The majority. Majority. Even 10% I'd be happy as a starting point, but let's say, you know, the majority.

Whether it's through Zama's protocol or through one of our partners who are licensing our technology, I'm happy in both cases, obviously. And so to do that, we need to be able to guarantee that we're going to continue pushing on research, on development, on performance improvements, on security. on all these things. And so this funding really goes towards that. So even if Zama makes no revenue, which is not the case,

even if our token goes to zero and we make zero out of the token itself, right? So imagine like everything stops. There is a global war. Nobody cares about privacy and blockchain anymore. The whole world stops, right? We would still have enough cash to get to 2029 and above.

So we don't have to worry about any kind of world condition right now. And that's really, really important. Because if you're going to be betting the future of, you know, your application on some third-party technology, you want to make sure they're going to stick around for a while. How worried are you about regulatory capture? So, I mean, I know kind of like in this space we're all for privacy. but kind of from the regulatory side kind of transparency has been pushed more and more

and kind of won't regulators kind of bark at financial apps that are inherently private and cannot cannot be forced into disclosure. I think when you think about compliance, this is actually one thing I think, the Zama protocol is very strong at is the Zama protocol doesn't force you to do anything specific, right? What it does is it gives you tools to build confidentiality into your application and define whatever rules you want for how you deal with this confidentiality. So for example, let's say you're a token issuer and you want to offer a confidentiality for your users. You could, for example, give yourself as the issuer the ability to

decrypt the balances of your users. So users would see their balances. The token ratio would see all the balances, but nobody else on chain would see anything. So this would be exactly the same as like an existing traditional bank, where the bank sees the bank accounts of all their users. You see your bank account, but you don't see other people's bank accounts. So you can recreate TrotFi compliance models on chain using Zama, because it gives you this expressivity in the access control logic of who can decrypt.

to what. And this is a very important distinction because again, if you look at ZK, ZK imposes that confidentiality, sorry, the compliance is on the end user. So every user has to basically provide their own proof that, you know, they're a legitimate user and so and so forth. ZAMA enables the application to deal with compliance on behalf of their users directly, just like any application and finance does today. And so We as a company don't technically offer any privacy feature. Like Zama itself doesn't offer privacy out of the box. It gives you a way to build confidentiality into your application the way you want it to be.

Okay. That's a good answer. So kind of we've talked about kind of like the difficulties that kind of like doing this on blockchain kind of introduces. you said multiple times, Zama can do more transactions per second than Ethereum currently can. Is this just kind of the first commercialization step for you guys? Or are you looking at FHE

for broader Internet use cases beyond blockchain? We do. I think, you know, the long-term vision for the company is that, At some point, the same way we went from encrypting nothing to encrypting data in transit with HTTPS, we will have encryption of data during computation with FHE, something we call HTTPZ. So like you'll have a general protocol for any kind of online application, cloud, blockchain, AI, whatever, that guarantees that the data is encrypted end to end.

But that's going to take a while, obviously, to do, right? And so we think that blockchain is a great segue towards this long-term vision because blockchain needs confidentiality. Like most blockchain applications have not been built because of a lack of confidentiality on chain. Yeah, 100%. Going from past experience, so we last talked two years ago. So we talk again in 27. What do you hope Zama will have achieved by then? In 2027, our goal is to be running on multiple chains, so to bring confidentiality to every major L1 and L2 so that users can start building things anywhere they want.

We want, of course, Zama to have reached multiple percentage points of blockchain transactions encrypted with Zama, I know, 5%, 10%, you know, some step until we get to this 50%. 50% plus. But importantly, I'm hoping that by 2027, people realize that FHE can do whatever blockchain can do and that there's no reason not to use it. I think the next couple of years for us is going to be mostly about proving that blockchain with FHE is much better than blockchain without. Cool. For people who are interested in following you guys or possibly building on the test net or soon in the main net. Where do we send them?

You can follow us on Twitter, X, Zama underscore FHE. And then we have all the traditional social channels. You can also reach out to me directly, Rand, Hindi, R&D, H-N-D-H-N-D. My DMs are open. I really like talking to builders in particular. I'm a developer myself initially. And one of my regrets is that when you become CEO, you don't have much time for coding.

So I try to to keep my minority hat on as much as possible by literally talking to people who are building. So if you're building something and when I talk about it, just reach out directly. Cool. Thank you so much for coming on, Rand. Thank you for having me again.