Web3 Galaxy Brain 🌌🧠

Nicholas: Welcome to Web3 Galaxy Brain. My name is Nicholas. Each week, I sit down with some of the brightest people building Web3 to talk about what they're working on right now. My guests today are Ulas and Dogan, founder and founding engineer of Clave. Clave is a stablecoin wallet powered by Passkeys and ZkSync smart accounts. On this episode, Ulas and Dogan dive into the origins of Clave on Optimism, the UX advantages of account abstraction, and roll up improvement proposal 7212, which aims to bring SCP-256-R1 passkey elliptic curve verification to L2s. We also discussed their partnership with ZK Sync and some of the very slick onboarding flows they have to bring new to crypto users on-chain. It was fantastic getting to know Ulas and Dogan better. I hope you enjoy the show. This episode is brought to you by ContractReader.io, the best way to find and understand smart contracts on the EVM. With ContractReader, you can read smart contracts on mainnet, testnets and L2s with text highlighting and live on-chain values viewed right in line within the code. With their new audit toolbox, you can create public solidity gists or make them private by adding collaborators. Share the link to add comments and conduct audits in a native solidity flow. Give it a try today at contractreader.io. My thanks to Contract Reader for sponsoring this episode. As always, this show is provided as entertainment and does not constitute legal, financial, or tax advice or any form of endorsement or suggestion. Crypto has risks and you alone are responsible for doing your research and making your own decisions. Hey, Dohan, how's it going?

Dogan: It goes fine. Currently, we are exploring different options and we are just around the corner of the main launch. So it goes fine. What about you?

Nicholas: Going well, going well. When you say mainnet launch, I know there's like a zkSync tie-up, but when you say mainnet, it's for actual mainnet?

Dogan: Actually not, zkSync mainnet. So we had a closed beta launch during DevConnect, but it was on testnet. And we had some requirements from our users and also some of the industry leaders. And then we have changed the Clave wallet a bit. And it's ready for Zcasing mainnet. So we don't plan, we don't have any plan to launch it on mainnet, Ethereum mainnet or like any kind of other one.

Nicholas: Okay, so for the listeners, we should rewind a little bit and say today we're talking about Clave. We're going to talk about Clave and a bunch of other things related to smart accounts and... the P256 curve and all kinds of interesting things. And we'll go through all of it. But today, I'm sitting down with Ulas and Dogan, who are the co-founders of Clave, which has really been pioneering this whole smart account centric, passkey centric, new generation of accounts and wallet technology. Isn't that right?

Dogan: Just a small clarification. So Lush is one of the co-founders in Clay, but I'm a founding member. It doesn't that matter, but yeah, just a small clarification. Thanks for the introduction.

Nicholas: Of course. But did the project, my impression is that the project started at ETH Global in March, but maybe it actually goes back further than that?

Dogan: Yeah. so actually it was later 2022. i have started to research account abstraction and while i was researching i just came up with in this idea the idea of the opclay. opclay was using hardware signers within a custom precompile in an op stack. So, uh, actually it has been while I was researching this topic, but, uh, before researching the account abstraction, uh, we all as a Clive team, uh, has been working in different projects and we had our own development studio and we have been serving third party development, uh, in crypto space since like two years.

Nicholas: Okay, so like 2020, 2019, something like that, you got together and were doing what kinds of projects?

Dogan: Yeah, actually, I have recently joined the team as the development team, but all of the development team were working together since like three years, per se.

Nicholas: I see. And Ulaj, for you, is that your team? Very cool. So you're working on a variety of different projects and decided that you wanted to build something innovative and Opclave sort of emerged through your discussions with each other. Is that how it happened?

Dogan: Actually, we wasn't expecting that Clay will be real in Ethereum ecosystem. But I just wrote a thread that is explaining what is Opclay and how it works, and it got too much traction from the community, including the investors and some of the industry leaders. And we have decided to work on this project and digitize our own jobs, as Sulaysh mentioned. And this was how it happened, the transforming into Clave. But we always have been talking to each other that we want to continue with our own project, not working with third-party projects. So it was our dream, and the dream has become a real within the Clave project.

Nicholas: That's great. So the exposure from the tweets around the EthGlobal project sort of made it a reality. Yeah. Very cool. So Opclave, people may not be as familiar with, but as you mentioned, it was a hardware signer-focused project with custom precompiles. specifically for the OP stack. Maybe you could explain a little bit about what the idea was and then how we got to where we are today.

Dogan: So OK, actually, while I was researching account abstraction, the most interesting part for me is the key abstraction, the way that we can change the custodial solutions, because currently we have only MPC and UA or custodial solutions. And these three solutions have its own trade-offs. We want to build something cooler and something better than the existing one. And the key abstraction of the account abstraction allows us to do it. What does key abstraction mean? Key abstraction means that you can initiate a transaction with non-native Ethereum signatures. It can be a Shriner's signature, it can be a P256 or like Poseidon hash or like anything that you can imagine. It can even be an RSI signature. So while I was researching the account abstraction, I just saw this and I have already known that the secret enclave and pass keys are working with P256 curve. And I also have been researching OP stack and other modular approaches to how we can build customer-facing applications on top of this modular execution names. And I just saw that you can add custom precompiles as you are adding into the get node. So it's so simple and it's as easy as adding new precompiles into the get node. I don't know if my pronunciation is correct, but anyway, Yeah, that's good. And we have presented this project in the hackathon. We have won the hackathon and we have too many traction from community. But of Clay was an idea. And this idea says that we need a precompile. I think it would be maybe helpful to explain what is Program Pile 2. Normally, you can build Solidity smart contracts within any kind of languages. in Ethereum which you can express computation inside of EVM. but EVM is not designed to support non-native curves and it has some of the downgrades if you want to use non-native elliptic curve cryptography. so pre-compiles allows us to change the evm specs and this approach is also came up within a trade-off which is you need to get the community support and also you need a hard fork to get a pre-compile into the any kind of blockchain.

Nicholas: So do I understand correctly with a precompile that basically you're locating some functionality at a specific address inside the EVM? And then if any contract calls that address, they can access functionality that it's actually running on the bare metal, like in Geth or Wreath or any of the Node clients. They'll execute it in Rust or Go or whichever language they're written in.

Dogan: Yes, this is 100% correct. But as you know, getting innovation inside of L1 is so hard. But if you have your own app chain, then it's as easy as changing your RPC node. So this is why we have used OPStack as a starting point. But since we are using OPStack and we are an app chain project, but we want it to be compatible with an existing ecosystem and we don't want to have our own isolated state with another roll-up ecosystem. So we didn't want to build an op stack roll-up just for a hardware signer. And we wanted to serve this precompile as a public good to the Ethereum ecosystem. And this is where EIP-7012 has born. We wanted to have this precompile as a public code to all of the Ethereum ecosystem. And we took a lot of efforts on that. And I think we can maybe continue on this part too.

Nicholas: Yeah. Ulaj, I don't know if you wanted to add anything to that.

Ulas: No, it's fine.

Nicholas: So maybe the big thing that I guess is continuous between Opclave and Clave and the other topics we're talking about are the 4337 account abstraction improvements to UX that kind of motivate this whole project. Maybe we can talk a little bit first about 4337 and what it really does to enable a better UX for regular folks.

Dogan: Yeah, sure. So I think before the 4337, it would be helpful to explain how smart contracts work in Ethereum and how Ethereum accounts are working. So basically, we have two types of accounts in Ethereum. One is external-owned accounts, which are also known as EOAs. And EOAs are working with a private key, and also all of the Ethereum protocol has designed for EOS. So they have a huge advantage compared to the smart accounts. What is smart accounts? Smart contract wallets, or I love it as I call it smart accounts, is the way that you are storing your assets inside of a smart contract. And this smart contract... Ownership can be programmable, whatever you want. So you can use it as a multi-sig, as we've seen in safe contracts. You can use it as different signers, as we have seen in the past within Argent Wallet, and also we have seen a lot of examples around this concept. But smart accounts has a huge disadvantage, which is they cannot initiate a transaction without any third party delegation. And this third party delegation sometimes can be a problem because it breaks the censorship resistance of L1. What does it mean? You need someone to initiate a transaction, BL4Q, if you're a smart account. And this is a huge problem. And this is where 4737 comes. It doesn't only offers like meta transaction or like anything around it, but it's a bit more complex. But the exact thing that it's doing is that It allows smart accounts to initiate a transaction without relying on any extra parties in the Ethereum ecosystem. And this is huge because it allows everyone to build smart accounts without thinking of who is going to initiate the transaction. Currently, bundlers are doing the transaction initiating process, but in the future, bundlers are going to be block builders. And this is what 4237 offers. And I think it's a huge improvement.

Nicholas: Maybe you could explain a little bit about that convergence you foresee of bundlers and block builders.

Dogan: Yes, sure. So what bundlers are currently doing is all of them has its own isolated mempool and they cannot communicate within each other. And sometimes they lose their money. Why? Because I'm sending user operation to Bonder and Bonder takes it. And then Bonder somehow communicates with a blockchain block builder and If there is no way to trustlessly communicate between block builders, then the bounder can be front-runner and they can lose their money within failure transaction or like any other configurations. So this is the problem in blockers. But Etherspot is trying to solve this problem with a shared user operation sample. I think it's already on testnet right now and they have been improving this process so much.

Nicholas: So the idea is that if two bundlers separately include a user operation, but the user operations have nonces that mean that the second one will fail, then the second bundler could be front-run by the first one, for example, and unknowingly propagate a transaction for which it won't be compensated?

Dogan: Actually not. The thing that I'm referring to today is that MAV searchers are seeing that this founder made money within converting user operation into a transaction format. And if I do this with giving money to the block builder, as we call it as an MAV, then I can take his profit. so this is a problem but as i mentioned it it's not something that is private. everyone knows it and everyone is trying to improve uh this process as it is it's a sport team and they are a 43.7 guarantee if i'm not mistaken.

Nicholas: So Etherspot's proposal is to directly turn the bundlers into block builders or to just share the user operation mempool across different bundler providers?

Dogan: Great question.

Nicholas: I can ask them.

Dogan: Yes. I don't want to make any mistake, but from what I understand is that they will have process communication between block builders and bonders, or they will allow bonders to be block builders. But right now, the user operation economic activity is not enough. to any bundler to be a block builder because the transaction inclusion time is going to increase so much because of the economic activity.

Nicholas: So, yeah. Because they would have to wait until they have a complete block to submit a purely block bundle. Or purely bundled, user out bundled block. Interesting. Oh, so bundling brings me to one of the advantages is transaction batching. One of the advantages of account abstraction is transaction batching, which can potentially reduce costs. Whose responsibility is it to do the transaction batching? Would it be like the dApp or the person constructing the user operation or the bundler? Who's responsible?

Dogan: So I'm not sure what you mean by transaction batching. If it's like you are in the UAS, you need to approve first and then make swaps. And in account abstraction wallets, you can do it with them together.

Nicholas: Right. I guess there's two different ways because it's also the bundling of all of the user operations into a single transaction. But there's also this, what you're saying, referring to the account level batching where you can do an approval and the swap in the same transaction.

Dogan: Absolutely. My expectation actually, I think wallet teams are going to take the lead in this process and I don't expect the transaction batching will decrease the cost so much. I think there's a huge improvement on the roll-up side because if you can use different signatures or like if you can do compression in L2s, then you can decrease the data that you post to L1. And this is possible within 43.7 accounts. And I think within stative roll-ups, I don't think that we need to dive into it, but within the, and also within 43.7 compressions, smart accounts are going to be cheaper than UAS in the future, hopefully.

Nicholas: This is like a hot topic right now, right? This compression that you mentioned? Yes. Ulesh, I don't know if you wanted to talk about that or something else.

Ulas: Yeah, I want to add to batch transactions. I want to say that the DApps have to be aware of they are willing to make some batch transactions in the regular transactions because they may need to make some state chains in the front end or... they may need pre-traded transactions in a different way and if they are not aware of this transaction might be a part of a batch transaction, the transactions can have fails or the secondary transactions may not be performed.

Nicholas: There's also this affordance of spending ERC-20s for gas. Who's responsible for making that possible?

Ulas: with an ERC-20 or the wallet can change the transaction and add required Paymaster data to make it guess who's our favorite token.

Nicholas: Sorry, so it's in the user operation that it's defined?

Dogan: Yes.

Nicholas: Got it. So maybe, yeah, I wanted to ask Dogan about the compression, the 457 compression. Is there anything that you can explain about that? to give people a sense who aren't totally up to date with the latest news?

Dogan: Yeah, sure. So... When you do a transaction on any L2, you need to pay for three things. One is L2's execution cost, and second one is the L2's cold data cost, and the cost that L2 is paying for L1 for the data availability. And also for the third one, if it's a zero-knowledge roll-up, then it also needs to pay for proof verification, and it's at another cost. So as you can see, there's three different costs in the roll-ups. So what you can do within this concept is that if you can decrease the data that you are posting to R1, then you can get a huge amount of cheapness within this data compression. And this is also known as data compression. Instead of sending the data directly, you can do some tricks and then you can post it into L1. This is data compression. And since we are on zcasing, we don't actually need data compression because zcasing is doing it behalf of us. It's also known as the state diff rollups. It's really a bit deep concept. I'm not sure if you want to dive into it, but...

Nicholas: Stative rollups, you said?

Dogan: Yeah, state diff rollups.

Nicholas: State diff roll-ups, okay.

Dogan: Yes. So what you can do within roll-ups, forget roll-ups, each blockchain needs to store its data in a trustless way or maybe in a trust-minimized way. So what Ethereum currently is doing is the full nodes are storing all data from scratch and also they are responsible within verifying the new blocks. So when we come to execution layers or also as known as the roll-ups is that roll-ups are doing the computation of chain and they are posting the only execution result to the mainnet. But there is a problem. Currently, I'm talking about zero-knowledge roll-ups because in the optimistic roll-ups, it's a bit much complex. But in the ZK roll-ups, you can prove the off-chain executions integrity within zero-knowledge roll-up and you don't need anything else. The only thing that you need is the proof. But imagine that roll-off sequencer is done, or roll-off sequencer is censoring you as your account. And we have seen this example within DIDX. was a D-IDX version 3, was a roll-up running on Ethereum. And D-IDX decided to cancel or free the user's funds if they have interacted within Tornado Cache. But users just take their money within sending a transaction from L1. How was it? it was possible because the data was available on L1 and also anyone could build the state with only reading the L1's data And they could be a sequencer or a prover within the data that is in L1. So what L1 is providing to Ethereum rollups is that the censorship guarantees and liveness guarantees within this concept. But you don't actually need to post everything to inherit the censorship and liveness guarantees. from L1. How is it possible? So currently we have two types of Ethereum rollups. One is transaction data rollups and one is stative rollups. Transaction data rollups are posting all of the data to L1, whereas the stative rollups are only posting the changes that happened on L1's storage. So they both have its own advantages and disadvantages. But when it comes to account abstraction, stative rollups are so powerful because they don't post the verification functions result to the L1. And for example, if you are using a passkey, it has a bit more data in the verification side. And if you post it to L1, then you are getting a bit more cost for this reason. But in the state default apps, it's different and it's much cheaper.

Nicholas: So, for example, if I send – I use the Clave wallet. I use my passkey by Face ID or Touch ID on my phone to sign a user operation with my passkey. And then that bytes – those bytes are included in the transaction data, which are sent to – are included in the call data that the uh or blob space that the op stack style bundler is posting to op stack right. like these the amount of call data in the transaction increases. if there's more data in the tr in the transaction then it increases the cost whereas in the state diff roll up it wouldn't be the case.

Dogan: Yes, the only thing that you need to consider is that how much my transaction is changing the L1's storage, the storage that is living in L1. So, for example, I'm sending you 1it and you are sending 1it to do Lush in the same block. The Ethereum is only going to know that my balance has decreased within one ETH and Ulaş's balance has increased within one ETH. It doesn't even know that you have received the money and then sent Ulaş back.

Nicholas: But that's presuming that the assets that we're trading are, I mean, in a state diff rollup, is it even considered bridged ETH in that case?

Dogan: Actually, it was just an example to simplify it. It's much complex in the DeFi applications. For example, if I'm interacting with a municipal, the L1 don't even know the Oracle calls or anything else. that doesn't change the L1 storage slot. So this is the case because in the verification side, for example, in the verification side, I need to verify the P256 curve. And this correctness is being provided by the zero-knowledge proofs. Thus, we don't need to let Ethereum know that this execution is also correct within the sending data.

Nicholas: Wouldn't that also be the case if on, say, Optimism, if I used, if I...

Dogan: Optimism cannot be. Yep, sorry to interrupting you, but Optimism is a stative roll-up because optimistic roll-ups have to be... transaction data roll-up, they need to post all transaction data to L1 because the fraud proofs are only working if there is a full data availability and your security Not security, to be honest. Your safety is equal to the data-developed layer safety in the optimistic roll-ups. But in the zero-knowledge roll-ups, your safety is equal to the settlement layer and the data-developed layer only giving you the censorship guarantees and liveness guarantees. i hope that this makes sense.

Nicholas: it does make sense but even in the optimistic case when you verify a p256 signature it's happening in memory. it's not happening in storage right so it doesn't get stored to. it's not included in the only. whatever data is required to be verified like the signed struct the signature is required but And it incurs an L1 gas cost.

Dogan: Yeah, but you need to post the transactions data to L1 to show the execution is correct.

Nicholas: Right, but I would be sending a user op to an L2 bundler, and the L2 bundler would be writing the contents of the transaction and its data, but not the gas spent on L2 to do the P256 verification, right?

Dogan: Can you elaborate the question?

Nicholas: I just mean that the verification process of, say, running the P256 solidity verifier is not...

Dogan: Absolutely. It's a part of the execution cost. It's not a part of the L1 data availability cost.

Nicholas: Right. So to do like passkey verification, for example, doesn't necessarily incur more in a... What's the alternative to the state diff? The complete optimistic style transaction?

Dogan: Yes. The execution costs are kind of similar, but when it comes to data availability costs... Sure, it'll be much higher. Yep. Yep. This is what I mean.

Nicholas: So this is one of the advantages of zkSync. This is why you've chosen to focus on zkSync. Yep. So maybe you could tell us a little bit about that. I mean, people maybe heard of zkSync, but aren't so familiar. So state diff rollup, I guess that's one of the main selling points.

Dogan: Yep. So Zcasing is using state of technology and also zero-nose technology for sure. And they have native account abstraction, which means that we don't need any bundlers or any kind of third-party services to run as smart accounts inside of the Zcasing, which is perfect because you can be the first class citizen within the Zcasing ecosystem. And we are also working with EIP-7212, integration inside of the z casing and as a result we will see that ua and clear accounts are going to be having same costs. uh both in the l1 and l2 costs great.

Nicholas: well i I'm going to ask you some more about zkSync and get into the Clave app in a second. But first, we have an announcement for a sponsor today. This episode is brought to you by ContractReader.io, the best way to read and understand smart contracts on the EVM. With ContractReader, you can read smart contracts on mainnet, testnets, and L2s with text highlighting and live on-chain values viewed right in line with the code. And with their new audit toolbox, you can create public solidity gists or make them private by adding collaborators. You can share the link to add comments and conduct audits in a native solidity flow. You can give it a try today at contractreader.io. My thanks to Contract Reader for sponsoring this episode. so all of this research that you've been doing is being productized into the clave wallet. i've seen some screenshots and i know that there's this test flight out there. what are the core features of the clave wallet?

Dogan: actually before last week it was like a bit different but in the last week we had some important decisions about the clave application and how it would like in the future. So, first of all, Clave is a fintech application. It's not another Web3 wallet in this space and it's designed for payments. And we are designing our GTM on the payments in different markets. And Eric is also here. He's also an amazing person who is helping me to understand the different payment markets. Anyway, so what we are currently doing is we are allowing users to onboard with only one click. This is the main and most important part of the Clave. Because we don't want to have, like, you are typing something and you are clicking continue, and then there's a face ID verification, and then you are receiving an email OTP, et cetera, et cetera. It was also great compared to the EOS, but we really want to have the best onboarding process that is available on both Web3 and Web2 ecosystem. And for this reason, we are currently using passkeys and the only thing that user needs to do to be onboarded is that they're just clicking to create an account and the face ID has been happening and they're done. They have an on-chain wallet.

Nicholas: So really just biometrics and you create a passkey and that's all you need to have a wallet.

Dogan: Yes. Not on other teams.

Nicholas: That's great. So super fast to just get in and get a, as you clarified earlier, I like your clarification about smart accounts versus smart. Everyone's used to this smart contract wallet, SCW acronym, but really it's more like a return to the spirit of accounts. and a better quality signer, the PassKey signer that the iOS and Android and et cetera ecosystems are enabling. So if you drop into the app and you just create a PassKey, what's the experience like then? I guess you have a zero balance account, basically?

Dogan: Yes, but we also have a solution for it. uh, what we are currently also working as, and it's going to be available on the, uh, mainnet launch is that you will be able to send money within links. What does it mean? Imagine that you want to send money to your friend and your friend doesn't have any on chain wallet. The only thing that he needs to do is you will send him, uh, link and if he click the link he is going to download the clay and after the onboarding he will see the money inside of the clay vault. so this will be Also, one of our core features, because we want to solve the micropayments problem in the WebTree ecosystem, within this feature, to be summarized, You are sending your money with an only link and the receiver only clicks the link. and he's done. He has the best security level in the Web2 ecosystem and he has his own his own uh choice within uh paying fees in stablecoin or like it or like anything any erc20. and he can also uh integrate interact within web2 apps. so this is the clay replication and how it will like in the future.

Nicholas: So basically you can send a link to somebody and if they install the app and create an account, they'll receive your ETH or whichever token at that address. And so they have a booted up wallet right away, very easy to use. Yes.

Dogan: And also we are going to be, we haven't announced it yet, but we are going to have a debit card integration. where you can spend your crypto in your debit card. And this is also going to be one of the main core features for daily life users.

Nicholas: So you could potentially use Apple Pay with your Clave balance?

Dogan: Yes.

Nicholas: Very cool. So that's the add to wallet button I saw?

Dogan: Yes.

Nicholas: That seems very, very cool. I also saw there's a feature around, and sorry, that would work anywhere? Or do you have a sense of what geographies that would work in?

Dogan: Yes, it's going to be in Europe first. And maybe in the future, we can add other countries, especially on the growing markets like Latam or like Turkey, as we are also located. And also maybe Vietnam first. Angela, et cetera. But in the start, it's for only European market first.

Nicholas: How many people are working on Clave these days?

Dogan: We are a team of 10 people, and development team is six people, and the other people is like four people, and I'm one of them. I'm doing the research and writing stuff, and also helping my team within developing the GTM on the different markets.

Nicholas: For the app, you mentioned this easy onboarding process by sending your friend a link where they can collect some money. Is the app very stablecoin-focused, or are any tokens on an equal playing field?

Dogan: Actually, our focus is on stablecoins, absolutely. But it's going to be up to users to, if they want to have their own other coins, then we will support it. And they can add custom tokens in their choice.

Nicholas: And will the app connect to Dapps through WalletConnect or a traditional connection scheme like that?

Dogan: Yes.

Ulas: We use WalletConnect to connect to Dapps. Also, we have an in-app browser and it's also a way to connect to the apps directly.

Nicholas: So if you're browsing inside the in-app browser, then you don't even need to Wallet Connect, because it'll just know. Or it'll be like a window.Ethereum.

Ulas: Yes. I know. We use the Wallet Connect, but it doesn't need an additional app, probably.

Nicholas: Very cool. So why do you think, do you think this will appeal primarily, I know you said it's FinTech, so what is it that will make this app more appealing to people who are not crypto-native than something like Venmo or whatever the regional equivalent is?

Dogan: Yeah, actually what I'm thinking is that we just want to be the easiest way to send money and receive money. So that's the... starting point and we have a cool infrastructure on the Web2 side and also we have a lot of integrations coming on the Web2 banking side both in the European market and also in the Turkey market. We are also working with some of the integration in the Turkey market too. And yeah, this is why I call this as a FinTech app or like maybe a payment app. It really doesn't matter that much. But the only thing that I want to add is that it's not in another Web3 wallet.

Nicholas: Because it's so focused on making it easy to do cross-border payments?

Dogan: Yes.

Nicholas: That's interesting. And do you think it's... I guess for people who are just transacting with their friends domestically, I guess the local competitors are probably just as easy. I wonder if there's a reason why people would want to... Maybe the debit integration makes it particularly interesting relative to something like Venmo.

Dogan: Yep. Actually, the debit card integration is focusing on Web2 users first because... What WebTree users cannot do right now is that they cannot use the WebTree in their daily life and they have a lot of assets in the WebTree, but they need to convert it maybe in a centralized exchange and then take the money to the bank and then pay for the money. Anyway, this process is so problematic. And also what Venmo cannot do is that Venmo cannot be as transparent as blockchain is. And I think it's a huge advantage on the crypto versus Web2 and we can tap into the day market within just telling what is crypto and what blockchain is doing in this site. But I think Lush may can add something.

Ulas: I think there is the additional power of self-custodial. You can store your funds by your self-custodial wallet and you can use this money to transfer, invest or use by the cards. So I say FinTech because you can do anything you want with your money with Clay.

Nicholas: So you get some of the assurances of self-custody. No bank is going to freeze your account or cause you any kind of problems. There's nothing you won't be able to purchase. But then the convenience of the debit function makes it something you can use every day instead of a bank account, really. Yes. Very cool. Do you think it will appeal to Web3 users as well or primarily to people who are new to crypto?

Ulas: I think I'm a WebTree user and I really need this kind of a solution. So if it works for me, I think it works for any WebTree user because we have some cryptocurrencies and we always need some fiat currencies in our data lives. And it might be an easy way to use the funds.

Nicholas: Yeah, true enough. I know you also do support like email sign up. And I'm curious how recovery works in the Clave wallet. Maybe if I don't provide an email or if I do, how does the recovery situation work?

Dogan: Currently, since it's a pesky, it's just that how you recover your private email. product that Apple has invested billions of dollars. And also, another recovery method that we are working on is that we are working on social recovery. Ulaj, please correct me if I'm mistaken. And also, we are going to be integrating zero-knowledge email within our social recovery process. And maybe I can dive into it if you want.

Nicholas: Yeah, so basically the pass keys can be recovered with iCloud Keychain, but you're also doing... I'm curious, what is a ZK email-based recovery?

Dogan: Yes, sure. So what ZK mail is doing is that it allows any email... to be an on-chain account. So this is huge because you don't need to trust anyone and you can do on-chain actions within sending emails. And what we have done within Zero Knowledge Email Recovery, as we have named it as a universal recovery, is we have integrated recovery module inside of Clave accounts and we allow any email account to be a guardian to your on-chain account. So this just removes the necessity of your guardian needs to have an on-chain wallet. For example, you can add your grandma as an on-chain guardian with using Universal Recovery because she has an email account. So this is as simple as like this.

Nicholas: That's very interesting. Has that been used in the wild yet, or is that something you're building new?

Dogan: We are building it new, and it's not fully tested and ready for mainnet. It's not going to be a part of the mainnet in the start, but we are going to include it in the future.

Nicholas: Very cool. Which 4.3.3.7 implementation does Clave use?

Dogan: Actually, we are not using 48.7 because zcasing has native account abstraction. And this native account abstraction has different interfaces. Thus, we have used our own smart account infrastructure, which has modular approach. And it's going to be open source and we are going to release the audit report today.

Nicholas: Great. Great alpha. So how does it differ in broad strokes from 4337?

Ulas: ZK-SYNC has its own transaction type and every other type. And in ZK-SYNC ecosystem, you don't need any additional bundler or similar third party. ZK-SYNC frequency works instead of them. And our account interface is compatible with all parties of ZK-SYNC account abstraction ecosystem. And also, we have modified our account model to be able to use it in 4.337 systems. So we will be publishing both our ZTC native account abstraction model and 4.337 model, and they will be modular accounts which have lots of new and unique features.

Nicholas: Interesting. So you've really moved away from 4.337 in practice.

Ulas: Yes, but I think they work very similarly. But when it's native, it's more easy and efficient.

Nicholas: Got it. And yeah, could you maybe tell us a little bit more about the zkSync partnership? How did that come about? and why zkSync?

Dogan: Yeah, sure. So Zcasing, I think I have something that I cannot tell right now. But so what Zcasing is doing for us right now is that they are helping us within, especially on the business development part. And they have been helping us since day one. Since we have announced Opclay, they were super helpful to us, both building the GTM around the payments and other related topics. And also they have a huge team supporting us right now. And the partnership is both equally powerful for both parts because we are powering the zk-sync and zk-sync is empowering our products. This is both equally impactful.

Nicholas: That's great. And for the end user of Clave, I guess they don't really need to worry about being on zk-sync aside from maybe what other dApps they want to interact with? Yes.

Dogan: and they don't even know like they shouldn't even know that they are on blockchain. but yeah we are on zkasing and we allow to connect with zkasing ecosystem in clave application and also we are allowing everyone every zk stack chain to be integrated inside of the clave. this is another topic that we are exploring.

Nicholas: But yeah. Even though their chains might work differently, it doesn't matter?

Dogan: I don't know how, what do you mean by...

Nicholas: Sorry, you're saying you're offering other ZK, maybe I misunderstood.

Dogan: Okay, ZKStack is the code base of ZKSync, which allows you to develop your own ZK-based rollup. using zk-things-codebase.

Nicholas: I see. So any other rollup based on the same stack will be available inside of Clave.

Dogan: Yes.

Nicholas: Very cool. Are you thinking at all about transaction sponsorship? Does that play into the UX at all?

Dogan: Actually, it's still under discussion right now, but we want to sponsor our users' gas fees as much as we can. And it's also on our plans.

Nicholas: Yeah, because I've seen like Optimism or Base are offering some amount of sponsorship for, I think it's Base for USDC transactions on Base. So I imagine the other rollups will consider things like this too.

Dogan: Yes, Zcasing is also doing similar things.

Nicholas: Yeah. It's interesting to see them very slowly, but begin to really heat up in trying to attract developer attention. I mean, if you have a roughly EVM equivalent chain, then there needs to be reasons why devs choose to deploy on your chain.

Dogan: Yep. Sponsorship person.

Nicholas: Sponsorship is definitely one of them. I find one of the weakest things in terms of educational materials is nobody really makes it clear how many potential like prospective customers a developer has on each different chain. We have kind of anecdotal sense of who's on which chain, but we don't have a backed by numbers justification of why you might want to deploy on ZK Sync. base or etc. it's to me at least it seems it's mostly marketing and not so much. yes explanation of well there's such and such many thousands of wallets that are addresses that transacted in the last. you know some notion of like a volume and willingness to spend would make these chains more relevant to developers. I think yes.

Dogan: I totally agree on that because if we couldn't have any support from Zcasing and it would be so hard to choice since they are so powerful on the stack, but the other parts also super important and Zcasing has a lot of power in the other parts too.

Nicholas: The business part I think is one thing that's really hard for.

Dogan: technical And also marketing, 100%.

Nicholas: BDM marketing are challenging. Yes. Although I'm not sure that they are the strongest one. I feel like it seems to come in waves. Like there was a wave of Starkware being really loud. There was a wave of Optimism being very loud. There was a wave of Arbitrum beforehand where it seemed like Optimistic... Stack had kind of fallen out of favor a couple of years ago. So it does, once perception from how people are emoting on Twitter is not a necessarily great representation of how they'll perform long-term.

Dogan: But still, I think it's underappreciated feature, but zcasing has native account abstraction and has no smart account feature. smart wallets that is working live right now. I think I have seen in the past a bit of example like Argent or like HaltStation, but none of them has went viral and got a common usage compared to the MetaMask or like other areas.

Nicholas: It's interesting because you said the user shouldn't really have to worry about or even know about which chain they're on. But at the same time, some of the technology enthused crypto natives are often interested in how the technology works and understanding deeply how these things come together. But as you said earlier, there's no need for your customers to know even that they're on the blockchain in the first place or especially which one or whatever. what types of technology it's using. So it's maybe challenging for developers and teams in the space to translate their deep understanding of the technology and its potential into features that are relevant and convenient and trustworthy for users. I'm curious if you have any reflections on sort of focusing on what counts for the end user while still delivering high quality technology underneath.

Dogan: Yeah, sure. So actually our approach on the different technology is that We don't want to build any kind of innovative solution from scratch because it's really so hard to build a new z-casing or a new zero-knowledge email type of innovation. What we want to do is we want to complete the puzzles part and we want to use this kind of innovations in the consumer facing application within to be serving Better UX. So this was our approach since like day one and I think it worked so well.

Nicholas: Yeah, I'm excited to get to try it. We didn't talk too much about EIP-7212, which you also stewarded. That is still relevant. on zkSync, or do they also have a native precompile?

Dogan: Actually, they didn't have, but they are going to implement because they were waiting for... the roll-up informant proposal to be finalized and finally it has been finished and the specs are like has a consensus over it. so yeah they are also going to implement it and working on it.

Nicholas: So if ZkSync is inheriting something like EIP or now RIP 7212, is the execution environment inside ZkSync EVM or is it more than just a stapled on EVM inside? Or are the smart contracts running on ZkSync fundamentally like written in Solidity and Viper and executing in a traditional EVM?

Dogan: I think they are calling... this as an EVM, and they are going to have EVM equivalence on the opcode and precompile with an end of second quarter, if I'm not mistaken. And yes, it's another form of EVM.

Nicholas: And yet they have some, I mean, so it's sort of an EVM running on ZK tech circuits. It's not, but as a developer, you can continue, you can transition directly from mainnet L1 to ZKSync.

Dogan: Yes, there's some differentiators, like there's some of opcodes and precompiles that lives on L1, whereas it's not available on ZKSync. So yeah, it has some differentiators. written L1.

Nicholas: I also wanted to know what the transition from 7.2.1.2 being an EIP to an RIP has been like. Who is stewarding the RIP process and what's the difference between an RIP and an EIP?

Dogan: Yeah, sure. So first of all, getting support from Ethereum protocol as a new precompile is really so hard and when it comes to community educating like we could still uh push this per compile to the l1 but it will take us so long time and we already have a lot of uh passkey or secure-enclave based wallets on L2s and they need this precompile as soon as possible. So we wanted to make the process a bit faster and we wanted to focus for L2 first and show the usefulness of this precompile and then continue to push this precompile to the L1.

Nicholas: And even from the start, 7212 was, in the way that you phrased it in the first draft that I read, was focused on L2s. You really were more interested in that from the start.

Dogan: Yes, this is correct. But there were no forms that you could propose and core change to ethereum roll-ups. but thanks to the roll-up informal proposal standards right now we can do it.

Nicholas: where does the our roll-up improvement process uh come from? is that ethereum foundation spin-off of eips or is it run by different people?

Dogan: it's uh carl and oscar who are researchers in the ethereum foundation.

Nicholas: Okay. And so it's not strictly, it's not like associated with any specific stack. It's intended to work across them all?

Dogan: Yes. Like if you join any kind of roll call calls, then you will see a lot of core developers from different ecosystems, including Arbitrum, Optimism, ZK-Sync, Lina, Scroll, etc., etc., etc.

Nicholas: I don't know if we talked about it, but Clave also has this group splitting functionality that I saw. I don't know if we mentioned it in the earlier section, but that's pretty cool, too.

Dogan: Yes, but after Pesky's integration, I'm not sure if we will use it on mainnet or not. Ulesh, can you confirm it? Because I couldn't follow the latest updates. No.

Ulas: We will leave. Oh, OK. That's separate. Perfect.

Dogan: So, yeah, I think I can explain it right now. So what you can do within Split the Bills is that imagine that you are going in a restaurant and you want to split the bill. And Clave application supports it as a native. But it's not only a restaurant. It can be a trip. It can be... maybe a location or like anything else that you want to spend money within only one account and then pay for your debts. so this is the case within what you can do within your friends.

Nicholas: Very cool. We ran the gamut of a lot of different features of Clave and some of this migration to zk-sync. Are there big topics that we haven't covered that you think we should discuss?

Dogan: Actually, I think we have covered all of the things about our project.

Nicholas: You've done a great job, and it's fascinating to hear the transition. I didn't realize just how deep the zk-sync transition runs in Clave from the original OpClave design. So pretty cool to hear something go from... hackathon project to nearly an official debit card in Europe. Pretty cool.

Dogan: Yes, and we have other cool announcements, including Mainnet launch and something about an upcoming big event in America, in the US. Anyway, so you will hear us in the future And keep following us. I think this is the last comment that I wanted.

Nicholas: Ulaj, did you have anything you wanted to add?

Ulas: No, thank you for hosting us for the second time.

Nicholas: Yes, it was great having you on again.

Ulas: I hope you can try that as soon as possible.

Nicholas: Yes, I'm excited. And for people who want to hear that prior episode, Ulaj was on a few months ago on the EIP-7212 episode. So you can search web3galaxybrain.com. for 7212 and you'll find the episode or ULAS, U-L-A-S. But this was a great conversation and it's fantastic to hear all the progress that you've made since we last spoke. It's exciting to see the app come together. If people want to follow more, learn more about Clave or get involved in adopting some of these standards, where are the best places to find you?

Dogan: I think our Twitter account is the most up-to-date place that we are sharing the announcements. And also we are going to share our community channels where users can also join and ask questions to us.

Nicholas: Are those Telegram or where is that?

Dogan: It's both Telegram and Discord, but our focus is going to be on Discord first.

Nicholas: Great. And I also see you both on Farcaster sometimes. People can check you out there personally.

Dogan: Yes, we are also on Podcaster, LinkedIn, Twitter, and also on YouTube. And for me, I'm also like, I'm the person who is like presenting clay everywhere. So I'm also on Podcaster, as in Dogan Eat. But in Twitter, Dogan Eat account is for Turkish followers, Dogan Eat account. slash in is my english account. so if anyone wants to follow the latest update about clave then i think this is the place awesome.

Nicholas: i'll put links to all that in the uh in the show notes and it's uh get clave is the twitter handle for the man. yes thank you All right, Don, Ulaj, thank you so much for coming and talking about Clay. If I've been waiting for this conversation for a long time, looking forward to it and you delivered. Thanks so much and good luck with the forthcoming launches and announcements.

Dogan: Thank you so much. It was a pleasure to me.

Nicholas: Thanks everybody for coming to listen. See you in a few hours. I'll be talking with Pimlico. Christophe from Pimlico will be on the show at 5 p.m. Eastern time in about three hours, four hours. So be sure to be there. And if not, then see you next week. You can check out past episodes of the show at web3galaxybrain.com with full transcripts as well. Thanks, everybody. Thanks, Ulaj. Thanks, Dogan. Goodbye. Hey, thanks for listening to this episode of Web3 Galaxy Brain. To keep up with everything Web3, follow me on Twitter at Nicholas with four leading ends. You can find links to the topics discussed on today's episode in the show notes. Podcast feed links are available at Web3GalaxyBrain.com. Web3 Galaxy Brain airs live most Friday afternoons at 5 p.m. Eastern Time, 2200 UTC on Twitter spaces. I look forward to seeing you there. Thank you.