Web3 Galaxy Brain 🌌🧠

Nicholas: Before we get started, at present, Web3 Galaxy Brain has 12 reviews on Spotify and 7 reviews on Apple Podcasts. If you love this episode, please give Web3 Galaxy Brain a review wherever you listen. 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 Conrad Kopp, co-founder of Rhinestone. Rhinestone is an exciting project that's researching and developing smart account modules atop the ERC-4337 Account Abstraction Standard. AA modules promise to allow smart contract account owners to safely add new functionality and permissions to their accounts without having to upgrade to new smart contracts. The module pattern described in the draft ERC-6900 Modular Smart Contract Accounts and Plugins aims to create an ecosystem of interoperable modules to augment the various 4337 implementations that support it. On this episode, Conrad and I discuss the different approaches to account abstraction contract architecture, including SAFE and the ERC-2535 Diamond Standard. We dive into the details of ERC-6900 and discuss the compelling Rhinestone video demo, which shows how a user might activate and disable smart account modules like pass-key validation, dollar-cost averaging, and recurring payments. We also cover the grants that Rhinestone recently received from the Ethereum Foundation's 4337 team to develop a module registry, a public goods venue where security audit firms and others can attest to the safety of specific modules. Rhinestone is one of the most exciting projects working on AA right now, and it was a pleasure talking to Conrad about the smart account modules landscape. 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, Conrad, welcome.

Konrad Kopp: Hey. Hey, how's it going?

Nicholas: Good. It's great to get you on the show. Thanks for coming to talk about Rhinestone.

Konrad Kopp: Yeah, thank you so much for inviting me. It's a pleasure to be here.

Nicholas: Absolutely. I'm super excited. Rhinestone is like one of the projects in this space, working on modular smart contract wallets that everyone is excited about. Everyone I talk to is like, "Oh, great. Rhinestone. I'm excited to hear that.". So this is going to be a great conversation. Rhinestone started as a hackathon project at ETH Denver, right?

Konrad Kopp: Yeah, that's right. Yeah, I went to ETH Denver, obviously at the start of this year. And yeah, built essentially the first modular smart contract wallets or smart accounts based on diamond proxies.

Nicholas: So is it the same team that was working on the hackathon project that's working on it today?

Konrad Kopp: No, it's not. So I was actually previously... Before going to Denver, I was working with my co-founder, still my co-founder, Kurt, and went to Denver with a couple of friends who I lived with. But everyone else on the team kind of had their own startup already. It's kind of I was the most bullish on and kind of drove the idea forward. So I continued working on it.

Nicholas: That reminds me, your name on Twitter is Abstractor. I like that.

Konrad Kopp: Exactly. It's kind of the Web3 vibe, like optimizers.

Nicholas: When did you pick that up? After starting the project?

Konrad Kopp: Yeah, yeah. It was during Denver, actually. It became a big meme within the team.

Nicholas: That's great. You were gonna say something else about the hackathon project?

Konrad Kopp: Oh, no, I was just gonna say, obviously, I offered my friends to stay part of Rhinestone. But most of them had already raised funding for another project, so couldn't easily switch over.

Nicholas: Got it. And where are you and Kurt based? Do you do work together physically or remotely?

Konrad Kopp: Yeah, so I'm based in Oxford in the UK and he's based in London. So it's like an hour train journey and we try to work together once or twice a week in person. So it's quite nice that I can just kind of like travel over.

Nicholas: Not too far.

Konrad Kopp: But apart from that, yeah, apart from that, we're just remote.

Nicholas: So for people who don't know Rhinestone, what is it? What is Rhinestone?

Konrad Kopp: Yeah. So Rhinestone, I would say that Rhinestone overall, kind of like what we are trying to do is to make the wallet. And by wallet here, I kind of mean the interface that a user interacts with to make the wallet a platform for innovation within Web3. And obviously, that's quite broad. So I can kind of go into specifically what we're doing. But I think that's the goal that we have.

Nicholas: Yeah, I was thinking maybe a good way to get into it is for people who haven't seen the Rhinestone video demo on rhinestone.wtf. Maybe you could walk me through the UX of creating a wallet and adding a plugin. And then later on, we can get into some of the technical details what's going on in the background.

Konrad Kopp: Yeah, for sure. For sure. I guess like one caveat there is that actually the wallet, we see it as more of a reference implementation. We don't actually... This is actually not kind of like the main product that we're building. We're actually more focused on the infrastructure to allow kind of everyone to do a similar thing. But yeah, I think that makes sense. to chat about this first.

Nicholas: Okay, so we'll keep that in mind that you're really building the underlying tech, but the demo is a kind of good example experience.

Konrad Kopp: Exactly. Yeah, exactly. And that's actually what we built at ETHenver as well. So the idea there was, what if you flipped the paradigm for how wallets work today a bit on its head? And what if you allow the user to completely customize how the wallet works both on the front end, but also as a smart contract? And obviously, this only works for smart contract wallets or smart accounts. This doesn't work for UAs. But in the demo, like you were saying, a user comes to the platform, and they can select essentially the features that they want. And they can kind of, in this demo specifically, just drag them over to essentially the right side. And then they can create their wallets with those features that they have, that they've selected. And I can kind of go into specifically what those features can be. But I think that's the core principle. And well, I guess the second aspect of it is that throughout the lifetime of that wallet, a user can change what those features are. So it's not that they pick them at the start, and then they kind of forever have those features. But they can later add and remove features whenever they want. Very cool.

Nicholas: So basically a modular smart contract wallet and kind of reference UI implementation, at least from the hackathon, to sort of see the experience. One question that comes to mind, even before we jump into the plugins is, at least on the version in the demo, I think you're using Touch ID, maybe passkeys. How are you generating the sort of sign or the initial access to the wallet in the first place?

Konrad Kopp: Yep. Yeah, yeah. So in the demo specifically, we are opinionated in the sense that we have the user on board with the passkeys, like you're saying. So we're using, yeah, like the secure enclave and the WebAuthn standards to essentially create a key that stores, like I said, in the secure enclave of the device, and authenticated that the key, like the kind of permission to use that key can be authenticated using the biometrics stored on that device. Which obviously, like, we're not the only people to do. I think you've had like multiple people on the podcast who are either working on the ERP or just kind of like thinking around passkeys and WebAuthn. But yeah, we went through the flow there and implemented that.

Nicholas: So essentially, that's like, from a sort of contract perspective for you, that opinionated choice on the front end is just one of many potential choices for how you could sign on the smart contract wallet. But it's just like a convenient onboarding for this demo.

Konrad Kopp: Exactly. Yeah, exactly. And then the user could say, actually, I don't like passkeys because, you know, maybe I'm skeptical about the NSA. Maybe I want even more kind of protection. And I can enable a different kind of validator. I can even have multiple validators.

Nicholas: So in any kind of opinionated front end that would live on top of the rhinestone technology stack, basically, the first action would be even just creating a wallet is already like applying a plugin to a wallet, right?

Konrad Kopp: That's right. Yeah, you would always need, at the very least, you would need to have at least one validator, because otherwise you can't use the smart contract account. And then we strongly encourage you to also have at least one recovery option so that you can recover that validator if you lose the key.

Nicholas: A validator is like an authentication mechanism?

Konrad Kopp: Right, exactly. Yeah, maybe it makes sense at this point to kind of talk through as we see kind of like the different types of modules. So one of them are these validators. And validators essentially, they, so in ERC 4337, there's the kind of like the validation flow and execution flow. So during the validation flow, the entry point calls the account, and the account essentially does some computation and then returns to the entry point whether this is a valid use operation, which is like a 4337 transaction. So validator modules are modules that are called during this flow. And then, for example, if you use like a passkey, then you send that to the entry point, which sends it to the account, which then sends it to the passkey validation module. And there's a couple of other different kinds of types of modules that I can go into, if that makes sense now, or we can talk about it later.

Nicholas: Yeah, for sure. Just before we jump from validators. So for example, in this case of using a passkey, which yeah, if people want to learn more about passkeys, there's a bunch of other episodes of the show they can go listen to. When they authenticate with the passkey, the validator plugin that's applied to the rhinestone wallet is like an R1 verification module, basically.

Konrad Kopp: Exactly. Yeah, exactly. So if you are a dev that wants to build a validator module for passkeys, you can either obviously build your own or you could use some of the existing logic or contracts that are out there that have been built by economy or ledgers, FCL implementation or whatnot.

Nicholas: Great. So okay, yeah, let's dive into some of the other kinds of modules that there are. So there's validators. What else?

Konrad Kopp: Cool. Yeah. So there's another type of modules, which we call executors. And actually one caveat here, or in general, is that there's a couple of teams that work in the modular kind of protection space. And we've been trying to kind of align people to use the same terminology. But actually, it's still the case that most of the people still use different terms. But we call these executors and they basically have two different functions. So they can modify your normal execution flow of the account. So you could kind of like do x, then do y, that kind of thing. Or they can also introduce automation into your smart account. So they could be triggered by a relay, for example, as opposed to being triggered by the user. And for example, perform actions on a scheduled basis. So that's executors. And then the third...

Nicholas: Before you jump to the third one. So those two types that you gave examples of, the first might be something like bundling both an approval and a swap into a single one-time transaction. And the latter would be like the dollar cost averaging plugin that people can see in the demo on the site.

Konrad Kopp: Yeah. For example, you could also have kind of the batching natively in the account. So maybe another example for the first type could be that you have a very specific kind of like flow of operations that needs to be executed in a certain kind of like order. And for some reason, like these might have to be executed from the smart contract that you can't very easily kind of format this into call data. And then you could have an executor module that does this like very specific kind of type of logic. And you just call this module as opposed to kind of like passing the entire kind of function flow in the call data.

Nicholas: So would that be sort of for people who may be familiar with safe, like the construction, transaction builder experience there where you can have like multiple transactions that are going to be executed sequentially? This would be something equivalent to that?

Konrad Kopp: Yeah, and especially kind of more advanced options of that, where there's, for example, interdependence between the different things that you execute. So for example, the first thing that you execute returns some data that is that fed into the second thing that you execute, for example.

Nicholas: Very cool. I mean, I know one of the big advantages of AA is that unlike something like multicall, you get to preserve the message sender context. So you can execute multiple transactions in a row without having some of the downsides of the pre 4337 user experience. So I guess this is kind of taking that even further by allowing you to pass data from the first transaction to the second or something like that.

Konrad Kopp: Exactly. Yeah, exactly.

Nicholas: Very cool. And also, you don't need to know that data in advance. It can be kind of the output of some transaction where you may not be able to predict exactly what the output will be in advance of sending the transaction.

Konrad Kopp: Right. Yeah, exactly. That's it.

Nicholas: Yeah, that's very cool. Especially in a context where you're in like a mempool and maybe you're, minting, you don't know what your token ID is going to be once the mint gets through and is on chain. But you know that there will be some token ID. So you can use that as the basis for something subsequent.

Konrad Kopp: Yeah. Yeah. I think that's a really good example. Yeah.

Nicholas: Okay, cool. So those are executors. Was there a third type?

Konrad Kopp: Yeah. So a third type is what we call hooks. And Safe used to call them guards, I believe. But now they also call them hooks. And basically hooks are kind of functions that can run pre and post execution and they can enforce certain things. So one really cool thing that we've been exploring internally is a virtual cold storage hook that essentially checks. Well, first of all, you configure it and you say, for example, I want this NFT to never be able to leave my wallet. And then before and after every execution or every transaction from that account, it actually checks that, for example, the token balance of that specific token, or just like that you're still an NFT, if we're talking about non-punishable tokens, it's still the same. And if that's violated, then it reverts the transaction.

Nicholas: That's very cool. So almost like a flash loan kind of experience, but over your own assets, where you can sort of guarantee that at the end of any transaction, some state remains invariant.

Konrad Kopp: Exactly. Yeah, that's one example. And you can do kind of other really cool things as well. So for example, you might say, and I don't know, maybe this is not that realistic, but you can say, every time I interact with Uniswap, I will also take a bit of whatever the output is of that Uniswap transaction and put it into a savings vault.

Nicholas: Very cool. I feel like a lot of what shines through in your designs, although it's extremely technical, and we're going to get into some of the nitty gritty of that in a second, it feels like a lot of your motivation is these kind of very regular user experience benefits, like having a sort of easy to use savings account, feels like a kind of late stage banking product that's really for regular people. But it's actually something that's like top of mind for you in terms of designing this stuff.

Konrad Kopp: Yeah, yeah. I mean, to be honest, I would probably say that we're very product driven, and large parts of that are due to Kurt, who has a background in products. He'll probably say that I'm also more of a product minded engineer than most. But yeah, I agree. We have a pretty big product focus and kind of like a focus on actually tackling problems that exist currently for people that use wallets.

Nicholas: What was the term you used for these cold storage hooks? You had a phrase.

Konrad Kopp: We just call it virtual cold storage.

Nicholas: Virtual cold storage. Why do you call it that?

Konrad Kopp: Well, because it's not actually... So you have a ledger, right? Which is like a cold wallet. So you could call that kind of like cold storage. But in this case, your key might not be cold, it might actually be hot. It might be in your area or it might be a passkey. It's kind of like virtual cold, virtually cold.

Nicholas: Okay, cool. All right. Because this is kind of... All right, we'll get back to some of the terminology and the fracturing of the market, etc. stuff in a second. But this is kind of part of my question. Do you imagine Rhinestone will replace other software wallets or maybe even hardware wallets because you can get some kind of additional security assurances with things like the hooks you're describing?

Konrad Kopp: Yeah, I think this is a really good question. And I would probably say that, I mean, obviously, I'm pretty bullish on account abstraction. And my hypothesis is that account abstraction or smart contract wallets will replace most existing wallets. And you might still have something like a ledger, but as a sign, kind of on a wallet, which actually holds assets. So I would say that's my hypothesis there.

Nicholas: Yeah, that makes sense to me. When you talk about trying to align people around terminology, are you speaking about people who are working in the 4337 stack or something even more specific than that?

Konrad Kopp: Yeah, more specific than that. So I would call... So there's kind of like the general account abstraction movement. And then there's kind of the subset, which I would say we're working on is the modular account abstraction, which we're talking about aims to modularize these accounts so that users can kind of plug and play different features. So that's kind of where we tried or we've been trying to align people on using the same terminology.

Nicholas: Okay, so this is perfect, because in your WTF is AA blog from May, you discussed the difference between the 4337 approach and the 2535 diamond approach to account abstraction. Maybe could you explain a little bit about what the difference is between the two of those and where it stands today?

Konrad Kopp: Yeah, yeah. So it is the difference between kind of the 4337 approach and the diamond approach is more... So both of these, I would say, obviously, you can have account abstraction without 4337. But in this context, both of these build... Both of the different approaches I talk about build on 4337. But essentially, what 4337 is, it's essentially just... It standardizes how smart contract accounts are called using an alternative mempool. And you can get stuff like censorship resistance from that, as opposed to guarantees that you couldn't get from just using a normal centralized relay. But what I talk about specifically is kind of like, 4337 is very minimal in what it specifies for how accounts should look. In fact, it only has basically one requirement, which is that you have to have the validate user function, and you can only do specific things during the validation phase. But everything else is kind of left up to the account to decide. So kind of within this approach to modularize these accounts, there are a couple of different approaches. And you could call them, for example, the diamond-inspired approach, and then the safe approach, which kind of safe has been working on for quite a while. Obviously, like I said before, they're not kind of natively 4337 compatible. But in the context of what I talk about, I kind of just assume that they will be at some point in the near future. Does that kind of make sense?

Nicholas: Yeah, totally. So there are different ways of actually implementing 4337 wallets in practice. And so maybe can you stick out what the difference is between the way safe does it and the diamond approach?

Konrad Kopp: Right. Yeah. Yeah. So the diamond approach is obviously inspired by the diamond proxy standard, which is a way to modularize smart contracts. And how that works is essentially you store pointers to function selectors and addresses. And basically, whenever a call comes in, you look up in this essentially, this essentially lookup table, where you just look up what is the function signature that comes in, and then you get the address. And then you externally, well, you actually delegate calls to that address, which essentially means that you grab the code that's at that contract with that address, and then execute it from within the contract. So essentially, what that means is you can have a single kind of like main contract that holds the state. And then you can have multiple contracts that essentially like, almost like sit around it, that hold different pieces of code. And whenever you need a specific piece of code, you essentially just grab that and execute that on the state of the main contract.

Nicholas: And those are facets, those external pieces of code?

Konrad Kopp: Exactly. So the diamond standard calls these facets. There's been kind of debates about the language and terminology here. But yeah, so wonderful.

Nicholas: Overall, you like that. I've heard people, I've never written a diamond contract before, but I've heard people say that they're, they can be difficult to understand. And they can maybe also introduce, I suppose, because you're calling external code on internal state, that can maybe be a little bit more dangerous.

Konrad Kopp: Yeah, yeah. Yeah. First of all, the terminology can be a bit confusing. Like I don't dislike it as much as other people probably. But I think the big problem is that really what diamonds are designed to do is get around large or essentially make large contracts possible. So there's a cost limit, which is I think, 24 kilobytes of bytecode. But obviously, sometimes you might want to have more code. So that's one thing that they make possible. But I think the main focus and the main inspiration for diamonds is from when a single team wants to either make it easier to upgrade specific pieces of code, or like I said, get around the code size limit. But they weren't designed to be used by multiple teams, and some of which might be malicious. So that's the big issue with diamonds, because you're essentially kind of taking external code and then executing it on your state without actually having guarantees that, you know, that external code doesn't mess up your state. And so in the contract of a smart contract wallet, that could mean that the external code could just like replace the owner of your smart contract wallet, which would obviously be very bad.

Nicholas: Maybe this is not exactly the same thing, but there was the parity wallet problems years ago. That was maybe because of initialization of contracts from factories or something?

Konrad Kopp: Yeah, I'm not super familiar with it, but I don't think it was the same issue.

Nicholas: But so essentially delegate calls, I guess, are delegate calls and re-entrancy kind of, do they rhyme in a way?

Konrad Kopp: Not necessarily. So they're a bit different. So delegate calls, kind of the problem. there is more that you need to essentially completely trust the code that you're kind of delegate calling, because it can perform any operation on the state of the callings.

Nicholas: Okay, got it. But you seem to think of it as having some advantages, even though that's like a little bit scary, as long as you know that you can trust the code that you're calling, if you know the address of the contract you're calling and a delegate calling, I should say, and you know that it's immutable, then I guess you can trust it if you've verified it in the past.

Konrad Kopp: Yeah, yeah, there are definitely advantages. I think in the kind of like in the account abstraction kind of talk, I would probably lean towards or lean away from them. But like, you can't deny that there are some advantages to use environment. So one example is obviously they are stateless, which means you can deploy them once and kind of you can like write them very easily, as opposed to if you write the singleton that's stateful, you have to use like mappings for different kind of like people that might store data. I think that's one thing. And the other thing is, you see 437, like I said, I think earlier, has some specifications about what can and can't be done during the verification phase. And one of those things is that you can only access the storage of the account, and very specific storage starts on external contracts. And what that means specifically is, if you delegate call and get some piece of code to essentially execute on the storage of the account, then you're fine, then there's no problems with the 437 specs. But if that contract is external, and you write or want to read states from that contract that's not kind of in those specific slots that 437 allows, then you're actually not allowed to do that. So that presents some problems for building validators.

Nicholas: And the enforcement of those rules about which slots you're able to access are something that's a part of the 437 spec and that's expected to be implemented in a true 437 compliant implementation contract?

Konrad Kopp: Yeah, and that's more specifically, it's also verified or it's implemented in the bundles, they perform those checks. So if you use a bundle that's compliant, that will reject kind of reject a user up that doesn't comply. And also once the mempool, once the old mempool is up and running, all the bundles I think are expected to comply to the specs. So you wouldn't be able to use the old mempool.

Nicholas: And that's something that they can do by simulating the transaction.

Konrad Kopp: Exactly. Yeah. And the reason I mean, we can go into this like more in depth, but I think there's those better people to talk about this is essentially DOS protection for the mempool.

Nicholas: Okay, very interesting. And you mentioned sort of in passing that the mempool is not available yet, the old mempool for these things. How, I guess, what's the difference between this state of the art today for this stuff and where we're headed with a old mempool for 437?

Konrad Kopp: Yeah, yeah. So I'm not the most up to date because all the bundler devs are actually building the mempool and I'm not currently building a bundler. But essentially how it works today is you essentially, you select the bundler that's either your host yourself or someone else hosts for you. And you send your user operation or your user operation directly to that bundler. And then that bundler directly kind of sends it on chain. Whereas later on, you would directly or indirectly send it into the mempool. And then bundlers kind of would pick the user ops out of the mempool and include them on chain similar to how you have the normal kind of transaction mempool on Ethereum.

Nicholas: And there's like a whole 1559 style priority fee situation for I don't know the details of it, but it operates like a full mempool, essentially.

Konrad Kopp: Exactly. Yeah, I think so.

Nicholas: Very interesting. Okay, I'm gonna have to get some bundler people on. What teams are working on that that are interesting?

Konrad Kopp: Yeah, there's Pimlico. So Christoph is one of the authors of 437 actually. And he's building bundlers and paymasters. There's StackUp, there's kind of Etherspot and Biconomy have their own bundlers as well. Alchemy obviously, well, you already spoke to Noam, right? But they have their bundler. So yeah, there's quite a lot of people.

Nicholas: A lot of people. Okay, a lot of good. We're not going to run into guests for the show. That's a good thing. Yeah, that's true. So yeah, speaking of that Alchemy, the recent Alchemy interview with Will and Noam, they are working on an AA plugin architecture. Do you think it's compatible with the architecture that you're coming up with? Or are they working on a completely different approach?

Konrad Kopp: Yeah, yeah. So the architecture is kind of under the umbrella or essentially ERC-6900. And so kind of. one thing I haven't gone into actually yet is we started off building an account. We built that at Denver and then continued building that for a month more. But then actually, well, two things started to happen. So first of all, more and more people kind of started to jump in and started to build modular accounts like Zerodev, we built a kernel and Biconomy and also Alchemy like releasing ERC-6900. And that was the first realization that more and more people are going to build accounts and accounts might become commoditized and modular accounts specifically. And the second realization is actually there's other infrastructure that is required in this kind of modular ecosystem that doesn't yet exist. Most importantly, kind of infrastructure around the security, which I can go into in a second. So I actually stopped working on a modular account and started working on almost a translation layer between accounts. And that translation layer essentially aims to A, give security guarantees to users. And also, one of our main goals is to allow developers to easily build modules that work on any account. So whether that is a 6900 compliant account, a safe, anything else, basically.

Nicholas: Okay. So just to make sure we don't lose a thread here. So we were talking about the diamond versus safe approach. I guess that's a separate conversation from the 6900 conversation.

Konrad Kopp: Yeah. So 6900 started off on the diamond side. It wasn't like hardcore diamond, but very much inspired. I'm not sure if they removed it from the ERC, but at the very first draft that they had, they were talking about how it was quite inspired by diamonds. But it's kind of moved further away from that, especially from Delegate Call, for the reasons we talked about earlier.

Nicholas: Okay. And before we get into the details of 6900, maybe can you explain what the safe approach is. that's different from diamond approach?

Konrad Kopp: Sure, sure. So safe. So they've, for a long time, kind of in the safe, you've been able to execute transactions on the safe from a module. And basically how that flow works is you somehow trigger a module, which is obviously an external contract, and then that external contract calls into the safe, and then that safe executes something. Whereas going back to the diamond approach, the flow is actually kind of reversed, where at first the account is called, and that then gets code. I mean, the Delegate Call could be an external call and executes that. Whereas here, the approach is more of a call back into the account. So that's a big difference here.

Nicholas: And what are the advantages or drawbacks of the two options?

Konrad Kopp: So the advantages are definitely, it's more, well, it's definitely more battle tested and arguably, and I think most people would agree, it's more secure. The disadvantages, it obviously costs more gas, especially, say you had a 437 module on safe. As much as I was explaining this flow system the other day, and they got really confused after like two seconds, but the flow would be the entry point calls the 437 module, which calls the safe, which then kind of calls some sort of manager contract, which then calls the executor module, which then calls the safe, then the safe executes something.

Nicholas: Oh my gosh. So when you say it's like much more expensive, despite its maybe greater battle testedness, it's because of all of these calls to external contracts.

Konrad Kopp: Exactly. Yeah.

Nicholas: And what's the difference in the cost of Delegate Call versus external regular call?

Konrad Kopp: I actually think that there isn't a difference in the minimum gas cost. I think, yeah, I don't think there's a difference. But like you said, like the main difference here is the number of calls. Okay. So on the kind of like diamond account, you just have one to the accounts and then one delegates call. Whereas like here you have like multiple.

Nicholas: Is there maybe something also about like slots being hot because they're on like in the context of the calling contract in a Delegate Call or maybe not if you haven't touched the state of those storage slots yet?

Konrad Kopp: Yeah, that's a good point. Actually, yeah, you could get some savings because you might be accessing multiple slots, the same slot multiple times. That is true. You do get some savings for any call if the address is hot as well.

Nicholas: All right. So some savings. But am I crazy or it seems a little scary to be doing Delegate Calls out of my wallet? But it sounds like that's where we're headed.

Konrad Kopp: Well, I actually don't think so. I think it seemed like we were heading for that for a bit. But then I think a lot of people, like I said, like 6900 and most other people were like, this is a bit crazy. Kind of like you were saying.

Nicholas: All right. All right. And I'm sure, I mean, think how many, it can't be that many people who are already worried about this. It's a pretty niche subject, but an interesting one nonetheless. Okay. So ERC6900, modular smart contract accounts and plugins. So you're saying it's not going. Yeah. Where are we headed with this diamond versus safe pattern? And how does this relate to 6900?

Konrad Kopp: Yeah, I think like, I would probably say we're very sensibly kind of headed and into kind of like a compromise between the kind of meeting in the middle and trying to get the best out of both of them. Obviously, if you want, I can dive kind of like deeper into it. But I think that's like the high level takeovers.

Nicholas: Yeah, that's great. So okay, let's talk about 6900. You touched on it a little bit, but maybe can you explain what is it trying to achieve? Because it's sort of... Is it a direct successor or sequel in a way to 4337? Or are there other EIPs in between that it's relying on?

Konrad Kopp: Yeah, so it builds directly on 4337. And like I said, 4337 has very minimal kind of things to say about how smart contract wallets actually work. And 6900 actually is specifically focused on that. How, well, in this case, modular smart contract wallets work. And the main rationale or the main goal, I guess, of 6900 is to make sure that modules are compatible on different kind of implementations. And obviously, also that these implementations are the most secure that they can be. And this deals to A, make the life of module developers easier, because they can build a module once and then deploy it to any account. And it also means that users are less likely to get locked in. Because you might then create a 6900 account on whatever interface. So like Alchemy has an interface. But then you're actually like, "Oh, wow, this other company, call them like Company B, has a really cool interface. I actually want to use my same account with my same transaction history and assets. But actually, this is not my preferred interface.". And this obviously is very easy to do if you have an EOA. You just export the private key from Metamask and go into Rainbow or whatever. But you can't do that with smart contract wallets today.

Nicholas: Right. So this is one of the things that you mentioned in... Or maybe it's Kurt. But in any case, in some of the blog posts from Rhinestone, you talk about this concern about vendor lock-in, essentially, and having plugins that are specific to particular... You call them interfaces, but I would have used the word implementation. Maybe you can correct me. You'd say Alchemy's interface for 4337 is really the deciding factor here? If it has a different interface, then the plugins won't work with it, I suppose?

Konrad Kopp: Yeah, actually, this was a bit confusing on my end. I actually didn't mean to use interface in the sense of like a solidity interface, but like a kind of a front-end.

Nicholas: Oh, I see. Okay. So basically, the goal we're aiming for is that all AA wallets that comply with 4337 be able to have the same modules compatible with them. And 6900 is the way to get there.

Konrad Kopp: Yes, exactly.

Nicholas: And 6900, I mean, I keep hearing the name, it's still a draft, but my sense is that there's like pretty broad support for something like this happening.

Konrad Kopp: Yeah, I think a lot of people are excited about it. I think, and we've told the team quite a few times, it's hard to actually kind of see how far it's gotten without a reference implementation, without actual code you can look at. And I think they're working pretty hard and have been pushed by basically everyone in the space to kind of get this reference implementation out there, so that we can actually finally look at some code and look at how the account actually looks, as opposed to just reading the text and the specifications. I think they're meant to release that pretty soon. So I'm pretty excited about that. And I think after that, we can actually have a lot more focused kind of talks as a community around the specific code of how these accounts will look.

Nicholas: That's exciting. So for the commodity 4337 contract, do you think there will be a shelling point that everyone will end up just using more or less the same contract? Or are we going to have lots of different contracts? What are the different affordances that you would even be worth having different contracts for?

Konrad Kopp: Yeah, I think that's a really good question. I think there's, I mean, I could argue for both sides. So one of the sides is, basically, we might end up converging to the same, very minimal, but extensible account that everyone uses. And then really what your account is, is just a module. So essentially, what you as the owner kind of makes it to be. But there could also be, which is more similar to what exists today, there could be different account implementations, like economies or saves, or the kernel by zero dev. And they all have kind of like different trade-offs. And so some might be more gas expensive, but arguably more secure. So I guess like, I mean, that's kind of like a spectrum of trade-off, like gas versus security, I would say. Yeah, there's probably a couple of others.

Nicholas: But essentially, not mostly just these kind of under the hood optimizations, not really functional differences between the different account implementations.

Konrad Kopp: Yeah, yeah. Exactly. I would think so as well. Yeah.

Nicholas: So how does 6900 intend to make modules something standardized? What is the way that modules will interact with 4337 accounts?

Konrad Kopp: Yeah, so without kind of going into the specifics too much, it basically standardizes a how specific module types look. So the actual like solidity interface and what functions they must kind of have. And then also, it specifies how accounts call these modules. And that's essentially just the pieces that you need. And then the steps in between, like different accounts, kind of builders can decide. Like I said, like maybe opt for security, maybe you want to have some insane optimizations. But yeah, that's the main aspect of it, I would say.

Nicholas: Okay. And you're not...Rhinestone is not one of the authors on 6900. So what's left for Rhinestone to do if 6900 is coming into play?

Konrad Kopp: Yeah. So I mean, obviously, I would say something pretty big is still left. Obviously, we wouldn't work on that on Rhinestone if it wasn't. But you still kind of with 6900, even if you don't delegate call to a module, you still as a user, you need to know that you can trust that module. Like that's true even if you don't delegate call to it. Because for example, even if that module kind of calls back into the account, it could just tell the account to kind of like transfer all the assets somewhere else. And the way we think about kind of adding protection to users, especially to users who can't manually audit every single kind of module that they install, which is obviously the majority of users, is we introduced this kind of concept called the registry. And that registry essentially allows people and those people mostly being kind of security auditing for firms or maybe kind of automated like scripts and that kind of stuff to essentially make security statements about these modules, which we call attestations. And users who then install or want to use a module, they can then query the registry with a module address and essentially ask, "Is this still safe to use?". And if it is, then they use it. And if it's kind of like been flagged as not secure, then they might not use it or uninstall it or not install it.

Nicholas: So the registries will function something like an on-chain Yelp for modules?

Konrad Kopp: Sure. For security, I guess.

Nicholas: Entities like known entities will attest to the security properties and can then if they discover some problem in like a new version, or I guess, are there versions of modules even or it's for a specific version that they make an attestation, I guess?

Konrad Kopp: Yeah, you could have kind of modules that are upgradable. I think we as a security entity will strongly prefer like modules that aren't upgradable, just because it's easier from a security perspective and kind of like less things can go wrong. But yeah, you could have, well, you can have versions that have different addresses. But in theory, you also could have versions that have the same address, although it's less secure.

Nicholas: So it would just be up to the attesting organization if they want to attest to an upgradable module, that's sort of on them. But then if, so let's say, what kind of organization might do that, like a security auditing firm, for example?

Konrad Kopp: Exactly. Yeah. So security auditing firm, kind of either, it could be solo auditors, it could be kind of like just normal auditors, it could be someone who's doing formal verification, or other kind of more automated type of security and testing.

Nicholas: And this registry would live on which chain?

Konrad Kopp: Or all of them? Yeah. So it would have to live on all of them. That's one of the issues, or at least until we solve some of the cross-chain problems. So actually, for example, I'm not sure if you've read Vitalik's post about the Keystore. But you could use the same for a module registry, you could read from a different chain. For example, if it lived on mainnets, once that's kind of like that infrastructure is in place, you could read on it from Optimism. But until then, it's kind of has to live on every chain.

Nicholas: So congratulations, by the way, on the recent EF grant. I take it it's to work on this problem?

Konrad Kopp: Exactly. Yeah, exactly. So we've been working with the 437 team, or they've been supporting us and kind of like figuring out this problem, essentially.

Nicholas: Very cool. So okay, so there's a registry, then there's going to be people attesting to the security properties of different contracts saying that they're, you know, good or not good. And then from the perspective of someone installing a plugin, I guess the idea is that the front ends would pull in some of the attestation data to give you kind of like a verified security review of the plugin before you click install.

Konrad Kopp: Yeah, exactly. So you would, you could have this on the front end, which obviously like might mean more or less to user depending on how technical they are. But the more important part is that you actually also perform this check on chain. Because like I said, like, one of the things that 6900s or in general, like kind of modular accounts aims to solve is kind of removing the vendor lock-in, which is great because you can take your account to a different kind of like wallet interface and use it there. But it's also bad because you might go to malicious interface, and then it tells you to install this module and says, oh, yeah, this is safe, but actually it's not.

Nicholas: Before we go further on that, how would I even switch from one interface to another interface? Like let's say, I guess maybe pass keys are a little bit restrictive because there's some domain restrictions about using them. So let's just say that it's a EOA signer, I'm using Metamask to control my AA wallet. How would I switch from one interface to another? I guess just connecting with Metamask on a different UI?

Konrad Kopp: Yeah, for example. So we're working on something for the reference implementation where you can connect your Metamask. And then if you have existing saves, those will kind of pop up and you can use those saves like in the reference implementation and kind of start modding them.

Nicholas: So basically, the interface is able to go look up which saves this EOA that's connected in like the injected in the browser, which saves it's an owner of?

Konrad Kopp: Exactly. Yeah. And you could also just have the user import the address of the smart contract wallets. Obviously, that would be more cumbersome. But yeah, there's different ways of doing that.

Nicholas: Yeah, I'm curious about what this experience is going to be like. I don't know that I've seen a really solid demo where people are logging into experiences as the AA wallet, even if all that they have in their personal custody is some kind of signer like a passkey or an EOA.

Konrad Kopp: Yeah, yeah. I mean, I think like, I don't have anything to show right now. But I think it'll be basically like, like you described it. Okay, so discover the specific case. Yeah, exactly.

Nicholas: So you'll basically sign in with the signer key, or whatever authentication mechanism that is, and then the interface will handle all the nasty business of figuring out what contracts you own, what accounts you own.

Konrad Kopp: Exactly. Yeah.

Nicholas: Very cool. Okay. So we were talking about permissions and the registry stuff. So you're saying that also, you could have maybe like a plugin or module to tell me which terminology, but where my account would essentially reject adding additional plugins if they don't, if they aren't on the list of authorized ones from some trusted security firm or something like that.

Konrad Kopp: Yeah, yeah, exactly. Yeah. On the terminology, we've kind of tried to push people to use modules generally, because some people call executors plugins, and some people call executors plugins, and then everything else also plugins. But yeah, yeah, exactly. So one of the things we've been working on is what we call adapters. And it's those kind of adapters. And those adapters, they might be modules, but they could also be kind of native functionality in the account. And those adapters are kind of responsible for performing this check on the registry, depending so user can decide like, do they want to perform this check only when they install a module, or do they also want to kind of perform this check every time they use that module, which would obviously be more expensive, but more secure.

Nicholas: And that would be in the case where the modules functionality changes over time, it's upgradable, or it depends on something external to the module itself.

Konrad Kopp: Yeah, not even right, like you have a lot of contracts that never changed. But after like, I don't know, like a year, like someone finds an exploit, right? So it's just kind of like for ongoing security.

Nicholas: Okay, so so just to walk through the whole flow, make sure I understand. So basically, I sign up on, let's just say rhinestone, or, you know, brine stone, some app version of rhinestone. And I sign up for I log in with my touch ID or face ID, it generates a passkey, it counterfactually deploys an AA account onto some lovely L2. So and in this counterfactual deployment, it's also going to specify, of course, the WebAuthn plugin in order to be able to verify my r1 signatures, but maybe it'll also specify sorry, module, maybe it'll also specify another module that will check or maybe it's intrinsic to the account where it's going to check either only at install time, or every time I send a user op, whether or not that module that it's interfacing with is on the brine stone, trusted list of in the registry, essentially, that it's attested to by the brine stone devs. And then if it's not, the transaction will just revert or won't even be propagated from the mempool because it won't be a valid transaction.

Konrad Kopp: Exactly. Yeah, yeah, I think that's a good summary.

Nicholas: Sweet. That sounds great. How long do I have to wait?

Konrad Kopp: Well, so we're, so we've been, yeah, I mean, we've been working pretty hard on the registry and releasing v0.2 after like a lot of feedback. And I think we're pretty happy with where it is now. And so the other two things that we've been working on are one on the user side, like I said, the reference implementation. So for that, I think, I would say we'll have some early testers on the reference implementation this side of Christmas, but the majority will be after the new year, essentially.

Nicholas: That's a reference implementation of which piece specifically?

Konrad Kopp: So that's a reference implementation of a modular wallet. So kind of like the front end interface. And the reason we're building this is kind of, well, it's twofold actually. So one of them is definitely just kind of getting this concept out there and having people play with modular accounts. Because right now, we can talk about it, we can show you mocks, but no one actually has an interface for a modular account. So it's still kind of out there. And the second kind of purpose of it is just being a playground, both for us and then also for other developers to test building modules and building the front end components for modules, and then just play around with that, basically.

Nicholas: So this will be a reference 6900 wallet. I guess we'll eventually move from talking about 4337 wallets to talking about 6900 wallets, or accounts.

Konrad Kopp: Yeah. So on launch, it won't be 6900 compatible because there's not enough time basically from the reference implementation and so on. But we'll use different kind of modular accounts under the hood. So like I said before, you can import your safe, which is obviously modular, or we can spin up a different modular account for you under the hood.

Nicholas: Oh, okay. So you're even going to kind of agglomerate all the different underlying implementations into a modular experience that papers over the difference between safes and 6900s? Yeah, yeah.

Konrad Kopp: That would at least be... Yeah, we'll have some of that in kind of like the early version. And then if we continue building this kind of longer term PC value there, then we would, yeah, like you were saying, aggregate basically all of the accounts out there, or a lot of the accounts out there that we think are worth supporting.

Nicholas: Interesting. Okay. So Rhinestone then is kind of leading the charge for, or part of the many people leading the charge to make modular smart contract accounts a reality. And you're also going to go the extra distance and not just put your weight behind 6900, but also support these other things that are out there.

Konrad Kopp: Exactly. Yeah, yeah. Yeah. I mean, we're pretty big fans of 6900. I think one kind of critique, not of 6900 specifically, but generally of kind of the approach of write the standard first, and then build implementations, is you just get less experimentation, right? Like if everyone, if 10 people or 10 different teams decided to build a modular account first, and then we kind of get in a room a year later and say, "Okay, cool. Here's the learnings. What should the standard be like?". That could arguably be a better way to do it. So I think experimentation makes a lot of sense at this point. But my hope at least is for 6900 to take learnings from different places anyways, and kind of converge on a standard that makes the most sense.

Nicholas: Okay, I see. That makes sense. So really, you're building out this reference implementation, or an attempt at it, at least, in order to try and practice with some real running code, simultaneous to the development of the 6900 thing. So it's not competing. It's sort of a simultaneous effort.

Konrad Kopp: Yeah, yeah.

Nicholas: Okay. So you mentioned two things there. The first was, we talked about the 6900 stuff, we talked about the reference implementation. Was there a third thing that you're working on that you wanted to mention?

Konrad Kopp: Right, yeah. So the other kind of like, I guess side of the marketplace, you could call it, is obviously developers who are building modules. So we've been pretty focused on, well, a building modules ourselves, and then kind of taking the learnings from that and helping build to build tools. that allows other developers to build modules and ship modules as well. So one thing we released a few weeks ago now, I think, or maybe a couple of months ago now, actually, is called the module kit, which is basically an abstraction library that lets you really easily kind of build a module, and then test it. on launch, it was just the safe. So it had a library or has a library that abstracts the entire testing away from you. So you just build the module. And then there's kind of, for example, like a helper function, which is called exec4327. And you just call that and it executes a 4327 transaction for you. That goes from the entry point to the account and does everything kind of under the hood. And we're working right now to support other accounts as well. So that's kind of the other area that we are pretty heavily focused on.

Nicholas: So module devs can just focus on building their module and not dealing with all the other plumbing.

Konrad Kopp: Exactly, exactly.

Nicholas: Very cool. Before I forget, I wanted to ask you about the registry. Is the idea that there's a single registry on every chain or that there can be even multiple registries?

Konrad Kopp: Yeah, that's a really good question. So one of the things that we're, like we've talked quite a lot about, and we're pretty convinced that it might be the best approach is to have a singleton registry. So yeah, a single registry on every chain. And the main reason for that is basically that you have kind of maximum module liquidity, I guess you could call it, which basically means that you can always go to the same place and all the modules will be there, which also makes it harder to lock in people into a specific registry and into kind of only being able to use the modules on that registry. So the way we've designed the registry we've been working on is essentially it's kind of permissionless. Anyone can deploy modules, anyone can attest as well. It's only us, we can't upgrade it after it's deployed. And it's obviously free to use. But that being said, there might still be reasons why you would want to have your own registry. Off the top of my head, I'm not sure if any of those reasons are super valid at this point. But I think that could still be the case.

Nicholas: So basically, one advantage of it being a singleton is that you get the same address, most likely across all chains, right? Barring any strangeness to a specific chain. So that'll be kind of easy. I mean, just simplify implementation for everybody and avoid bugs and make a single place, as you say, avoid lock-in and things like that. That's interesting. I was talking to somebody at SAFE who was telling me a little bit about their approach to registries at ETH Global NYC. And I think their approach there maybe are more focused on having multiple registries rather than a single place. I'm not sure. But it sounds like there is a variety of designs competing in the space right now.

Konrad Kopp: Yeah, yeah, for sure. Yeah, I think with SAFE, it's still kind of up in the air. For the SAFE protocol right now, it does look like they want to support multiple registries. But I also haven't seen a reference implementation of a registry yet. So it kind of might still change. I think, I guess the biggest downside of using a singleton is obviously it's kind of like a central point of failure, which obviously is a major downside. But it's kind of like the same downside, for example, that the 437 entry point has. It's kind of also a singleton that pretty much everyone uses, which could also be a central point of failure. But it's kind of, especially the community or just like kind of auditors and pool their resources and everyone kind of gets behind and helps secure this single point, then it can lead to a lot of upsides. But yeah, I think you're right. We will still see kind of how it plays out. I think it's the users, like the end users who would win the most if it was a singleton. But yeah, things might not be as easy as they are in theory.

Nicholas: Yeah, there's definitely a lot of complexity in this emerging AA field. And I can already sense people not being excited about much additional complexity and dependencies there are, even on standards, not on companies or centralized parties necessarily. But just, it's a lot more complicated than an EOA.

Konrad Kopp: Definitely. Yeah, that's true, for sure.

Nicholas: It'll be interesting to see if, you know, it seems like the UX for this stuff will enable things like passkeys, for example, which could potentially way outstrip the number of EOAs in a relatively short period of time if any killer applications come along that happen to build in AA wallets. It seems like we could really have an explosive growth in accounts that could make the preponderance of EOAs today seem a little bit less insurmountable. But it definitely does feel like there's a lot of new stuff to understand, and maybe some dangers in adopting so many things at the same time.

Konrad Kopp: Yeah, for sure. I mean, I guess our jobs as people building in this space is to, especially for the mainstream end user, to simplify it as much as possible. Not just the UX, but how the entire thing is presented and how we talk about it and so on. But I fully agree. I think like definitely passkeys and a lot of really cool other interesting stuff like, for example, being able to do kind of automated trades like DCA or kind of like limit orders or whatever, like stuff that right now in crypto you can only do really in centralized exchanges unless you want to give up custody of either your key or your assets. I think there's a lot of other really cool stuff that's enabled by modular accounts and that will draw in a lot of people.

Nicholas: I guess you can even do things maybe like intents where you don't have a lingering approval, but it's just built into the intent itself and sort of extinguishes itself at the end of the transaction.

Konrad Kopp: Yeah, definitely. You can also, for example, you could have a module that is triggered at whatever frequency you want that revokes all of your allowances for your AC20 tokens. Or you could even have a service that you trust, or you could kind of build in some kind of way to verify that trust on chain. But some service that can monitor hacks and say if DEX one is hacked, it will kind of try to front run attack or at the very least kind of get out your liquidity as quickly as possible or remove your allowances as quickly as possible. That's cool.

Nicholas: That reminds me, I think it's Harpy that works something like that, where if they detect a malicious transaction in the mempool emanating from your account, they can, I guess from a vault, I think they have a separate signer that can try to front run the malicious transaction and remove the approval. I think actually, it only has permission to move the assets into a vault that only you control. So I guess you could achieve something like that even in a simpler design with a module.

Konrad Kopp: Exactly. Yeah, exactly. Yeah, there's a couple of kind of different projects. I actually previously worked on something during a hackathon where we tried to front run hacks and then pause using kind of like the possible kind of, what is it, like OpenZeppelin has a possible library and essentially tries to prevent trading contracts or trading taxes or whatever. But yeah, I think that concept is really cool. Especially when you can start moving that functionality right into your wallets.

Nicholas: Yeah. Yeah, maybe even make it a default for someone on Brinestone. So speaking of modules, this is super interesting. I think there's probably some prospective module devs listening. So we talked about a handful of things. Are there any other one that jumped out at me from the demo that I saw as a deadman switch we didn't talk about yet?

Konrad Kopp: Yeah, the deadman switch is pretty cool. Obviously, I'm not sure how many people actually use it. And hopefully not that many, especially people that probably set up kind of recovery. I think we actually have a list. It's linked in our docs and it lives on our notion of about maybe 26 or something like that, module ideas that we've just kind of like thought about over time and been pretty excited about. But yeah, I've already named quite a few exciting ones, like the virtual storage and so on. One that we've been talking about internally is kind of similar to what you were talking, I think, about earlier with the flash loans. You could also kind of do NFT rental directly from your account, or actually instead of moving that asset, you just give someone else the permission to, you know, for example, prove ownership of that asset using a signature. I think that could be quite cool.

Nicholas: That's awesome. We sort of mentioned it in passing a couple times, but social recovery is a big issue, or I guess recovery in general. Do you have any ideas about how recovery ought to work for this kind of wallet?

Konrad Kopp: Yeah, I think recovery should be a module. Obviously. And one thing that's kind of quite interesting is, we were talking about validators earlier, and you can have multiple validators, right? Like you could have a WebAuthn or a POSKEYs one, and you could have an EOA one where you have like a ledger, for example. And the issue is, on a naive implementation, you might have to have recovery for every validator specifically. So your POSKEYs validation module has social recovery inbuilt. And then when you want to change the guardians, or whatever you want to call it, kind of like the entities that can help you recover, you have to change it there. But then you also have to change it kind of on your EOA validator that you use your ledger for. So I think kind of the way that recovery will work is it'll kind of be a separate module as well that can then interface with these other validation modules and help recover them.

Nicholas: That's very smart. So basically one source of truth on how to do recovery across all of the keys, all the signers.

Konrad Kopp: Exactly. You might still have different recovery modules that have different ways to recover. You might have a social one, you might have an EOA based one, and maybe those could even have different permissions. But yeah, exactly. Kind of like you were saying.

Nicholas: Very, very cool. Speaking of permissions, at least the impression that I got from the demo from ETH Denver is that permissions are handled by either adding or removing a plugin, or sorry, a module. And that there's no separate notion of permissions. Is that how you think about it?

Konrad Kopp: Permissions? Do you mean permissions to kind of execute transactions from the accounts?

Nicholas: Yeah, let's say that we lived in a world post-Rhinestone, post-6900, and something like Frentech were to come out and you wanted to connect to Frentech with an existing wallet rather than creating a new embedded wallet with a signer specific to the app. You might not want to give it access to your whole vault. You might just want to have some limited permissions. Would the likely path be that someone like Frentech would have to build a module that you would interact with? Or would you have some way of defining some set of permissions that maybe a specific signer that lives inside of the Frentech PWA can only execute certain kinds of transactions?

Konrad Kopp: Right. Yeah, I think that makes sense. Yeah, there's different ways you can do this. And one of the ways that people talk about is session keys. So you can kind of create specific keys, and those might be ERA keys, but they could as well be a passkey, and then link that key to specific permissions. So those permissions might be related to the contract that it or contracts that it can interact with, might be the value or the call data that it can send, or it might be kind of restricted to a period of time. So yeah, that's definitely something that's possible. And some people already have some session key modules in production even, I think.

Nicholas: So session keys are something that in the absence of modules, you could configure directly on a 4337 contract. But with modules, it would make sense to use a session key module to simplify that interaction and standardize it, I guess.

Konrad Kopp: Exactly. Yeah, exactly. And you could even have different implementations of session keys, like that simultaneously live in your accounts as different modules, because some might have... I think this is actually a pretty recurring theme, the trade-off between gas and security. But some might be more secure, but kind of cost more gas to verify or whatever. But yeah.

Nicholas: Very interesting. So many trade-offs. But I feel like we're headed in a very good direction with all this stuff.

Konrad Kopp: Yeah, I agree. I'm really excited about the space and modular accounts and all of the things that they can unlock for users, whether that be us or whether that be mainstream users.

Nicholas: So we touched on this a little bit earlier, but continuing with this Brinestone example, if I go to an app, and I want... So maybe the answer is that session keys are the sort of 6900 native equivalent to something like Wallet Connect, that I would just create a new session key and essentially be adding a module or permission to existing module already on my 4337 account, rather than connecting in with something like Wallet Connect? Or do you think we actually will still use Wallet Connect and things like that?

Konrad Kopp: Yeah, I think there's definitely room for both. So how I would think about it is, you go to an app and you connect for the first time, or you're just going to connect once. You still do it through Wallet Connect. But then say that's the app, or say you go to a different app, and that app is a game. And basically, every move that you make is recorded on chain. And so you need to, in theory, you would need to create a user operation. But what you could do is you could just say, the app could say, here, I'll spin up this key, which only lives in the browser. And then you say, great, I'll add the public key of that private key to my session keys module and give it these permissions. And then from then on, the app within the browser can then create transactions or user operations and execute them automatically. And so say you move, the app executes that user operation for you. And you don't have to worry about a wallet popping up or even taking you to a different browser or using your phone and pressing confirm after everything you do in the game. But it just happens seamlessly.

Nicholas: So essentially, in a 6900 or rhinestone future, it's possible to execute like a one-off transaction from a DAP or an app. But it's also possible to create like a session key for an enduring relationship. So it's really slick from then on.

Konrad Kopp: Exactly. Yeah.

Nicholas: I'm pretty into, I don't know if you saw the latest version of Warpcast, is using this large blob feature attached to passkeys to save the recovery phrase for the Forecaster PK that they need to sign Forecaster casts. So basically, the app keeps in memory the private key, which it uses to sign every time you send a cast. But if you ever lose your device, you can recover it by grabbing the passkey off of iCloud keychain in the future, which essentially restores something like a kind of low key session key, I guess you could call it because it is just a regular POA.

Konrad Kopp: Right. That's really cool. I hadn't heard about that. But that's actually a really cool design.

Nicholas: Yeah, it's very slick. And it's like in production right now. I think the one thing that's maybe a little tricky because there's quite a bit of detail to it is to realize that the fact of putting this Forecaster private key into the large blob associated with a passkey is really just solving for backup and recovery. If someone loses their device, it doesn't really change the score on that private key living in memory of the app as it runs, because it needs to have access to it in order to cast.

Konrad Kopp: Yeah, yeah, that makes sense.

Nicholas: I guess we're gonna see a lot of variety in how people go about things.

Konrad Kopp: Yeah, yeah. I'm pretty excited about kind of all the possibilities that people can, all the ways that people can, you know, make either transactions kind of on an ongoing basis, or just like onboarding or whatever, like Slickr and just like abstracted away, essentially, right?

Nicholas: Yeah, it's gonna be great. I'm really excited. So is Rhinestone for end users or for devs? It sounds like it's kind of at least right now for module devs and kind of helping people to get across the chasm and start implementing stuff to accentuate and evolve the 4337 reality. But do you ultimately anticipate being something built for end users as well?

Konrad Kopp: Yeah, I think that's a good question. We haven't decided, basically. So the main thing we're working on is obviously this infrastructure. And we're mostly building for devs, but also kind of, like I said, like the reference implementation is kind of user facing. I personally kind of like long term. I think the way is that Rhinestone, or kind of this like modular ecosystem with Rhinestone and the registry and kind of like the protocol built on top of this as part of it. And that kind of is unbundled and put into different kind of wallets, the wallets here being the front end UIs, whether that's a Chrome extension, mobile app or whatever. And that can empower both wallets kind of in the traditional sense and also embedded wallets. That's kind of how I see the end vision. So it would not be directly user facing, but users would use it.

Nicholas: By the way, we've been throwing around like wallet account and all this. Should we really stop saying wallet and just say account? Because or what's the correct terminology you think?

Konrad Kopp: Yeah, I mean, so what we use is basically we call the on-chain kind of the smart contract wallet, we call that a smart account. And then we call the kind of the front end interface. So the thing you actually interact with, we call that the wallet.

Nicholas: So the thing that holds the signer, basically.

Konrad Kopp: Exactly. Yeah.

Nicholas: It's tricky because I've always felt wallet is a very, very bad metaphor for what this is. I understand in some sense, it's like the thing that holds the keys to your assets. But it doesn't, I don't know that for regular people, wallet means wallet or something. It's more like account in terms of experience, especially with things like sign in with Ethereum.

Konrad Kopp: That's true. Yeah, yeah. Maybe we'll move to account kind of like for everything. I think, yeah, I also quite like account. I do think it kind of gets complicated if you just say account and then you don't know this is like the front end, now it's just the back end, like the smart contract. But yeah, I quite like account as well as a general term.

Nicholas: Yeah. I mean, you have a Facebook account, you have a Gmail account, and you have a crypto account. I don't know.

Konrad Kopp: That's true. Yeah, that's true.

Nicholas: So I only have a couple of questions left, and I'll ask you in a second if there's anything we missed. But one ERC that we haven't talked about is 6492, the signature validation for pre-deployed contracts. Is that something you think about at all? I think that's a pretty cool ERC.

Konrad Kopp: Yeah, it's really cool. I actually don't spend that much time thinking about it, because it's mostly for dApps, right? So dApps will need to integrate this, just like they need to integrate 1271. It is essentially an extension of 1271 for counterfactual address generation. So yeah, I think it's really cool. Definitely try to support it and just general awareness for dApp builders to think more about account abstraction. But yeah, I'm not actively involved in building it, and I don't think about it enough.

Nicholas: But yeah, so for people who don't know, 1271, standard signature validation method for contracts is, in the terminology of the EIP, a standard way to verify a signature when the account is a smart contract. And I guess that's from way back in 2018, but I think a lot of dApps don't have that currently, right? There's a lot of things where you can't connect as a safe, for example, today.

Konrad Kopp: Yeah, yeah, it's still an issue. This is still an issue both on the dApp side and on some smart contracts. But yeah, I think, yeah, in my mind, the way to get out of there is, A, just put pressure on basically every dApp to support this. And then also start educating new people, well, new developers that enter the space, and start having them think about signatures, not only in the EOA signature, like ECDSA signature sense, but also about smart contract signatures. Because I think, for example, when I was getting into the space, I would look at a tutorial, and it's basically like, how do you recover a signature? And then it just says, like, use ECDSA recover. And like, sure, that works, but it kind of knocks out smart contract accounts.

Nicholas: Yeah, and then this 6492 signature validation for pre-deployed contracts is really cool, because a lot of the time, you actually don't need to deploy the AA account in order for, let's say, someone with a passkey or an EOA generated in an app or a PWA to be able to start interacting with things. They can be signing, you know, mint permits, intents, all kinds of different things, connecting to apps that ask them to sign something to agree to their terms of service, etc. They could do all of that without actually having spent any gas and not even being subsidized by some kind of sponsor either, if the dApp supports 6492. So that's pretty cool.

Konrad Kopp: That's right. Yeah, that's super cool. I think one of the coolest things that started to be adopted, or basically the default for smart contract wallets today, is counterfactual deployments. Like you said, you get an address as soon as you create the account, but actually, the account isn't actually deployed and you don't have to pay for gas until you actually do the first on-chain transaction. And like you were saying, this means you can receive stuff. But you can, in theory, also create a signature and use that either to sign in or even to create some intents that someone else then relays and pays gas for you. So yeah, we kind of need this, or we need the apps to support this.

Nicholas: It's really cool. One thing that I actually am curious, I wonder if you know, if I do a counterfactual deploy of an AA wallet, so I compute its create2 address, even though nothing has been deployed on-chain for, let's say, a passkey generated in a PWA, let's go with the trendy topic. If I want to add an additional module or a signer or somehow change the configuration, but the contract isn't yet deployed, is that something that I can do off-chain and then just propagate both at the same time in a bundle? Or how would you, maybe you only want to interact with the counterfactual address as long as no state changes have been made to the permissions on the contract?

Konrad Kopp: Yeah. So if you actually want to change the states, then you would actually have to put it on-chain. What you can do is you can either yourself or you can trust someone else to hold transactions for you or use operations. So for example, you might say, "Actually, I create this user operation to change whatever now, but someone else is going to hold on to it and then they're going to relay it at some other point.". But this obviously means you have to trust that entity to not lose it, essentially. So yeah, that's kind of an issue. We started thinking about that a bit more and seeing what other things are possible there. But yeah, I haven't delved into that too deeply.

Nicholas: Yeah. I mean, it's pretty niche at this point, but it does seem like, you know, you can imagine someone creating an account on one device. They don't need to deploy the contract yet. So it's still counterfactual. And then they go and add another device, maybe on a different platform. And because of some challenges like syncing passkeys or passwords, et cetera, it's better to just make a new signer on the other device and add it to the 4337. But someone's going to have to start paying gas or at least hang on to those user ops somewhere safe.

Konrad Kopp: That's right. Yeah. I think some other teams are definitely thinking about this as well. But I think there might be some pretty cool solutions we have to this where you can at least reduce the trust assumptions and make this even smoother for people.

Nicholas: It does remind me, we kind of touched on a little earlier, but it's like multi-chain permissions. You know, I add a signer or I rotate the keys because something got compromised or I lost the device. I guess we're just waiting on Vitalik's vision to be a manifest or something like that.

Konrad Kopp: Yeah. Yeah. Cross-chain is a huge thing for small contract accounts. So on the one hand, I think you touched on this a bit earlier, you have some chains where you can't actually get the same address. That's obviously an issue. And then you also have dependency on... You might want to install a module on every chain, but actually, you don't want to pay gas on every chain. That's kind of stupid. Or you might want to read from a contract like Keystore or the registry, even if that contract only exists on one chain. And there are some... I mean, obviously, it seems like Vitalik is exploring this. I know that Optimism, they sponsored or gave a grant, I think, to a team to implement the... I think it's called Static Call into L1, where basically you can... Well, Static Call into L1 and read data on Optimism. Data that's stored on Ethereum.

Nicholas: So it's okay as long as you're willing to store your permissions on the most expensive chain.

Konrad Kopp: Yeah. Yeah. That's definitely an issue. And you would also... Well, first of all, you would also need other L2s to support this as well. Otherwise, you can just do it on Optimism.

Nicholas: Right. It seems like a real political problem to put this on any of the less expensive L2s. Like, which one?

Konrad Kopp: Yeah. Yeah. And also, I think the other problem is also it's just a lot harder to read cross L2s, as opposed to read from L1, from an L2.

Nicholas: Yeah. Research to be done. More grants to be given.

Konrad Kopp: Exactly. Exactly. And this doesn't impact account detraction only, right? Like, you already have teams like, I think, Herodotus, they're called, who are doing storage proofs.

Nicholas: Yes.

Konrad Kopp: That are used for other applications as well. I know WorldCoin, actually, I think they were working on a solution where they were bridging storage proofs. I don't know if it was bridging per se, but moving storage proofs from Polygon to Ethereum or something like that. And they moved something like that.

Nicholas: All right. Well, we've reached the end of my list of questions, but I feel like there's tons more subjects that you're interested in and are worth talking about. Is there anything that jumps to mind that we didn't cover that people should know about Rhinestone or about this modular space related to AA wallets?

Konrad Kopp: Yeah, that's a good question. I think we talked about quite a lot of stuff, to be honest. I guess one thing we could talk about briefly that we haven't talked about is that one thing that is kind of necessary when you have these on-chain modules is you also need a way for frontends to be able to format or create call data or signatures the right way so that you can actually use those modules. And that's something I think that's generally less talked about and also just less thought about. Because say you have a kind of... Like you were saying before, you have two wallet interfaces, both being frontends. On one of them, you activate a validator. Let's say that's a Postgres validator, right? And then you move to the other interface. And that other interface also needs to... Well, first of all, you need to add a different Postgres probably to the module. But then it also needs to know how to actually encode the signature that's created by that POSKEY the right way and then pass that into the user operation. So there's also some interesting problems there.

Nicholas: So this is the... Can you just repeat exactly what the... Constructing. which part is the problem? Where's the need for standardization exactly, or at least for communication between these modules?

Konrad Kopp: Yeah. So constructing whatever data a module needs. So it might be the signature that the validation module, for example, parses and verifies. Or it might be the call data that, for example, a hook or an executor module can use. And the frontend just needs to know how, based on whatever module is going to be called or going to be used, it needs to know how to format that data.

Nicholas: Hmm. And is anyone working on that right now?

Konrad Kopp: So we're exploring that. It's not the highest priority right now. As far as I know, there's no one else in the open talking about it. I know, I think Jaden from SolWallet, he put some thoughts out there at some point, to even maybe create a domain-specific language for doing this for frontends. But I'm not sure to what extent SolWallet is exploring this. But it's something that we think about, I guess, to some extent. And one of the solutions we see is you have this library, essentially, of on-chain modules. It's not a library in the strict sense, but there's just different on-chain modules that exist. And then you also have, corresponding to those on-chain modules, you have a library or whatever of frontend modules. And then an interface could say, "Oh, this is not going to use validation module A." And we just kind of fetch either just the functionality, or even kind of like a widget or an interface that can be embedded in the frontend, to actually format the data the right way to be sent to validation module A.

Nicholas: Do you think that's something that might live on-chain, like in parallel to the registry related to security?

Konrad Kopp: Yeah, well, it's mostly off-chain for frontends to do. It could live on something like IPFS, or RWEV, where I guess more and more people are starting to host frontends there, to have more secure data availability. Secure in the sense of trust assumptions, but yeah.

Nicholas: So you might imagine a module might be registered on-chain and have a pointer to the content address on IPFS, or something where a frontend could go fetch the format of call data it needs to pass.

Konrad Kopp: Yeah, for example. Yeah, I think that could be a feasible architecture.

Nicholas: Very interesting. All right, Konrad, this has been amazing. Thank you so much for coming in and telling us all about Rhinestone. This is really exciting. If people want to find out more, if they want to start building modules, where should they go? Where should they find you?

Konrad Kopp: Yeah, so on Twitter, we're @rhinestonewtf. Our website is currently very underdeveloped. It was built during ETHenver, actually, in a few hours by myself. And we haven't had the time to update it. Although we will soon. But I think for developers, the best place would be to go to our docs, which are docs.rhinestonewtf, and kind of find out all about the registry, the module kit, and kind of how to get started in the modular ecosystem.

Nicholas: Yeah, very exciting. And make sure to interact on Twitter, because I think your Twitter account is like Shadowband or something. I can never get you to come up in the search results.

Konrad Kopp: Yeah, it might be the name. Maybe Elon doesn't like the WTF.

Nicholas: WTF somehow, Elon doesn't like it. Yeah.

Konrad Kopp: Yeah. It's okay.

Nicholas: Oh, well.

Konrad Kopp: We're an under-followed account.

Nicholas: What is it? Shadowy super coders. So I'm sure the right people will find you. All right. Thanks so much for coming and sharing all this information. This is great.

Konrad Kopp: Yeah, thank you so much for having me. It's great to be on the podcast. I think I already told you, but I'm a big fan. I've been listening to most of the episodes, I would say, actually. Oh, wow.

Nicholas: Thanks so much. That's great to hear. Well, I'd love to have you back, and I'd love to have Kurt on in the future as well to talk some of the product. thinking around this as well in the future, when maybe you have something else to announce or some news about the 6900 or the EF grant. It'd be great to have you back.

Konrad Kopp: For sure, yeah. That'd be great. Yeah, we'll definitely think about it.

Nicholas: Awesome. All right. Have a great rest of the day. Thanks, everybody, for coming to listen. See you a little bit later on today, having a second interview at 5 p.m. Eastern today. So see you in a few hours. Thanks, everybody. Thanks, Conrad.

Konrad Kopp: Great. Thank you. Bye.

Nicholas: Hey, thanks for listening to this episode of Web3 Galaxy Brain. To keep up with everything Web3, follow me on Twitter @Nicholas with four leading ins. 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.