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 Christoph Gazso, founder of Pimlico. Pimlico is an ERC4337 smart account infrastructure provider. Pimlico offers a handful of services, including Alto, the most popular bundler by total executed user operations, a Paymaster transaction sponsorship solution, and permissionless.js, a new platform agnostic TypeScript library built on top of VM that helps devs wire dApps up to smart accounts. On this episode, Christoph and I chat about the design of 4337, the most recent updates to the spec, and their recent seed round fundraise. It was great getting a chance to talk to Christoph about his journey building Pimlico. 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, Christoph, how's it going? It's going great. Christoph, thanks so much for coming to talk about Pimlico and everything you're working on.

Kristof Gazso: My pleasure. I'm very excited.

Nicholas: I love the name Pimlico. Where did you get the name?

Kristof Gazso: So Pimlico is actually a neighborhood in London that I happened to live in previously. And, you know, that was kind of the inspiration. But, you know, the actual reason was like, okay, I really wanted a name that could really serve as a blank slate. People didn't really associate with anything. So in the same way, you know, Solana is a beach, technically, right? Right. Pimlico is a neighborhood. But obviously, the idea is to evolve into its own brand, in a way.

Nicholas: I find it a very upbeat name. It just sounds fun to say.

Kristof Gazso: Tell me more.

Nicholas: Oh, I just like it. Pimlico. It's just, it's fun to say. I didn't know, I wasn't familiar with the neighborhood before. So it's the first time I, well, it maybe has some, maybe I have some recollection But I would never have been able to say it was a neighborhood. But it sounds so upbeat.

Kristof Gazso: Yeah, thank you. Thank you. I think the P and the K sound definitely make, kind of makes it seem powerful, in a way. Like, you know, it's strong, you know, stable, reliable.

Nicholas: That's interesting. Pimlico, it's the vowels that make me think almost Italian or something.

Kristof Gazso: Interesting. That's the first time hearing that. But that's a good point.

Nicholas: A subjective take, anyway. So I'm curious, I guess, to start off, tell me about how, how 4337 came together and how you got involved in co-authoring the ERC.

Kristof Gazso: Yeah, that's a, that's a cool story. I used to be an Ethereum core researcher back in the day at Nethermind. And I initially did some research on MEV stuff, then spent a bit of time on the merge as well. This was in 2021. And, you know, then I really took a step back and I started thinking, okay, what are actually the biggest outstanding problems that I, as an Ethereum core researcher, can really try and address, right? And, you know, after really surveying the space, looking at, you know, what potential improvements can be made at the protocol level, I really find myself drawn to the UX issues of Ethereum, which have, you know, in my opinion, really been overlooked, right? There's been work at the time on scaling, on ZK, and, you know, many ZK things. But, you know, UX improvements, I didn't find as much momentum. And so I found, you know, at the time, it wasn't very well known, this idea of account abstraction, how can we, how can we relieve Ethereum of this very hard-coded way that defines accounts? How can we make them more flexible, modular, interoperable, powerful? And so, you know, I obviously saw many of the previous ERCs, so EIPs that were already being proposed by my friend Ansgar and, you know, Matt. Like, 3074. Previously, there was a couple other ones back in the day, the early days of Ethereum. But none of them really had any momentum behind them, right? And, you know, this is very frustrating to me, because I was, you know, seeing how we can actually bring this to Ethereum's users in a relatively speedy manner, right? The issue with account abstraction, to actually put some specifics on it, is that kind of by definition, it introduces some DDoS risk. Right? Because now, with account abstraction, you allow the account to define whether a user operation, whether a transaction going through it is valid with custom EVM bytecode, as opposed to, you know, just a couple very specific predefined rules with EOAs. So now, because, you know, custom code can validate it, you have no idea, you have very little idea if you're going to get paid as a validator, if you execute this user operation. And so this was a big reason, that, you know, all these previous EIPs didn't really have as much momentum, there's a lot of little worry amongst Ethereum core developers, rightfully so, that, you know, this could introduce some potential DDoS vulnerabilities into Ethereum itself. And so, okay, so if it's not going to, you know, if we can't convince Ethereum core developers right now to include an EIP that, you know, makes a hard fork that introduces this natively, what if we could achieve the same functionality on the smart contract layer? Right, actually program what we wanted to change on the protocol level with smart contracts on chain. So that, that's kind of how the idea of this ERC was born, really. And I found myself talking to a lot of other really amazing Ethereum core researchers, like Yoav, Jor, some other people, as well as Vitalik. And, you know, we took this very sort of nascent idea of using smart contracts. They did a lot of the work when it comes to fleshing it out, making sure it's, you know, all the restrictions are in place so that it can't be exploited by the, via, you know, potential DDoS attacks. That's how the storage restrictions came about. And I worked a lot at that time on getting a first prototype version running live with the Netamind client, actually, back in the day. It's pretty funny. Yeah, the first prototype version of Abunda was actually built in, hard baked into the Netamind client.

Nicholas: And maybe we're wrong. We're going in the future, too, mind or not.

Kristof Gazso: Yes, yes, yes, yes, yes. That's a great point, actually, right? If it becomes native to the protocol, it's again going to go back into the client. So that's, that's exciting.

Nicholas: Okay, I do definitely want to get there. I have a bunch of questions. But first, I think there is this kind of human engineering story that maybe doesn't get told as much, which is sort of, how do you actually go about it? You started to get into it a little bit, but thinking, okay, you know, people are concerned about DDoSes if it were integrated. You're going to integrate it directly into the node spec. So we're going to write an ERC. How do you think about solving it? And how did this design, how did we get to the point where this is the design that's proposed and gained momentum?

Kristof Gazso: It's definitely a trial and error, right? So, I mean, it starts off, you know, the whole process started off very, very, very nascent, very, very high level, right? Basically Vitalik being like, hey, Vitalik and you have, and you are being like, hey, like, what if we could do some sort of pseudo transaction that gets validated on chain? And then, okay, we have this very like bland HackMD document, which is like, you know, a hundred lines long only, which just doesn't need a couple of explanations. And then it's like, you know, a nice telegram chat, which is like, okay, what if, okay, well, okay, well, okay, we do this, but then we have to like restrict the validation. So it can't do X, Y, Z. Okay. Then, you know, we go think about it a bit more, you know, I might, in this, for instance, I would, I would make the change and then, you know, I would, you know, I would, you know, I would, you know, I would go back and be like, oh, well, actually I, you know, as I was coding this, I realized like, we also can't allow this, this and this, right. Okay. Well, everyone's like, okay, well, that's a bit too restrictive. Is there a way we can avoid restricting that part? And then you, we have a call and it's like, okay, can we, you know, what if, what if we only restrict this specific rule? Right. And then, but not this other one, and then we can allow for more use cases. And it's just a lot of like this very, very kind of hacky back and forth until, you know, the very specific rules that we have now sort of slowly crystallize. as more people comment on it, more people take a look, more people find flaws. That's kind of a very beautiful way in which these standards in which these EIPs emerge. I think it's, it's very, very, very interesting process.

Nicholas: It is very interesting. Is there just one prototype at this point? You're the only person we're building anything that's like a working prototype.

Kristof Gazso: Well, initially I, I, um, I was the only one building a prototype, but then I convinced Tomas from Netherlands. He's very, very, uh, grateful for that too, to have a couple of people, uh, who I can take from other teams who can help me out with this.

Nicholas: But it's, it's this iterative process between a single working prototype and like a group chat and some occasionally some spec documents that are being, yeah, some, some hack MD documents, which people get, which get sent around.

Kristof Gazso: Yeah. Um, you know, me and one or two other people from Netherlands working on the client and obviously the telegram group chat and just develop back and forth. Uh, occasional calls.

Nicholas: from what you're saying, it doesn't sound like, first of all, you might expect, especially in an environment where there's been several proposals related to this subject that people might come into the conversation, very opinionated about how it should be solved. But from what you're saying, it sounds like it's more iterative and first principles.

Kristof Gazso: Oh yeah, definitely. And initially I thought it was, um, um, you know, everyone, you know, no one knows that this is going to be the ERC that's going to, you know, completely solve or not completely, but like really address, um, a really big part of a kind of structure. I see everyone's also working on different things. Uh, you'll have in drawer, obviously, you know, um, found, uh, very, very early in, um, and working on gas station network, right? Vitalik, well, I don't want to go into that. He's doing many things, right? I'm also, I also have, you know, some other things I'm doing in, in, in the mind, right. And as you know, more people see this proposal, more people take it seriously. There's more and more people, you know, actually focusing full time.

Nicholas: People are gravitating towards things that are personally, they believe personally are important. It almost reminds me a little bit of, uh, is it holacracy, the valve, uh, or whatever valves management style supposedly was to let people sort of go to the projects that they desire to work on. Even within core dev teams, EF, other people getting involved. It sounds like people are interested in a variety of things. They may not all work out, but they are driven by what's interesting to them.

Kristof Gazso: Yes. I mean, definitely in the theorem core research space. Um, yeah. And, you know, even, even, um, in a, in a company like another mind, you know, Tomash was extremely understanding. He's, you know, very encouraging, um, that if he, you know, someone in the company found something they're really passionate about, even if it's like, not like, you know, directly, um, even like a potentially, uh, uh, business unit, um, he'll encourage you to get, pursue it. Let's, let's make something happen. Let's try and push the space forward. So I was very lucky to have, um, you know, people like Tomash at my time at the mind, and also like be able to work with you. I've been sure who obviously also had their own projects that they're working on.

Nicholas: And I guess, uh, how do people stay upbeat about all the focus that they're putting into these things? If, if they're so Nate, so because they require such broad support from the community, even if they're not integrated into the core clients, even an ERC, like four, three, three, seven requires so much time and energy from people to get to the point where it is accepted. How do people feel? Like what's the tenor of an early conversation building something like four, three, three, seven. Is it kind of. More experimental. We don't know what will happen. or are there people who are really like, no, we're going to make sure this happens?

Kristof Gazso: Well, I, I didn't feel like, um, I didn't feel any pessimism. Uh, definitely not. Uh, even at the early stages, right. It was like, you know, this is an unsolved problem. Um, we don't know of anyone really like putting too much effort into trying to solve it. We, we think we're like the only ones at this stage. Um, and so, you know, this is something that needs, that's going to need to exist in the theorem in the theorem space. Um, so yeah, you know, obviously we're going to, uh, we're going to be just pushing this forward constantly and, you know, eventually, uh, unless we, unless we're missing something big, which is possible, um, we expect this to, to really take off in the end sooner or later. Um, and of course, like this, it's not like it wasn't instant, right. So I remember like, for instance, um, presenting at East Dubai, um, and that was, that was nice. I think it was 2022, right. Or I gave it, gave a talk about, uh, account abstraction. Um, and. And, you know, the, the, the response was pretty mixed. I talked with a bunch of projects afterwards, even some of the big ones who are now, um, doing a lot of account abstraction, but your things and really passionate about it. And I was getting very lukewarm responses like, oh yeah, well, we'll, we'll see sort of how it progresses. Um, and I guess it's interesting, but no, no real, you know, excitement, right. Whereas like you can look at the space now and while there's a definitely a big, big, um, community of, of account abstraction enthusiasts.

Nicholas: That's for sure. It's definitely, definitely picked up traction. And, uh, and it's interesting to hear also about the kind of iterative approach, like you have in drawer coming from gas station network specialization, and there's some overlap with how AA works. So it's interesting to see people working at the similar themes over multiple generations of projects.

Kristof Gazso: Yeah, yes, absolutely. And yeah, it's definitely an evolution of, of, uh, a lot of things they were doing before. So, um, I'm sure they've, they've had to think about a lot of the problems that they faced building gas station at work. And translating that into like a, an, a potential ERC that the whole community can use. Mm-hmm.

Nicholas: Uh, is there anything you can say about the actual design of four, three, three, seven, uh, to explain why this mechanism is the right one for, uh, we understand the context of integrating it into the node is not so easy. So making an ERC is a better path, but beyond that, what, what made this design the right one?

Kristof Gazso: So the reason this is the right one. Well, obviously it's going to be slight iterations and, you know, you must have. You must have seen the new, uh, entry point V 0.7, um, that was just talked about recently, but, um, yeah, the reason is there's previously been many, many, uh, relaying providers, these operationally relaying providers, relay providers. Now the issue is that there was no way that without white listing, these relaying providers could be protected from DDoS attacks, right? The reason was that, you know, imagine, um, I submit something to be, um, to be. Relayed, right. And, um, as a relayer, if you submit that transaction, right, you're going to have to pay for it upfront. Um, but then, you know, I can invalidate that transaction that you just re. you're just reading very, very easily. Um, by say, you know, changing some, some storage variable, right. Or changing any sort of simple, simple variable on chain, and then you're going to lose money. Now, this would not be an issue if I, if I was just spending one transaction to validate one of your. Transactions, but the issue with any relaying is that this is completely, completely scalable. If you do not have any restrictions on, on, um, and some guarantees that you get paid in some way. So, you know, uh, let me give you a technical example, right? Imagine I submit, I won't brief you. You're the relay. I want to greet you. I submit, um, 1,000 transactions for you to relay that each do one simple thing, right? Um, check that this store. Variable is a zero. If it is a zero, then, you know, pay you as the relayer and then execute whatever. Right. Um, so now great. I send you 1,000 of these transactions. Uh, you simulate them when you get them, right. Because you want to make sure you get paid and, you know, you check it and the storage variables, obviously zero at the time. And so you get paid, you would get paid, but now I can be like, okay, I see you now have these transactions, these 1,000 transactions. You think you're going to get paid, but now I make a very simple transaction, which changes that slot variable to one. So now when you submit these 1,000 transactions on chain, all of them are going to fail and you're going to lose money on every single one because the relayer has paid the gas to, to put the transactions into the blockchain.

Nicholas: by submitting them to the mental they're, they're exposing them to the danger that something in the touring complete, uh, logic execution reverts the function such that they don't get paid. By the, uh, Precisely.

Kristof Gazso: Exactly. So now, okay, imagine you're a relayer and you want to, you still want to allow for, um, decentralized submission of transactions now. Okay. You have to be like, well, okay, this is annoying. Um, what if I don't allow the access of external storage, right? So if I, if I, if I sent the transaction, like what I just sent, it would, um, it would try and check during validation this external contract storage slot, but you know, you can't. I, I, I'm going to ban that because I can be DDoSed, right? And now there's this restriction. So now I'm like, okay, fine. Um, I, as the Griefer can't, can't do that. Um, now let's say I, I do a transaction which checks the timestamp on chain and only allows the transaction to succeed if the timestamp is now is less than now, plus five seconds, right? So I send it to you. Um, it's valid when you get it. But by the time. You submit it and it gets included, it's going to fail. So now you have to go back and be like, okay, well, you know, doubt again, could DDoS me. So not to ban this, this opcode, the timestamp opcode during validation and you sort of slowly get to feel like, okay, you're going to ban these opcodes, ban these storage accesses, ban anything that really stops the validation from being, um, deterministic in some way. Right. And, and that is, it's a process is how, um, the four from seven set. The spec came about this, the spec is really just, you know, iterating these, these little, uh, game theory games until you find all the required restrictions that must be in place for a relay to be able to accept decentralized transactions to be late.

Nicholas: And is it just, but it's not just a matter of making certain kinds of transactions impossible from a smart contract account. What is the solution in four, three, three, seven to that problem?

Kristof Gazso: Oh, it's just banning a lot of things until you can be sure that. Well, yeah. Exactly. It's literally just like you keep banning things, keep buying opcodes, keep banning storage accesses until you're at a point where if you receive a user operation and you simulate it, there's no scalable way to invalidate these user operations when they get put on chain. Right. So, you know, we've had to ban, uh, 10 plus user operations. You know, you have to ban a block number timestamp, you have to ban, um, things like base fee, um, all the things that can change between the time when you submit it. When you submit these operation and between the time it gets included on chain, anything like that, you have to buy them. So it is, it is actually just like that.

Nicholas: I guess I didn't realize that's the method that you arrived at this spec. It's very interesting. Does it, I guess, I suppose it does change what you're able to do with, uh, you know, what, what, what, what, how does this limit the horizons?

Kristof Gazso: So there are some annoyances, right? There are some annoyances. Um, the biggest thing that gets in the way typically is. Um, there's a rule in four, four, three, seven, that you're not able to access storage external to the smart, your own smart account that is not associated with your account's address, right? I, it's not like a, a storage store that's, that's bounced, um, to a key, right? So it's not like a mapping, um, from your sender address to, to some other value. Um, anything like that, um, must be bad, right? So for instance, um, you can imagine. Okay. A good example is like, you know, USDC, USDC has a, has a storage variable that gets checked when you make a transfer. And this is called, um, uh, it's paused, right. And to see if the USDC contract itself is paused. So, so because of this, you can't really check, you can't really make a transfer natively, um, via USDC. And if you do, you know, it's going to not be valid.

Nicholas: You couldn't, you couldn't simulate it. Yeah.

Kristof Gazso: Yeah.

Nicholas: So you can't be sure of that. That's storage variables value. Yeah.

Kristof Gazso: Because imagine you submit it and then, you know, USDC becomes paused, but you have 1000 transactions in, in there, which try and make a transfer at the same time. Right. And that one switch of that one storage variable is able to invalidate all those 1000, um, uh, user operations, work case scenario, also making them fail on chain.

Nicholas: You're out of a lot of gas if you're the, uh, relayer bundler. Yes.

Kristof Gazso: Although in all likelihood, you know, uh, the vast majority. You're going to be simulate before submitting. actually, so you're going to do two simulations and hopefully you catch it in the second simulation, but many of them might actually be submitted and you might actually discover it's, it's, um, it's set to zero. I mean, it's blo it becomes blocked, um, after submission. So, you know, good case scenario, you just like literally blow up the mempool of the bundler. Worst case scenario, uh, you actually lose a lot of gas as the bumper.

Nicholas: So how do you get around this for transferring USDC?

Kristof Gazso: For example, well, you have to whitelist, you have to, you have to do, um, define a special, um, rule in the bundler, which is like, Hey, well, you know, for practical purposes, you know, this is something that we should just whitelist, right. And there is, um, you know, if, if you're using a mempool, then you would also subscribe to a, a special mempool, um, an alternative mempool, um, where all the participants of this mempool, um, agree that, okay, well, you know, let's have the storage. Slot. Um, that we're actually going to whitelist. So it's like, as talk, you have to just like come to social consensus. Like, yeah, we're going to, we're going to allow this.

Nicholas: And that would be specific to like, for example, the USDC contract, a bundler would have logic that specifically permits the USDC contract to transact.

Kristof Gazso: Yeah. For instance, right. And you, you can come up with any number of examples that you might, uh, want to whitelist, but yeah, the idea is just you put custom code into your bundler, um, that lets that through.

Nicholas: So is there a censorship, uh, concern here about, uh, I, I suppose you're kind of dependent as a, someone sending a user operation to a bundler, you're dependent on the bundlers having permissive enough logic for whatever it is you're trying to, to convey to the chain. Correct.

Kristof Gazso: Um, and so, you know, a bundler is, is that an off-chain entity, it's a piece of code running on some, you know, probably US East one, you know, as, as most, most things in crypto are. so, so yes, you are at risk of, of, uh, censorship. However, you know, the, the great thing about, um, ERC 4.7 versus previous, um, relaying systems is that user operations are completely permissionless to include, right? So if you find that a bundler is refusing for a reason to try and include your user operation, you can, if you have an EOA with some amount of, of ETH, um, you can literally just submit these operations through the entry point yourself. There's, there's no whitelist of bundler addresses that can include user operations, right? It's. Um, anyone can submit them, um, that kind of also backfires, um, when, when, when you start thinking about MEV searches, trying to sandwich, uh, bundlers, user operation bundles, but, uh, but that's a different story.

Nicholas: That is an interesting story also, though. I don't know if you want to take a sidestep into that. Yeah, please.

Kristof Gazso: Happy to, happy to. So, yeah, we've, um, um, because anyone can include user operations and because the bundler makes a small amount of profits on every single user operation. By including it, um, any generalized MEV search is going to sniff that out and be like, well, I see you got a little profit on chain, right? In a way that, you know, I can, if I included that use operation, I could get that too. Right.

Nicholas: Forget bundling. Let me just front run.

Kristof Gazso: Exactly. Exactly. Right. And so, um, there is a big risk that, um, unless bundlers have some sort of privacy, um, private RPCs that they use or some, some deals with block builders or something. And that they can be, uh, front run.

Nicholas: So essentially bundlers need to MEV there. They need to flash bought their own bundles because if not, they'll be front run by someone with better latency or something. Exactly.

Kristof Gazso: Exactly. By any stretch, if you tried to bid higher or yeah, it is, it's a very sort of risky thing on some chains.

Nicholas: That's a specific thing.

Kristof Gazso: But with Pimlico, we're actually live on 30 plus chains. So we've, we've had to deal with this quite a bit. But the three chains that we're really seeing some front running on, um, if they remain, it, um, Binance, Smart Chain, Mainnet, and Avalanche. And so for each of these, um, we, we have to use, um, a private RPC to submit these bundles with, so that's, um, that's a shame.

Nicholas: Does that increase the costs for you on those chains or not necessarily? No.

Kristof Gazso: And the only thing it does is that, you know, these private RPCs, they're not actually integrated to every single validator, um, on chain. So, um, say, you know, in, in Binance, for instance, the one that we use, I believe it's. It's, uh, it's used by 60 or 70% of validators are hooked into that. And so what this means is that, um, the average time to include a user operation bundle increases a bit.

Nicholas: 30% or like proportional directly to the, the number of validators is not on, I suppose.

Kristof Gazso: Yeah. On average, it's going to take, um, one divided by 0.7, which if I do my quick maths, that's about 40% longer.

Nicholas: Interesting. And it's not, so then you have, there's so many. There's so many software interdependencies for propagating these things correctly, uh, or that's correct.

Kristof Gazso: Yeah.

Nicholas: So I suppose one solution would be to be sending these bundles to whatever other private mempools are out there for BSC, for example.

Kristof Gazso: But maybe there's limitations or no, you can send it to as many as you want. As long as these, you know, public, um, public, uh, front-end boss don't, don't get you. Um, we've seen that, you know, this one obviously does pretty well. It happens that. Most, um, most private OPCs are hooked into the, pretty much the same values over and over again. So adding more doesn't help as much, but yeah, you know, all other things being equal, the more you have, the better.

Nicholas: I have more general questions, but while we're on the topic of MEV, how, how else are, are there any other dimensions or ways in which four through seven or Pimlico services relate to MEV?

Kristof Gazso: Um, so we could, you know, as, as a, as someone in the, um, who has access to this overflow. Right. If someone submitted a user operation, uh, which for instance, is very MEV-able, uh, we could theoretically, um, sandwich the user front-run them or back-run them.

Nicholas: Right. Or sell the data to do it.

Kristof Gazso: Precisely. Yeah, exactly. Uh, sell it to like some, some searchers to bid on and, uh, and take some profit for ourselves. Um, obviously like, um, so we, you know, as, you know, FTC speaking, we'd never do this. Right. Um, but there is this theoretical capability of these bundles to do so.

Nicholas: Others, others might do that. And in fact, other apps might even choose to do that because they get a cut.

Kristof Gazso: Precisely. Yeah. So, you know, the, the, the, the flow of these user operations is pretty long, right? I mean, the user, the, the, the DAP creates this user operation, um, submits it, you know, asks the wall to submit it. The wall submits it to us. We get it. We, we check in with the RPC provider to do a bunch of simulations and we send it to them or we send it to a, a private RPC provider. And then, you know, they do that thing and they, um, You know, they try and send it to all the validators. And at any point, or the block builders, at any point, anyone could be like, oh, well, that's a nice user operation you have there. I wonder what happened. Would you shame someone's friend by that? So yeah, it's a lot of, it's a big, quite complex flow that these things go through.

Nicholas: I guess you are just positioning yourself and Pimlico as reputable ethical services and that being a reason to use it.

Kristof Gazso: Yeah, I mean, like, yeah, it's just, you know, trust takes so long to build, but it's so easy to destroy, right? And like, you know, trying to front run users, it's not a very long-term strategy. And, you know, if someone found out, if people found out and if you did that, you know, people could easily switch to other bundle providers who do not do that, right? So there's a lot of trust involved.

Nicholas: I'm tempted to think about the opposite, where they turn it into like a rewards, referral system for the apps. And it's a reason to onboard to a certain bundler because they're splitting the proceeds with you in one way or another.

Kristof Gazso: That's a great point, right? Imagine, you know, there could be a bundler hypothetically, which is like, yeah, we will like MEV the crap out of these operations, maybe only back run, right? Imagine if it's only back running, right? So the user doesn't actually suffer directly. Yeah. And, you know, we'll split some of the proceeds with you.

Nicholas: You could imagine the BSC in the same, these ecosystems of private mempool providers. seems like it could maybe fit. That's actually another theme. I want to touch on. It seems like there's many different players. You know, there's bundlers, paymasters, sequencers, block builders, private, I guess, private mempools. They overlap in some cases. Do these things end up all converging? Or what is the like the logical amount of software you have to run to actually get a transaction on chain with AA?

Kristof Gazso: So are you talking about the end state of how things are progressing? Yeah, I guess.

Nicholas: Yeah. Yeah. How things are progressing or which pieces of software will end up being shipped together and run together?

Kristof Gazso: Yeah. I mean, I can definitely imagine bundlers becoming more and more integrated into block builders. I mean, block builders are, several block builders would actually do searching on their own. And you can imagine, you can think about bundling as a specialized form of searching, right? You have these operations, which if you include yourself, you make a small cut on top of them, right? So you can think about these as like, you know, actual, just like literally any viewable pieces of pseudo transaction, right? Yeah. I definitely expect at least on mainnet, if there's enough volume to, for these block builders to start running their own bundlers. Now on layer two is where it gets interesting.

Nicholas: That's it's quite different, right? Yes.

Kristof Gazso: Right. So this, you know, sequencers, and you know, who knows when or how, or, or even if maybe all of these L2s are going to actually decentralize the sequencer.

Nicholas: Because they kind of argue they don't have to, right?

Kristof Gazso: Yeah. Yeah. I mean, as long, I mean, there's many ways to do it, right? There's, you know, you can do like anyone can sequence, or you can do like, okay, well, we will do like an auction that you, you know, only one party can sequence for a certain amount of time. And then they do another auction. There's a lot of ideas floating around. But, but it is, it's likely to, to be integrated into sequences as well. Now, now the one place actually, the one reason, the one big reason I can imagine bundlers not disappearing is when it comes to compression, app specific compression. So that's actually something we've been thinking about. We were working on and telling the ad chemical, and we're going to be launching soon is the biggest problem. One of the biggest problems in the smart account space. So these operations are expensive. They are a lot more expensive than normal transactions, right?

Nicholas: How much approximately what a factor of what, like about two, 2.5.

Kristof Gazso: So I see this is pretty prohibitive on places like on Ethereum mainnet, for instance, also pretty prohibitive on their twos rollups because, you know, the vast majority of the gas cost on rollups comes from call it. We call it the cost. And, you know, you have to post as the bundler. And then the whole use operations call data on chain to execute it. So there's a really big overhead when it comes to that. But, you know, we realized that, um, working with Dymo actually a really amazing wall that's, um, that's building on smart accounts and using Pimlico. And we're, we're very close with, you know, they, they, they started thinking and we started, you know, working with them on how can we compress the amount of call data that a user operation has to occupy when it gets posted on chain. Hmm. Right. So if you look at a user operation, you'll see that there's a lot of values which don't need as much accuracy. There's also zero low padding that doesn't actually occupy any useful bytes. So what if you asked this use operation through a compression algorithm, like, you know, normal GZIP, um, submitted that on chain and on chain, you use an algorithm to inflate it, to, um, to sort of decrypt, not decrypt, but like deflate, um, bring it back to normal use operation. Right. And then submit it on chain. That's clever. So you submit this very, this is something that's very compressed use operation as the bundler and on chain, it gets decoded and sent to the entry point internally. And so with this, you know, we've been seeing, um, potentials of 20 to 25% cost savings. And this is with just generalized compression, right? We have to know nothing about what the underlying use operation does. Um, but actually there's something even cooler, which is stateful compression, right? So imagine, um, Dymo, the wallet. They know a lot about what their users are doing and what kind of use operations they're submitting. They know, for instance, that, um, basically the only thing possible on Dymo since the P2P payments app is just transferring USDC. So what if instead of every time, you know, encoding the USDC transfer signature as well as the USDC address, as well as the, you know, complete amounts and, you know, all these like repetitive things. Imagine if you just marked one by one. As like, what type of transaction is this? and by say by zero one signifies, this is a transfer of USDC. And so you skip the USDC, I actually skip the signature and you just have to specify the, the amount you're transferring and to whom.

Nicholas: So in that, if, for example, if we were to follow that example through the signer, like, let's say the Dymo wallet has this passkey signer, I think will be signing a, still a user operation or, or something else, a struct of their own design, this compressed design. I suppose.

Kristof Gazso: So they would still be signing the user operation, but then this user operation would be compressed at the bundler, right? And yes, compressed by the bundler. And this will be decompressed to the exact same user operation that was signed, right? So it's not like a lossy compression. Usually it's, it's completely lossless.

Nicholas: So someone like Dymo could make a definition of what the minimum actual data required to know what the user is asking for. They would maybe specify that too. Their bundler of choice, maybe Pimlico, and then Pimlico's bundler would execute this compression and decompression.

Kristof Gazso: It,

Nicholas: if they wanted to change what they were doing, would it require just changing what data they were having the user sign or rather changing the definition at Pimlico at the bundler, or would they have to change something on chain or change how they're signing transactions on the wallet?

Kristof Gazso: That's a great question. Actually, it's a little more, uh, it's a little more permissionless than that and not, not completely, but it's a little more permissionless. What they would actually do is. Create an on chain inflator contract, this inflated contract, uh, would implement, um, the inflate function, which takes in a sequence of bytes and outputs a user operation strut.

Nicholas: Right.

Kristof Gazso: And so they define this on chain and what they would do is, um, they would deflate, they would compress this operation when they submitted to Pimlico and we only get the compressed these operation. We don't get the whole thing. Um, we would, uh, we would inflate it using the address. Yeah, exactly. We'd inflate it during simulation with the address, uh, with the inflator address. They specified, make sure, make sure everything works. Everything looks good. Everything's valid. And then, um, we would submit again, the compressed these operations, the submit to us, um, through a room, some on chain smart contracts, which, you know, does the inflation and submission logic on chain, the one that we, we, we did, we, we simulated. Um, so yeah, there was an on-chain contract, which inflates, which decompresses, but they submit only the compressed user operation to us.

Nicholas: Very slick. Uh, the EVM is not so simple anymore, huh?

Kristof Gazso: Yeah. I mean, the EVM was never really simple and, uh, uh, there's obviously many, many, all their ones are many, many really cool, actually innovation people would try to do to me away from the EVM. Um, but it just so happens that, you know, everyone is using the EVM. There's so much. Developer tooling, even though it's a bit, a bit, um, questionable in places. So, so yeah, we, we, we keep hacking and hacking and hacking and hacking on top of the EVM, uh, to make these things work.

Nicholas: It is very cool. I wonder if it's how like early days of Linux or something felt, it has a little bit of this collaborative, decentralized open source energy. And it's funny how, like what you're describing here with this compression at the bundler, it's not really something that's envisaged in the designs of the composable parts that you're touching. With the bundler, but it is possible. And so you can do it. Absolutely.

Kristof Gazso: If you think about it, ERC 437 is kind of a hack to the EVM to allow her functionality. That's not natively possible, right? So, you know, ERC 437 is kind of hacking the EVM and then this compression is like hacking on top of 437 and then you can, you know, go quite far back and like, see this, see this chain of hacks on top of each other, which you end up, you know, solving most of the problems, um, that could originally happen. Fixed if the EM was designed in a different way. Okay.

Nicholas: I have a technical ish kind of question about the bundler. So bundlers will verify in simulation before, uh, propagating the, the bundle to the chain, they will check that they will be paid. And I guess the sort of naive way to check is to check that the transaction itself compensates the bundler and, and maybe then some for the gas spent putting that transaction on chain with a traditional EOA. But then there's also this way that they. Bundler can communicate with the paymaster to check that the paymaster will be the one compensating it. Maybe, could you just explain sort of the flow of execution in a high level way? So we understand how we get from one step to the next.

Kristof Gazso: Right. So I think it's important to note that luckily for us, really the vast majority of this payment logic is handled by the entry point itself. Um, so what the bundler does to simulate things to simulate payments at least is we literally just call the handler. And the ops function of this entry point. And, you know, if something gets messed up along the way, if someone doesn't do their job, if someone in the paymaster of ads or the account reverts or something happens, the entry point will revert. And so we will very, very easily know if something went wrong.

Nicholas: So a lot of the hard work is done for the simulation part, right?

Kristof Gazso: Precisely, precisely.

Nicholas: That's great.

Kristof Gazso: Yeah, exactly. So that really, really helps us as the bundler, uh, and means like, even when you submit things on chain. Um, we can't just, you know, randomly get scammed, um, by, by some storage variable changing because, you know, the actual validation is done by the on-chain, uh, entry points at the same time that this payment will be taken.

Nicholas: And that will include checking, uh, on the paymaster being able to compensate.

Kristof Gazso: Yeah, that will also include that. So the flow of the entry point is, is the following. The bundler submits the user operations to the entry point and, you know, one by one in that bundle. Um, the entry point. Is going to check that, um, the account accepts and thinks this is a valid user operation or not, right? So, um, if there's no paymaster, this is going to involve paying the entry point and validating the signature and any, any, any other checks that the account wants to do. Uh, this is the validate user function and it goes back to the entry point. If there's a paymaster, then the paymasters asks, asked on chain, if it wants to sponsor the entry point. This user operations gas fees. So this famous will do the on-chain checks that it's implemented, go back. And so now you'll go through this loop again and again for every single user operation in the bundle. And then you move on to the execution step. But for every user operation, um, you execute the custom call data that has been set in these operations through the smart accounts. And at this point, the entry points, like, you know, we stopped caring. We're like, okay, we've, we've gotten paid, you know, that part's done. Now, anything else is, is your problem. The smart accounts problem, if any reverts happened from this point, that's, that's a skill issue, um, for, for, for the smart account. Um, but we were already going to pay. Right. And finally, and there's just, um, in, in the current spec, there's a post-op check to the payment that is done with the paymaster that allows them to do any sort of small accounting, um, at the end of these operations. But that's pretty much it. The two main parts of the validation step. And then, you know, At that point we get paid and the rest is like just pure execution.

Nicholas: You mentioned, uh, recently the entry point 0.7.0 version was, uh, announced. What kinds of tweaks are happening at this stage of the EIPs development? Yeah.

Kristof Gazso: So it's interesting, uh, cause if you think about it, the EIPs got quite a bit of adoption, right? There's over 8 million user operations. If you look at Dymo, if you look at, uh, bundlebap.com, um, and you know, there's a lot of wallets building on top already. A lot of production wallets.

Nicholas: Got the numbers here. What is it? Overview cross-chain total account. It's 2 million accounts. This is bundlebap.com. As you said, total user ops, 8 million gas covered. Uh, is that a million?

Kristof Gazso: Gas covered. That's over, uh, yeah, 1.1 million gas covered.

Nicholas: That's gas covered by paymasters and total bundle transactions. So these are the, the transactions that bundlers are actually submitting to the entry point 5,800,000. It, they're pretty big numbers. They do seem pretty big. I guess I looking at the graphs quickly, it's like polygon is very predominant, but other L2s also some L1.

Kristof Gazso: Yeah. Yeah. It's, and you can go through all the different tabs on this. Paymasters. Paymasters, different account factories, see who the biggest players are. It's very interesting.

Nicholas: It's, it's, it's quite surprised. I mean, I guess there is a intuition. Maybe there's some airdrop farming going on, or maybe there's something we don't know about going on on polygon. Do you, do you have a sense of what is actually popular so far? Oh yeah.

Kristof Gazso: We, I mean, we look at this every, every week internally, see what's, uh, see what's happening. So yeah, a lot of this early volume was driven by a couple of airdrops, a couple of minutes, a big minutes. We've recently been seeing more and more sustainable volume coming up. Um, so yeah, initially it was. There's a lot of airdrops, um, now it's actually, if you go out, you can actually go to the apps tab and there's, um, you know, like grinding is driving some volume, fan TV, cyber connect, uh, obviously many, many, really amazing, uh, walls and walled as a service solutions. Um, so worth mentioning a patch vault, which is a, a really amazing way to embed walls into your website, into your applications, obviously Dymo who are working really close with, I like for B2B payments and then, you know, many, many, many other. Uh, use cases, many in production, many for hackathons, um, those developers messing around, trying to embed it into their apps. Yeah. It's a, it's a great time for building in the space.

Nicholas: Yeah. I'm always surprised a little bit by the top applications or even in a prior meta, you know, the top NFT collections or tokens, but they're not always the thing. They're really, they often are quite different from what you might see on social media and crypto Twitter, for example, uh, completely different projects. They're actually popular. Yeah.

Kristof Gazso: Yeah. It's very interesting. Um, oh, obviously. It really teaches, you know, building and working with so many projects, um, reopens you up to a lot of things I would never have come across, right? So for instance, you know, cyber connect, um, I was never previously really involved or paying attention to, um, the, the social, um, networks on chain, right. But like, you know, by working with them, trying out their product, it's like, you know, really, really gets you, um, to explore a lot of the things that are on chain, which you've never just thought about. Even previously, same with like telegram bots, you know, Grindr, um, same with many of the embedded wall solutions are allowing you to, um, you know, send, send tokens to someone's, um, Twitter account or GitHub account with patchwork and things.

Nicholas: Yeah, I think the actual applications often differ from what we expect, especially like this spate of, uh, embedded wallet solutions that are some, many of them leveraging smart accounts, they may not end up looking like MetaMask. They may look quite different. Or maybe they're embedded straight in the game, uh, but it's not, not the experience you expect as kind of a prosumer, but it actually has traction with people.

Kristof Gazso: Absolutely. Absolutely agree.

Nicholas: So I cut you off earlier. You were talking a little bit about the, uh, 0.7.0 release and what's sort of what's new at this stage.

Kristof Gazso: Oh, right. So, I mean, the biggest, um, biggest impact users are going to see is that the user operations struct is now different. So, um, that is, uh, something I'm very much. Big news. Yeah. Big news. A lot of work, a lot of work that we're gonna have to do. So much tooling has been built around the current user operations struct, uh, from, you know, the bundler, the paymaster.

Nicholas: I saw some people upset about this on Twitter today. They were saying maybe, maybe we shouldn't do that. What do you think?

Kristof Gazso: Uh, yeah, I am. I'm very sort of very bittersweet. This whole thing is, um, cause like, cause you know, there's, there's a reason this change is being made. Okay. Actually, let me go to the specifics just so, just so we can get off on a nice pace. We'll have to explain like why, why this is kind of important. So, um, what's changing is that previously these operation included three types of, of gas values, right? There was a pre verification gas, the verification gas limits and the call gas limits. So the pre verification gas is just the amount of gas paid. Paid to the bundler just for executing the user operation at all. So this compensates them for, for instance, the call data costs of submitting these operation. So fixed value, it's not a limit. This is a fixed value. And there's two other limits, but the verification gas limits is how much, um, the user operation and, you know, the biostation, the user is allowed to spend for the verification step of these operation. Finally, the call gas limit is how much you're, uh, you're out to spend for execution. So, you know, this sounds, this sounds pretty great, right? I mean, it covers all the steps I mentioned, but wait, no, it doesn't. Um, because it actually, it's actually a little more nuanced. So let's see what calls are being made by the entry points. Well, initially, you know, we, we call the accounts to verify that they allow these operation to succeed. And if there's no payment to pay, um, the entry point. Okay. That's fine. Right. This is the verification gas limits. Okay. Next we ping the paymaster and we all have the paymaster. Hey, is this about these operations? Do you want to spawn for this? If there is one. So now, okay. Well, where does, what do we use for this? A good question. Um, the V 0.6 entry point uses the verification gas limit. Again, the same value for both the account and the paymaster limits. Um, and this new one, this new one, this, this, uh, paymaster verification gas limits is actually embedded. Into the paymaster and data field now. So it's going to live, um, somewhere else in these operations. And it's going to be separated out.

Nicholas: So this change is essentially protecting someone.

Kristof Gazso: Well, it does a couple of things, right? So what it means is that now you actually have more fine grain control over how much gas limit you want. Um, for the account verification step, as well as for the payment certification step means that the bundle needs to waste less gas on, um, that they need to include in the, in the transaction.

Nicholas: So it's going to be more precise. So it's going to be more efficient with their gas estimation.

Kristof Gazso: Uh, yeah, exactly. Right. So, so instead of having this a really high gas limit, just because the, say the paymaster verification, you know, took so much gas instead, you know, they can be very precise in how much gas, uh, how big the gas limit they set is. Um, and again, it just also allows you to be more precise, as you mentioned with like, as a user creating a user operation. Like how much do you want to allow for each of these steps? Yeah. It's, it's really arbitrary kind of that, you know, the verification gas limit is responsible for both, um, the account and the payment of the step. It's, it's really doesn't, doesn't really make much sense.

Nicholas: So basically fine tuning things that have been revealed to have been minor errors in the design or inefficiencies that can be, can be tweaked, but, but overall not, I mean, they are major changes if you're someone implementing them. Uh, but maybe for, for the high level understanding of the contracts, not, not much is changing at this point. No.

Kristof Gazso: So the users wouldn't be saying their own gas limits, no likelihood, right? So they, the end user would definitely not care. Um, the vault might care because they want to be, you know, more precise in, in how much they allow things. They want to be more efficient. Um, the bundler, um, and you know, all the tooling is, is not gonna, not gonna enjoy this very much. Uh, at least the migration step, but it is again, going to allow them to, to be more precise as well. So this is, this is one change. Um, the other change in the struct is that now. Um, the call gas limits and the accounts verification, gas limits are kind of included into one field. They're really, you know, put basically lodged together in the same field. And this means less, uh, using less parameters and using less gas.

Nicholas: Mm-hmm. Just more efficient. Post storage operation.

Kristof Gazso: Yeah. Mm-hmm. Correct.

Nicholas: Filling up some of those empty zeros.

Kristof Gazso: Yes, exactly. Precisely. And finally there's a, you know, the, the post op. Um, call I mentioned. Which happens at the end of these operation execution. That again is gonna be separated out and included in the pay monster and data field. It can be another gas limits that's going to be specified, um, by itself.

Nicholas: So it turns out gas limit, uh, specification is maybe one of the details. This wasn't as obvious earlier in the design process.

Kristof Gazso: Yeah, exactly. Um, so, so it, it, it was really, um, it was like, okay, well, you know, there's two steps for occasion execution. Let's just do one, you know, gas limit for each. But now it's like, okay, well, there's a little different types of verification and no different, um, things that you wanna be able to tweak. So now it's gonna be separate. Hmm.

Nicholas: Interesting to be making changes like this after, uh, already 8 million user ops across the, the chains, at least on bundle bear. From an app dev perspective, how does a person make use of Pimlico?

Kristof Gazso: There's quite a few ways and it depends what type of application you are. Okay. If you're, uh, like a normal, you know, that, that, you know, provide some, you know, on chain game or, or, um, you know, some pretty amazing on chain service. The most relevant and the most direct thing you'd be interacting with is, um, uh, libraries. And so we've been building and we've really been pushing, uh, permissions.js.

Nicholas: Yes. I was gonna ask you, tell me about permissionless.js.

Kristof Gazso: So, um, permissions.js is a library that allows you to work with. ERC for Ruby seven, um, use operations, um, smart accounts, bundlers, and pay masks in a very easy way.

Nicholas: Cause it's not so obvious with the, with the default tools as they stand. Right.

Kristof Gazso: That's, that's true. Right. So like these operations are very complex. Structs to try and create and, and make sure, you know, you're doing the right thing and making the right calls. And so, you know, what, what permissionless.js is trying to allow is, um, the very simple change, very simple swap out. Actually you can do and start using immediately smart accounts instead. And so, um, this is one part of what we've been trying to tackle with this. The other part is trying to make it very, very flexible, right? So, so with permissionless.js, we want to allow you to be able to use these higher level account systems and plug and play any of the different parts of the stack that exist in the smart account space. Right. So you should be able to plug and play and add and remove different bundler and pay off the providers. You should be able to remove, you should be able to remove Pimlico as well. Like we should not be locked in. We should not be, um, you know, the sole provider for this SDK. We want to make this an open thing. You should be able to choose your smart accounts, um, system like safe kernel, economy, simple account. The actual thing that lives on chain that executes these operations. And finally, you should be able to pick your signing infrastructure. Right. Any really amazing signing, um, providers like tanky privy dynamic, but three off magic link and many others capsule. And, you know, they've made MPC, um, really friendly, really usable. And you should be able to embed that when you create your smart accounts very easily. So yeah, we, we, we feel like developer experience has an is been the, one of the biggest blockers for smart account adoption. Developers having to, you know, go out of their way. Trying to assemble these very complex pieces of infrastructure changed all the ways they've been building their apps. Um, and with permission is JS, you know, if we succeed, it's going to be because we allow you to very easily start using smart accounts with barely any change to the way you've built your applications. So we think this is going to be a really big enabler of, of, uh, of adoption.

Nicholas: Because you have to, as a DAP that's trying to integrate these things, uh, you have to build the user operation. You also have to. Uh, have some, I mean, especially talking of Dymo and others, uh, many of these new era embedded wallets, uh, with, uh, like passkey signers and, uh, smart account on the blockchain. Um, they have to also be representing not the signer, not, you know, there's a key somewhere on the device and it's not that keys address that you want to be the user in your application. It's actually the smart account. That's the user. So maybe the traditional like VM or something. Or ethers are not necessarily set up to do that out of the box or, or any of the boiler plates that you might download. Precisely.

Kristof Gazso: And actually touches a really sort of deep and maybe even philosophical point. Well, actually not philosophical, but a really deep point about account abstraction, which is that, you know, with account abstraction, the signer is no longer the account.

Nicholas: That's it.

Kristof Gazso: Previously an EOA, an EOA account was both the signer and it was both the account that the user had. Access to, right. And so these, you know, we're breaking this assumption. We're like, okay, you have a signer that has a public key, right? But like, that's not where you would store your address, your, your money, your assets. It would just be a way to authenticate to a real on chain account that you have. Cause it's kind of like, if you, I think looking back, if you look, we look back in, you know, two, three, four years, we're going to think back of, of having the signer and the accounts being the same thing is very, very weird.

Nicholas: We're going to tell our grandkids about, uh. About wallets.

Kristof Gazso: Exactly. And it's like, you know, if your SSH key, uh, was storing assets in some way, like that would be really weird. Right. Yeah. In the same way, I don't think we'll be seeing signers signing accounts, um, have assets. There's just going to be signers to smart accounts.

Nicholas: It's a challenge in the terminology for people to adapt. I mean, even AA itself, people have this acronym smart contract wallet lodged in their heads, but it's not a smart contract wallet. It's a smart contract account. Or in a way, I mean, it is a smart contract account. I, I am looking forward to the day when we just call them accounts because it feels like a return to the authentic paradigm or primitive of the account in the first place, rather than how we've come to understand externally owned accounts.

Kristof Gazso: Yeah. I mean, I, I quite like smart contract accounts or smart accounts. Yeah.

Nicholas: Smart accounts the best so far, I think.

Kristof Gazso: And eventually, yeah, I definitely look forward to the day when it's, you know, everyone's just calling them accounts. And if you're that weird kid who uses EOAs, then, you know, we'll be like. Oh, he's using an EOA.

Nicholas: Yeah. What are you, a bundler? Yeah.

Kristof Gazso: Exactly. Exactly. And then, you know, we'll have to say, oh, he's using an externally owned account, not an account, right? It's different. It's different. Externally owned.

Nicholas: It's different. Yeah. It's different, but okay. It kind of makes me wonder. when we were talking about the process of coming up with ERC 4337, you didn't mention that any part of the early process, and maybe there was, but it just didn't come up, but you didn't mention like looking at what other blockchains have done. And one of the themes that comes up every time an alternate VM rears its head in terms of market price is that maybe there have been lessons learned since the definition of the EVM that could be heated or, and I'm not extremely familiar with them, but things like Solana, like Near, other blockchains, the ZK chains that have their own paradigms that maybe have a different notion of an account or a different notion of, I mean, some of them, like, you know, like Flow, for example, has, I think, a different notion of tokens enshrined into the chain such that the tokens don't depend on a contract. Once they're issued, they sort of move around on their own and the original contract being hacked or having some kind of bug doesn't affect the assets, which is an interesting alternate property. Do you have any thoughts on, is it just that the EVM is like, it's here to stay and so get used to it? Or yeah, how do you relate to like alternative approaches to building blockchain VMs?

Kristof Gazso: Yeah, I mean, there's 100% a lot of lessons that can be learned from the EVM's mistakes, right? And I would imagine if, you know, Vitalik and Gavin and all these, you know, early pioneers were designing the EVM, again, with the knowledge they have now, they make a lot of different decisions about how it works, right? It's just, you know, at some point, once you have enough network effects, once so many developers are building, on a specific virtual machine architecture, it's so difficult to try and get anything else off the ground. I feel like there's been some virtual machine systems, which have really, I think really have the potential, like, I quite like StockNet, right, what they're doing. They've really taken a different approach. And I quite like how, you know, ZK Sync, for instance, has experimented with, native account abstraction from a very, very early point. So, so yeah, I can see, it's actually, it's interesting to know, actually, it's like two very different approaches to account abstraction, because ZK Sync just does a small change, right? It's mostly, mostly EVM equivalent, not completely. But then, you know, there's these couple of small tweaks, which improve user experience. Whereas StockNet, they were like, okay, let's, let's, you know, like, let's start over. Let's start completely over. Um, let's not, let's not tweak the EVM. Let's, let's rebuild something completely new. And obviously you have account abstraction natively in the VM, but it's not just like a slight iteration.

Nicholas: And they don't encounter the problems that you, of the, uh, gas payment problems or DDoSing challenges?

Kristof Gazso: I, I, I'm actually, it's been a while since I took a look at how they did it, but I do know that every single, um, account is a smart account. Uh, and they, they, I believe they have taken inspiration from the early version of, of ERC-407. Uh, but yeah, I don't know. I, I would need to double check before I, before I go too deep into the architecture.

Nicholas: So we were talking about permissionless JS. So basically permissionless JS makes it easier to interact with, uh, any part of this composable ecosystem of four through three, seven from the front end. Um, I suppose the primary application would be for app devs, dApp devs, uh, doing front ends or, or is there something else I'm not thinking of?

Kristof Gazso: Yeah. I mean, that, that's, that's definitely, um, probably the biggest one, right? It's like, um, Hey, you have your Wagme app, just make these couple small changes. And you can immediately start using smart accounts and getting your, your end-user smart accounts. Right. Um, we've seen a lot of vaults that building their stack through permissionless JS as well, which has been really exciting. So, so that's, that's one that can be used as a backend, backend framework as well to actually assemble these operations, you know, do, um, do simulations, um, interact with bundles and paymasters directly. Right. Um, so, so yeah, there's, these are the two main biggest ones you can use as a front end tool or a backend. So, but very importantly, permissionless JS is not trying to give you a UI. This is not going to be like a wall model, like many other. really, you know, awesome projects have built like third web, like, uh, like dynamic privy, like these guys where you have an actual UI that you can click, you know, connect walls, um, sign up with Google, all that stuff. This is, this is not that we're not building a UI. We're just building a very, very easy way to, um, to interact and work with smart accounts on the backend.

Nicholas: So let's say I pick up permissionless JS and I'm starting to integrate it into some little demo experiment or, uh, an app, maybe even, uh, what else, uh, can I use from Pimlico or might be interesting to use? I know there's the Alto bundler. I guess that's one of the main things. Right.

Kristof Gazso: So permissionless JS, um, as I mentioned, it, it can, it allows you to combine four pieces of a stack, right? The bundler, the paymaster, the smart account system itself, and the signup, the signing infrastructure. So natively, uh, uh, the, the, the, the, the, you know, Pimlico, uh, we, we have, and we run bundlers and paymasters that you can use. And so if you so choose, you can use, uh, Pimlico bundlers and paymasters with permissionless JS. Of course, you know, we're not locking you in. It's completely up to you. Um, but yeah, you, you could use, uh, Pimlico bundlers.

Nicholas: What might be the, what would be the advantages of, of the Pimlico flavors of these? Cause they're, they're, they're popular. They're very popular.

Kristof Gazso: The Pimlico flavors of, uh, of bundler when it comes to permissionless JS or just in general?

Nicholas: Yeah, uh, bundler and, and paymaster. Why, why are people using Pimlico? Yeah. I heard that.

Kristof Gazso: I feel like, um, there's quite a few reasons. So if you at least look at the bundle by stats, um, you'll see that we've done, let me just double check now. So there's 8 million user operations total. We've done 4.6, right? So if I, if I have my math correct, that's, uh, one in 55% of all these operations, um, ever submitted. Pretty great.

Nicholas: Pretty great. Pimlico.

Kristof Gazso: Um, same with the paymaster, very similar figure.

Nicholas: And since when, how, how long has the bundler been online? Roughly?

Kristof Gazso: Oh, it's been online since like early 2023. Like it was in February or, or mosh or something along those lines.

Nicholas: Pretty good. So about half the, more than half the transactions, more than half the user operations or, or sorry, more than half, more than half the bundles, I guess, or no, we're counting total user ops executed within those bundles. So more than half of the user ops propagated onto chains in the last year, uh, or Pimlico. So it's very popular. People do like it.

Kristof Gazso: Well, I'm, I'm, it seems so, it definitely seems so.

Nicholas: You can't lie. Yeah.

Kristof Gazso: I mean, people seem to, uh, appreciate that it's very, very battle tested, right? So we've, we, you know, we've been deployed on 30 plus chains. Um, we've encountered very different architectures, very different, um, environments when it comes to dealing with the different RPC providers and all that quirks that, um, that we've had to encounter. And so, you know, it's kind of like, it just works at this point. It's been so battle tested. We've encountered so many, so many bugs over time and we fixed so many bugs that it's just, you know, you can just run it and it will bundle. We've, um, we've paid a lot of attention into making sure that whenever there are issues, we're able to really quickly address them and push fixes or, you know, revert to an earlier version, which is just general, really strong attention to detail when it comes to DevOps processes.

Nicholas: Robust.

Kristof Gazso: You're right. Exactly. And, you know, we're trying to innovate at the forefront as well. So when it comes to, um, you know, for instance, things like, you know, compression that I mentioned, um, when it comes to these new developments, you know, when a new entry point version launches, we try to be very, very early and also, um, some, some extra, you know, sprinkles that we put on top. Trying to be really, really precise, really comprehensive, uh, with our documentation that we provide for end users, um, or adding docs. Yeah. Yeah. We, we, um, I'm, I'm, um, I'm one of those people who gets really obsessed about documentation. Um, so I, um, I, I might lock myself in the closet for, uh, for a weekend and not come out until I've written 30 plus new docs pages and, you know, completely revamped, um, almost everything.

Nicholas: It looks great. So. And look quite different to other docs in some ways to, uh, sort of, clearly you've put some attention into it.

Kristof Gazso: Yeah. I mean, I, I'm, I'm, um, I'm, uh, not perfectionist in everything, but when it comes to docs, I, I'm, um, I'm definitely, definitely wary of any, any, even small errors. Right. I feel like people, uh, many times, right. Really. So judge a project by how good their docs are. Absolutely. So we definitely want to be at the forefront of that.

Nicholas: I, there are, there are, uh, web three libraries out there that are a pain to use, but there's, for sure.

Kristof Gazso: Yeah. Exactly. And, you know, we also feel about like, um, extra, um, uses extra benefits development and, um, can get by using public code. So for instance, you know, allowing for you to query the specific status of these operation as being bundled. Right. So, so we have, um, a function which eventually we're going to look to, um, hopefully make possible spec itself, make me like a public thing, not just the public or specific thing. Um, right now. Now it's called Pimlico GetUserOperationStatus. And this, for instance, gives you, you know, is user operation not found? Is it currently in the mempool? Has it been rejected? Has it been submitted? If it's been submitted, what's the transaction hash that is bundling it? If it's failed, what's happening? Is it queued? Getting information that you can show to end users so that, you know, they have better clarity on what's happening. Many of these, you know, slight developer experience improvements that kind of add up over time and, you know, add up as you do more and more of them.

Nicholas: So we talked about Alto, Bundler a little bit and Paymasters. We kind of talked about them together. I guess, might people use one separately from the other?

Kristof Gazso: Many people do. Many people use the Bundler and don't use the Paymaster. There's people who use the Paymaster and don't use the Bundler. It's, you know, if you use one, we're not forcing you to use the other one as well. It's completely a separate piece of infrastructure.

Nicholas: And how do I pay for it? Or which parts am I charged for? If I want, I guess, just the Paymasters?

Kristof Gazso: So natively in the form-based spec, these operations pay us a tip to the Bundler. And that's, you know, the main way we really charge for the Bundler. It's just by, you know, the native spec and use it leveraging the fee payment mechanism that it provides.

Nicholas: In ETH? In the Gascoin or what?

Kristof Gazso: Precisely, yeah, in the Gascoin itself. And for the Paymaster, there's actually two types of Paymasters that we have. So we have a so-called bearer, a bearer-fying Paymaster. This allows you to attach a payment method that you give to Pimlico. that allows you to draw from your account. And, you know, it can be a credit card. You can load up your money with crypto as well. And you can, if you do that, spend and sponsor on-chain user operations on all the 30+ chains that we have. And we will just simply draw from your account, from off-chain Pimlico accounts as you spend. So it makes it very easy to get started with on-chain sponsorships for all these different chains without having to onboard GAS fees or GAS tokens. And second is our ERC20 Paymaster. So a big, big promise of account abstraction is that it allows you to pay in ERC20 tokens. And so we've developed what we, I think it's the first permissionless and first permissions implementation of an ERC20 Paymaster. So to use this, there's actually no API key you need to get. There's no, there's no dashboard you need to sign up to. if there's just an on-chain smart contract that we've deployed that you can give an allowance to from your smart accounts and start spending, start making transactions, paying with these ERC20 GAS tokens.

Nicholas: Makes me think about paying GAS in ERC721 tokens, but maybe another day.

Kristof Gazso: That's possible. That's possible. Uh, you can, I can imagine a, imagine Paymaster, like, you know, imagine, uh, one, one, one transaction. One user operation, uh, costs one ape, right?

Nicholas: And there's some, there's some NFTs I wouldn't mind paying GAS with.

Kristof Gazso: Oh, I can, uh, I can definitely imagine.

Nicholas: Maybe not an ape, but, um, how are people deciding which transactions to sponsor? And how do they do that if they want to use the Paymaster that Pimlico provides?

Kristof Gazso: Right. So, so by default, if you use the Verifying Paymaster, it's literally just a call that you make. And we will blindly sign that user operation and sponsor it for you. We don't care what conditions, there's no conditions that we check, uh, beyond like, you know, just basic sanity checks of these operations. Um, and so up to you by default to actually do the checks on your side, decide if you want to sponsor this. And just, you know, call our API if you do. But recently we released, um, what we call sponsorship policies. And so this is something you'd sign up to from the dashboard and it would allow you to to decide on a lot of really cool things like, hey, you know, Pelmico, you can host my policy and we'll specify in this policy that, you know, we want these certain maximums, we want these, you know, end dates, start dates. So you can be like, hey, I want to spend a maximum of $10,000 on this campaign. And I want each user to be able to spend a maximum of, say, you know, 0.01 ETH, right? Or a maximum of 10 user operations per user that I want to sponsor. And, you know, just to make sure we don't get scammed, each user operation is able to cost a maximum of $1 ETH. And, yeah, you can select the chain, you can select, you know, add some other small checks and deploy this sponsorship policy. And when you call the sponsor function on the Pelmico Paymask, you're able to pass this in as an argument. And if you do, we will check that actually meets this criteria. And we will revert this call if it doesn't.

Nicholas: Got it. So it's not so complicated to restrict sponsorship of transactions. Yeah.

Kristof Gazso: So previously it was up to you to host all the logic yourself. But now we've made it a lot simpler to just sign up, you know, configure it on a dashboard and get going.

Nicholas: I had Ulaash and Doan from Clave on the show earlier today, actually. And we talked a little bit about, you know, this convergence of bundling and block building. And they mentioned this group EtherSpot that are working on, I suppose, making the bundlers compatible with one another or creating a shared mempool. Maybe do you know anything about this or what's coming for bundler convergence in this dimension?

Kristof Gazso: When it comes to the shared mempool? So I would imagine you as the shared mempool becomes more popular, bundlers are going to then start. So, I mean, block builders are going to then start running their own bundler implementations. Until then, until it's purely the bundlers who have all the flow, there's not much that these block builders can get.

Nicholas: Are you focused on, I know you talked a little bit about ZK stuff before, and speaking with the Clave team, they were speaking about their ZK sync deploy that's forthcoming. Are you focused primarily on one-to-one EVM equivalent chains, or are you, also, compatible, like is Pimlico working with chains that have more divergence like ZK sync, and at what point is it too much to consider supporting them?

Kristof Gazso: Yeah, we've been talking ZK sync, and we definitely would like to deploy into the near future, to ZK sync. As you stray more and more away from EVM compatibility, and even equivalency, because it's more and more difficult to deploy a bundler. So something like stockdent, it doesn't even really make sense, to deploy a bundler on stockdent. or even a Paymaster. And actually, it doesn't even make sense to deploy Bundler on ZK-SYNC because they natively have Bundler. The only thing relevant for them is Paymaster services. But yeah, we've been sticking to all the 30 chains we're live on right now are very, very EVM compatible.

Nicholas: And is that where you see Pimlico going is being this kind of infrastructure provider for services related to 457? or is there something else or some specific angle on that that you're focused on?

Kristof Gazso: So Northstar as a company really is user experience. Like what was the best and most high leverage thing we can do to improve how easy it is to use on-chain applications. And we found that ERC-457 is by far the highest leverage thing we can build and build out on right now. But as this matures and as there's a lot of growth and as we look for other things to build to... to work towards this mission, I can definitely imagine us doing non-ERC-457 related things as well. moving on. But, you know, we would definitely be a company which has a lot of focus, right? So we want to be doing at this stage at least one or two things, but doing them really, really, really well. We don't... We're not really as drawn to, you know, doing 10 things good-ish. That's not really the way we want to expand at this stage.

Nicholas: Yeah, I don't know exactly what made me... understand that, but it does come off in the way Pimlico presents itself and the things you're focused on. You recently announced this $4.2 million seed round from A16Z. Congratulations, by the way. Thank you. How many people are working at Pimlico now? What's the stage of development like?

Kristof Gazso: So currently we have five people working full-time for Pimlico. We have a couple of people doing some part-time work as well, but it's five people who are working full-time.

Nicholas: Nice lean operations. Right, yeah.

Kristof Gazso: I'm a big believer in... I think, you know, Sam Altman was a big... said this, that, you know, small, extremely exceptional people making concentrated bets on the future who do not tolerate C players or B players have a really, really... a really big advantage to any other team.

Nicholas: Yeah, no bozos. Big advantage, for sure.

Kristof Gazso: Yeah, I'm extremely proud of our team. I mean, you know, without them, we would be nowhere near what we are right now.

Nicholas: And $4 million, is that just a long runway for you, or are there some infrastructure costs that are really expensive to operate a bundler?

Kristof Gazso: So most of it is still salary, right? It's just a human cost. There is some infrastructure costs, but it's not as significant as if you're running a node yourself, for instance. So yeah, luckily, that's not as big of an issue.

Nicholas: I was curious how you see the lay of the land of the different 4337 account implementations so far, and what you see... Is everyone going to be running the same implementation of 4337, or how do you foresee that playing out?

Kristof Gazso: When you say the same implementation, you mean the account systems, like, say, for ZeroDevil, like, Colony or...

Nicholas: Yeah, exactly, the account, yeah.

Kristof Gazso: Yeah, so that's... Hmm, that's quite interesting. I'm paying very close attention to that space, because as Pimlico, I'm very much quite against moving into that, because we feel there's so many great production-ready implementations. It's not really... Agnostic. It's not really our strength. Yeah, exactly. We wouldn't be quite neutral, quite agnostic to that. But I imagine it's going to be three or four main implementations with slight differences that are going to be used, especially with the advent of ERCs, like ERC-6900, or ERC-790, or ERC-7579. These numbers take a while to expect. There's going to be a lot more standardization across the smart account space. And so I expect, for the vast majority of users, it's not really going to make a difference. What's going to make a difference is what the underlying SDK, what the dApp happens to choose for you. Mm-hmm.

Nicholas: Actually, 7579 I hadn't seen, before, but that essentially is a smart account implementation with 6900 built into it?

Kristof Gazso: Not quite, not quite. It's actually an alternative, for the most part, to 6900, made by the Rhinestone team. It tries to be a lot more lean implementation. So, you know, the reason they did this is because they felt that the 6900 spec and reference implementation was very bloated. And so they wanted to make sure that defines the minimum amount that needs to be defined and leaves everything else up to the account. Right.

Nicholas: I was going to ask you about 6900. And specifically, if you think that as this account implementation differentiation plays out in the market, do you think, when Conrad was on the show, we were talking about how you could potentially imagine managing all modular affordances of your 4337 account via 6900 modules. So, for example, adding or removing signers, recovery options, etc. Yeah. It could be that modules are the primary way that the user modifies the behavior of their account. Maybe this 7579 delivers an even slimmer version of that. Do you think that is likely to be true? Or do you think we will have different account implementations where you interact directly with the account implementation in some way and it's not a standardized affordance that works across them all?

Kristof Gazso: I would imagine it becomes more and more standardized. Like all the different postage tooling and space, prefer more standardization. So, for instance, we have permissionless JS and we provide you high-level access to all these different account systems. If we could literally just pick one ABI that we interact through things with and one module system, that would make our lives so much easier. And it would make it likely easier for developers as well to work with and debug these systems. So, I do think and I probably do hope as well, we find some neutral standard that doesn't bias towards any specific implementation but allows developers and creators to develop a tooling to really make it easy to do anything with smart accounts.

Nicholas: Do you foresee, I was looking at 6492 recently and I was a little bit disappointed to see that the method of verifying a signature on a pre-deployed smart contract account is to first of all deploy that smart contract account, if I understood what I read correctly. Do you imagine that there's a way that you could verify user operations or signed intents or other things for a pre-deployed smart account without deploying that smart account? Delaying that? This is a very specific question.

Kristof Gazso: Yeah, this has been a long-running issue with smart accounts. I feel. I feel like, from what I've seen, 6492, I believe originally by the Ambiya team, is the best that we have. I haven't seen anything else that really comes close.

Nicholas: But you could imagine a kind of entry point design, right?

Kristof Gazso: I feel like actually, I would recommend taking a look at delegatable.org. Okay. It's a, I believe Dan Finlay was the one who came up originally with this spec, which allows you to do lots of the things you would normally do with an account off-chain. And everything becomes counterfactual with this, right? So imagine I'm able to counterfactually deploy an NFT marketplace, that someone counterfactually deploys an NFT to, that that person, someone counterfactually mints, that that person counterfactually sells to someone else, that, you know, it goes on and on and on. At any point in this flow, someone can actually, you know, trace back all the signatures that they got, and the whole flow of all these counterfactual, you know, actions, and deploy everything on-chain. At any point, you can deploy it all. Yes, exactly. So you can imagine like, I've sold someone my NFT, and that person actually wants to like realize that and like see that on-chain. They can be like, okay, let's deploy all this. so then they deploy the NFT marketplace and deploy the mint transaction, deploy the, you know, the listing, and then deploy the sale as well. then everything becomes on-chain. There's this really cool designs that you can leverage as well.

Nicholas: That's very cool. I'm gonna have to look into that in more detail. Are there any subjects related to these topics that we haven't dived into that you think listeners might be curious to know about? I'm sure there's tons of things that come up in your daily work that people would be fascinated to hear about, but anything about 4337 or smart accounts or new kinds of signers or EIPs that you're interested in watching? Or even applications that are interesting or architectural discussions that are ongoing that would unblock you from something coming up?

Kristof Gazso: Yeah, I'm just thinking there's so many things that we're doing day to day and, you know, picking one. Yeah, I would be very excited for one specific standard, right? Which is, there's actually two things, two separate standards I really want to see emerge. One of them is, how can we allow for decentralized embedded accounts, embedded walls into devs? So what do I mean by this? So currently, it's not particularly easy to actually, there's no standard for it at all, of say, having this flow. Imagine I sign into a dApp and the dApp generates an embedded account, an embedded smart account, counterfactually for me as I sign in. So it gives me like this literally zero click onboarding. This is fantastic. But then, I start using the dApp and, you know, it kind of wants to prompt me to actually deploy and actually connect this to a potential main account that I have. Somewhere else. Right? Because if my browser storage gets wiped, then I lose all my assets, there's nothing I can do. So, you know, at the early stage, you just want to prioritize user onboarding, but then you want to like make sure the user keeps their assets. And so imagine in this flow, I would have a button where I would click this and I would get prompted to select a provider. And with this provider, I would make the embedded account that was originally generated for me, a session key or a module that links to this main account I already have with this provider. Right? And so, you know, what does this allow for? This allows for zero click onboarding. This is better than Web2 UX. Like this is literally zero clicks. Right? There's nothing, you go to the dApp and you start using it straight away. You have a smart account. You have gasless transactions. You have everything you would want. But then you're able to actually secure your assets. Connected to a provider of your choice. And you can leverage a lot of these standards that are coming out like with session keys and with modular accounts to do this. There's no way currently to communicate, you know, the intent to talk to a main provider, first of all, and to communicate that intent of creating a session key or creating a potential, you know, module with limited access to the main account to, you know, to link these two. There's even no developer tooling as well to create, you know, these embedded zero-click onboarding counterfactual smart accounts. So, a lot of things missing there. There's actually an ERC which is trying to do something similar. ERC 7555, and ERC 7556. These are two to check out. - Yes. So that's one thing. The other thing potentially worth mentioning is if I don't have to forget right now, as I was talking, I might have-- - I understand.

Nicholas: That happens to me all the time.

Kristof Gazso: - What was it?

Nicholas: zero-click, you were talking about zero-click counterfactual account creation and then linking it to existing contracts, session keys.

Kristof Gazso: - Yeah, exactly. Listen, I want Web3 UX to be better than Web2 UX. I don't want to just get feature parity with Web2. exactly. It can literally be more, give you more self-sovereignty. You know, it allows you to decide who you trust and how much. UX as well with less of these, you know, annoyances that you have with Web2 accounts. So, this is why I'm in this space. I really want to see it be better than the existing system we have right now.

Nicholas: - I agree with you, especially between the new signer technology that's embedded in the operating systems and the browsers. So many guests on this show have talked about passkeys. Are there other kinds of signers that you think are particularly pertinent?

Kristof Gazso: - Other types of signers. I mean, I'm also a passkey lover, I have to say. It really allows for super simple UX.

Nicholas: - It's pretty exciting. But are there, I wonder if there are others or if maybe we're too obsessed with the shiny new one. but actually, maybe actually email-based is what would ultimately be more popular or some other social sign-in or something. - Yeah.

Kristof Gazso: I don't think it's talking about email specifically. It's talking about how do we add modules, specific modules to these main account providers. But with CKP2B, I can imagine it being a system of login for these applications that require more security. So for something like an on-chain game, I don't think you'd need to send a secure email. You could just make a passkey that lives on the browser. But for something where actually you would need an account which has personal information and important data.

Nicholas: - Multi-factor.

Kristof Gazso: to just be anywhere. Yeah, exactly. It can be a multi-factor alternative.

Nicholas: There's so much going on. And it's interesting to see these new ERCs about SSO and the embedded accounts as smart modules as you mentioned. So much is happening.

Kristof Gazso: - Oh yeah. - Yep. - I just remembered. the other thing I'd love to see is the ability for these dApps to try and signal that they want to batch multiple calls, multiple transactions into one.

Nicholas: - Not only from a single user?

Kristof Gazso: - No, no, no. Just from a single user. So imagine, you know, account abstraction allows for batch transactions, right? But, you know, if I'm like a Uniswap or I'm like a protocol which has to do a proven swap, maybe, I think Uniswap might have actually. But for most applications, they don't know if the end user has a smart account or not. - They have very little way of knowing. And if they, even if they do, if they check like the, you know, is the contract deployed or something? And they don't really change the logic of the dApp to account for that, to make use of that potential benefit. And so why not, right? One is just like, you know, it's extra work, which fair enough and there's not enough smart accounts maybe on that specific chain to, to make that viable. But second is, okay, so I have a smart account that is interacting with me and I would prefer to batch things. if there is a smart account. How do I tell them that I want these two things batched? Right? It's two separate calls they need to make. I don't know the interface. I'm not the one typically who would create these operations. Most of these operations are created by the wallet. So what if there's a way to make an RPC call to the wallet? that was like, hey, I want to execute two transactions batched together. There's certainly no, no, no popular standards for that. But there's been, there's been a couple ones proposed. One is, one, it's, I actually can't remember the EIP names right now. But there's two ones. There's one new one and there's one quite old one which has been stagnant for a while.

Nicholas: And these would essentially, you know, they would make it more clear to be able to communicate between the DAP and the account to check that it supports batching.

Kristof Gazso: Well, it's like, yeah, to check if it supports batching as well as to actually submit multiple calls in a, in a way that's batched together on chain. And so the account can decide, you know, because the account knows what the interface is for the smart account, it can decide to batch in a certain way.

Nicholas: for a certain implementation than another? Or what, why?

Kristof Gazso: you just, the DAP doesn't know what the interface is that they have to batch with, right? They have no idea what the smart account looks like, what it does, like what the, if it's a 4337 account or if it's not, or if it's like any number of different possible things, right? So the account has to be the one. But the DAP, there's currently no way for the DAP to communicate the intent that, hey, I want to batch these things to the account so the account can actually create the correct user operation.

Nicholas: But 4337 does cover the basic batching operation, right?

Kristof Gazso: Right, but send user operation is not something that, for instance, the World Connect API between accounts and apps allows for, right? At least, even if it's extensible, there's very little adoption of that, These are some nice wishes for the future.

Nicholas: I hope you get your wishes. Yes.

Kristof Gazso: I love, you know, people. There's so many things to build on smart accounts. It's not too late. It's, in fact, very early, so definitely encourage any hackers or any people who want to work on this to try it out.

Nicholas: And where are you keeping tabs? Where are you keeping tabs on these things, all these ERCs that are coming up? Ethereum Magicians or somewhere else?

Kristof Gazso: Oh, not as much these days. Typically, it's from the 4.7 mafia for the modular smart accounts telegram chat. I obviously have a lot of friends in the space who I talk to regularly about this and, you know, they ping me with new developments. Many of these new ERCs can be quite, can benefit quite a bit from bundler support or tooling support. So, you know, someone knows that, you know, we're building permissions JS or we have a bundler. then, you know, a bit of, if we know about them, we can advise them on how to make the best proposal. So, yeah, a lot of sources by osmosis, but a lot of these really cool group tests as well.

Nicholas: We've run the gamut of all of my questions. I don't know if there was anything else you wanted to discuss before we close the show out.

Kristof Gazso: I think that was, that's all, that's all I had.

Nicholas: Yeah. We've talked about everything there is to talk about. Kristof, thank you so much for coming through and sharing all your knowledge. If people want to learn more about Pimlico, if they want to get in touch with you, get more involved in 4537, what's the best place for them to go?

Kristof Gazso: Definitely check out pimlico.io, which is our website. If you want documentation, docs.pimlico.io. And if you'd like to get in touch, you can find me on Twitter, ChristophGasjo, K-R-I-S-T-O-F, G-A-S-S-O, or Pimlico.hq on Twitter or Telegram. Thank you. Yeah, we absolutely please get in touch if you're interested in any of these or if you want to contribute to the spec or Pimlico or these amazing standards coming out. Yeah.

Nicholas: Awesome. Kristof, thanks so much. This was a great conversation.

Kristof Gazso: Thank you so much and thank you for inviting me.

Nicholas: Of course. Thanks everybody for coming to listen. See you again next week. All right. Bye-bye. Bye. Hey, thanks for listening to this episode of Web3 Galaxy Brain. 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.