Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Aztec's Rebirth, The $61M Token Sale & Programmable Privacy on Ethereum

Episode Date: December 18, 2025

Fresh off the launch of the Ignition Chain and a successful community-led $61M token sale, Aztec Network co-founder Zac Williamson joins Friederike Ernst to unpack the "existential" journey of building programmable privacy. Zac opens up about the "sacrificial altar" moment where the team decided to kill their live product, Aztec Connect which had 60k users because they realized true decentralized privacy required rebuilding from scratch rather than iterative upgrades.They dive deep into the architecture of the new network, which utilizes a hybrid state model (encrypted UTXOs for privacy, public accounts for transparency) to enable composable applications. Zac challenges the cryptographic dogma of "don't roll your own crypto," arguing that for pioneers, relying on "battle-tested" libraries is impossible. He explains why decentralized sequencers are not just a moral choice but a security necessity to prevent government-mandated backdoors. Finally, Zac contrasts the chaotic but decentralized resistance to surveillance in the US with the increasing top-down control in the UK and Europe, framing Aztec as essential "defense in depth" for the digital age.Topics00:00 Intro 03:45 The "Sacrificial Altar": Killing Aztec Connect10:15 Hybrid Architecture: UTXOs vs. Accounts16:30 Why You Must "Roll Your Own Crypto"22:00 Decentralization as a Defense Against Backdoors28:15 Performance: Throughput & Latency Trade-offs34:40 Private Smart Contracts: Gaming & Identity41:00 The Macro View: US vs. EU SurveillanceLinksGnosis: https://gnosis.io/Zac Williamson on X: https://twitter.com/Zac_AztecAztec Network: https://aztec.networkNoir Language: https://noir-lang.orgSponsors: Gnosis: Gnosis has been building core decentralized infrastructure for the Ethereum ecosystem since 2015. With the launch of Gnosis Pay last year, we introduced the world's first Decentralized Payment Network. Start leveraging its power today at http://gnosis.io

Welcome to Epicenter, the show which talks about the technologies, projects and people driving decentralization and the blockchain revolution. I'm Friedrich Erz, and today I'm speaking with Zach Williamson. You're not going to launch this thing without decentralization, right? Kind of like you want a decentralized sequencer and approvals. We're not doing this out of some moral crusade. We're doing it. We're decentralized because we need to be. We can't be centralized.

We'd have to build in a backdoor. We don't want to build in a backdoor. Backdoors are really bad. You want to use things that are battle tested as much as you can, right? Building novel things kind of means having to build new systems, but trying to possibly fall back on proven systems. There's no such thing. There is a big feedback.

We are the first. Ashton will be the fallback for future generations of private cryptography. Once we can't beater, we'll be much more comfortable making claims about it security. We'll be much more comfortable with people putting large amounts of funds in. But until then, it's going to be a risky protocol. I'm Friedrich Ernst, and today I'm speaking with Zach Williamson, co-founded and CEO of Aztec, a layer-2 network building what it calls programmable privacy for Ethereum. So Aztec was once known for private transfers, but a couple of years ago, the team did something that very few projects actually dared to go through with. They shut everything down and rebuilt from scratch.

The new Aztec promises fully private smart contracts, not just private balances, but private logic computation identity, while still remaining compatible with Ethereum's public ecosystem. We'll dive into all the details in just a bit. This episode is brought you by NOSUS, building the open internet one block at a time. NOSIS was founded in 2015, and it's grown from one of Ethereum's earliest projects into a powerful ecosystem for open user-owned finance.

NOSIS is also the team behind products that had become core to my business and that of so many others like Safe and CowSwap. At the center is NOSIS chain. It's a low fee layer one with zero downtime in seven years and is secured by over 300,000 validators. It's the foundation for real-world financial applications like NOSIS pay and circles. All this is governed by NOSISDAO, a community-run organization where anyone with a GNO token can vote on updates, fund new projects, and even run a validator from home. So if you're building in Web 3 or you're just curious about what financial freedom can look like, start exploring atnosis.io. Zach, thank you so much for coming on again. Thank you so much for having me on it. It's a pleasure

to be back here after all these years. Yeah, absolutely. Yeah, you were last on Epicenter when Aztec was still running its earlier version. Tell us what's happened since. Yeah, so back then, I think we were on Aztec Connect, which was a continuation of the Wells First fully private roll-up. So it was a layer-to-network where you could send private transactions and use our network effectively as an anonymous proxy into Ethereum Defi. So you could talk to something like a Uniswap or an Arveh contract and have the Aztec. Smart contract act as your proxy. Then the result of that defy interaction would come back into the Aztec network and then you could take your claim of it privately.

So back then, that was the most advanced thing we could do with the technology that we had available at the time. Something we called turbplunk was an extension of the original Planck paper that we put out in 2019. But that was

the Ashtick was never really the full aspirations of the network. We built it because we wanted to demonstrate that privacy was possible and useful and needed. What we've wanted to do all the long was create a private smart contract ecosystems. So one where instead of just doing transfers or talking to Defi, you know, you have

a sharing complete smart track language where you can write your own state, your own state transition functions and describe the logic of whatever protocol you desired, but with private data as a first class primitive. So yeah, that's what we just, that's what we decided to build, I think shortly after our first conversation. Why did you decide to kind of rebuild this completely, instead of just iterating on the old system. Because, I mean, obviously, people were already on there. People were using it. That would have been nice.

I think it was 60,000 multi-active users. It was growing quite rapidly. The challenge was that SDAQ-Kanex was built from scratch with the latest technology we had in our disposal. No one had really built a fully private roll-up before. So we were figuring out a lot from the first time. And in hindsight, we made a lot of architectural missteps that we wanted to correct.

We didn't really have a viable path to iteratively upgrading our set connect to add programmability into it. Everything changed. You know, the semantics of how you call create transactions, the cryptographic proving system that you need to use, the node software

and its interface and its API. We quickly realized it was, what we wanted to build was unrecognizable compared to what we already had, and that we needed to take those learnings and that institutional knowledge and recast it. But we didn't see a viable pathway to iterate as to connect, unfortunately. Tell me about the moment that you guys realized this.

So kind of obviously kind of as a builder, as a founder, you get attached to what you've built, right? Kind of like it's your baby and kind of like the users kind of, you feel close to them, even if you don't actually know them personally. You are somehow indebted to them, right? So kind of you have some. sort of. So tell me

how that went down. Yeah, I still feel like pain of guilt whenever I talk to somebody and they say, hey, I use SaaS Connect. I'm like, I am sorry. That I used SESA connect. So. It was tricky, you know. It started with we had some internal conversations. Basically, there was this

inciting incident where we made some research breakthroughs that made the full programmable version possible. And it was an evolutionary process. You know, a lot of brothers also spent maintaining there's no software. We didn't really have the ability to really launch this what we were calling ASTC 3 project. You know, there were some people, we were having discussions. So people were like, hey, like, maybe we need to kill this.

Then that started turning into, internally, quite, quite an active discussion. And yeah, like, eventually it was, ended up this me and Jernar in the coffee shop, having a very long conversation about the future, about what we wanted to do. We came into a agreement that, yeah, we need to, there's no way that we can serve both ASTEC connect and ASTX3. needs to go and and it should be asked to connect. But it was a tough conversation. Which one of these kids do you think we should kind of put up for adoption sort of?

Yeah. Yeah. You know, everyone says they love their children equally, but maybe deep down there's like one of them is a secretary. We don't want to acknowledge. And then we're like, yeah, okay, one of our kids needs to die. Repair the sacrificial also. Okay, maybe maybe let's move into kind of like more teary territory.

So one of the kids is somewhat alive again. So tell us kind of like what's what's live now and what's still being built? We're calling ASSEC now. We're releasing it's not ASSEC 3 anymore. And it is alive. It's on public test net. It's fully decentralized. You can deploy contracts to it today, send transactions to it.

I think it's is it Playgrounds.isag.network, I believe. And we are currently going to a audit process and doing some last. minute adaptations to it, to get it ready for main net, which should be happening early next year. Exciting. Very alive at kicking. You know, like now, now we're, the main focus internally is basically focus on the DevX. We launched the test net earlier this year. And, you know, we're basically transitioning the company, the organization from a place where

the goal was just get it working. Whatever it takes, just get it working to one where a mandate now, we need to make a good easy to use for, use and develop for. So that's still working for a guess, but by the time we hit our launch next year, that should be all squared away. Fantastic. So maybe let's talk about the way this thing is architected. So kind of there are a couple of core design choices that you guys had to make.

And I think maybe it's easiest if we kind of walk through them one by one. So kind of the first I noted down as kind of decision to kind of have a high, hybrid public and private execution situation. Tell us about that. For sure. Yeah, well, that came out of, again, I think Aztec Connect was existentially important for us, because this came out of ASTEC Connect,

like a learning that we were like, we realized, okay, so with private state, the way currently is at least if you don't have FHU, if you don't have announced FPC, like Taseo's stuff, which we do have, but at not yet like critical level. At the critical level, all private data is encrypted, and you need to use a UTXO-based state's model to do that, like Bitcoin,

where instead of having an account where you have a guill balances that can be modified, you have individual discrete objects of state in your database, and these things have owners, so that your balance, your token balance is made up of lots of these different notes in your database. The reason you need this for privacy is because if I have an encrypted balance and you send a transaction that changes my encrypted balance, well, if that balance is just one piece of data in the network database, then you can see it change, and therefore you can see it change,

And therefore you can see the transaction growth. You also need the entire state, right? Because kind of like in an account model, you don't actually have the account balance noted down anywhere. Kind of like you actually have to walk through the entire history of the state in order to kind of arrive at. You do, but in an account-based model, you still in the state tree, you do have like a state variable.

Yeah, a state tree. We'll have your balance. Finding it might be tricky. But if it's that. And so when a transaction changes it, you can see that. and that's not okay if you're private. So instead we have a, you know, we have the model that really is Zcash and zero coin propagated,

where you have individual bits of state. They're encrypted by an owner, and they can be created or they can be destroyed. And that's how you modify them. You destroy it and then you create something new. The reason why we do that is that the records of destroyed notes and the records of created notes, you use different encryption algorithms for them,

so you can't, so that an observer can't link the two. So if I destroy two of my notes, create two new notes, maybe one of those owners owned by you, one of them was owned by me. The only thing an observer can see, if they look at the network, is that two notes were created, two notes were destroyed, but they don't know what they are, and they don't know how they're linked. Therefore, it's private.

But if it's private and it was encrypted, how do you do global state? As in, you know, take Unisop as a smart contract. If you have an AMM, a liquidity pool, well, you need to know what's in the liquidity pool so that you can perform your liquidity calculations. And like a token, which has a total supply, how do you update that? If everything's owned by somebody who holds a decryption key, you can do it via NBC, you can do it, which is very challenging. Or you can kind of skip the problem entirely by having this hybrid statement where some information you can make private and some information you can make public.

So in this context, the simplest way on Aztec to make an AMM is, well, you make the AMM fully public. So you can see that the token values going into the market. you can see the trades that are happening, but you can't see the identities of the participants. So I could put some USDC into an AMM, take out some eth, and people can see what the prices, but they don't know it's me.

In many ways, that kind of system can get you the best of both worlds, where you get privacy for the user, but transparency for the protocol, which often can be very important to understand that you've not been cheated, you've not been manipulated. But you can,

Sorry, I'm rambling here a little bit of a bit of monologue. With advanced MPC shared state primitives like Tatsaya, which is present on Aztec, you can create fully private contracts if you desire it. It's just right now the infer to handle that is less built-house than it will be in a couple of years. I understand that there are public contracts and there are fully private contracts. Can I build something that's in between, so kind of that I can kind of share with a select group of people? kind of like my own AMM poor that I only allow my besties to kind of trade on sort of thing. The code for private contracts does not have to be published.

You need the code if you're going to send a transaction, but it's not published by default. So if you want, you can just share that code with a selectry group of people, have a white list so that you can basically have this completely isolated, sweet as smart contracts within the arcing network that nobody else knows about. I don't think we've actually added it as a premise of yet in our protocol, but it will happen in an update where you can encrypt smart contracts so that you don't just need the code in your description key if you really want to go that direction. You can also have hybrid systems in another way where you can have a single smart contract that has both the public and private functions. So a canonical token contract is like this where you can shield tokens, but you can also unshield them and you can send them around publicly. And if you want to go even further, you could only share the private parts of your contract with a select few people if you really wanted to.

Okay, walk me through. I mean, so at the face of, it's kind of like it sounds very sensible, but kind of as an engineer, it sounds tremendously complicated to kind of construct something like this. Walk us through kind of the challenges and the solutions that you found to them. Oh, so many challenges. Because it's not just the difficulties of building it, but also it's creating abstraction layers that.

allow building on it and for it to be relatively easy and straightforward. The goal is that for any Web 3 engineer to be able to write into play smart contracts. You don't need to know cryptography or weird, weird complicated semantics around primacy. I mean, I guess the very first problem was just technological, is in if you have private transactions, then each transaction itself is a zero-nostic proof. And so how do you make that proof? Because, you know, normally if you look at things like the ZXE paper and early attempts at creating private transactions.

They're very unintuitive to a developer or engineer. The idea is there is that instead of having a code that modifies state, you have state that comes attached with some code, which defines how that state variable is created or destroyed. That's how it used to work. And it's like, it's not intuitive, it's messy. So we needed to take those models that existed in the literature that you could create SNOC.

seconds for and actually go, okay, no, no, no, we want contracts. And those contracts can call other contracts, and these contracts can manipulate a database of arbitrary state. How do we do this? How do we do this? So we had to come up with some very novel cryptography to actually pull this off, because if you have a bunch of contracts all written by different people, they all have different verification keys. You basically, one transaction that calls lots and lots of contracts is effectively large numbers of zero-nolged proofs that needs to be recursively composed together. You need to handle large amounts of data transfer between these zero-nological proofs. Effectively, you know, You've got algebraic circuits that you're trying to pretend are iterative programs.

And creating a ZK-proving technology that can handle that was very, very challenging. But that was just the first step one. Then on top of that, you know, we needed to come up with an ABI from scratch about how to interpret this stuff. As in, you know, you have a private function call. It's got a bunch of public inputs in your zional circuit. You need to interpret those inputs according to some ABI so that your protocol level circuits can figure out what to do. We need to undertake to figure out how our state treaties worked. Even that was non-trivial. How do you do events in an encrypted way? How do you do state sharing

efficiently? So if I, you know, technologies like Zcash, I think they've made improvements recently, but back in the day, same with Asta Connect. If you wanted to sync to the network, you need to download every single piece of encrypted state and try to decrypt it yourself to see you owned it. That doesn't scale. So how do you create a world where I can send you a note where that note doesn't necessarily represent tokens that represents arbitrary state in the smart contract and you know that this has happened

and you can decry that information without having to sink to the entire network. Again, like that's an open problem. It's until we have much more advanced FHE solutions, there's always a tradeoff fair in terms of privacy.

So figuring out where to go on that tradeoff was very challenging. Yeah, as just as the start of it, you know, then there's how do you, even basic things not associated with privacy. Like how do you decentralize an L2 in the network. That's actually, there's not a huge amount of work on that

in the public domain. We had to figure out a lot of that ourselves. You know, eventually we even realized for our particular needs, we needed to build in a very small data variability network into our layer two in order to secure certain libelous guarantees. Yeah, it's been very challenging. There's a reason it's taking us so long to build this.

One thing that we haven't yet touched on or you very briefly kind of glossed over just now is that not only kind of did you not want to make compromises in the privacy realm?

You also told me back kind of like when I last said you're on, you're not going to launch this thing without decentralization, right? Kind of like you want a deceditorized sequencer and provoers. Even if you kind of look at L2B now, even the non-incrypted L2s

haven't come a very long way there, right? So tell us what you learned on that. Again, it's all about fun of metal and sentence, you know, we're not doing this out of some moral crusade, we're doing the decentralised because we need to be. There's the same reason why, if you take the internet and HTTP, you know, where now all requests to website to a server, they're all made encrypted, they're all encrypted, they're all encrypted, the responses are encrypted.

If all that traffic flow through one company and one company servers, they would be the most over-regulated company in existence, you know, because everyone, every, every government agency is we engaged with them going, hello, I would like all your information, please and thank you, please, please, to crypt it all. reason for Aztec. We can't be centralized, not without, we'd have to build in the backdoor. We don't want to build in a backdoor. Backdoors are really bad. So we need to be decentralized where it is a genuine distributed network made up of thousands of different participants that are all collaboratively participating in this network. And so we're one of the few networks

that genuinely has an incentive to decentralize. Most layer two's decentralization is actually corrosive to their interests because if you're an EVM, either a ZK one or an optimistic one, your unique value proposition is price and throughput and latency. Basically cheap transactions, lots of them instantly settle. I would kind of, I would contest that, I think. So kind of in kind of because in the failure case, that kind of kind of like someone, God forbid, compromise the one multisic that you kind of use to kind of govern URL to kind of all that value that's kind of protected. and is potentially gone, right?

You're talking about security, which is not a value proposition. It's basically, it's a protective technology. And to be very cynical from a minute, if you look into traditional web to judicial software, how often do companies invest in their security? Like, not very, if you can spend money to make money or you can spend money to potentially not lose money in the future, you know, the monkey brain goes, we make the money,

we don't, we don't protect our, we don't protect future. I'm not saying we have this culture. I'm just saying that this is very common. But you're right that there is a desire to decentralize for that security reason. But it's corrosive to the bottom line for... 100%. Yeah. I mean, basically, best business model is being AWS. Yeah. Yeah. How decentralized are you? Or your decentralized nose around on AWS.

This is a genuine thing we're covering and wrestling with. But yeah, like, you know, if you're at ZKL2, decentralizing makes your costs go up, right? Your transaction latency increases, your throughput, like the network throughput decreases, the GPS load goes down. So there's a very low desire to actually make it happen, whereas for us, we need to make it happen. We can't survive without it. And so we discovered a few things,

like even our protocol to select sequences is somewhat novel. There wasn't anything off the shelf that we could take. And you'd think you'd do that wouldn't be figured out right now. You have a bunch of people who want to produce blocks on an L2.

They're staking on L1, how are they selected? You do that get started, but it's not. Well, there's many different views. Then there's just, you know, we've had to do a lot of work on the peer-to-fay networking side, which, again, is a bit surprising. We couldn't use anything completely out of the box, we had to do a lot ourselves. But the most interesting one for us was a unique characteristic of Aztec, which is that

ASIC transactions, an individual user transaction contains within a to zero knowledge proof. You have your transaction data, which describes what you want to do, which will be encrypted, but that's fundamentally it's still there. But then you have the proof that comes along with it going, my state transitions are all correct. I followed the rules of your protocol. And in our roll-up blocks, we effectively swallowed that proof data, right? If you're making a proof of an Aztec block, you are inside your ZPIC circuit, you're verifying all of the individual transaction prints, which means when you publish the roll-up

block, you don't need the proofs anymore, that you need the proofs to make the block, to make the block proof. And we had this dilemma because we did not want to publish the transaction proof data onto L1, because it's large, and that's expensive. And I'm thinking, well, we don't need to publish it if, Every block comes with proof. The only challenge is you need your proveer. So you have a statistic to take you to you to read block producers and block provoers, right?

The block producers are making the block. If they're not publishing the user transaction data onto L1, you need to guarantee their data exists for about 20 minutes so that a block prover can still make that block. And so we're like, oh, God, we need a DA layer to make this happen. Like, we need a 20-minute DA layer. It's not the most impressive thing in the world. It uses some basic economic consensus,

but we had to build that out to make our LTO a reality. And that was an interesting detour we weren't expecting. So what we've kind of tried to cover and mostly glossed over because there's a lot of it is incredibly a high level. So maybe let's kind of take it down two notches. So imagine I'm an entrepreneur building on Aztec. So what choices do I have to make that differ from building on a more standard roll-up like base or Arbitrum? Yeah, so if you're able to look on Aztec, I think there's going to be an assumption that you desire some kind of privacy in your app or you want to interact with private accounts. What different choices are you going to make?

Well, we do have to learn a different programming language and a different technical stack. We figured the semantics around private sale on the blockchain are sufficiently distinct that we needed to go the route of creating our own language. To make it to basic so that we could create the abstraction layers that we thought would be appropriate to minimize the complexities of something. campus. It's called Noir, and it's basically, it's heavily inspired by Rust. So if you know Rust, it'll be very intuitive. If you don't know Rust, it's still pretty, it's still easy to pick up. You know, it's like any low level programming language. There's going to be a certain, you know, custom, well, as I said, somatic keywords that you have to learn in terms of, you know, how this, how state is, how to create the state, right, storage slots, how to how to, how to,

how to manipulate them when it comes to private stuff. But, you know, our dox. are constantly improving. I think hopefully by the time that this is broadcast, there'll be, our latest docs will be, we're going through a documentation revamp, so hopefully that'll be done by then. Yeah, so, you know, but the forms of what you're doing should be very familiar. You know, there is a node that you can install to send transactions to. That node has an API that you can interact with. You know, you can write contracts, and there's contracts. You can define an API that's your node users to get data, and you can connect this all to, you can communicate all all of this with a JavaScript wrapper if you want, so that you can write a web application.

So the forms of it all are very similar. The details will be slightly different because the state model is different. You know, like we have public and private keywords in our contracts, which mean they're not visibility specifiers like normal in a regular programming language. They really mean like this, this can be seen by the observers or it can't be seen. And then, you know, these cut functions can call other functions and you can commit events. You can, you know, do all the similar stuff you expect from a contract. system. This is a few more, a few more keywords that you have to think about because of the public-private thing. Okay, but so kind of the way that I should think about contracts and gas

and wallets and user interactions and so on, that doesn't really change. That doesn't change at all. Okay. It's all the same. We have L2 gas, we call it a fee juice. You know, yeah, you know, we have wallets in production. The idea is to basically mirror all of the concepts one would be familiar with already in about three. Seeing that kind of I have to learn a new contract language,

that doesn't particularly dawn me. So I'm a physicist by training, which means kind of I'm a terrible programmer, but I'm a terrible programmer in many languages.

So I'm not put up, put off by this. What kind of application do you think it would make sense for me to build first? So kind of which ones do you see where

kind of privacy is actually a cool feature rather than an afterthought. I think what I'd like to talk about next is kind of performance, so kind of like the trade-offs you kind of make for this. So yeah, I'm also ex-physicist so I can relate.

Hopefully over the years I've become better at Saturn Programme, so you've been analyzing it code for Aztec? What do you mean? I can't do this in Python. You can do everything in Python. Yeah. Well, in my case, Fortran. Oh my god, that's You don't look old enough for this.

This is just going to be kind of backwards, you know. This is true. This is true. We can be very backwards. The applications that make sense are varied, but generally they will revolve around two things. Either you will need an understanding of a person's identity that requires disclosure of sensitive information. Or you want to, more broadly, you want to create an application that's based around information asymmetries. You want an application where you're interacting with somebody, a third part, like a counterpriced. and your counterparty knows stuff you don't, and you know stuff your counterparty doesn't, and you don't want to disclose it. I know that's very vague.

Some of the low-hanging fruit for that is games. To give an example, the original breakout NFT from 2018, I think was Crypto-Kitties, which was all about, you know, you have these cats and you can breed them. You can combine other cats to create new cats with different traits. And back then, what they relied on was code obfuscation, basically. They didn't publish their source code. And so it was hard to figure out ahead of time what... how to breed cats get the optimal design tricks. Nowadays, that won't work.

That kind of stuff gets instantly reverse engineered because the overall skill level is much higher. But you could use privacy to actually make sure that you couldn't know. You could use things like Randall and some randomness to basically make it so that only at the conclusion of your transaction will you understand exactly what traits you're getting, what algorithm was run. I like where you're going with this.

So kind of like when I ask you, so what do you think is the most pressing application? to build on top of this. Oh, but we can we can breed private crypto goodies. This is fantastic. You did not say most pressing. Sorry, sorry. Is this going to solve all the society's problems?

Absolutely. It's relevant. And this will be, there will be demand for that kind of thing on chain. No, I think kind of like games, in principle, kind of like old school games, I think they're actually pretty good examples because they actually use very little state. kind of like if you look at kind of like these 80s arcade games, kind of like they're tiny. So kind of running them in this kind of environment.

I totally see where you're coming from. More useful stuff would be for web free native utility would be some basic identity protocols to protect against civil, to make for civil resistance. Basically, prove of uniqueness so that you can do things like adjobs that can't be, you know, farmed by somebody pretending to be a thousand different people or if you want to do a sale of tokens, for example, and you want to ensure that it's only one person coming to purchase or governance. So let's say you want to do a

vote on the Dow, but you want to use quadratic voting, where the more tokens you have, like the less, the marginal, like voting power of your additional tokens. There, again, you need civil reasons. You need to ensure that one voter, like that Keloady vote wants instead of pretending to be 100 different people with smaller balances, because then, because otherwise you can gain quadratic voting. And so civil protection, basic identity protocols, I think will be very, very valuable, things like ZK Passport. Then that can be expanded to do finance. That is existing in regulated spaces. So if you need to prove somebody's not on a sanctions list, for example, or maybe you need to prove transaction limits so that somebody is not transacted above a certain thresholds in a time period, or you need to know that somebody's resident in a certain country, things like that, where you can basically add in identity credentials to build out DFI protocols that.

that interacts with assets that are more originating in the real world. And again, I think this is also one of the reasons why one of the original use cases of NFTs didn't take off. NFTs originally, people were like, well, why aren't these useful? Tickets. You know, because Decatur and Laster is, charges very high fees. Ticket technicians, Tarsak, it's like, well, why can't I get rid of them well? Because one of the reasons is that, to make that work, you need to link an identity to a

cryptocurrency account in a transparent world. If you have identity protocols, that's not a challenge. thing to do. I 100% concurred that that would be incredibly useful and kind of like barring kind of like all potential attributes of your person to

kind of like whoever you want to buy a bottle of wine from. Obviously it doesn't make sense. But if you look at the way that these regulations are drafted typically proving that you are above

18 doesn't cut it. So typically you kind of actually, as the person selling the bottle of wine, you actually have to have some sort of copy. So how do you get around that? Well, a couple of things here. First of all, there's very, there's a lot of value in adding identity to things that are not, it's for functionality, not regulatory. Yeah. Things like, you know, civil resistance for adjobs. Then there's basically, I think the more mainstream, your use case, the more unnecessarily, uh, overregulated.

comes. To be fair, like, you know, these regulations were not drafted by people that knew about zero knowledge proofs. So the idea, you know, when people were drafting here, like proof of age laws, you know, God knows when in 1950s, right, like the idea that you could prove your age without seeing, like, I, as me, I'm selling wine, I know somebody's 18 without actually seeing some identity. That was just inconceivable to them. So I do think there's a, you know, there's some advocacy work that we're doing. I do think that's, legislators, politicians are, they are actually becoming more aware of zero-knowledge-proops. And this will change.

I do think there's plenty of regulations that are actually very amenable to zero-knowledge-proofs already. Things like using ZK passport, a particular passport proofs because e-passports are already a thing. There's already precedent for them to be used in things like passport gates. There's already a well-established understanding that these are very strong credentials. You also have a lot of precedent from the document-signing world, digital signatures on documents can be as good as the real thing. And so you can start it, you can kind of combine these precedents to make claims that some of these on-check, some of these ZK-based identity solutions are good enough.

Yeah, I mean, if DocuSign can kind of check that box, then obviously, I mean, kind of like that, there was some impressive lobbying going on there to kind of make anyone, anyone agree that this is kind of definitely the same thing as signing something in wet ink, like clicking, yes, this is my name. Yeah, and I think, I mean, different jurisdictions will progress at different speeds. You know, for example, the US has already in the process of passing, several crypto regulations, the Genius Act, there's the Crypto Markets Act. He's got a fancy name.

I can't remember what it is. Europe will be much slower to be very blunt. We're not really like... We always are slow. If you want to do some advanced enterprise privacy stuff, we're not talking with the people right now because Europe will be very slow. Nevertheless, there is value there. There's some things you can do within the existing frameworks, but really it's America's taking the lead.

There was an opportunity for other countries to take advantage of America's conservatism under the Biden administration. My country, among them, there were many voices advocating for what could be done and the value that could be generated. And now these countries will deal with the consequences of an action. The economic center of gravity for crypto will be America. And that's just the way it is. Tell me about the performance trade-offs for programmable privacy. So it's kind of like what's the bottleneck right now for performance? Is it the proving or what kind of constraints me?

Proving is proving is more the user experience bottleneck than a performance bottleneck because your user makes the proof, then they send it to the network. But when it comes to transaction through ports, the amount of time it takes for the user to make the proof doesn't really matter because you can have large numbers of people making proofs at the same time. For network throughput, right now we are targeting for our very first release on the Ethereum main net. We're targeting a whopping 2tPS, which doesn't sound like much. However, if you look at the throughput of existing L2s and how much they're being used, 2TPS is actually quite more than enough. It's fine. And over the next 12 months at post-launch,

will be scaling up to 100 TPS. Some of the bottlenecks are, well, there's a lot to prove in a roll-up, in a Zika roll-up, particularly because we have something I didn't even mention until now. We have a public virtual machine, a ZKVM. So for all the public things that you're doing, like public functions, public trace transfer transfers, they're all proved via ZKVM that's proven server side. Either there's some performance challenges there, particularly with like how much can be parallelized, how much can be serialized, how much is serialized, how much is serious,

We have issues with our peer-to-peer network throughput, bandwidth throughput, because every user transaction is completed by zero-old's proof. And so in your p-to-peer network, to get that transaction into the mempool, you need to propagate this information. And your peer-to-peer network throughput will be substantially lower than the bandwidth of your node operators. And so the zero-notch proof size there actually is quite important. So right now it's about 50 kilobytes, and, you know,

we have some work scheduled post-launch to get that down to four. So that's work there needs to be. To four kittabytes? Yeah. Okay. It's not a hard problem. It's just time consuming, so we haven't done it yet. The, uh, using multi, multi-polynomy, basically, instead of committing to one

polynomial, like one commitment per polynomial, you just have one commitment from lots of polynomials. And then there's just generally our node software, because we built everything from scratch, you know, because we have, the semantics from private state was so different. You know, we have this thing called the private execution environment, which it doesn't even exist in other networks, which handles. you know, state, private safe sinking, state retrieval, zero's proving. We wrote this all of our node software and typescripts so we could rapidly prototype,

but this is not a performance language. So there's there's huge amounts of engineering work to do to improve our performance. Like to get from TBS to 100 TPS, most of it's just pure engineering, taking something which is brass backing you and just applying traditional software engineering optimizations to it. One rule of cryptography or applied cryptography is you never build your own systems. Right. And it seems like you've built all the systems. Are you worried about that? What rule? No, I'm not.

That's a stupid. That's a stupid rule. In my opinion, the rules don't roll your own crypto. Well, then who rolls crypto if nobody does it? Oh, experts. Who the hell are the experts? Self-appointed? That's not who they are. Well, I mean, everything that's kind of like, you want to use things that are battle tested as much as you can, right? kind of, and I understand that kind of like sometimes entering, building novel things kind of means having to build new systems, but trying to possibly fall back on proven systems. There's no such thing. There is a fullback. We are the first. Ashton will be the fallback for future generations of private cryptography.

There is nothing else. So we didn't have that option. If you are building your own cryptography, there's dangers there. The typical canonical business of don't roll your own crypto is target towards software engineers that don't understand cryptography. They're not like, so, so, okay, so what's the barrier? If you want to roll your own crypto, well, step one, you need to do your own original research. You need to publish it. It needs to be peer reviewed by cryptographing experts.

You need to secure it. You need proofs of soundness and you create the completeness. You need proofs of zero knowledge. They need to be widely accepted and understood. And they need to use security assumptions that are, like, widely accepted. So you go, you could probably get away with the algebraic group model, just about, nothing, nothing weaker than that. And then you need to, okay, so then you have the theory down,

then you need to implement it in software, and now software needs to be audited internally and externally. Then what you have out of that is you have an insecure system which might work. This is it will work. Because, as you said, the only thing that really guarantees the strength that security of cryptographic technology is time.

The fundamental assumptions that we abase our security groups around are actually not known to be true. We do not know that they just get a little bit of the problem is hard. We just assume it is because no one's, figured it out yet. And so we are taking a very security conscious approach to our launch. You know, I say we're going to be launching on the Ethereum Miner early next year. What that is going to be is we're calling it the Aztec Alpha, because we will not be under any illusions that this will be secure. We will have done our best efforts. We would have gone beyond

all reasonable attempts to secure this network with our internal external audits. but any software engineer will tell you it's not possible to write secure code. It's just not. It needs to be battle tested. There will be bugs. The bug will be found. Hopefully by white hats because of our generous bug bounty, we will fix them. But the messaging when we launch will very much be security contours.

The message will say, this is not secure. Do not put too much money through this. Don't put any money. You're not prepared to lose. And we're going to have a checklist of things that need to happen before we're willing to consider the network more secure. We're going to need to not have any serious or critical bug reports for three months. We're going to need to have something like 99% network uptime for three months. And once we pass these criteria, then we will consider the network to be in beta.

And once we get beta, we will be much more comfortable making claims about it security. We'll be much more comfortable with people putting large amounts of funds in. But until then, it's going to be a risky critical just because of the nature of what we're doing and because it's decentralized. There's a lot of tests here. You, you are, you, already kind of talked about this a little bit earlier, kind of the bandwidth issue with kind of submitting the proofs as well as kind of the generating the proofs. How much do you worry about latency for use cases? So kind of like when you kind of say this is great for games, obviously a lot of games rely on fairly low latency, right? You don't want to wait

for an hour for your opponent to kind of make their move. The latency will be good for a large variety of use cases. We are targeting 12 second latency. So we're not producing blocks every 12 seconds, but because of our proof of state network and the fact that we have our own little DA layer and things like that

use, we can guarantee fairly, with fairly strong guarantees, you can get finality on 12 second time limit. Where at that point is the lying, they'll get slashed and so there's a few there'll be a few million dollars of value backing that claim. Is that good enough for everything, no. Similarly, but at a fundamental level, the problem is that if you're sending

a transaction across a layer two, you're paying for the highest security guarantees. You're paying for the highest, like, live-ness, sensory resistance guarantees. And there's no market for security. It's not like you can choose to pay less if you don't care so much. And so the solution to this, in my opinion, is the L3 thesis-application-specific well-up thesis, something that we are post-launch. we will be aggressively building out via the Aztec stack. Basically, imagine the scenario where you can write an Aztex smart contract, and it's all the same as a regular ASTIC smart contract, but when you go to deploy it,

you're not deploying into the Aspect network. You're deploying it to a roll-up that's hosted locally or host journalism in AWS. But basically, it's a network where there's only one sequencer. It's not decentralized. There's no data very easy guarantees. You just trust a sequencer. and in that kind of model you can get very far-harned, throughput, very low latency. Particularly if your transactions are all private, because if they're all private, you're not modifying any shared state.

So your transactions don't have any race conditions. And the only serial part of the transaction is recomputing your state trees. But everything else is fully paralyzable, so you can make Vox very quickly. And this L3 component will be very, very valuable for low-value high-three-use cases, things like high-repayment. things like gaming. That's how we plan to solve the problem. Okay, that also kind of solves your two transactions per second dilemma to some extent. How do you think about state growth and storage in a word of encrypted data?

Yeah, it's challenging. You've got to start it. Basically, the state sheet only ever grows in a private network, right? Because when you delete a record, you're not actually deleting it. You're just creating another record that says this old thing has been deleted. And you do it in a way that you can't link it to. So data proliferates much more rapidly on a private network than a public network. And there's a really great solution for this right now,

other than basically you do sharding. You have state epochs where, let's say, I don't know, like maybe a gigabyte, terabyte of states per epoch. And whenever you're performing state transitions, you're specifying the epoch of your note. And so this leaks a little bit of information because if you're modifying a really old note, people know you're modifying a really oddment.

But it's kind of the best we can do right now without requiring nodes to consume enormous, enormous massive data. There's obviously, okay, so there's sharding. You could do like the full Ethereum foundation sharding desire, but that's, I mean, that's challenging. I'd prefer if somebody else does it, prefer if Ethereum does it.

But right now, yeah, it's a bit beyond us to build that all out from scratch. Cool. So kind of like, yeah, no, I, hear that, I think kind of like not building everything is often good advice. Sorry, can I be annoying and interrupt? Another thing, sorry, I just realized, Sharding doesn't work for us because if you have just one giant database, even if you shard it up, if I want to prove that my note exists

in that database or prove it doesn't exist, I need to create a Merkel proof, which requires knowledge of the entire data set. And that's the problem. You need to be able to do inclusion and non-inclusion proofs over subsets of your data. And that requires what, like, what I call Sharding, like this. spitting your stake into epochs and revealing a small amount of information about your notes, the age of your notes as a result. There are a couple of competing privacy-based chains.

So kind of, if you look at systems like Alio or Namada or ZK Singh's privacy layer, how do you mentally categorize them with respect to Aztec? Privacy is a hot narrative right now. And so, and it's also a very poorly defined word. And so what people say will they mean when they say privacy varies. And so obviously I have my own biases here. I don't want to throw, like, I don't want to throw shade around. Things like the model, we'll see about them.

I think that they have a very ambitious goal in mind. They're the ones that use FHE to fully, like to create like a fully encrypted Ethereum. There are certain challenges with IPHE that are yet to be satisfactorily solved. I've always to be to use it. So one of them is, so if with FHE, you can, so, okay, with ZK, I can prove anything about my data. With FHE, you, I can give you my encrypted data and you can run a program on that data, and you don't know what's going on. You can't do that with ZK.

So it's multiple powerful in that context. However, it has two very big flaws that needs to be resolved. One of them is the data is all still encrypted. And so if you want to just take a regular EVM, and make it all, encrypt all the data, then use FHE. Then the problem is who owns those decryption keys? You need a multi-party competition network to hold that, to hold part, like, shit, like partial decryption keys for your state.

If you have that NPC network, then you can also use that NPC network to do zero knowledge proving via secret sharing. This is what TSAO do. You get very similar outcomes both ways. The whole, like, who holds the description keys, how do you do, key rotation, make that secure. It's very challenging. And we'll see, we'll see how they, how they, how they, how they, how they, how they, how they, how they, I do, I do hope they are successful. I think that right now, any privacy solutions that offer genuine privacy, like, it would be good if any of them were successful. You have things like ZK Sync. What they're doing is very different. I would not call what they're doing privacy by any,

like, like, meaningful standard. What, the way that they get privacy is that you run, so, so, so, you run an L3, and people send transactions to you and you don't broadcast anything about that L3. So the way that you get your transactions is not through your public network, it's through private information, private messages.

And then when you make your rollout proof, you basically discard all of the information around the data in your roll-up, and then you put that roll-up proof on chain. Is that private? Yes, it's the same way they're private server as private. It's not a great way of creating a composable ecosystem. The thing about the thing that I think is with valuable

privacy is composable privacy. The idea is you can write a private smart contract, I can write a private smart contract, and these things can talk to each other. They can call each other. And that's, like, we don't have to share any information with, like, with each other. Our users don't have to share any information. It all just works out of the box on a public network. You start getting some very, very nigh trust assumptions if you want composable privacy on a network like ZK Synch is building where everything is run by one server and that one entity sees everything and nobody else does. It's a huge amount of trust you're placing in that person. But it is useful for certain in the use cases. It's useful for enterprise. It could be useful for gaming. It's useful

where the trust assumptions are very low. But yeah, and then you have other teams like Alio and Mina that are basically doing the ZK route that we are. There, it's an execution play about whether this stuff can be made performant enough, easy to use, whether you can create the right abstraction layers. And right now, no one's really cracked that problem. And I can't claim that Aztex cracked it. We're not even lost yet. I hope you will. But Nobody has yet. I'm convinced as a matter of faith that privacy is useful, that is needed, that if you make it easy enough, people will build on it. Not because users care about privacy as a feature, but because it's a require property for a lot of valuable applications.

It's a question about building a technological base layer that's competent enough to provide the developer user experience that people require. Aztec is an L2 on top of Ethereum and kind of the decentralized world has shifted since you decommissioned the last version of Aztec. How do you think about the benefits of being an L2 on top of Ethereum rather than say a standalone L1? I mean, you already have the decentralized sequencer set. You could just be an L1 and kind of like not pay. for living on top of Ethereum, no? It could, but then

there are other problems with that. Specifically, privacy doesn't matter if you don't have any value you want to make pretty private. Nobody cares how many magic beans you have. They care about how many US dollars you have or your property or like who you are.

And so you have a very big chicken and egg problem if you're running as an L1. Whereas how do you get value with your ecosystem? Because it's completely new itself from scratch. Like, obviously you can do bridges, but bridging is still a fairly complicated process with an unpleasant user experience. And ultimately, yeah, we thought the costs, the risks would be too great. And also, we did gain a lot from building our software with Ethereum, but we don't have to

roll our own consensus network from scratch. There is a slight lower maintenance overheads to our software because of that. I was hoping at the start there would be much lower than they are. But yeah, we've had to build a lot out ourselves. Ethereum is still the canonical source of assets on CHEM. If you want to issue an asset, okay, you can do salana and things like that. But if it's a chunky asset with a lot of value in it, you put it on Ethereum. And we wanted to be able to make it so you could very trustlessly bring your assets into Ashtick from Ethereum.

Because just in the same way that Ethereum is the canonical source of assets, our goal for Aztec is to make Aztec the canonical source of credentials. Effectively, if you have a token or an attestation that says something about you or what you've done, or what you want to do. The natural place to issue that is on Aztec where it's encrypted by default and you can selectively disclose that credential to either people or to smart contracts. And yeah, we felt Ethereum is the right place to do it because it's where the money is and privacy is not useful without money. More generally, we do think that bridging, like creating a very, making it very easy to get transactions into an out of Aztec from any other network for us is extremely important.

We don't want to just be tied to Ethereum because there's a very unique value proposition for Aztec that no other L2 faces. It's not a secret that most L2s are somewhat parasitic to their host networks because the L2 wants its own set of liquidity, its own tokens so that you can build applications on the L2, and that liquidity comes at the cost of taking it out of the L1. With Aztec, it's very different because there is unique value in bridging, not tokens, but information between Aztec and other networks. For example, imagine you're building some kind of, um, um, um, trading marketplace on Solana. But you need a level of compliance.

Maybe the assets, you need to know that people are not on a sanctious system of Iranian. Maybe you need to understand if someone's American or not, things like that, some basic compliance. Well, what you can do is you could send a request into Aztec, where that request will check some encrypted credentials on that person. And the request responds with either true or false. Like, yes, like, or no, they're not.

Solana, that application on Salana has gained something of value from interacting with Aztec and the Solano network has not lost any tokens. Effectively, you get a privacy shield for free, well, a very low cost. And that's the direction we want Aztec travel in the future. We wanted to be the universal privacy layer for all of blockchain. And we want to execute on that in a very positive some way where the canonical method of interaction with Aztec from other networks is not UBridge assets and Aztec. And then they stay there is you bridge identity information into and out of Aztec.

Or maybe you put tokens into Aztec so that you can create so that you can perform private interactions with them. But then very quickly they go out back into the parent network. We think that's a much more kind of positive sum way of interacting with the ecosystem where everybody wins. I 100% concur on the message passing use case. So kind of like if you were to kind of use it as an identity layer, 100% agree with everything you said. if you look at how assets are actually issued in the Ethereum ecosystem today, I know that kind of like back in the day, we talked about assets natively being minted on Ethereum main net

and then kind of being bridged into L2s. And then kind of things happen on L2s. They get rolled up and then kind of like you bridge out of the L2 onto main net. again. What we effectively see is that kind of like acids are born on L2s. They live on L2s and they

die on L2s and ideally they're happy on L2s. But kind of they don't and kind of like for anything that is natively minted on an L2 the L1 doesn't actually give you any security security guarantees whatsoever.

So kind of like all the security you inherit from being an L2, you only inherit for bridged assets from mainnet, right? And I think to some extent, we've seen that play out differently. When you say that you don't get any security from the 01, I think this is largely because these LTs are centralized. And so you have this kind of, the weakest point of failure is something in the LTI, like a multic or something. It's a bit different for Aztec, where, you you have sequences, you have sequences sticking on Ethereum L1 to be a block producer.

And once a block has been produced and you've updated your state route, then you are very much relying on Ethereum's consensus to define what the canonical version of ASTIC is. And so I do slightly disagree with the idea that you don't inherit anything from any security from Ethereum. I mean, we are targeting to be a stage two robot on launch where that kind of, that is kind of the point. But say I kind of deploy some sort of token on Aztec directly, right? I can't force exit to Ethereum, right? I can't. But that asset, that kind of like Ethereum knows nothing about?

So the way we do it is we call it an escape hatch. But basically for a certain fixed amount of time for every block production epoch, anybody can send a lot of transactions. It's not just a sequence it. It's basically a free-fool. The idea is we don't intend for this to be. used, but it can be used. If you're getting sensitive for some reason, you can use that window to make your own Aztec transaction to exit. If for some reason there's something catastrophic failure

states and like no-bonds producing blocks, then you can use that to produce your own blocks and get out of Aztec. So no, you can force exit onto Ethereum. But can I force exit an acid that was not minted on Ethereum? Oh, it wasn't minted on Ethereum. It's minted on Aztec. Yeah, yeah, yeah. Okay. In that case, in that case, yeah, if you've minted on Aztec, then you can't force exit. Yeah. Because it's exit. So I get what you're saying, that the security guarantees you get a kind of, it's a combination of Aztec and Ethereum where like the weakest security holds.

And the way that users behave is all kind of the way that I'm, and when I say users, I kind of mean application developers, kind of is assets get natively minted on L2s all the time now. So kind of like if you look at the values, and that kind of, get transferred on L2s, kind of the minority of them have actually been bridged in from L1. The majority of them are natively L2 assets. And then you have no security guarantees. But the majority of value is not on L2s, as in L2s, most LTs don't really have front-up market fit. And so most of what's going on is synthetic, it's liquidity farming, it's incentive-based,

it's basically nonsense. And so I don't think it sets a very useful precedent for a network that has the useful economic activity on it. You're right that, okay, yes, so what happens in L2s is you get these synthetic moon coins that get produced and, yeah, it's all on L2s. Does it matter? I mean, do you need ironclad security for a moon coin? No.

So I don't see this as a problem. I think that for Foresic, it's fairly clear, I think, how things are going to play out. if you have an asset that requires identity checks, regulated checks, it's going to turn off on a stake as a native asset. Is that secure? Yes, because we're fully decentralized. We have a very willing, we're going to have an enormous amount of stake backing the network. The more economic activity the network generates to hire the fees. The number one cent of there is to put more stake onto the network. So I'm not worried at all about its security. What I don't want

to see happen is that ASIC starts becoming very parasitic to, Ethereum. Yeah, I hear that. And I think that's commendable. Because I think that the value proposition really is with bridging information. I think that ideally, the only time on ASSEC is natively omitted on Aztec is if you can't put it anywhere else because it requires privacy checks, composable privacy checks that you get on Aztec. I don't see ASIC as being a very popular home for like low latency in midpoint trading because it's going to be more expensive and slower than fully transparent networks. So I do think that there's always going to be, I mean, obviously there'll be some of it.

You can't stop it. It'll happen. I don't see that as being a particularly dominant use case on Aztec, unless we've completely failed to execute on any of our privacy. Unless all of my thoughts about privacy was wrong, then that's the only way that world will happen. Maybe let's zoom all the way out to kind of like pass all the crypto stuff. If you kind of look at the world right now, kind of we are dealing with declassing declining expectations of privacy. And kind of like you see that in the UK,

you also see it in Europe. So kind of like chat control is something that only recently failed. How do you see that shift? And do you think kind of that level of cryptographic privacy can play some sort of role in reversing it? Yeah, it's a tricky one. I noticed two trends, which utterly confound me

because they seem to be at work, They seem to be mutually incompatible, which is that Western societies are becoming more and more distrustful of their governments and, like, less confidence in their ability to execute on implementing effective state policy. Yet, at the same time, seem to be more, more willing to give those governments powers and control over their private data. Part of this is a lack is like, how do I put this? Privacy is not a mainstream narrative, and people don't think very much about it. I don't think this means necessarily people don't care about privacy. they don't care about government overreach. It's just that it's not part of the kind of the canon

of ideas that they consider important or contentious. To give an example about this, right, the UK has recently passed a very unpleasant surveillance bill called the Online Safety Act, ostensibly to protect children, but in reality is, I would argue, is a massive curtailment of free speech online.

This has mean people don't care about government overreach, they don't care about privacy? Well, maybe, maybe not, because at the same time, the UK government is trying to introduce identity cards. which is met with overwhelming popular opposition. People hate that because identity cards are more familiar with that as part of the

concept of ideas they have, right? They think identity cards they're familiar with totalitarianists using those to restrict people's movements, exchange of ideas, information, and they don't like it. They're not familiar with how governments use online surveillance laws to repress free speech

or limit free exchange of ideas or make their personalism more secure and more likely to be leased. This will change. change in time. I think that what's going to happen is more and more oppressive. The decision's going to get past and it's going to be abused and manipulated more and more. And eventually, we might see some kind of backlash. I think that there's always my hopes here when it comes to these other things that lies with America. I don't think, whilst you're getting some annoying age restriction laws at the state level, they're not the same as chat control, for example,

where it's just a very, very clear power grab by the state bureaucracy. I think it basically, America will always be basically demonstrating what's the alternative if you don't have controls over speech. Eventually, it'll just become a very compelling differential, I think, I hope. But I mean, just to push back here, so kind of in some way, the US are a nation that is most advanced in surveilling their own subjects. And it's also currently a state where you can lose your visa for kind of being, holding a non-majority opinion, right? So kind of like it is very kind of anti-free speech in some sense. I'm not going to hold America as a bastion of liberal values anymore, for sure.

Like there is an element of capricious state policy. I think you've also seen in America the degradation of the rule of law. We've even seen that with crypto, right, where under the Gary Gensler regime, crypto was based on the criminalized crypto without passing the legislation to do so. And then under the Trump regime, it's a free-for-all. However, I do think that part of America's strength lies in its decentralization, as in you don't have a particularly strong unitary authority that can exert massive amounts of controlling the people's lives,

like you do in most European states. I know Germany is slightly different with this federal structure, but most European states are unitary entities where the government says, hey, we're going to surveil you and create an unwarranted financial surveillance resume. There's nothing you can do about it. And if you think that we're, and if you complain, we're going to just call you a child molester. This is hard to do in America because you have state governments

that generally have political incentives to push back against the federal government. When it comes to things like online surveillance, is actually the state governments that are the ones pushing it. to perform age checks and other content. It's a very mixed landscape, but as a core cultural value, America does value free speech. Regardless of what the rules say,

the laws say they value free speech. You'll see that getting eroded for people in outgroups, immigrants, people on visas, but I don't think you'll ever see a world where the American people as a cultural will say, yes, we were willing to take a tail free speech to gain safety. That's not going to happen.

Whereas I think in Europe and in the UK, that is currently a debate that's happening and you have very powerful factions pushing for less acceptance of free speech and more acceptance of government's oversight over what people are saying. And I think that that is very, very concerning. Cool. Thank you for coming on again, Zach. I hope you're right. I mean, I share your pessimism with respect to Europe. I don't share your optimism on the other.

other side of the Atlantic. But yeah, your word and gods are the earth. Thank you. Just to be clear. I mean, I'm normally based in the UK, non-America. And I wouldn't say I'm optimistic on America. It's just that I think that it's more likely to preserve. Like, it's not moving in the right direction. It's just moving in the wrong direction and a much slower pace than the rest of the world. That makes any sense. I know what's why I call that optimism. Cool. Thank you, Zach. Thanks a lot.