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 guest today is Derek Chang, CEO of Zerodev. Zerodev is a smart account provider whose SDK makes it easy for app devs to integrate social authentication, passkey signers, Paymaster gas sponsorship, transaction bundling, and third-party plugins. In this conversation, Derek and I discuss 4337 in depth from the perspective of the app dev. We talk about the differences between wallet signer providers and smart contract account providers, how to choose between the many smart account implementations, and which transactions to sponsor as an app dev. Derek also shares some alpha about an upcoming product that will synchronize smart account state across chains. It was a pleasure talking to Derek in this wide-ranging and detailed conversation about 4337 in practice. I hope you enjoy the show. 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, Derek. How's it going?

Derek Chiang: Hey, Nicholas.

Nicholas: Great to have you here. Yeah. Thanks for coming on the show. I'm excited to talk about Zerodev.

Derek Chiang: For sure, for sure. You know, thanks for inviting. I've heard really good things from, you know, about this podcast from many friends.

Nicholas: Oh, that's great. Oh, I'm happy to hear that. You grew up in Shenzhen, right?

Derek Chiang: Yeah, that's right. I grew up in Shenzhen, and then I went to the U.S. for college, and then being here for like, you know, 11 years now.

Nicholas: Wow. I spent about a month and a half in Shenzhen. It's an amazing place. I visited lots of factories and marketplaces and things. Very, very cool place.

Derek Chiang: Yeah, you know, it's built as the Silicon Valley of China, you know, for a reason.

Nicholas: You also have a background in distributed systems, right?

Derek Chiang: When I was in college, my area of focus was distributed systems. I did some distributed systems research related to just like, you know, like large-scale databases and whatnots. So that's actually what led me to become, you know, interested in blockchains, just because like blockchains, if you think about it, it's really just like the largest possible distributed system, right? So like, I would say that I got into blockchain from the perspective of a distributed systems researcher, you know, so that's why I like. the first few projects I worked with were like, layer ones, right? You know, so I wanted to see what it's like to build just like really, really large and scalable blockchains. And then I, you know, kind of like, you know, just like through some really interesting journey, I kind of wound up working on ZeroDev.

Nicholas: Yeah, well, I wanted to ask you a little bit about this journey. But just before we move on from distributed systems, like, what are the issues that people in distributed systems typically work on? It's not usually blockchain stuff, but more, I don't know, what kind of problems is distributed systems pointed at usually?

Derek Chiang: Well, so when I was working on, I would say, you know, just like, you know, in my pre-progress, pre-blockchain days, I worked a lot on distributed databases, right? You know, so basically, even today, right? Like, if you're working on some kind of like Web2 projects, you'll probably be using a database like MongoDB, like, you know, like Cassandra, you know, right? You know, so those are like large cloud-scale databases that are kind of like powering, you know, basically like the, you know, like the really big Web2 applications like Facebook, you know, and Google, you know, you know, you know, like that we know today, right? You know, so like, even if you don't consider. Blockchains, like, just like storing a massive amount of data, you know, like the Web2 context is actually already like a really, really big and difficult problem, right? You know, so, so, so that's kind of like what's distributed systems research was, was typically about.

Nicholas: We'll get into the blockchain stuff in a second, but I'm curious, I see people talking today about how, I think it was someone from foundation was saying, you know, people, people shouldn't use L1 or really any of the blockchains related to EVM as like a data storage solution. Whereas there's. Other people who are really focused on that kind of thing. Is there, given your background, do you have any faith in particular in, I don't know, Arweave or Celestia or any of these things? Do any of them strike you as particularly interesting solutions?

Derek Chiang: I mean, I think, I think, I think the move towards kind of like just decoupling the, the, you know, like a monolithic blockchain into multiple modular components is definitely a very sensible and reasonable, just like direction, right? You know, I think, I think like in particular, just like this idea of like having like. A separate data availability, DA layer, right. You know, like for your blockchain, I think, you know, I think, I think it's, I think it's that like, definitely makes a lot of sense from like a distributed systems perspective. Um, I think some people that have gone as far as saying that, like, perhaps, uh, you know, like, like, you know, like, like people can even like in theory, like use a web tool storage solution, such as like, say a AWS S3 buckets or like a regular database as like the DA layer. For. For a blockchain, right. You know, but I think they will probably be taking it a little too far, you know, just because, you know, I think like. at that point, you know, you know, you're kind of like defeating. kind of like, you know, like one of like the, the main reasons why people use blockchains in the first place, you know, you know, you know, which was that kind of like this idea of a always on, always available computing environments, right. You know, cause it's like, like, even though it's technically possible to kind of like have like the execution layer and the settlement layer be like decentralized, but like just have the. DA layer. Layer be like a web tool storage system, you know, to achieve like maximum scalability, the reality is that like, like if that's layer is centralized and kind of like, it's almost like a bottleneck, right. Right. You know, so like, so if like the storage layer goes offline, if like the, if like, if the company behind the layer, um, you know, like, you know, it goes, uh, goes bankrupt and like, you still lose access to, to the, to the entire blockchain. Right. You know, so, so I think, you know, I think overall, I think it's a good thing that people are kind of like taking more of like the, um. Um, the theory and science from traditional distributed systems, researching to blockchain, but on the other hand, you also don't want to go too far and kind of like, just like, uh, you know, to kind of like essentially remove like the thing that made a web through interesting in the first place.

Nicholas: Yeah, absolutely. Um, speaking of which I wanted to ask you, I'm very curious about your last position before zero dev was as CTO of eternal, um, which for people who don't know is like a Twitch streamer clipping NFT platform. Uh, YC backed, uh, like over 4 million raised built on flow. I'm curious if you had any reflections on that, cause I think it's still a very interesting product, but was it an issue of timing or did you learn anything in particular from that experience?

Derek Chiang: Yeah, I think, I think, I think like our success and failure with that company were both due to timing. Right. You know, meaning that like, you know, we actually had, had a lot of success when we launched, right. You know, cause like there was, I think backing, I think it was like 2021, right. You know, um, you know, so, so, so there was like when NFP was just exploding. And we were, you know, so like both me and my co-founder were big basketball fans. So we were, we were like really inspired by the success of NBA top shot. Right. So we, um, and, and, and, and given that my co-founder was like very connected in the e-sports slash streaming industry, you know, like we, we, we came up with like this very natural idea of kind of like essentially doing NBA top shots, but for e-sports and content creators. Right. You know, so, so we want to work with like e-sports players and content creators and help them issue essentially NFTs. Right. In order to kind of like, just, just like, as like a new way for creators to monetize.

Nicholas: Makes a lot of sense.

Derek Chiang: So we, we, yeah, yeah. So we, we actually had like a lot of success or, you know, I think, I think, I think we sold close to like a million NFTs in total, you know, which is like a lot. Um, but you know, I think, you know, like when the markets crashed, just like, you know, you, you know, I think it was like late 2021st, right. You know, or like early, early, early, early 2022, you know, I think that's when, um, you know, we just kind of like had to make them to, had to make the difficult decision. Uh, you know, or rather, you know, like the, the difficult decision that's, you know, perhaps like, you will be more responsible to kind of like, just like, um, basically like seek and exits for the company, you know, just like, you know, like before things completely crash, you know, uh, as opposed to kind of like trying to just like continue to, cause the, the, the red here was that like, even though there was a lot of like a willingness on our sites to continue the projects, um, the. The content creators. the content creators that we worked with, they were all very spooked by like the negative perceptions of NFTs at that point. Right. You know, so like, you know, we, we, we, we kind of ran into this like position in which, um, essentially like if, if a creator says that they work with us or that they want to launch an NFT in general, like they will just receive such backlash from the community. That's, you know, it's like, like, like we, we basically got to a point where like all but the most brave creators, you know, we're not willing to work with them. Right. Right. You know, we're not, we're not willing to work with NFTs anymore. So at that point, you know, we just decided to sell the company, you know, at like a reasonably good price of, you know, and return as much value to investors as possible, you know, you know, like as opposed to continuing the project.

Nicholas: Yeah. It makes sense. Um, and especially cause you were focused on the like top 0.05% of Twitch creators. So I'm sure they're especially sensitive to kind of public perception around these things. It's interesting that at the same time, the Reddit, uh, collectible avatars project has kind of flown under the radar somehow and been quite successful with an audience. That's, that's pretty skeptical.

Derek Chiang: Yeah, that's right. Yeah. You know, but I, I, I, like, I will say though, that like, um, my experience from, you know, eternal was actually like what inspired me to work on zero death. Right. Cause like back then we were trying to obviously like build this platform that's um, will allow the regular fence of content creators to purchase NFTs. Right. And so, so, so we really just like struggled first hand with like this problem of like onboarding web two users to web three. So that was kind of like what got me, just like looking into things like things like account abstraction. Um, so yeah, so, so, so, so, so, so after we won, we, we, we won down that company, like it was like a very natural path towards, uh, working towards working on zero death.

Nicholas: So it was mostly about simplifying the onboarding experience, the move to smart accounts, because there's also this element that you returned to more like a EVM orientation as opposed to flow blockchain. So I guess there's, it's in one, in one way you're making a move to do easier UX, but in another way, maybe more difficult, because it's sort of less a Fiat oriented than flow was.

Derek Chiang: Um, that's right. Yeah. So, so, so we, we, we made a decision to build eternal on flow because, uh, like that was the, blockchain, the NBA top shot was spelled on. Right. So since we wanted to build a NBA top shots for content creators, we thought that's like, we, we, we, we, we basically wanted to leverage a lot of like the open source codes and infrastructure. that's, uh, NBA top shot released, right. You know, in order to very quickly ship and build our products. So, um, so, so, so, so that's why we went, so that's why we went with flow. But I think, um, it's definitely very much true. that kind of like experience of, of working with flow also made me really admins about just like working with, with, with the EVM for my next project, just because, um, cause you really see the limitation of like working with like a, just like a less popular blockchain. Like once you actually work with it, right. Cause it's like, um, there's just like not that much liquidity. Right. You know, right. You know, I, I think, I think like back when we were working, on eternal, like we pretty much had to rely exclusively on, um, just like kind of like new users. Right. You know, cause like there are not that many just like native flow holders that we could leverage. Right. You know, so we, so, so, so, so, so we basically like have to guess like new users to onboard web three in order to have like any liquidity in our system. But like, if we, we were building on EVM, then we could have also kind of like work with like people that already have, you know, you know, that, that are already, that, you know, that they already have group. Right. Yeah. And, you know, and I think another really big thing was also that like, um, so flow, so flow, so flow actually had actually heads, uh, native, native account, objection, you know, you know, which is like a very little, little non-fact, you know? So, um, yeah, exactly. Yeah. So, so, so there was also why kind of like, I saw firsthand the power of a kind of objection. So like, so I thought that's just like the fact that's EVM didn't have that with such like addiction. So that's why like I wanted to kind of like, just to just work with just work on a work on a projects that would bring a kind of objection to, to the, uh, to the EVM.

Nicholas: So in the EVM context, uh, what's the problem that zero dev is solving? How is account abstraction helping?

Derek Chiang: So from the highest level, um, a kind of structure is about the wider adoption of smart contract wallets.

Nicholas: Right.

Derek Chiang: So, um, and the reason why the wider adoption of smart contract wallets is important is because, um, right now, you know, users, they have to choose between two things, right? They have to choose between UX and self custody, right? So if a user wants UX, they will use centralized exchanges today. Right. Right. You know, it's like, it's like very easy to use some kind of like centralized solution, right. You know, like, you know, cause like the experience, the experience is like purely web tool. You don't have to deal with like, see phrases. You don't have to deal with guests. You don't have to deal with transaction signing. Everything just works. Right. You know, so, so, so, so on one end you could choose UX. On the other hand, you can choose, uh, self custody. Right. So it's like if you care about self custody and being able to interact, being able to interact with the, you know, with the wider Web3-DeFi ecosystem, then you will be using things like MetaMask, right. You know, uh, but, but then like you will be sacrificing UX because you have to deal with, you know, like all the, just like big, big UX issues with, uh, you know, with Web3 such as like guests, transaction signing, see phrases and whatnot. Right. So smart contract wallets, it's the only way to achieve both UX and self custody. Right. So like from, from, from, from a high level, like this is like, this really is like the most important point, right. You know, like smart contract wallets is really the only technology that will, that will enable people to have both UX and self custody. Right. So with smart contract wallets, you can have a totally self custody wallets, um, you know, that you can use to interact with like the wider DeFi and Web3 just like protocols and applications. So why are, you know, at the same time having the same smooth web tool like experience that people are accustomed to today from centralized, from centralized exchanges. So that's kind of like, you know, just, just like really, just like the really big things that we are working on top of.

Nicholas: So like, I guess the main UX pain points in a traditional EOA are seed phrase, which is very unusual to have to deal with in an onboarding experience and also kind of difficult for some, aside from like the friction of, of during the onboarding process, they also have to in the longterm keep hold of that thing. Uh, then there's also, um, uh, the, the sort of, uh, the non-abstract part, the one-to-one relationship between that seed phrase and a specific account versus with account abstraction, you get the advantage of. maybe you can have different logins or you can change your email address that is associated with the login or whatnot. Do you think those are the main UX advantages? or do you think, uh, yeah, I guess, how do you think about the advantage to a developer? Who's looking at these tools?

Derek Chiang: So, um, I would say that like there are actually like many, many advantage of like smart contract wallets over EOAs, but, um, to date, the three most relevant advantages that's kind of like, you know, like really get people excited about AA are basically, um, you know, seed phrases, right? Uh, guess, right. And also transaction signing. So here's what I mean, right? so, so for, for seed phrases, um, w with a smart contract wallets, you can implement the smart contract wallet in a such a way that it's not going to be the same as a traditional EOA, the way that it recognizes, um, basically signing beyond kind of like the normal Ethereum, ECDSA signing algorithm. And what that means is that, um, you can use kind of like hardware devices that we already own to sign transactions, even though the signing algorithm is like difference than what Ethereum natively recognizes, right? You know, so, so like one very big check in, which I'm sure you're aware of, uh, is the idea of like a passkey, right? So passkey, right. it's like a, just like hardware key. that's, um, companies like, you know, like Apple and Google have like integrating into, into, into, into their devices. So like in the future, I have no doubts that like most people, most people will be signing their transactions with just like the devices that are already on, right. whether it's like an iPhone or like a Chromebook or whatever, right. so, so, um, the idea, like the ability to sign transactions with the devices you already on is the fundamental reason why you can remove C phrases, right. Because like, you don't, you don't, you don't need like a external private key to sign transactions anymore. Right. Um, and then the second really big thing about AA is of course gas, right. So like right now for like a new user to use web three, the first thing that I have to do is to on rep, right. You know, you know, so it's to get some native tokens so they can interact, so they can interact with the protocol. Um, but a really big trend that we're seeing, especially with like layer two and layer threes becoming like a really big thing is that like, as like the gas costs of like interacting with blockchain decreases, it becomes more and more viable for the application developers to simply sponsor guests for their users. The same way. that's kind of like when you use like a web two applications today, you don't really think about paying for the server costs, right? Cause like the, the, the web two application developer, they are totally okay with shortening the silver costs. because that, because they're so cheap comparing to like the value compared to the value they can catch up. Right. So I think we're definitely moving to a future in which, in web three as block space gets cheaper, there will be like, it will be more and more common for people to just like sponsor guests for users. Um, and then kind of like gas, which has become like a thing of the past for like most, for most blockchain interruptions. Right. So gas is also, is also not a big thing. Um, and then the last thing is our transaction signing. So right now, you know, I think for people like you and me who have like, you know, who use blockchain a lot, right. we are super used to this idea, you know, like this experience, that's like, every time I need to send a transaction like MetaMask pops up, I confirm and then the transaction set. But like for a web two user, that's like a very foreign and very, um, just like annoying experience. Right. So, um, the really cool thing about smart contract, what is, is that, um, it's possible to kind of like delegates certain transactions for a third party to execute for you. So what I mean by that, is that like, um, so imagine like, um, for example, right. Let's talk about, uh, I think for example, like let's talk about like dollar cost averaging, right. Right. You know, you know, like, like this idea of like, uh, just investing in some tokens like once a month or something. Right. So even something as simple as that is not actually doable today with today's wallet, because like every transaction needs to be science, like personally, right. Right. So, so you're, so you have to be kind of like very active and like be online in order to invest. But if you are using a smart contract wallets, then you can form a smart contract agreements with the protocol. So they're like, you're essentially allowing them to send a transaction for you every month to invest for you. Right. And like the, the permission you give to the, the, the, the, the permission you give them can be very, very specific so that there's like no way for them to abuse that permission. Right. So, so you can be very specific about, okay, like they can only send one transaction for me per month and only for the, that much money. Right. So, so, so, so, so, so this idea of like, just like transaction automation is actually like a really, really powerful one that will really revolutionize like how people interact with like web. three. Right. So, so basically like, you know, like it will no longer be the case that like every transaction has to be manually signed, but rather there can be like a lot of like automation. that's, that will kind of like really simplify the, the, the, the user experience. Yeah. So, so, so, so. basically TLDR, the three big advantage of smart contract wallets, as I see it today, you know, being able to sign transactions with the devices you already own and therefore removing the need of C phrases and to, you know, being able to skip guests. Right. And three, you know, being able to automate transactions so you don't have to like manually sign every transaction.

Nicholas: That's a great overview. So we'll, we'll dive into a little bit of each of those subjects. But first I wanted to know, what's the difference between the different four, seven implementations? Offered by zero dev and other service providers. I know you use kernel, right? Uh, what, what are the advantages of kernel versus other things? Or how do you think the ecosystem will play out between the different implementation options? Sure.

Derek Chiang: Sure. You know, so, so, so, so. first of all, you know, to, to kind of like, just like clarify, clarify on the terminology, right. so like, um, it wouldn't be technically accurate to say that like there are like different implementations of four, three, seven, right. Cause like there's only one canonical implementation of four, seven, which is like the one, uh, developed and deployed by the Ethereum foundation. Right. So like everyone's like building on top of like a, a, a standard set of smart contracts deployed by the, by the Ethereum foundation. So, so what you're referring to is the smart contract, right. Right. So, so, so zero dev, um, you know, so kernel is the name of our smart contract implementation. We call it kernel because it's like very much inspired by the Linux kernel in the sense that you know how, like the Linux kernel is kind of like the, it's like, it's like a minimal operating system that's like many other operating systems built on top of, right. For example, Android is building, you know, you know, it's spelled on top of, on top of the Linux kernel. And so it's like something like Ubuntu or Fedora or something. Right. So the idea behind kernel was that we wanted to build a minimal and extensible, um, smart contract wallet that is compatible with four, three, seven, but it also has the ability to be compatible with like any forthcoming, uh, a contract and standards. Right. like if anything gets like, uh, why is it about it? Right. But the, but the point is that like, like this smart contract wallet is not a full wallet in the sense that's a MetaMask is like a full wallet. Right. Right. it's like the, the, the end user doesn't interact with kernel the same way that they interact with MetaMask is really just like the back end of the wallet. Right. And then like different developers, they can build their own scheme of front ends on top of kernel, uh, in order to very quickly get like this, like smart, smart contract, account abstraction functionality, the same way. that's kind of like, um, just like say smart phone makers, they can quickly build on top of Linux and build on top of Androids in order to quickly get quickly ship a smart, a Android powered smartphone. Right. You know, so it's kind of like the same idea. Um, but kind of like what really sets kernel apart. I mean, so, so, so first of all, right. Like, like, um, some, some, some stats, right. So kernel today powers, I think over 60%, of all account abstraction, what it's ever deployed.

Nicholas: Wow. Right.

Derek Chiang: So kernel, so kernel has like incredible, uh, adoption, I think, um, for two reasons. So once it was once just because like we, we had like a, we had like a first mover advantage in that's like, we were really like the first production ready, um, kind of like a production ready and extensible, like, um, uh, smart contract, what it's that's compatible with like, uh, yeah, simple to do seven. Right. But also, you know, like we just, just from like a technical perspective, like it really is just is kind of like the most superior smart contract. What is, um, like out there, like, like, especially, especially in the context of, of, uh, you know, of a, right. like it's, um, it's like extremely extensible, right. Right. so, so, so, so like the, um, like different, uh, smart contract, what the developers can very easily develop like this plugins that can extend the functionalities of kernel in order to cost in order to customize, kind of like the, uh, the wallets to their needs. Right. Um, and also it's also very like gas efficient. Cause like, cause like one big drawback of like smart contract, what is comparing to, to UA is that like, there's like some guests overheads when you use a smart contract, what is right. Cause like the, like the logic of, of the wallet is implementing smart contracts. So naturally there's like some overheads with like every transaction, but we have taken great care in like optimizing the wallets such that like the overhead is like a minimized. So, so we, we actually like published like some, um, some really like wisely used benchmarks in which kind of like, it's fun that like, like kernel kernel has like, like I like a very wide margin, you know, it's like the most optimized, uh, a wallet out there. Yeah. So, so I would say that like, just like our extensive, our extensibility and our just like gas gas optimization is like a really big reason why kernel has been super widely adopted. But I do want to just like make a clarification. That's, um, kernel is at the core of our products, but kernel itself is not a product, right? cause like a smart contract, what it is like a set of smart contracts are not a monetizable product, right? So like the actual products that zero dev is selling, um, is a, a kind of extraction embedded wallet, right? So I'm sure like, you know, like everyone here is like familiar with like the concept of embedded wallets, right? so like, you know, like, um, like there are companies like privy, like magic, web three auth, right? so like, um, so zero dev is also a embedded wallets, but what makes zero dev kind of special is that we are, um, we are not just able to be used as a self content, embedded wallets, the same way that say privy and magic can be used as like a self self content, embedded wallets. Like we can also be used on top of like, uh, existing embedded wallet solutions. So if you go to kind of like the zero dev documentation, you will see, see that we have integrations with like all the most popular like embedded wallet providers out there, right? so like if you're already using say privy or, or, you know, or web three auth or magic, we've developed integrations with these companies so that you can put zero dev on top such that's the wallets that these services wound up spinning up will wound up being a account abstraction smart wallet, right? And then from there on, you can rest, you can use the rest of zero dev tech with the embedded wallet. In order to enable like functionalities such as like, you know, like passkey signings or like, or like our sponsoring guests for users or like batch transactions or like, you know, session keys and whatnot.

Nicholas: So basically, uh, the ecosystem maybe can be divided logically into two parts. The wallet embedded wallet providers who are really handling authentication and signing at the app experience level, be that a web app or a native app. And then there's like smart account providers like zero dev. That are, uh, plugged into those. So the wallet providers are the ones that handle authentication and signing and zero dev provides the services around bundling and, uh, four through three, seven accounts, et cetera.

Derek Chiang: That's right. Yeah. So, so, uh, you know, just one clarification there. So, so, so, um, like we've also built zero deaf in such a way that it's possible to use zero deaf as the whole thing. Right. Right. so, so zero deaf can also be used, uh, I guess spent the long way, you know, that, you know, that includes like both, like, um, it includes like the UI, the signing, the key management as well as like the account objection, smart wallets. But the reality is that like the, uh, the UI layer is like a heavily, um, contested space, right? Like there are like many, many solutions out there. and people have different preferences when it comes to what kind of UI or signer they want to use. So that's why we've also made our product compatible with these wallet providers so that you can also use ZeroDev only for the purpose of account abstraction and not so much the signing part.

Nicholas: So if you want, you can use ZeroDev for the full stack, but you don't expect to be able to be competitive with all of the different options for front-end solutions. That's right. That makes sense. Do you think ultimately that will continue to be the case or do you think providers like Privy and Magic will end up doing their own smart account implementations also?

Derek Chiang: That's a really good question. So I would like to think that what we're building is very, very technically challenging. So the only reason why we have been able to build what we're building is because me personally, as well as my CTO, as well as most of the core teams, like they, like we are like, we have been like involved with 437 way before it even came out, right? You know, so we were like really, really deep in the community and we really know the ins and outs of account abstraction and smart contract wallets. And that's why we have been able to build just like kind of like a really competitive smart contract wallet solution, right? So I'd like to think that it's like going to be way more just like economically just like a rational for other wallet providers to partner with us rather than build their own just like AA solution. You know, but you know, I think it's definitely in no way guaranteed that like, they won't attempt to kind of like build their own just like full stack thing that includes like the AA stack as well, right? You know, but like so far that hasn't been the case. just because, you know, just like the kind of expertise, like the kind of technical expertise that's needed to build what we build is very simply just like very different than the kind of expertise that like these teams have today. Right. But yeah. So, that would be my answer right now.

Nicholas: - You mentioned your CTO. It's Taek Lee, is that right? - Did you work together before or is this your first project working together?

Derek Chiang: - It's our first project together. Yeah, you know. So, it's interesting. 'cause, you know, he actually wound up joining the team because like, like when I was working on it, you know, like, like, you know, was developing zero death. so i got like this dm from tech right you know. so so so so so at that point like we we didn't we didn't know we didn't know each other right you know. so it was just like it was just a random dm. so so it was a dm about how he finds a security vulnerability in our smart contract. um and you know how like kind of like. it's actually like very common if you work in tech to receive like this kind of dms from so-called security researchers about your security vulnerabilities. um in order to kind of like. you know people usually like they expect some kind of like bounty right so like i thought that. so i thought that it was just like one of the one of those spam messages so i didn't like one of. so i didn't wind up replying at first yeah but then like later you know like when i was kind of like reading his message in detail i realized that he actually knew what he was talking about and then like you know like the the vulnerability the vulnerability that he was pointing out was actually real. so that was kind of like how we wound up like talking and then like you know it just like you know yeah and and and and then you just like want to become children in which because like tech is actually like kind of like like he like he was like he actually is like one of like the person that contributed the most to the eventual shipping of 437 right you know like like he he yeah so so like. he single-handedly identified like some of like the most security critical um security critical vulnerabilities in 437 like before he came out. so he was like really instrumental in the shipping of the whole you know uh you know of the whole standards. so he's like actually like really really well known uh within the 437 community. yeah so so so yeah so so i think i think i think i've you know we we all feel very lucky to have him on the to have him on the uh like on the team. that's great.

Nicholas: and how big is the team so far?

Derek Chiang: well the team is uh five people right now uh about to become six because we you know we just like recently made an offer to someone nice and nice and lean that's the best.

Nicholas: um so i i wanted to just round out the discussion of the 437 providers in the first place. um how as a dev if you were approaching building an app of your own would you decide which smart account provider to go with?

Derek Chiang: so i think like there are like a few things to consider right you know. so at the most basic level you want to go with something that's like really reliable in the sense that like the last thing you want is for there to be some kind of issue right you know it's like. it's like you don't want to launch with like uh you know like smart accounts and aa only to kind of like have your users lose money right you know. because you know because of yeah because of a vulnerability in the smart contracts or kind of like to have your app go offline because of a um just like kind of like the the like the the the bundler you know you know like the like the bundler are like the nodes that kind of like power like the contractions transactions right so it's like you also don't want to like the security and reliability is probably like the top most concern and i would say that like i would say that we have like a really big edge here just because again right you know like the fact that kernel is like so widely deployed um and like so far there has like there has been like no vulnerability being funds just to kind of like gives a lot of confidence in the fact that it's kind of like. we're likely the most uh secure solution out there right um. and then like our infra i think it's also the most reliable just because you know we kind of like you know like pioneers this idea of a um. uh you know we call it like a meta bundler uh meaning that we kind of like work with like all the bundler providers out there uh and. and we kind of like short traffic between them um but also like if one bundler goes down you know which unfortunately happens from time to time. like we can like transparency like route the traffic to another so that like the the the end user doesn't notice any downtime. right. so from like a security and reliability perspective um in terms of integration right you know because like again it's very popular to use zero dev on top of one of one of these like embedded wallet solutions. so just the fact that we have like really good integrations with like all the like really popular uh embedded wallets providers out there it's like another really big reason to use us. um. third thing is just like the fact that zero dev is just. it's just like the most powerful smart contract wallet or wallets today. right. so like because kernel is extensible our community have developed just like a lot of like really useful plugins such as like multi-sig recovery session keys. so when you use like zero dev you also get all this for free right. so it's like you know using zero dev means that you can as your application grows you can integrate more and more powerful smart smart account functionalities into your application. uh in order to enable just like really powerful functionalities for users.

Nicholas: makes sense. um you talked about being uh involved in 4337 for a long time even before it was finalized. i'm going to be having a conversation next week with some 4337 skeptics who are uh still fans of 3074. i'm curious if you have any takes on why 4337 is better than 3074.

Derek Chiang: so um this is like a very interesting question because i i like i i don't think it's you like. i think it would be incorrect to say that 437 is better than uh 3074 right or you know? or really like. you know like a number of companies um. so i think i think this is like really kind of like a meta point in which like it's not always like the best technology that works right it's like that's. that's not like. it's like it's like right right it's not like. it's not. um it's like like. that's not just true in aa but also just like in wider technology industry in general right. so i think um 437 is like a really really good case study in which you really realize just like especially like especially in blockchain how important just like social coordinations are right. so i think like the reason why 4337 succeeded was because obviously it's like a out of protocol proposal right meaning that it doesn't take any buy-in from like the core ethereum developers or before before 4337 can be implemented. right because like everything is like implemented as smart contracts. that's like just like out of protocol. um like software such as like bundlers um um so so. so therefore like even though there were not necessarily more believers in 437 than believers in something like 3074 only like it was only 437 that was possible to be deployed. right because it's like it's like like it didn't really matter. that's only like a small core group of people believing 437. uh because they can just deploy 437 without the consent of of like other people right and like once like the the protocol is up and running now naturally kind of like. there's like this flywheel effect of like a small core group of believers kind of like you know attracting like attracting like like more people that that i you know that are curious about the tech building on top of 437. so kind of like the ecosystem just like snowboards into how it is today. right but like it wasn't necessarily the case that the the the the the the the the 437 than people who believe in something like 4 something like uh like a native a protocol like 3074. it was just that even if you believe 104 in 3074 you could not have done anything unless you could convince the wider ethereum core developer community to implement that into the protocol. right. so yeah so so i would say that you know it wasn't it would like like. it really wasn't the case that like the tech was better. it was just that like it was like the only like viable path towards the kind of structure.

Nicholas: yeah i think that's a very mature perspective. it's i think it's hard for devs sometimes to see that it's not just the tech that matters but also the adoption mechanics and the social aspect. it's. it's tempting to think that just the technology is all that counts but it's really not true definitely definitely so. um you mentioned that uh zero dev has like tons of adoption 60 plus of wallets. so far i'm curious or a smart account so far i should say i'm curious. uh which chains is zero dev primarily popular on right now?

Derek Chiang: so i think i think polygon definitely by far has the most volume um. but i think that's just because polygon just has like the most like like by far the most volume in general right right like like like among all the um like among all the um kind of like side trends and layer tools. right um. but i would say that we're also pretty popular on like arbitrage optimism and base. yeah so pretty much like all the popular evm chains do you have a sense of what people are using these for?

Nicholas: or are they airdrop farming or something? do you have an idea?

Derek Chiang: yeah so so honestly like airdrop farming has been like the primary um traffic driver product market especially like. yeah exactly right yeah i think i think especially when it comes to things like sponsoring gas for users right you know i think um just like the ability for people to mint things for free right you know i think that. i think that i think that you know that's just like a very natural use case of the technology um. but i would say that kind of like the use case that's i'm most excited about are definitely uh in defy right you know because like uh you know well you know we are having a lot of like defy protocols building on us like building on us right now. and the reason is because um there's just like a very strong synergy between aa and defy right. so beyond kind of like the three major um aa features that we talk about you know like removing c phrases uh abstracting away guests as well as like transaction signing um another. another really big thing is also transaction batching right. so transaction batching is this ability to kind of like send multiple transactions as one right. and it's particularly it's particularly important in defy applications because today when you interact with the defy protocol it typically involves like more than one transaction to do. to do anything right you have to like approve um like a token and then you deposit and then you swap and sometimes you even need to kind of like um talk with like customers before you can do one thing right. so for example if you want to like i don't know like maybe like um take out a loan in compounds and then putting and then put like the loan back into other in order to form something. so that's also something that involves like many many transactions. so the ability for a defy front end for a defy application to batch them all into one transaction it's just like really such like a leapfrog in user experience. but that's like most relevant in defy right um. and then like you know transaction automation you know which you know which i talked about before. it's also really important in defy because um um you know how like in defy like a lot of the times. so so for example right you know like for for lending like. uh liquidation is always like a really big issue right. it's like if your collateral the value of your collateral drops like there's like a chance that um your collateral could be liquidated if you don't pay the loan back right. so uh today you kind of requires like that the user either just like over collateralized or just like kind of like they have to like. they have to like very vigilantly watch watch their positions um in order to kind of like. you know just in case like they might get they might get liquidated right um. but with transaction automation you can now actually delegate to the protocol for them to pay pay the loan back for you um if your position is in danger of getting liquidated right. so so so so things of that. so things of that nature you know are also you know and that's only possible with like smart counterparts that that's very interesting.

Nicholas: that makes a lot of sense. we usually focus so much on the ux side of things and the user onboarding especially. but you're right it actually makes more sense for people doing more complex interactions. uh that are more advanced users. actually um which type of signers do devs prefer today with zero dev?

Derek Chiang: so today i think the um the most popular signers are still definitely social signers right you know just like um you know. so so so to be honest i don't think there's a lot of to be. to be clear you know like when i say social signers um it's not like kind of like a google accounts has the ability to sign right it's more like there are like some technology providers such as like privy or magic that are able to kind of like turn a social accounts into a private key through some like npc magic right you know um. and then kind of like using that as the sign. right you know but you know but but but from like the end user's perspective they are just like and then they get a wallet right. so so yeah so so so today's social social signers still definitely by far the most popular. um uh but i think like past key is also like picking up steam as well.

Nicholas: i wanted to ask you about the social signers. i'm still a little bit foggy on how they actually work. like where if i log in with google or facebook where does the private key live? am i am i essentially authenticating into google and then that's giving me access to a private key that's sitting on someone's server? or or is it really just like a private key some kind of npc distributed key generation solution? where where is the private key?

Derek Chiang: yeah so so so different. um like different technology providers like they do it differently right um so uh web3 auth today is probably like the most popular. it's probably the most popular social signer and the way that it works is that they basically have a decentralized network of nodes right and then when you log in with google um it's like google they generate some kind of like uh cryptographic token right you know that kind of like a test to the fact that you're logging to google right. so you essentially send this token to um all the nodes in this network and then basically like there's like some kind of like a um like uh like an n like an n out of n thing going on right. in which kind of like maybe like as long as like three nodes out of like i you know like out of like like like i don't know how many like um a test to the fact that you could attest to the fact that you did successfully log into google. um these three nodes. they would then kind of like perform some kind of like npc magic in which kind of like each node has like a fragment of your key shell right. so then like they would essentially uh combine their key shells to generate the key for you right. so basically like the tldr is just like. there are like there's like some distributed. there's some distributed network of nodes that are able to kind of like verify the google token and then once they verify it they do some kind of like like a distributed key generation and the npc to generate a key for you.

Nicholas: and that process of verifying the jwt or whatever it is is something that anybody could do it's not. it doesn't require any kind of elevated privileges. with regard to google in particular i can just verify that someone has for example connected as a owner of a twitter account when twitter returns the token.

Derek Chiang: anybody can do that right for sure for sure you know. so it's the same way that like or kind of like today like pretty much anyone can can can can create a website that's works that works with google logging. right you know it's very it's very easy for people to integrate like a signing with google button into their website. so the reason for that is because like the way that the google like the o the oauth system works is that like anyone can verify the fact that you log into google got it.

Nicholas: so then and then for the actual holding of the private key there's i guess a variety of solutions between npc solutions where there's these sharded options or maybe even other solutions where they just hold a straight private key on a server somewhere. so basically you sign in with google prove you own the account to some system that then is able to use probably just a regular old k1 curve eoa as the signer on the smart account excited. um i like you i'm really interested by the passkeys uh movement. i guess you could say even uh maybe people have seen i think it's passkeys.director. it's just like tons of services you know adobe coinbase amazon google apple everybody's whatsapp. even i think whatsapp announced recently that if you create a new whatsapp account on an android phone. it's by default a passkey um and google is prompting everybody to switch over to passkeys from username and password. so it's it's really picking up steam. um i'm curious if somebody creates i guess it will depend on which provider they use for the wallet aspect if they use zero dev or privy or somebody else that you're integrated with. but i'm curious if they create an account uh like a zero dev smart account with uh let's say in uh you know demo app um will they be able to connect to that same smart account from uh you know demo demo app b from a different app or will they be restricted to accessing it through the app that generated the embedded wallet signer in the first place?

Derek Chiang: um so the way that zero dev works today is that uh the same private key will always use the same smart accounts. so uh if you for example like use um the same say web through auth uh google social like signer like on two different apps then they will use the same smart account.

Nicholas: okay great. so so if two different dap developers integrate zero dev then uh the same like google login will have access to the same smart account.

Derek Chiang: uh assuming that like the two daps are using the same uh i think like underlying like google signer technology. right so so if one app is using privy another is using web through auth then then then they will get like different accounts.

Nicholas: okay and if they were to use the zero dev wallet a piece then it would be the same.

Derek Chiang: that's right that's right.

Nicholas: it's going to be tricky for people for users coming to different apps where they are presented with the same social login options but it's actually corresponding to different wallets. i'm curious if that makes you think at all about. uh i know the docs. you mentioned that you don't have um like a generic wallet interface. but in cases where say i you know i'm playing with some app and then it goes offline and everybody disappears if i have uh tokens in or any kind of asset in that wallet or in that smart account i should say it seems to cause like the need for a generic access uh to the wallet uh provided by the sdk suppliers because the apps themselves could disappear which could make it difficult to access the assets stuck in those smart accounts. does that make you think that eventually you'll have to do that or there will be some generic solutions built on top of zero dev to provide that answer?

Derek Chiang: for sure for sure. so so so that's actually something something that we're working on right now. you know they're like. um we want to make sure that like no matter what signer you are using under the hoods that there's like always like one centralized. i i mean you know maybe maybe centralized. it's not it's not a dirty word it's just like. it's like. it's like. there's like one like canonical place that you can go to to kind of like manage your smart accounts right. yeah so so we are calling it's account central. so basically um yeah you know. so so so we are building this like interface. so so it's not. it's not quite a wallet because um like it's not really supposed to be used as like a wallet that you use to kind of like interact with like other applications. it's more like this like portal where like you can uh look like view the states smart accounts such as like which signer is connected to um like even like you know in the case of like social recovery like which guardians you know like are able to recover accounts for you etc. um so you can go to that portal and then like uh if you want you can even like switch signer on the portal right you know. because like the thing about smart accounts is that like like the you are actually not coupled to any signer in like any kind of like um in any like fundamental way right you know. so like you can even like. so. so like if like some like wallet front end you know like like like. if some like embedded wallet front end goes down and you want to be able to kind of like uh recover access to your wallets or like switch to another friends you can do so at this accounts portal.

Nicholas: that's very interesting. so let's just say i mean i don't think privy is going anywhere but let's just say privy services disappeared one day from earth. would this still work with the privy uh associated smart accounts or would it only work with the ones that where the wallet is created with the zero dev uh wallet front end piece of the sdk?

Derek Chiang: so i think i think i think we'd have to look at like the specific uh like the specific scenario right you know. so like um in the case of privy right um ultimately privy the company. they control servers that hold like the key materials right. so if we are talking about a wallet in which all the servers they are for some reason wiped right uh meaning that like the the raw key materials are lost then there's like no way for us to recover that key can't add a new can't recover the key? well yeah but but but. but the cool thing about smart accounts is that if this is a possibility that you're worried about then you could have set up some kind of recovery mechanism for your smart account right. so you could have already enabled some kind of like social recovery mechanism in which even if your privy key is lost you can ask your guardians to essentially recover meaning that like to set like a new key for you uh to be like the new owner. the answer is that in the catastrophic scenario they that you just described which kind of like the master key is lost whether you can recover the account or not depends on how you set up your account right. so like if it was set up with a uh with recovery uh enabled then you can recover otherwise you can't make sense.

Nicholas: um so that's something that would probably be the responsibility of the app dev to choose.

Derek Chiang: yeah the app dev or you know or like maybe the user themselves can also be key because you know we we we will we want to make it so that like there's something that's like doable on the account portal that would you know. you know that that was just talking about right you know. so like. um if if there's like some kind of like like awareness that's um that's. the zero dev account portal is a thing that may be like a lot of. like these users they will just like be vigilant and like come to the account portal and set up recovery just in case like you know like just in case like they they they they they lose they lose that they lose access to their account.

Nicholas: so it sounds like you're positioning this portal as not intending to be competitive at all with anybody building on top of zero dev but just like a recovery solution.

Derek Chiang: essentially for sure for sure yeah yeah yeah it's it's like the. it's kind of like the the the management's the account management's portal you know for like um yeah you know for just like yeah like like like like like managing ownership and recovery for your account

Nicholas: yeah just in case of last resort uh but i suppose if if devs wanted to build something of that of their own you'd have to not have them come to the zero dev portal. that's right that's right um we kind of touched on this a little bit but i'm curious given the past keys orientation and sort of our shared thinking that that may be a really successful form of signer um. do you have any thoughts on eip 7212? do you think it should be integrated into l2s into l1? do you think it's the right spec?

Derek Chiang: um so so so personally i'm definitely in favor of having a pre-compiler um for just like the past key curve right um. so i think that like that like you know just because like so popular popular and so widely adopted in today's hardware right you know that like i feel like like we should be practical about it and just kind of like um like really enable people to build past key based like smart contract wallets right you know by by by integrating the the uh the pre-compilers um. on the other hand i also i guess want to recognize that kind of like. it's not such a um just like a obvious thing. that like that like we should like obviously at as this pre-compiler right right you know. meaning that like because because i feel like sometimes people they um they look at this like conversation about adding pre-compilers and they wonder why the ethereum core devs don't simply say yes right because it's like oh you know why not? right you know it's like. you know like having a pre-compiler doesn't really hurt anyone right right you know. so like why not just add another curve? right um. but the reason is because like the more pre-compilers you have right the um kind of like the more bloated the client's code base has to become right you know. because like the thing to realize about ethereum is that it's very much a multi. uh it's very much a multi-client ecosystem right you know it's it's. it's a like like like the fact that like there are so many ethereum clients you know are what makes ethereum so strong you know from like a decentralization perspective right. and if you take like the l2s into accounts right so it's like the l2s. they usually also have the l2s and the l2s. they usually also have the l2s their own clients um. and like you know if they want to be even compatible like their clients also need to implement the evm stack right. so adding a pre-compiler is a lot of work for like you know when you consider the fact that there are like so many you won't consider the fact that there are so many um just like different client tips. uh like like like different client teams out there right. so um you know and like especially for something like a cryptographic primitive. um it's just like. like because cryptography is just like pretty hard right you know. so it's like you know if you consider the fact that there are so many clients and like different clients that retain like different programming languages. like it is a lot of work to expect so many different teams to implement a certain cryptographic primitive correctly right. so um yeah. so i can also see kind of like just like why it's not such like. it's not such like an obvious thing that like you know they're like you know people should just add it um but um obviously that you know as someone who is like not building their clients right someone who is like right you know who you know who is you know trying to enable um people to use smart contract what is in like a very easy way. i'd like to see the pre-compiler being adopted.

Nicholas: yeah makes sense.

Derek Chiang: um.

Nicholas: so one of the big features of zero dev is a gas sponsorship or of i guess a smart accounts and and as a function of of that uh is included in zero devs. how should devs uh building apps think about sponsoring gas. is it something where you should only sponsor gas if it's uh i guess the the basic filter would be if it's a transaction against a smart contract related to your dap might be one way. or should you only do it if it's uh ultimately the transaction is like profitable to your company or project in some way. or should you just consider it like consumer acquisition cost and just yolo let people do as much transacting as they want their accounts that were created inside of your app. do you have a sense of how like adapt dev should think about gas sponsorship?

Derek Chiang: i think like. this is very much something that people are still exploring today right you know i think i think like the most popular way to just like decide what transactions what transactions to sponsor has definitely been like being like you said. they're like they will only sponsor transactions that interact with the smart contracts pertaining to the app right. so so that's like the most popular strategy. um but um we're also starting to see things like for example like um uh for example right like uh on like the l2 right you know. so so you know how like there's obviously like right now there's like a very big competition between different like l2 sidechains l3s and whatnot. so we're also starting to see kind of like. it's like it's like roll up slash like uh chain operators they will actually offer to essentially like offer these like gas credits. so they will actually like offer these. so they're like they will literally just like sponsor everything. uh for like for for for for new users right. so it's like it doesn't matter what contracts or like applications you're interacting with as long as like you are a new user on the l2 they will sponsor gas for you right you know. so it's almost kind of like paid paid user acquisition right yeah. so that's also like another another approach that i'm seeing right now you know. but otherwise yeah i think i think i think it's mostly just like sponsoring everything that interacts with that interacts with your application.

Nicholas: are they um sponsoring both the l2 and l1 costs or just the l2 costs which they can control the sequencer?

Derek Chiang: um so they're sponsoring the whole thing you know. and uh you know and and and and just to be clear right you know like like this is not common on the more i would say um kind of like the more technically mature l2s. that's uh kind of like a you know they have like a significant l1 cost right you know. so so so so like for example right you know like for like like it wouldn't make any sense for say arbitrage or optimism to do it just because like the like the overall gas costs on these robs are still significant. right you know. you know. because like the l the l1 gas cost is still significant. but i think i'm seeing this on some like newer l2s. that's first of all they have like much more more of a needs of you know for user acquisitions but also because i think some of them are actually l3s right so like they're actually um kind of like putting their data availability on other l2s. so like kind of like the like the the data availability cost is actually very low. so like the overall gas fee is also very low. so like for for for those robs it's it makes more sense for them to sponsor all the transactions.

Nicholas: that's interesting. and when you say l3s are these things that are built on the the only l3s that i've seen people talking about are like on top of arbitrium orbit. is that where you see l3 development happening or are there other locations?

Derek Chiang: well yeah i think i think. i think. i think arbitrium orbit is definitely a big thing. but i'm not the impression that's in the stock net ecosystem there are also a lot of l3s um but you know i'm also not kind of like a kind of like a. you know l3 l2 experts you know. so so i wouldn't call myself on that.

Nicholas: um multi-chain smart accounts can be really tricky because the state changes especially around permissions are not automatically propagated across chains and especially even the signatures themselves because the replay protection can't just be automatically propagated across chains. do you expect that most zero dev wallets will be like single chain focused? or do you anticipate multi-chain? uh smart accounts being the the dominant paradigm?

Derek Chiang: i think the future the future is definitely multi-channel. right right you know. so i wouldn't i wouldn't expect like most zero dev. uh what is to be single chain? i mean i mean i think i think in the short term the fact is that like um zero dev what is that mostly used like in the context of embedded what is right? so like um and like the applications using the embedded wallets they tend to be built on a single chain. so then by definition the users they're using zero dev what is on the single chain. but i think like as smart contract what has become wider become become more widely adopted. i definitely expect most um people to be using multi-channel contract wallets meaning that it would be like a smart contract wallets with with like the same address across at least like all the evm compatible uh you know across all the evm compatible blockchains. um you know you know the same way that people use you the same way that people use their uos their uas today. but um it's definitely true that kind of like managing or rather like synchronizing the states of the smart contract wallets across all these blockchains it's going to be like a really significant uh like like technical endeavor. right but the good news is that like it's actually it's actually something that we've been working on for the past two months you know so like uh you know. so so actually we are we are looking to release something. um that's going to be kind of like a really big breakthrough you know in terms of like just like kind of like multi-chain smart contract. uh in terms of multi-channel smart contract wallets like hopefully within like within like the next month or so. oh that's exciting all right i i take it you can't share too many details about that yet yeah i can't show too many details except in terms of like the the end result right you know just like the end uh user experience. you can you can you can expect from that you will be pretty much like what you expect right like meaning that you will have like the same address across all the blockchains. um like if you change say like the ownership or just like any kind of configuration one chain it will be like automatically reflected on all the other chains. right you know so like so like you shouldn't take more than one transaction or either you shouldn't take like more than um just like uh basically like like like as a user you shouldn't have to update your your smart contract wallet config more than once. right if you want to have the state synchronized synchronize across all the blockchains um as well as like just like the fact as well as as well as like the fact that um you know like even when it comes to things like paying gas like you know it should be the case that's uh with the gas money on one chain you can pay for you can pay for transactions on other chains as well. right so from the end users users perspective you can expect a multi-chain smart contract what is to work the way you want it to work in like the ideal world but like what? what? what i cannot show today is like the underlying technical details.

Nicholas: uh that's very interesting though at least from the user perspective that it be simplified so that a change to his signers on a smart account for example if you want to use a smart account for example it would be propagated across all chains at the same time. um with only one user interaction is ideal. um i know that like groups like um safe have at least i hear this and i've seen a little bit that they don't. uh they no longer try to guarantee that you'll have the same address for your safe on different chains and i think the justification is differences in op codes and uh like unique idiosyncratic non-evm compliant. uh changes across chains make them like skittish about making that kind of promise to users. i think that's the reasoning. um does that concern you at all? or you think it's possible with the technology you're coming up with to to make this pretty pretty successful across especially one one evm compliant chains?

Derek Chiang: yeah i think i think i think on evm. uh on evm compatible chains i think it's still like worth it uh you know to strive for having the same address across all the evm chains just because like that's like the paradigm that's um they're like most users are accustomed to today right but it's definitely true that like if we're dealing with non-evm compatible chains um or even just like entirely different vms then it's literally just technically impossible to guarantee that. right you know so so um so yeah so so so for those trends we'll also wind up having different addresses. and i think um you know i think i definitely also like. i'm also definitely aligned with like the wider kind of like efforts to kind of like just like update the wording in. you know you know just like the wider what the you know the wider the wider web through what infrastructure so that people kind of like operates not so much with addresses but it's like more so with names. right because like ideally um everyone will just be using something like ens and then you don't really worry about like what address the yet the the name resolves to on each chain. right. so that would be the most ideal um you know because then that saves us you know from even like you know whether whether you have like the same address the same address on each chain but um to kind of like have like all the what is and that's you know and that's and what not adopts a more naming oriented convention. you know it's going to take some time.

Nicholas: yeah it seems like a similar problem to like. vitalik has talked about having a registry for what addresses you're at on on different chains. but even even if the technical challenges are solved there is this always lingering problem of where would such a registry live and how could we commit same thing with ens and a naming convention. ens is great. on mainnet it's awesome but nobody's going to pay. i mean a very small number of people are going to pay the fees to register names on mainnet. so even just choosing which l2 to live on or some other solution so challenging do you have any thoughts about how to resolve that conflict for naming or other problems of coordination between all these different chains?

Derek Chiang: yeah yeah i don't i don't. you know i don't. i don't really have like uh have a good answer. answer to that. you know. that's also why you know i'm kind of like not really sure how how we will actually wind up um completing that transition towards like a more naming oriented um just like paradigm right you know. but i think like i would speculate that likely there will probably be some kind of a um i think i think i think like i think like if i were to speculate probably the most likely thing to happen would be for all the sharding proposals to be first implemented right you know like the proto proto dank sharding thanks sharding blah blah blah right you know. so for the shouting protocol to be implemented first so that like the even like the gas caused on layer one can just like get lower first right and then probably like the naming registration will likely happen on l1. right because like the benefit of it happening on l1 is that then basically like all the l2s they get to resolve them. they get to resolve names names for free because like l2 is by the definition they can read the state of l1s for free right. so like there would be one there would be one possible path towards that you know. but honestly i'm kind of like yeah i mean honestly like. i guess now that i think about it like i don't really know if like l1 gas fees will ever get low enough. that's because because like naming is like a very fundamental thing right you know you know like like everyone needs a name and you probably need different names for like different applications right you know like you probably want like a name for like a gaming app. you probably want another name for like a social app. you probably want another name for like a social app. so if naming is going to be so ubiquitous like i feel like l1 l1 gas fees will never get low enough for that to be just like to be used as like the names for um. just like just like the the the um the medium that holds everyone's stamps right you know. so like then it might be one l2 but then the question becomes which l2 right you know? so yeah so yeah you know i i i i really don't have good answers for that.

Nicholas: yeah we're talking about tens of billions of names. um maybe even hundreds of billions of names. um there's also things like erc uh 3668 the ccip read uh off-chain data retrieval. that feels like maybe there's some solution there although of course you can't be guaranteed about what you get off-chain. so not clear. um so zero dev charges uh 0.1 or sorry one cent per transaction plus five percent of the sponsored gas. at least that's the numbers that i see on the site today. i'm curious does that apply only to transactions that are like user ops that are sponsored. or does it apply to all user all user ops? uh corresponding to a smart account that created with zero dev?

Derek Chiang: it applies to all the smart accounts that are created with zero dev. yeah um you know. but obviously you only pay for the five percent if you're sponsored. you know like if you sponsor gas but you but you pay the one cent per transaction regardless.

Nicholas: and is that in the contracts themselves?

Derek Chiang: oh no no no yeah so so. so. so when you use your death we basically have an sdk. right you know that makes just like interacting with like the smart contracts and create the uh you know rather like interacting with the smart accounts as well as like creating the smart accounts. um like super easy right. so like the sdk uh takes a api key right like when you initialize the sdk. so by using the sdk and providing the api key is how we know kind of like who to charge you know. so like you know to use zero dev you kind of like put on your credit cards on our dashboards um and then like you also like so like. so like you know like if you want to sponsor gas for users um we actually like front the gas for you? right you know. so you don't have to kind of like actually manage crypto and like actually kind of like pay gas for users but rather we we we front the gas for you and we charge your credit cards. and the reason why we know to charge your credit cards is because you provide your api key when you use our sdk if that makes sense.

Nicholas: got it okay. so you could eventually move away from that if you spin up smart accounts with zero dev but you'd have to move away from the entire zero dev sdk and just interact directly with the smart alternative fashion.

Derek Chiang: for sure for sure. yeah yeah you know. like like our like our smart smart accounts are open source and uh and mit licensed you know. and and there are projects out there that use um they only use like our smart accounts but don't kind of use the rest of our the rest of the rest of our products you know. so so i would say that like the way we capture value is like very much similar to kind of like like the way um like all the previous like successful open source projects capture value which is like this basically like this open core model right right basically like you build like a very strong um open source offering but like the open source offering is like kind of like very flexible and very low level and very powerful but like for the for the for the developers that are operating on like a higher level who kind of like who kind of like just want things to work they they would typically prefer to use a paid solution that makes their life and just like time to go to markets shorter right? um and uh yeah you know and you know and that's and that's exactly what we're seeing today. right you know that like most people who want to use our smart contract wallets wind up using it through our paid products. but it's also possible to just use the open source to just use the open source products on that uh like directly got it.

Nicholas: and do you think that model will inhibit like growth at all? uh given that it's sort of got an upfront cost at the api versus maybe other people will offer free to you know or freemium at least experiences.

Derek Chiang: um that's uh there's a good point you know. so so we we actually don't charge if you just want to deploy on test nets right so it actually doesn't doesn't cost you anything to start playing with zero dev and also just like developing and deploying your applications on test nets. but like when you go to production that's when you pay us. so i think that has been a good just like model for us so far just because it's like you know like like. it kind of allows people to start playing with and experimenting with account extraction for free um and then like once they kind of like experience once they experience that just like that massive ux benefits there's a ton of that kind of instruction brings um. converting them to like a paying customer has been has been you know has been like relatively easy um rounding up nearing the end of my list of questions at least um.

Nicholas: you mentioned that plugins are being developed on top of kernel and on top of the zero dev sdk. i'm curious if you could go into a little bit of detail on which ones uh. people have created. i think you mentioned multi-sig dca which are the most popular ones.

Derek Chiang: so the most popular plugin by far was the one that we kind of like officially developed. um so it's uh it's it's it's session keys right. so session keys itself is just like such like a fascinating topic that we can probably spend um just like another podcast on but basically it's this idea that's um it's basically so. a session key is a temporary key that you can assign certain permissions to right. so for example i can create a key that can send transactions for me but only if those transactions are not transactions interact with uniswap and only if it uses usdc and only if like the amount of and and only if like the amount of usdc uses is lower than one thousand dollars right. so it's kind of like like like you can create like really fine grant permissions for a session keys. and the reason why that's so powerful is because it enables like the remember how like remember how we talk about like one of the primary benefits of smart contract what it's. it's automation right it's like it's ability to delegate um certain permissions to third parties. so session keys is the. it's the means on which you can kind of like you you can you can you can you can you can you can delegate permissions right. so um so yeah you know so so so session keys has been uh incredibly has been incredibly popular because it allows the the dev developers to develop just like highly um seamless and automated experiences that doesn't you know that don't require users to kind of like manually sign every transaction. yeah so i would say that that that's like the most popular plugin. and then following that is probably recovery you know. so like just like the ability for people to um essentially like set up guardians. um so that like even if they lose access to their keys that their account can be recovered you know like that's also been like a really popular plugin as well.

Nicholas: session keys are not part of or how do they fit into the 4337 spec because they're not defined in 4337 itself.

Derek Chiang: right like like session keys has been like a really popular plugin and it has not has nothing to do with 4337. so 4337 is like a very long spec. but as far as like kind of like. so as far as like what's um what the smart contract what it does 4337 actually says very little says very little about it. like 4337 doesn't like doesn't really define or restrict kind of like like the the wallet itself. it only defines like a very minimal set of interface between the wallets and the kind of like the. uh just like the the bundlers and the paymasters. right you know which is you know which are like the like the other two major components of the stack. but yeah you know so so so session is very much functionality of the smart contract wallets and it's not part of the standard it's not part of the the standard at all. and like today i think most smart contract wallets outside of zero def still don't support something like session key and like session key is like definitely like one of like the the big competitive advantages of uh of you know of you know of zero def and kernel and kernel in particular

Nicholas: um and these plugins are specific to kernel. or there's something that might be interoperable with other smart contract wallet implementations.

Derek Chiang: like there's a ongoing efforts to make plugins more interoperable right you know. so you might have heard like you might have heard of this standard. it's called yasi 6900 right um you know it's uh it's it's pioneered um and like written by the by the alchemy team. um you know but you know but we are but but we have actually also been working very closely with them to just kind of like identify issues as well as like just like finalizing the uh like like like the you know like finalizing the the standards. so the the the goal is that in the future hopefully like all the plugins should be uh interoperable across like different smart contract wallets. but you know that's actually like another topic that we can expand on. you know like if we have more time. but like um the reality is that like if you dive into like the technical details of the of the plugins you you realize that there will always be some limitations to the extent to which the wallets can be interoperable. you know just like like due to the way that's um just like due to the way that the plugins work right. so like basically like there will always be plugins that due to like the very nature of what they do that like they will have to be a little bit different for each smart contract what is and that's not something that's any spec can solve you know. but like the spec would definitely make some plugins kind of like being able to work like unmodified across what is but not all plugins.

Nicholas: is it possible to say in a few words what it is about the smart contract wallet uh implementations and the differences between them? that makes plugins difficult to make interoperable or is it just too detailed to to describe simply?

Derek Chiang: so so so i think from like a high level you could say that um if like a plugin needs to modify some kind of internal state of the wallet right. so for example like imagine that's you want to build a plugin that um would automatically um. or let's say that you want to build a plugin that will automatically um. uh trying to come up with an example here. so imagine that you want to plugin that will automatically um. let another signer take over if the current signer has sent say more than a million dollars worth of value right um in the in the previous i don't know like you know 100 blocks right. so it's like basically like the use case here here would be like oh like if it looks like this account has been hacked then like maybe another signer should take over right you know. so like there would be what. there would be one example right. so for something like that you're you're assuming so like in order for that to work the plugin needs to understand how the smart contract what it's kind of like handles signers internally right you know. so that's a internal implementation detail that's not captured in any spec right you know. because like that depends on how the so like. it's like the way that kernel deals with signers is going to be different than the way that safe deals with signers and it's going to be different than the way that like other what is still? what is uh the designers right? so in that case it would be impossible for the plugin to work in such a way that's just works for every smart country. right right right i think. i think even if it's the same plugin the the internal logic of the plugin will have to have some kind of like branching such that it's like like. you will have to check oh you check and be like oh if i'm talking to like the kernel watcher is i will execute this branch of logic. if i'm talking to like a safe what is? i will execute that branch of logic. so like so like yeah yeah yeah like they're like. there's always going to be some some extent to which the plugin needs to customize its behavior depending on which wallet it's talking to.

Nicholas: yeah got it. uh that's the end of my list of questions. is there anything that we didn't cover? that's important for people to know about zerodev.

Derek Chiang: i think honestly like i feel like the questions you like the questions you ask have been like way more in depth than i expected you know. so i think yeah you know i actually thought that i thought that you'll probably just. i just just like ask something about you know kind of like oh you know you know like the state of the state of adoption of a blah blah blah no but i think you actually went into. you went into like some really really deep questions about you know just like you know like you know even things like plugins kind of like the interoperability between different smart country wallets and whatnots. yeah so so so. so i would say that like i'm i'm very happy that we were able to um just like really dive into these like really deep topics. um you know i'm actually calling from uh china right now. so like um yeah so it's actually kind of late you know so hard yeah yeah yeah yeah yeah so so so so. so even though even though even though i think there are definitely way more interesting questions that we can dive into or it might be like a time to like a good time to uh to just end it.

Nicholas: well we'll have to have you back on the show uh sometime to to talk more. um maybe when uh you have some future release out that we can uh get some more details and new developments as things change if people want to check out zero dev uh or keep up with you where are the best places for them to go?

Derek Chiang: um so i think we i like like i really think that we have like one like the best documentations across like the entire web through space you know. so like if you check out like our docs you can learn like way more about zero dev as well as like just like a common section and smart country boys in general. um other than that i think our blog is also very good you know i think we have written some of the most widely showed uh like articles kind of traction and smart country what is in general. so i think like our docs and blogs you know which are both under um obviously like zero depth or app you know it's like a uh you know you know uh you know are really good resources. and other than that obviously just just follow us on twitter. yeah and i think um um again right you know you know i think we are working on something or rather a number of things that you know that we are super excited about. that we think will really push the boundary of what's possible with aaa. with aaa today um and hopefully there will be there will be like some really major product product releases in like the next one or two months.

Nicholas: yeah that would be fantastic. uh i can vouch for the quality of the blog. it's very active very detailed technical posts that are still uh readable covering all kinds of things like optimization comparisons 6492 mpc all kinds of interesting topics. if you're interested in this stuff the zero dev blog is a great place to go derek. thank you so much. this was a wonderful conversation. i'd love to have you back in the future.

Derek Chiang: thank you nicholas you know. thanks again for asking so many so many good and detailed questions.

Nicholas: you're welcome all right. thank you everybody for coming through to listen. see you next week for another episode. all right bye-bye. 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 5pm eastern time 2200 utc on twitter spaces.

Derek Chiang: i look forward to seeing you there.