Zama: FHE and The Holy Grail of Blockchain Privacy

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 FHE
• Zama's confidential blockchain Protocol
• Security guarantees of MPC coprocessors
• Maintaining a healthy operator set
• Slashing and governance
• Zama’s throughput
• Open-sourcing FPGA & ASIC development
• The Zama token & its implications
• Zama’s public testnet
• Private voting
• Zama funding
• Regulations
• Expanding use cases beyond blockchains
• Future goals and expectations

Episode links:

• Rand Hindi on X
• Zama on X

Sponsors:

• 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.io
• Chorus 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.one

This episode is hosted by Friederike Ernst.

Episode Transcript

(00:00):
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 FHE. Today at least Xamas version of
FHE 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 itfor anything from databases to

(00:22):
AI to smart contracts. That's why we decided to build
our own protocol called the XamaProtocol that enables
confidential smart contracts on top of any public blockchain,
L1L2, 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 heading to run

(00:46):
the FHE computation on chain, it's done by what we call a
network of coprocessors 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 Frederica ANZ, and today I'm
speaking with Rand Hindi, who isthe CEO of Zama.

(01:09):
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 1. More than 150,000 delegators,
including institutions like Bit Go, Pantera Capital and Ledger
Trust Corus One with their assets.

(01:30):
They support over 50 block chains and are leaders in
governance or networks like Cosmos, ensuring your stake is
responsibly managed. Thanks to the advanced MEV
research, you can also enjoy thehighest staking rewards.
You can stake directly from yourpreferred wallet, set up a white
label note, restake your assets on Eigenia or Symbiotic, or use
their SDK for multi chain staking in your app.

(01:52):
Learn more at Chorus .1 and start staking today.
Hey guys, I want to tell you about Gnosis, a collective of
builders creating real tools forreal people on the open
Internet. Gnosis has been around since
2015. In fact, it started as one of
Etherium's very first projects, and today it's grown to a whole
ecosystem designed to make open finance actually work for

(02:13):
everyday people. At the center of it all is
Gnosis Chain. It's a low cost, highly
decentralized layer, one that's compatible with Etherium and
secured by over 300,000 validators.
So whether you're building a DAP, experimenting with Defy, or
working on autonomous agents, Nosys chain gives you a solid,
neutral foundation to build on. But Nosys is more than just

(02:33):
infrastructure, it's also tools that people can actually use,
like Circles for example. Let's 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 Nosus Pay.

(02:54):
All this is governed by Nosus DAO, where anyone can propose,
vote, and help guide the network.
And if you want to get involved,running a validator is super
easy. All you need is 1 GNO and some
basic hardware. To learn more and start building
on the open Internet, head to nosus dot IO.
Nosus building the open Internetone block at a time.

(03:16):
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.

(03:38):
I hope that's, that's, that's a fair description.
How, how? How has Zama evolved since since
then over the last three years? Well, that's a good question.
So when we started XAML 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

(04:01):
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, Xama's version of FHE 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 itfor anything from databases to

(04:22):
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 blockchainprojects, for example, Phoenix,
Enco, Sheba are all users of Zama's technology.

(04:44):
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 block chains like Etherium 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 Xama

(05:06):
Protocol that enables confidential smart contracts on
top of any public blockchain, L1L2, 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 theFHE computation on chain, it's

(05:28):
done by what we call a network of Co processors who act on
behalf of the application that'srunning 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 to buildconfidentiality on existing

(05:51):
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 to their specifications.
So tell us about kind of like building this FHE environment on
existing chains and how that works on a technical level.

(06:16):
So the way that FHE works is youtake 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

(06:37):
encrypt all of the data amongst the smart contracts.
Which means you also need a way to do selective decryption
without, you know, 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

(07:00):
behalf of the application. So let's say for example, I want
to do a confidential token transfer, right?
So I want to send you some moneyon 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 chain, and you wantto keep the amounts encrypted on
chain. The way you do this with the
XANA protocol is you deploy A confidential token contract.

(07:23):
So it's just a regular smart contract on Etherium, 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 thebalances.
So, for example, the user shouldbe able to decrypt their own
balances, but he could also start building some compliance

(07:43):
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
fhe 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

(08:07):
Zama coprocessors that basicallysay, 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 tobe done from the actual
execution that is happening off chain in the Zama protocol

(08:31):
operators. And by doing that, it means that
there is virtually 0 slow down on Ethereum itself because there
is no competition happening there and everything is
offloaded to a network of DP operators.
Tell us about that network of Coprocessors and kind of like how
I become a part of this and kindof what the security

(08:54):
implications are for people who kind of use the confidential
blockchain protocol as part of the Ethereum or Solano whatever
stack. There are two components to a
protocol. The first component is the FHE
operators. They do the FHE computation.

(09:14):
Technically this can be anyone because the FHE 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 XAML protocol.
Anybody can publicly verify it. So think of it like any
blockchain protocol, right? It's a publicly verifiable

(09:34):
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

(09:56):
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 todecrypt.
So that MPC protocol, you know, has to hold by definition, like
a secrets, right? The, the, the, the, the like

(10:17):
basically the pieces of the secret key that allows you to do
the decryption. So you cannot have random people
around that because otherwise, you know, well, how do you know
they're not just cheating? So what we did in the Xamarin
protocol is we basically ran an RFQ, right?
So a request for, you know, for operators where people had to

(10:38):
prove that, one, they were able to run infrastructure in a very
reliable way 'cause, 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
Xoma are validators with billions at stakes in other

(11:00):
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 sets of people running the MPC protocol, so 13

(11:21):
operators in the case of XAMA together bring 100 plus billion
dollars of reputation security on top of whatever stake they
put in the XANA protocol itself.And that's really important,
right? Because in the case of Etherium,
you know, I mean, you have what,a million validators, They can

(11:42):
be anybody and it doesn't matterbecause anybody can be a
validator. But for MPC protocols, and
that's true of all MPC protocols, you can only have a,
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, the logic here is that anybody could run an FHE node

(12:02):
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'll lose more money than
they have in XAMA because their whole business would fall down.
Like you know, if I don't know if a Tier 1 custodian cheats in

(12:24):
the XAMA protocol, they're not going to have many customers
left after that, right? Yeah.
Tell us about. So kind of there's thirteen of
these 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

(12:44):
five nodes. We have 13 which is already way
more than anybody has has has 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 of13 to decrypt.

(13:09):
What we are working on now is a way to combine $0.00 proofs with
the MPC protocol so that each ofthe MPC nodes has to provide a
zero knowledge proof that they've done the MPC computation
correctly. And if you do that, you can
actually have even better security because you can have
what we call verifiable MPC. You know, one thing about MPC is

(13:33):
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 9 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

(13:55):
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 thereis no solution to that today.
Just 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

(14:17):
this is unlikely in the catastrophic failure of the
protocol, but what 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 forprivacy, but I guess is.
Yeah. I mean, the question is kind of

(14:38):
like, can they, can they kind ofdivulge 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 if your application uses adecryption of something to
trigger some financial, you know, side effect, then
obviously forging a fake decryption could lead to

(15:01):
triggering the wrong smart contract logic, right?
So one example where this happens is let's say you have a
confidential token and you want to, you know, bridge it to a non
confidential token. So you want to go from
confidential to non confidential, someone has to
decrypt the amounts that needs to be bridged out of the

(15:22):
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 thebridge 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, majority

(15:43):
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 alreadytoday.

(16:06):
So the stake they bring. Is to you.
I, I totally understand that. And I think kind of, I mean, we
have the same thing kind of for multi six, that kind of upgrade
layer tools and bridges and so on.
So kind of like, I, I think kindof like I, I, I just, I, I'm,
I'm not critiquing the setup perSE.
I'm just trying to understand what kind of the, the, the, the

(16:27):
risk landscape kind of looks like.
Well, you see, The thing is thatif you think, 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
way 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 XAML.

(16:50):
The other way is to basically have interactions.
So people just basically do a bunch of of transactions to the
protocol, you know, to basicallycommit their own result.
So that's actually a good a goodexplanation of the difference
between FHE based and ZK based privacy protocols.
ZK based privacy protocols don'tallow you to have computation
and composability on the secret state because you cannot compute

(17:13):
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 basically doing a bunch
of interactions, right? That's OK if the transactions
are simple and everybody's online.

(17:35):
But if people are offline, it doesn't work, right?
You need everybody to be here todo that.
The only way to have composability in an offline
asynchronous manner is to use confidential computing, FHET and
PC, which by definition means you need to use threshold
decryption for the decryption. There's just no other solution.

(17:58):
It doesn't exist. Like 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?

(18:20):
So say I, 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, I sell it or kind of I getacquired or I just decide to
quit. What, what happens then?

(18:41):
Can I kind of like pass pass on my part of the MPC pie to
someone else or what? Do I need a new ceremony?
Yeah, yeah, yeah. We can do what's called re
sharing, which means that you can securely hand over, you
know, or change the NPC sets, NPC participant sets in the XAML

(19:04):
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 who can replace them, in which case
it's just a simple kind of handover that we do based on

(19:24):
epochs. So every X months or whatever.
We haven't really decided this yet.
We effectively look at who has, 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 sometime to prove that you've got
the DevOps capabilities and thatyou're not just rich, but you

(19:48):
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 propose make a governance proposal
asking to. Either penalize or slash or

(20:09):
replace the operator providing some proof that they cheated.
So for example, if you're monitoring the NPC network and
you see, oh, you know, Zama's note has been misbehaving, you
just file a governance proposal on the Zama governance DAO,
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.

(20:32):
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 it was
a software bug that they've deployed or something like that.
And we want to make sure that wecan distinguish between
malicious intent and honest mistake.

(20:55):
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 the

(21:15):
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 doingthe best that technology today
allows us to do. Cool.

(21:37):
Tell us about the incentives forthe operators.
So kind of I'm, I'm one of those13 companies that kind of kind
of takes part in this MPC pool. What's in it for me?
You get rewarded with XAMA tokens, so all of those
operators have to stake and theyget rewarded proportionally to

(21:58):
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, right. Again, you know, the idea is to
have sort of a a competition forwho's providing the best service

(22:19):
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

(22:44):
entities because kind of like inI mean?
Yeah, that's a good, that's a good point.
Yeah, pretty balanced. So we, the Genesis operators,
are based in Asia, Europe and US.
OK. But kind of there's there,
there's not nine kind of there'snot a threshold of nine kind of

(23:05):
like in anyone 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,

(23:26):
they're not within the same country.
So I guess it depends if you consider Europe to be 1
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.
OK, cool. Fantastic.
Then tell us more about the governance that kind of decides

(23:47):
on the slashing policy. So kind of like, say my my data
centre 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, we, we assume that,

(24:10):
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, we expect people to offer 99.9% uptime, then, you know,
someone can say, hey, you've been offline way more than

(24:32):
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 world 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

(24:54):
immediately punishing them. You know, 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
proof of stake, on shame becausethe validators are anonymous.

(25:17):
You have no idea who's participating the protocol.
In the case of Zama, every single node is publicly known.
So you know which company, whichentity is running which of the
nodes, right? So everybody's completely doxed.
And that's why you're able to bring in reputation and off
chain stake as part of the economic security.

(25:39):
And I think this completely changes the way that you think
about proof of stake and slashing because you're no
longer just dealing with some random person on the Internet,
you're dealing with a multi billion dollar entity that has
way more to lose than the protocol.
Totally granted. And then kind of once kind of I
make proposal to kind of slash someone else.

(26:00):
Is it just token holder, token holder or how?
How do how do you decide? Token holder voting basically
with that threshold, obviously, you know, like, you know, you
need at least some participation.
You don't want, 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?

(26:21):
Usual governance related stuff. But again, we keep governance
for critical parts of the protocol.
So operator slashing, changing the rewards, the reward emission
rates, things that materially change the security of the
protocol. OK.
Tell us about the throughput that's Zamar currently supports.

(26:46):
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 beable to do thousands of
confidential transfers per second across multiple different

(27:08):
chains. Right now, we're going to launch
on Ethereum mainnet first. So the first chain we're
targeting is Eats mainnet. Eats mainnet has limited
capacity Zama, the Zama protocolcan already support more
transactions than Ethereum itself can support.
So the bottleneck is not FHE, the bottleneck is blockchain.

(27:31):
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 millisecond order book matching NPCFHEZK.

(27:52):
It just this is just not how thetechnology works, right?
I think for that you need to usesomething else.
Where we see FHE really playing a strong part is anytime you
want to do payments, anytime youwant to do you know, swaps
lending. So I would say not high
frequency trading type of applications, but importantly I

(28:15):
think that FHE 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 ZKT, S&P, CFHE basically right.
FHE is the only one that actually currently offers the

(28:36):
highest level security long term.
So if you want something that ispost quantum 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? Where does that come from?
It was slow a long time ago. I think, you know, most people

(28:59):
have not really used FHE in practice yet, so that's why they
still have this impression. But as I mentioned, you know, we
can already go faster than Ethereum, OK, So granted
Ethereum is not the fastest chain, right?
And I think you know, before SOAMAC and support 10,100
thousand TPS, we still have a bit of work, but we're going to
get there. FHE increases exponentially

(29:20):
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, you know, 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 ACPU

(29:41):
and an ASIC is roughly 1000 X cost performance ratio.
So you know, I'll just give you 1 number.
We've, we've done some estimatesof what we could get on a single
server using ASIC for FHE, right?
So just one box, not multi server, just one box you put in
data center. We could currently get to 80,000

(30:06):
confidential token transfers persecond on a single box with an
ASIC. So you could run, you could run
like, you know, Visa three timeson a single server in FHE if
you're using ASICS. OK.
So kind of currently we're usingCP US and then kind of like you
get a factor of 10 for going to GP US and then another factor of

(30:29):
10 for Fpgas, right. So and then.
Another 10 for ASIC. And then what's, what's the
timeline for this and what are kind of the, the bottlenecks
that you're introducing? No real bottlenecks.
I mean, hardware is hard. It's in the name, right?

(30:50):
So I think, you know, you need quite a bit of time.
So moving from CPU to GPU, we'vealready done that.
So the TFETRS library that we use as a back end for the XANA
protocol works on both GPU and CPU.
We're starting with CPU on if your main Nets, just because we
don't need more than that. We're moving to GPU Q 126 once

(31:11):
we start supporting other chainsthan Ethereum mainnet, so base
BNB, all of these things that require more performance.
And then we're going to move to FPGA.
So we recently open sourced whatwe call the homomorphic
processing units, which is a completely open source FPGA
accelerator for Zama's FHE technology.

(31:33):
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, the ASIC we have in mind is, is a chip as
big as a GPU effectively. So that's very difficult to
build. Most likely we're going to

(31:55):
probably have multiple failures in the process.
So I estimate that is going to be two to three years of work
and 50 to $100 million. It's nothing possible.
It's just like nobody has done it.
So we're the first one to attempt that.
Maybe let's, let's dig a little deeper here.
So kind of I, I think most listeners are familiar with CP

(32:17):
us and GP US, but tell us about what how they, how Fiat
programmer Burgate race. So Fpgas and ASICS, kind of how
how they evolve from that or kind of how they behave
different than a normal GPU. Right.

(32:39):
So CPU and GPU are program like software.
OK. So you write C code and then
that runs the GPU runs that in parallel.
Think of like matrix operations that are can be done massively
parallel. CPU is more, I guess, like
branching logic type of operations.

(32:59):
And FPGA doesn't run software and FPGA, think of it as an
array of gates, very crudely speaking.
And you're programming the gatesas in you're doing literally low
level electronics saying this isan and this is a, this is an or
and I'm going to connect them together with a wire.

(33:20):
So it's almost like you're doingraw electronics, but instead of
actually, you know, printing the, the circuit on a, on a
chip, you're using a, an array of gates to do that.
So it's similar to how you wouldbuild an ASIC, but you don't
actually have to build the ASIC because you have a programmable

(33:40):
hardware in a way, right? So FPGA usually is good as a
stepping stone towards an ASIC. So you build your FPGA
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.

(34:01):
Moving to ASIC, could be, you know, 1-2 gigahertz.
An FPGA typically has a limited size.
It should because there's like aphysical 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.

(34:26):
OK, This is this is a huge investment, right?
And you just set that kind of like the the idea for how to
build this FPGA, you, you open source that.
Yeah, yeah, yeah. I mean, it's everything we do at
XAML, 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 onwhat's running.

(34:47):
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
consensus. 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

(35:09):
better than running a web to cloud service effectively.
I totally granted, I, I, I was getting at the, at the economic
viability of this. So kind of when you say it's
open source, I mean it I, I can,I can view it and I can review
it, but can I also repurpose it?So can I use?

(35:30):
Is it? Does it have a permissive
license? For a non commercial use, if you
want to use it commercially, youneed to get a license from XAMA
or you need to use the XAMA protocol or any kind of XAMA
services, right? So the reason we open source it
is not to make it free, right? We're a commercial company, you
know, we're not, we're not a nonprofit.
The reason we open source it is so that people can see what's

(35:50):
running and not have to trust uswhen we tell them that this is
secure. We, we touched on this a little
bit. Tell us about the Xamar token
and what it does. So can you, you already said
that kind of like the the the entities that are involved in
the MPC, the protocol kind of need to stake them, but but give

(36:13):
us a bit more context here. Right, so there are two type of
operators in the Xamar protocol.You have FHC operators that run
the FHE computation and you haveMPC 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

(36:35):
ZAMA tokens as a reward. Those ZAMA tokens they get as a
reward are based on an emission rate.
So we basically meant ZAMA tokens to distribute to them pro
rata of their stake, pro rata ofthe performance, pro rata, the
kind of work they did and so on and so forth.
So very vanilla kind of emissionreward type of of of mechanism.

(36:56):
So that's the one First Utility of the token.
It's just literally just people participating getting rewarded.
The second utility is paying fees on the user side.
So every time I want to encrypt or decrypt data design protocol,
I need to pay some XAMAT tokens.So those XAMAT tokens are burnt.

(37:18):
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 XAML protocol is based on volume.
So the more someone encrypts anddecrypts, the, the cheaper the
fees actually get for that person.

(37:39):
Kind of like you would expect itin a Web 2 SAS 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 that third is voting on governance proposals,
so slashing operators, changing the emission rates and other

(38:01):
things which would be material to the protocol I.
Mean don't hope this happens, but kind of say Zama for some
reason kind of goes downhill, right?
There's a lot kind of hanging onthese tokens and the token
governance. So as someone kind of like who's
used a Zama based application onsay Ethereum main net, what's

(38:25):
the worst that could happen to me after the fact if kind of say
Zama market cap goes way down and someone buys up, you know,
50% of this tokens to kind of doweird governance stuff for what
kind of, I mean, what, what, what, how exposed am I after
after the fact? That's a good question.

(38:46):
I think this is a generic question about governance
attacks on protocols in blockchain, right?
I mean, there, 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 drainthe 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

(39:10):
just not something that governance manages in our
protocol. So what you could do is you
could slash operators effectively, right?
So you could say, hey, I want toslash this person, I'm going to
slash everyone. So it's more of a denial of
service attack that could happenmore than it would be like an
active draining attack. So there is no financial gain

(39:31):
for you to do that unless you'relike a XAMA competitor who just
wants to take down the XAMA protocol.
But could could I decrypt thingsafter the fact?
No, no, you couldn't. You, 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.

(39:54):
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 will
need to have introduced publiclyenough operators to control the

(40:18):
protocol, right? So like somehow you will need to
have promoted at least nine operators.
That are trustworthy without thecommunity 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? Like if the whole community says
this is completely wrong technically you know they could

(40:40):
also decide to just take the protocol and then move to like a
different set of operators, but 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

(41:02):
time. So kind of like if I managed to
kind of replace nine of them by cronies by kind of and I mean
attacks could be fairly cheap ifkind of like the the the market
cap tax, right. So if if I managed to kind of
subvert, but the thing it's the securities also compromised
backwards looking not just forward-looking, right?

(41:25):
Yeah. But I mean, think about it
logically though, right? If the market cap is so low that
you can just buy up, you know, a51% of the supply or whatever,
right, then it means by definition that there is no
activity on the XANA protocol. Like there would be no
meaningful amount of money in the protocol at such a low

(41:47):
market cap. Like I don't think we've ever
seen a protocol with billions inTDL that has a 10 million market
cap. So I think there is a bit of
like a, if the protocol is successful and worth 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. Either protocol is cheap to
attack. It's probably useless anyway.

(42:09):
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 TBL is
not a good indicator of how muchreally is at stake, right?
Because I can also, I can also kind of make an attack on value

(42:31):
that's already been processed inthe past that's no longer kind
of in your TBI measurements. Well, the way that we measure
TDL in this, our protocol is howmany, how much money is in
confidential tokens. OK.
So that's, you know, I mean it's, it's not TDL in the sense
of D5, it's not like swapping orsomething like that.

(42:53):
It's TDL in the sense that you have, let's say a stable coin
and then you have a confidentialstable 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

(43:14):
money, they're not going to be running design protocol and
design protocol is going to shutdown.
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 attacks 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

(43:35):
an operator is pretty high. And we're talking, you know, 50
to 100 KA year for an MPC node minimum for an FHE node is more
than that even. Like so you wouldn't really
invest this much in infrastructure unless, you know,
there was profitability in the protocol.

(43:55):
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. OK.
Maybe let's move on just a little bit.
So you're currently live on testnet, right?
So who's building on that publictest net at at this point?

(44:22):
A bunch of people. Xama itself actually has
multiple, I would say apps that we're building internally, kind
of like, you know, when when youbuy 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.

(44:43):
When the Xamar protocol goes to main net, it's not going to come
empty. It's going to come with a suite
of Xamar apps. So for example, we have a, an
app that allows you to run tokenoptions 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

(45:06):
a company who's building a self custodial bank on chain using
confidential stable coins as theassets 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

(45:27):
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 the current

(45:50):
ecosystem, that's for sure. I know you've also talked about
private vote 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 sealedbid, sealed bid auctions we're
going to do for sure because I think this is a cool use case.

(46:11):
Confidential governance voting. So we are not the governance
like we, 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.
It's going to happen. Like I think when people realize

(46:31):
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? HTTPS in the beginning was
expensive to do encryption. It was difficult to setups.

(46:53):
Nobody used it. You know, I think it was 13% or
14% of Internet traffic was encrypted with HTTPS 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.

(47:14):
We're going to go, we're going to get to a point where the
vast, vast majority of blockchain transactions are
going to be encrypted because why not?
Like 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 on encrypted data in a publicly verifiable manner,

(47:38):
that's what FHE does, then you could actually have public
verifiability without having thedata publicly disclosed to
everyone either. And I think this is a very, very
important thing that just wasn'tpossible at the time when
Ethereum launched. Yeah, 100% agree that the the

(48:00):
transparency is not not a feature for most applications.
You recently closed a pretty bigSeries B round, so you raised
57,000,000. How does this change your
trajectory or does it kind of make a lot of the things that we

(48:21):
already talked about initially possible?
So things like doing mighty yearresearch for building an ASIC
and so on. So what, what where?
Where do you plan to spend that money?
Exactly what you said, multi year research projects.
So so XAMA has consistently beenkeeping a multi year runway.

(48:45):
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,

(49:08):
the majority of blockchain transactions are encrypted using
Zama's technology through the Zama.
Protocol. Sorry, how much percent?
What percentage? The majority, the majority, even
10%, I'd be happy as a starting point, but let's say, you know,
I'm the majority whether it's through Zama's protocol or
through one of our partners who are licensing our technology,

(49:30):
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 of these
things. And so this funding really goes
towards that. So even if XANA makes no

(49:51):
revenue, which is not the case, even if our token goes to zero
and we make 0 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, so we don't have to worry about any kind of world

(50:15):
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

(50:39):
regulatory side kind of transparency has been pushed
more and more and kind of won't regulate as kind of bark at
financial apps that are inherently private and cannot,
cannot be forced into disclosure.

(51:02):
I think when you think about compliance, this is actually one
thing. I think the XAMA protocol is
very strong out is the Xama 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

(51:25):
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 issuer wouldsee all the balances, but nobody
else on chain would see anything.

(51:46):
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 track FI compliance models on chain using
XAMA because it gives you this expressivity in the access
control logic of who can decryptwhat.

(52:07):
And this is a very important distinction because again, if
you look at ZKZK 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 on so forth. XAML enables the application to

(52:27):
deal with compliance on behalf of their users directly, just
like any application in finance does today.
And so we we as a company don't technically offer any privacy
feature like Xama itself doesn'toffer privacy out-of-the-box.
It gives you a way to build confidentiality into your
application the way you want it to be.

(52:49):
OK, That's a good answer. So kind of we've, we've talked
about kind of like the difficulties that kind of like
doing this on blockchain kind ofintroduces you, you said
multiple times kind of Zama can do more transactions per second
than than Ethereum currently can.

(53:12):
Is, is this just kind of the first commerce commercialization
step for you guys or kind of areyou looking at FHE kind of like
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, you know, the

(53:33):
same way we went from encryptingnothing to encrypting data in
transit with HTTPS, we will haveencryption of data during
computation with fhe something we call HTTPZ, right?
So like you'll have a a general protocol for any kind of online
application, cloud, blockchain, AI, whatever that guarantees
that the data is encrypted end to end.

(53:55):
But that's going to take a whileobviously 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.

(54:16):
So we last talked two years ago.So we talk, we talk again in
2027. What do you hope Zama will have
achieved by then? In 2027, so 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

(54:39):
start building things anywhere they want.
We want, of course, XAML to havereached multiple percentage
points of blockchain transactions encrypted with
XAML. I don't know, 5 percent, 10%,
you know, some, some step until we get to this 50% plus.
But importantly, I'm hoping thatby 2027 people realize that FHE

(55:03):
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

(55:25):
the main net, where do we send them?
You can follow us on on Twitter X xama under score fhe and then
we have all the traditional social channels.
You can also reach out to me directly Rand Hindi RNDHINDI.
My DMS are open. I really like talking to
builders in particular. You know, I'm, I'm a developer

(55:47):
myself initially. And one of my regrets is that
when you become CEO, you don't have much time for coding.
So I, I, I try to, to keep my minority hat on as much as
possible by literally talking topeople who are building.
So if you're building something and want to talk about it, just
reach out directly. Cool.
Thank you so much for coming on,Rand.

(56:08):
Thank you for having me again.