Web3 Galaxy Brain 🌌🧠

Nicholas: Before we get started, Web3GalaxyBrain is doing a Gitcoin. If you get value from this show, please show your support at Web3GalaxyBrain.com. slash Gitcoin. Each unique contribution helps direct quadratic matching funds to the project, so please contribute to Web3GalaxyBrain's Gitcoin before the end of the round. Visit Web3GalaxyBrain.com. slash Gitcoin to show your support. Thank you. Welcome to Web3GalaxyBrain. 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 Biconomy co-founder and CEO Ahmed Al-Balahi. Since 2019, Biconomy has executed over 40 million meta-transactions to help devs make CryptoUX easier for their users. Today, Biconomy is one of the top account abstraction service providers, boasting significant market share across popular EVM chains. In this episode, Ahmed and I sit down to discuss Biconomy's ERC 4337 smart accounts, paymasters, and buybacks. We cover session keys, passkey signers, EIP-7212, and multi-chain permissions. We also touch on ERC-6900 AA modules, which Biconomy and Rhinestone are collaborating on for their forthcoming module store, which is planned to launch in Q1 2024. It was a pleasure chatting with Ahmed about his journey building Biconomy into one of the most important players in the AA ecosystem. 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. Ahmed, thanks for coming through. I'm excited to talk to you about Biconomy today.

Ahmed Al-Balaghi: Likewise. Thanks a lot for having me.

Nicholas: So Biconomy has been around for a few years now, right?

Ahmed Al-Balaghi: Been around since 2019. Yeah. So around mid-2019. So it's been four years.

Nicholas: That's great. I was taking a look at the blog, and I mean, the product has evolved somewhat, but there's always... There's always been an interest in metatransactions and something in the neighborhood of account abstraction, right?

Ahmed Al-Balaghi: Yeah. I mean, account abstraction can sort of come in all shapes and sizes, I guess, depending on how you look at it. And yeah, metatransactions was definitely in that realm. And for us, it was great to start off with that and really just understand what it means to think about transaction management. What it looks like for how UX can grow and improve as well. And yeah, I mean, it had its fair share of positives, but also over the years, we learned that there was quite a few stumbling blocks it had as well. Yeah.

Nicholas: So can you, for people who haven't followed the whole journey and are maybe just starting to pay attention to account abstraction, the current terminology and smart accounts under the current terminology, how has Biconomy's product offering evolved over time and as the ecosystem has evolved? How has it shifted through different ways of thinking about it?

Ahmed Al-Balaghi: Yeah. So when we started off, I would say one of the first builders on Matic sidechain, which we now know as Polygon, and it kind of was very clear when it came to gas fees and especially on these newer chains, they'll be cheaper and therefore they could become a custom acquisition cost for developers to essentially... On board users without them having to really bring in any form of gas or anything to do anything on chain. And so that was really our whole premise. And the other assumption that we had as well was that dApps will eventually grow and also make money. And as they are making money, a portion of their costs will go towards gas fees as well, much like how Netflix doesn't sort of charge you their AWS fees, right? Every time you press play video. So that was like how we always, I'd say, made people sort of realize or understand sort of what we do. And we managed to sort of grow and scale that product to basically facilitate over 45 million gas transactions across 300 applications or so, including a couple of enterprises as well. And, you know, I would say... You know, just from sort of very high level, right? When we started around 2019, the product went live in 2020. And I would say it was around mid 2022, that's when we sort of realized that, you know, this metatransaction framework kind of allowed only one use case. And we kind of had to like hack around it for another use case, which was basically allowing users to pay gas in... A different token. So that, you know, didn't get the traction that we sort of expected. I mean, there were some apps using it, and there is still one app that uses it, which is the Sandbox. And then in mid 2022, we sort of saw that, hey, you know, this new ERC 437 that has, you know, come about after many other, you know, attempts at account abstraction. And we saw that this was, you know, a framework that not just allowed us to, you know, account for the use case of gasless transactions, but also allowed the use case for so many, you know, new things that we always wanted to enable with metatransactions, but because of technology, it was just very limited. So that's a very, very sort of high sort of level of, like, that journey and involvement.

Nicholas: 45 million gasless transactions, 3 million apps, that's a lot of transactions. What were people doing with the straight metatransactions solution?

Ahmed Al-Balaghi: So, some apps... Some apps were gaming. So Zedrun for example, didn't want their users to pay gas and have to use Matic. They actually had another, they had another asset, which was actually Weth, right, where, basically, the gamers could come in and basically either place bets or essentially place, you know, that sort of trade using Weth without having to hold Matic. And, you know... that was you know um you know a great sort of you know way for them to just make the the ux super simple. um i would say one of the first apps that we actually ever got on board was curve finance. um these guys actually used um uh meta transactions to enable bitcoin holders to easily um deposit an lp um wrap btc into um into ethereum and of course they had to stop using us because gas fees went a bit too high. um but that was like um. that was really cool. that was when we just you know had the product launch um and ultimately you know over the years we saw. so um i have seen you know zed run the sandbox decentraland like for example decentraland. they were using uh meta transactions in the marketplace um and for every transaction that they subsidized they were still making money because there was. you know there are actually there are actual um orders of value which would they would take a cut from from that marketplace. um. and so you know we we saw those use cases we saw some defi use cases as well and so over the years we sort of you know have seen like a wide variety um of of use cases that have popped up and so that that's really i would say that has enabled us to at least understand like you know where meta transactions doesn't make sense where it might not make sense as much um. but as we move forward um we we we are seeing like now just the concept of like you know sponsorship or sponsoring users transactions. it's going from like a nice to have to a must to have and that's sort of the the path that we're seeing now got it um.

Nicholas: so so it sounds like it under the meta transactions the way most people were doing. it was like taking funds in escrow and then handling the meta transactions on their behalf by working directly with economy with by economy rather than having the user like the user didn't really have to think about it at all at that point.

Ahmed Al-Balaghi: yeah makes sense they didn't have to think about it at all.

Nicholas: yeah uh so. and then since then the project has evolved more towards this 4337 direction. right correct so um but you have a gorgeous website. by the way i was taking a look. it looks great. is that a new website?

Ahmed Al-Balaghi: yeah shout out to to logan from the noir team. they're they're really awesome.

Nicholas: yeah it looks awesome. um so yeah. so how like you kind of found the limitations of like the transaction um architecture? how have things changed? what's opened up with 4337?

Ahmed Al-Balaghi: yeah so essentially you know it's like the the concepts and how i like to think about it. you know account extraction is all about. essentially you know separating the the signer from the account and what that sort of enables is it essentially enables programmable um ways for users to actually um have newer experiences developers to essentially customize user journeys um for for their community and for their users. and what's um and essentially like? when we sort of think about the paradigm of of account abstraction it inherently um starts off with a smart contract on it right and we've kind of seen this over the years. um you know it has come about in in different forms. you know with argent sort of taking the lead and safe doing the multi-sig as well um and it's funny because we are by economy. you know when we were doing meta transactions hesitant to do smart accounts because smart accounts there were two really really big problems. the first problem was that if you were to give a user a smart contract wallet um it would basically mean that they would have two addresses. and how do you on earth have to? how can you essentially manage two addresses right especially when this is also new? and so that was one part and the second part was um uh was essentially around the fact that you could essentially you have all the distribution with any wallet right. so in a metamask or trust wallet a you know all the wallets that's under wallet connect right. they're all eos. and so if a meta transaction is there and if a user is um is uh coming in and doing a transaction it doesn't matter which wallet they're coming in from right as if the dap is sponsoring the sponsoring right. and so i would say that you know we we basically were in a place where we saw that. um we we we i would say like we went about and explored and tested as much as we can with with meta transactions so that when we saw account abstraction and what it can enable and and the fact that um we even saw some like i would say some user experiences as well um with even dydx they were one of our customers and it was really interesting to see that user journey and that user flow as well because when a user basically deposits some eth into an account that account created for them and then they could do all their transaction you know all their trading or transactions from that account. um and again what it allows is it allows for a way more flexible user journey and so it's funny because like in 2019 2020 we were kind of against this idea and then um a couple years later we we thought actually not. now it's probably the better time and the right time for this um especially around. you know a standard that we could all um you know um we could come together for. and so uh looking at you know when i look at as a standard and as a framework um and we see the different you know use cases and the different um things that i can enable for for the user. um we then sort of told ourselves that hey like instead of a user having to go down and you know um start off by you know writing down the c phrase they can now do this in a way that's you know very simple through email and they can now just see one you know address and that's the smart account address as opposed to the eoa. and so you know we i would say like thinking from that lens and sort of thinking from the programmability aspect the extent the extensibility aspect that smart accounts sort of provide within this framework. it kind of sort of dawned on us that this was definitely the way forward and um uh it made a lot of sense and even the concept of the paymaster uh as well it kind of helped a lot. you know it just allows um the infrastructure for um for this standard compared to let's say the relay infrastructure for meta transactions um you know within 437 it's more open it can become decentralized um and there's more of a community effort as opposed to sort of the. you know the meta transaction you know there was one standard but there was just many different types of centralized approaches um and there was no way or no goal in sight for that to become more open and decentralized. whereas with erc 437 um we have that. so so so when we sort of look at account abstraction we kind of see it from not just a lens of like you know oh easy ux right. we kind of see it from a you know really a bird's eye view of um of all the positives that um it it could bring um you know from openness from a community aspect from um of course the ux um and and the the programmability as well.

Nicholas: yeah it sounds like something about the sort of consensus shift to 4337 and allowing it to be kind of progressively rolled out has convinced you that compared to in 2019 or 2020? at that point supporting smart accounts of any kind would have been like a an install base of zero when you start whereas now there it does seem like there's this kind of groundswell of attention and and willingness amongst the community to to take seriously 4337 and really go for it.

Ahmed Al-Balaghi: yeah and honestly like when you think about it and this is just i mean it's markets right it's a lot of it is timing right.

Nicholas: yeah maybe it is just a bit more mature or uh i don't know if the multi-chain reality has. somehow i mean we'll talk about it in a second but it's not exactly easy dealing with smart accounts on multiple chains either. but um actually later today i'm going to be talking to some people about 3074. uh off and off call. i don't know if you had any sort of perspective on why 4337 is working whereas uh off and off call did not.

Ahmed Al-Balaghi: so i am i'm definitely not person to talk about 3074 um and i i would say so i i do have memories. well i mean it's not like a long time ago but i do remember very very vividly you know around mid 20 um mid 2022 when you know 437 kind of you know was um you know established not established but it was. you know it was just starting off. um there was lots of debates you know between the 437 authors and the 3074 authors like it was. it was as if like you know it was just like you know academics you know sort of talking out right um and it was really interesting because it did seem like it was two very different camps right um it was two different camps. and uh and it was interesting because we you know at least for me i remember i was like just sitting in this conversation between um you have and someone else. i can't remember his name but i remember and it was just like back and forth. i was just learning all about this. um because it was it was relatively very new and um it felt like you know it. when i sort of look back um i do see that with 437 because it managed to cultivate a community and of course vitalik helping 437 or favoring that a bit more does help. but with 437 there was that sort of community cultivation versus 3074 which didn't really um manage to sort of bring a lot of people around it. um i would say that was probably one of the biggest reasons. um and of course this is outside the technical you know reasons why maybe one you know one would favor one over the other and um for for us. uh we did eventually decide on 437 because of the programmability and the extra for 3-7 to provide or at least the the the promise that smart accounts will provide and i think it was a security aspect. ultimately that um that led us to um sort of that decision. um and i i don't want to sort of come across as well as like saying you know by economy kind of led the wave. but i do remember you know when we did our testnet launch in november of last year. uh i kid you not there was literally no one else maybe besides us that was able to come across as well as like saying stack up who were you know doing quite a bit of stuff in this space? and i i think we just did a huge launch. we kind of got a few people to talk about it and then a few other people talked about it elsewhere and then just became this like snowball effect. now we definitely contributed. i just don't know how big of a contribution that was. um and uh and i think you know that along with the community you know cultivation that the the 437 team did very well um you know managed to you know just galvanize the mindshare right that it currently has versus 3074 which is is not at the same. uh uh it's not. it's not the same um level at the moment.

Nicholas: yeah i i think it's interesting. i mean if people are interested in about four hours i'm going to be having a conversation with uh light clients greg the greek and joseph delong about 3074 versus 4337.

Ahmed Al-Balaghi: i mean i think i'd love to hear that i'd love to.

Nicholas: i'm excited for it because i'm i'm.

Ahmed Al-Balaghi: i'd love to learn like just you know where it's at and you know um because it's very interesting as well. i remember polygon as well. they were very very close to going 3074 but i i don't know what happened exactly.

Nicholas: but yeah anyways it'll be interesting to hear. i think even maybe more than the technical parts which are also obviously very interesting it's um one of the things we have to make decisions about so much when working in this space is i mean between chains between ecosystems between programming languages and paradigms of ercs and such. there's a lot of like uh trying to trendcast the social consensus or participate in building it. so i think there's an interesting conversation there even if 3074 never goes anywhere from now forward. um just sort of looking back on uh you know i think there's a temptation amongst developers to just pick things that appear like the the obvious technical superior choice but without maybe considering as much the social consensus aspect. so i think this uh this kind of debate between these two standards is exemplary of that. so be an interesting conversation. so so for you what's the point of? you know we've been talking about smart accounts on this show especially with so many different smart accounts. what really is the point of smart accounts? what makes it worth spending all this energy on?

Ahmed Al-Balaghi: i like to honestly define it as

Nicholas: you know

Ahmed Al-Balaghi: customizable or programmable user journeys simple as that um because with smart accounts you could literally enable all different types of you know use cases um for the user um and this is i would say pretty open to every single industry or that exists in web3 and that will also continue. you know that that will also um open up in in in the future. and um and because it's such a you know an open canvas it really sort of allows um. you know and i'd love to sort of you know talk about the the module aspect and the sort of the modular account abstraction and the work that we're doing with rhinestone as well because what's why it's important is because it kind of allows for you know this standard as an account or as a wallet that users could go with um and they could essentially easily they could easily um you know install different variations different um uh different features that would enhance uh you know their account in a very secure way um and in a way that is non-custodial right and and the way i like to think about it as well. is you know? how can we make sure that we're not? you know we're not going to get to a place where we can you know finally have on-chain ux that is as good as off-chain and essentially enabling one-click experiences and i i believe small accounts you know can actually provide that great.

Nicholas: yeah i definitely want to touch on modules paymasters bundlers multi-chain signers all kinds of things. let's just get through a few high-level things first. so what portion of my economy's attention is? four three three seven.

Ahmed Al-Balaghi: it is a hundred percent all right great.

Nicholas: um so and who is the ideal by economy? customer? is it like an indie dev or a big company? someone else?

Ahmed Al-Balaghi: i would um i would basically bucket it into three. uh it would be an app adapt a wallet and an app chain.

Nicholas: an app a wallet and an app an app chain. you said yeah.

Ahmed Al-Balaghi: or a roll app.

Nicholas: yeah roll app. i've never heard that. that's good. yeah do you think that's?

Ahmed Al-Balaghi: i only heard that i only heard that last week so i decided to to use it and see like people's reactions.

Nicholas: that's interesting. i like. app chain is is familiar. do you think? um are there examples that come to mind of existing app chains that fit this model for you or or applications you see in the near future that might make sense absolutely.

Ahmed Al-Balaghi: so we're we're already in talks with quite a few app chains. um you know there there is one that's sort of you know pretty well known in this space. um not sure if if i could name them we've signed with them and everything which is which is great and i think it's a really good. and they're about to launch um their uh you know like a new app within the app chain very soon. um so that's going to be exciting. um you know we've you know avagotchi and by economy we've been working together for a long time. it's been you know very clear in their mind. they want to do an app chain and account abstraction sort of makes sense for them. um. and and so when you look at um you know apps like avagotchi um or when you look at any form of like social um applications as well that want to sort of roll out their own chain uh for them you know what's really important is that the ux has to be you know it has to be on par with web2ux. um the great thing is gas is cheap and so you know utilizing paymasters um sort of solves for that and and of course you know they would at least you know quote unquote you know would be able to control as much of the environment as they can while still remaining studio. and so for for us we definitely see you know i'm actually a firm believer that when it comes to app chains or roll-ups they could essentially become like you know websites. right like you know how we have so many websites there will be um many roll-ups um many app chains in in the future as well.

Nicholas: um so yeah for us it's definitely a clear um target customer like the app chain almost replacing what you might traditionally think of as just back-end.

Ahmed Al-Balaghi: but you know it could also just be a front-end as well. right um again it depends on on on the the app chain itself. but uh um yeah ultimately it would be more of of the form of what you mentioned.

Nicholas: what do you mean when you say it could just be a front-end?

Ahmed Al-Balaghi: so at least with what we're seeing is that there are some app chains that are you know there are some ecosystems when they're in a way deploying their own chain. um there could easily be you know multiple apps um that that might exist on that chain as well. that could just be in the ecosystem play and so you can have a front end as well. that would just you know aggregate these different apps or they would be able to provide a different type of user experience um and so like. again this is i would say much more further down the line but it's it's it's something that you know. i would say we've at least started to see something like a wechat or a meta ecosystem.

Nicholas: you might imagine it as an app chain. would that be like a fair analogy?

Ahmed Al-Balaghi: yeah possibly yeah that's what i think about it. um we still haven't seen um a wechat like you know uh ecosystem yet right in the sense of um you know i guess this is the thing that's been heavily unexplored. and um yeah this is maybe somewhat outside outside the app chain um thesis but uh you we can think of it that way as well.

Nicholas: no definitely i i completely agree um that the pwa there's a synergy between pwa's smart accounts and app chains or l2s in general. but app chains in particular can really let you capture value better if you if you control a consumer application that's popular um at a certain why not control the chain that it's running on if you can do a roll-up? Exactly. Just while we're on the topic, do you think, like, are roll-ups as a service the way that people are likely going to bring these kinds of roll-ups to the world or something else?

Ahmed Al-Balaghi: Oh, I mean, 100%. I'm definitely bullish on roll-up as sales providers. You know, they are going to be needed and, you know, they will be an important part of the ecosystem as it scales. because, you know, if there's a Web2 app that wants to, you know, be able to have a Web3 element and they want to have, you know, their own chain, it makes sense to go with a roll-up as a service provider. So it's for roll-up. And this is something we've been thinking about as well is because we've been doing a lot of integration and integration. and the question then becomes, okay, how can we automate this at a really interesting and rapid pace? Yeah, but that's still, in a way, not, yeah, that's still a bit too early before we're able to crack that as well.

Nicholas: I've been talking with some of the roll-ups as a service and some of them think that it's, that they will have trouble establishing a moat and that it's kind of a race to zero between them. So I'm curious to see how that works because, obviously, if your roll-up as a service provider goes offline, you don't really want that.

Ahmed Al-Balaghi: Yeah. Yeah, no, absolutely. It's, I haven't really been in those discussions. And when I do think about it from sort of just a high level and looking through the possibilities, it's, yeah, it's very difficult for moats to be established. And ultimately, when it comes to these types of plays, it all comes down to the developer. The developer experience, the customer experience, and the product. And that is itself its own, you know, moat, to be honest. And it's very, very hard to replace, you know, an awesome experience that a customer had or a developer has had. And so I think those things, it really, if done right, they, you know, more moats will sort of establish themselves after some time. And, of course, that could go with, you know, many different business lines. But, yeah. For roll-ups as a service, given that it's still very much technical in nature, you know, I would say, like, just very much focusing on that is really key.

Nicholas: Yeah, I can imagine once you, migrating a roll-up to a different roll-up as a service provider does not sound very fun. So unless they're really extorting you, I think you probably don't want to change that.

Ahmed Al-Balaghi: Yeah, I mean, of course, the roll-up business model is amazing, right? I think ZK Sync did $30 million of revenue. I think ZK Sync did $30 million of revenue alone, which is crazy. And so, yeah, I mean, I'm sure there are, you know, plenty of ways for roll-up as service providers to capture some of that value with the apps that they work with.

Nicholas: How should developers think about choosing, like app developers, I'm thinking, how should they think about choosing between the various 4337 account contracts, the implementations that are floating? There's like a bunch of companies that have their own version of smart accounts. I guess Biconomy has one as well. So why should someone pick Biconomy? What are the dimensions that someone should consider?

Ahmed Al-Balaghi: Yeah, no, really good question. So we've been thinking a bit about this as well. And ultimately, when it comes to, you know, when it comes to someone building their app, you know, I do feel like, you know, to a large part, it's a very sort of, you know, personal and business experience, you know, together. And what I mean by that is, it's all about how the end user is going to, you know, it's all about their experience, right? How will the end user be, how will the user's experience on the app, you know, be impacted with, let's say, a smart account implementation or even an EOA implementation. And so for us, we always, you know, whenever we speak to new applications, we always ask, like, what's the, you know, user journey? How do you want that user journey to look like? What's really important? Because with that, you know, not in mind, then it just becomes harder, right? For, like, what the next steps would look like. And so for, you know, for us, that user journey is really important to understand from these, you know, new applications. And then when we sort of go down and, and look into the, like, when an app sort of knows what, in a way, what they want, it then comes down to, okay, you know, we've seen sort of many apps, you know, comparing and trying to understand who they'd want to work with. And one, you know, I would say, like, one clear, like, I would say differentiation when it comes to why and how these, you know, you know, apps would, would choose a provider. For some reason, there is this aspect of gas, right? Who essentially has the lowest consumption gas in terms of the contracts. But that is something that can easily be fade away through L2s. That's one part. The other part is who else has, has sort of used these smart accounts? You know, what use cases are there? What case studies exist at the moment. that, of course, builds confidence. We've also seen various folks, you know, look at the, you know, the safe approach versus like the diamond proxy approach as well. And so there is way more, you know, security concerns around the diamond proxy approach. And, and the, the, the safe approach, which, which we've sort of implemented has sort of resonated well with, with quite a few developers. Especially when it comes to the security side. So that, that's also another point for, for people to consider. There is also, at least right now, because, you know, we don't have, you know, something like 6900 ready. But when it comes to sort of modules, if there are, if there is an account implementation that has modules live running and that's working, that's also another reason for, for a smart account provider. To be chosen over another. And yeah, I mean, I would say these are, you know, sort of really important factors. The other aspect, of course, would be, you know, how would the signer look like in the smart accounts? Can I bring my own signer? Or do you support the signer that I work with? And I, I really believe in the future as we sort of, as we, you know, grow and expand. as an industry there will of course be smart accounts smart account providers dedicated to a niche um. that would naturally um happen before you know. they might get consolidated and so there are um definitely uh some segments um of the market that's maybe more catering towards you know one specific niche like gaming or maybe defy whereas others like us were a bit more general. um although we have you know amazing and great use cases that we're seeing within perps for example we're already working with around sort of five or six platforms um and uh. and i would say like one other reason is if one if one platform has used you guys then we want that same experience. so you know they'll use us again. so that's also like one other reason why we've seen other um you know applications use us as well. so it's i would say there is definitely there can be a herd mentality. by the same time we've seen you know various applications um you know really go into the detail you know and they really nitpick and and they even go beyond the um implementation itself and say oh um the documentation here isn't as easy. therefore we want to go somewhere else where it's a bit easy to integrate um. and so um these are yeah i would say like just various aspects as to how and why um apps will will decide which implementation to go for.

Nicholas: yeah it makes sense. same same things were on my mind um but basically sort of the lindiness of the platform that's offering the services how sort of um standards compliant and open their choices are about their implementation. gas efficiency is like one. that is obvious that you can do this side by side comparison but given the upgradable nature of aa even that is probably not worth overrating because it can improve over time.

Ahmed Al-Balaghi: um yeah

Nicholas: and yeah some of the sort of sdk affordances and how suitable they are for the specific application you have as well as maybe the breadth of the offering from that service provider if they can do the bundling and all the other paymasters all the other aspects of what you might want in your app. those seems like the important question.

Ahmed Al-Balaghi: so um i would i would definitely say that the lindiness is. i mean this will definitely be something that will exist maybe a year or more down the line. that's still. it's still a bit too early to be honest at the moment because it's um of course like you know the the lindiness of safe right like we know it's secure it's the best you know experience for multi-sig and so we will use that over anything else. um we are still not at that stage in terms of any form of security lindiness with any of the smart account implementations. now right um and so um yeah so that is still i would say an open question at the moment.

Nicholas: yeah it's interesting it seems like aa will start to eat into or maybe not that safe market share is exactly the same audience as aa but at least that the 4537 smart accounts will start with more what you're talking about these kind of pwas with embedded signers and more less uh significant not vaults you might not start with vaults although at any point someone could just say we have something that's better than safe for you know because it has modules or something and the whole narrative could be shifted and suddenly we may start doing vaults that are uh are aa uh compliant although and i guess safe is also moving in that direction too. so at the end of the day everyone will be interesting.

Ahmed Al-Balaghi: um um and yeah this one one point you mentioned as well um thanks for reminding me is is definitely the aspect of do you go with a provider that provides a full stack or do you go with a provider um you know like zero dev or patch wallet where you know they would have their own smart account? but might you know aggregate the different you know uh bundlers out there as well and that that's also you know an approach some people like some people dislike it. it really depends on on the developer and what they're optimizing for right.

Nicholas: and and so why should someone choose by economy?

Ahmed Al-Balaghi: why should why should someone choose us? i would. so there are two. there are two um different parts. the first part is as a team we work the hardest we don't quit and so if there is some thing that one of our customers uh has a problem with the needs we will do everything that we can to um you know to to meet that request of theirs. and so for us you know we've been doing this for a long time and so it's it's really important for us and that's just how we operate um as a team and that's just how you know we are culturally um at least when it comes to you know when we look at the the smart account side of things. uh we definitely when we sort of see our implementation that we've done um we definitely see ourselves. um you know i mean it's it is hard to say like it's. i mean of course time will tell but at least for now at least the design choices that we've made um we definitely feel are more secure than other various approaches. um you know the the approach um via the safe proxy um has enabled us to sort of um have a more cleaner and more stateless account structure um which would sort of result in less collisions um over time. and so that is you know one really strong aspect that um you know that that we think is super important um. another aspect that that we also um you know talk about quite a bit and think about quite a bit is um. even with some of the modules that we built um like for example the sessions keys module um that right now is the most adopted um module i would say in in the account abstraction space we have at least um a couple of platforms um using our our um sessions key module. it's extremely programmable to the extent that because we built you know a framework for it um it enables any developer to come in and customize um a particular use case on top of that right whereas other session key um implementations um isn't as customizable it's it follows a very rigid structure that you know. the module um team built out themselves and so one example i could give is because of the um. uh because of the um the the way we've implemented the sessions key module uh we've essentially enabled um or allow developers to actually build uh a way to have like batch sessions into one click as well. so you know one of the teams i'm working with called rage trade. we kind of co-built a module with them called a batch session router module um and so we've essentially enabled um a way to have like batch sessions um as well as another another one called a multi-chain validator module as well where you could um basically uh do you could basically trade um. uh on one chain um by you could trade sorry across multiple chains by basically um one click right. and it's a really interesting concept that uh we we sort of co-built with um you know with our clients and so uh when we sort of integrate with with a customer um you know we really care about sort of their use case um how they want that user journey to look like and can we co-build modules you know with these um with these clients um and of course like for us. a third reason like you know why people choose us is because we've practically been in this transaction management space for the past four years and so running paymasters bundlers um is definitely something that's you know. you know straight up our street and it's not really our first rodeo and you know we've. you know um have been there and i've been doing that for for for some time. um. so these i would say are just you know things that are sort of top of mind. as to you know why why? why people should choose my economy cutting edge uh.

Nicholas: collaborations with projects uh. lindy team uh. and dedicated and um uh. maybe breadth of service offering or or open standards the choice of the module architectures that you're choosing 1600 focus which i want to get into right now but um. so just one thing. first you mentioned the safe versus diamond um implementation choice architecture uh we talked about this on the episode uh previously with rhinestone with conrad from rhinestone um from a app developer perspective um there seems to be some some people believe that the safe approach is uh because it's more um. is there much um aside from like making that conscious choice? is there much implication as an app developer when interacting between choosing between um a contracts that are safe or diamond style or at the end of the day from the app developer perspective it's kind of uh beneath the api layer for them?

Ahmed Al-Balaghi: so i'm just trying to um understand the question a bit more could you like.

Nicholas: there's a security. there is a security trade-off between the two implementations approaches um and from the perspective of someone who's trying to choose uh which kind of um smart account contract to work with does aside from making this choice about what they believe is more safe does it affect their dev x experience at all really or or not?

Ahmed Al-Balaghi: so much good question um. ultimately it's up to the. of course the the smart account provider seem to enable um a better dev x. i'm not sure i could fully confidently answer that. oh one approach. would um provide a better dev x um because of that approach? so i i can't say that for sure to be honest um. but what i can say is it's of course that the the dev x can always be abstracted and be as simple as enough as it needs to be for for that integration to to go ahead. um yeah so so i'm sorry i can't answer that that question fully.

Nicholas: that's okay. i guess there might be something with the diamond approach. if you're integrating modules or you're having your smart account make calls to other things maybe it starts to be a concern where the app developer as long as they're building their own smart contracts as well maybe does need to think about storage slots and uh not getting into trouble in a diamond approach possibly but anyway i'll look into that in future. so uh we've been teasing this discussion of modules and you mentioned session keys just now. so let's talk about session keys and then let's talk about 6900. so overall what is a session key?

Ahmed Al-Balaghi: yeah um so a session key. i like solve json web tokens right where uh the like. if we look at the web 2 um landscape you essentially are providing um a key to the to the front end to this client um to be able to do certain actions on your behalf with with with a permission really right. and so session keys as a module. essentially it kind of takes a lot of data to and it essentially um allows users to grant permissions to daps to um do transactions on their behalf um and a very simple example which i was just demoing on one of our um clients betas. um. uh yeah one of our one of the betas of our clients um they literally have a um. uh you know that a user could basically dictate their trading session to be. is it an hour? is it six hours? is it 24 hours? so it's pretty cool. and so of course because it's on chain right like it's very automated and very fluid and it's very open as well. and so um yeah all in all um that that's essentially what a session key is.

Nicholas: and so you would be delegating permission to do uh transactions on your behalf within some permission space uh to like the some other smart contract or something or to the app itself who gets permission to propagate those user ops.

Ahmed Al-Balaghi: so it would be um the app itself okay.

Nicholas: so as a user of say like some perpetrating thing i might say okay for the next hour up to 10 weath. uh is tradable by uh app xyz something like that correct very cool. so how does um? so for people who are interested in erc 6900 and haven't heard too much about it you can check out the rhinestone episode where we talked to conrad kopp about it and a little more high level detail as well as some specific details. um but erc 6900 modules for four through three seven smart accounts. um how does this relate to session keys? and yeah how do you think about uh 6900 overall and your integration of modules in general into the the platform?

Ahmed Al-Balaghi: yep? yep no good question. so of course 6900 is is really amazing. i mean at the end of the day six nine hundreds um. so our mission is to enable um any module to work with any smart account right. and so of course right now it's the case um and it's a case where uh for example our session key module works for by economy smart account and zero dev session key module for example works with this. but then their session key module wouldn't necessarily work with ours because the implementation isn't isn't sort of the correct one. so eip 6900 would sort of solve that. where if um a developer were to build a module um and a a smart account? um also is um built according to the 6900 standard. it basically ensures that you know all modules built by module developers would would be compatible with these smart accounts. right. so that's of course the end goal um but we're not there yet. um of course 6900 isn't um like there still needs to be a newer reference implementation.

Nicholas: i think the first reference implementation was just put out a couple weeks ago right um it was.

Ahmed Al-Balaghi: it's still going through quite some comments. um there's still a few uh aspects that need to be ironed out. even you know um our team as well as i believe or ryan's team that um and a few others that there are still some uh at least on the technical level which is best for help for my engineers to to debate it out where they believe. um that you know. there are just some aspects where 6900 um could either be leaner um or could suit you know for for different parameters. and so um it's it's an alchemy as a team who i would say is a major force behind 6900. they uh you know are still i would say they are in a position where they would also need other co-authors. um uh you know for for um for the cip because you know in order to enable an you know an open standard for everyone to to to use then it kind of needs of course the input from the community. and so it's um it's still uh. uh i would say early days um uh and right now the modules that are you know existing um or uh are being built and maybe will launch even in the next two months. um none of these will. i mean they. they will most likely be um. they'll most likely be uh very much focused on one smart account implementation. uh what we are seeing some teams do um in this sort of module landscape is they are essentially um like building a module and just making sure it's compatible with other accounts. right um and so like moonshoot is is one example. and um yeah and so 6900's sort of vision is bold and there is. there is still a lot of work to be done to make sure that it's compatible with other some technical considerations at least. you know um. when i hear my team speaking about this um you know before. uh you know we we think it's you know could be finalized and um could come out um to to serve the community and and what we're doing as well right.

Nicholas: so basically the modules of today are unlikely to be sort of forwards fully compatible with everything because the standard is still being worked out. moonshoot i actually haven't heard of that. what is moonshoot? essentially?

Ahmed Al-Balaghi: um for your smart accounts. that that's what they're going after.

Nicholas: oh as a module too.

Ahmed Al-Balaghi: yep as a module. so essentially you could import a module which would give you a private self address.

Nicholas: wow very cool. um okay so that stuff is sort of in in progress and and one way that you're using that is to start thinking about this multi-chain uh propagation. we've talked about it in previous interviews uh regarding especially like the challenges about multi-chain smart accounts and propagating permission changes to for example swapping out signers or adding signers key rotation. this kind of stuff um across multiple chains becomes like a real headache um or at least a little bit dangerous. let's say for example you uh remove a passkey on one chain but you forget to do it on the other chains. there's a lot of uh sort of uh loose connections between the different parts that could get you into trouble. um so you mentioned this uh multi-chain validation work which i think is super interesting that you could sign a transaction one time and then it would allow you to execute that same transaction or some subset of a bundle of user operations across a bunch of different chains. that's very very cool. and you're doing that as a module too.

Ahmed Al-Balaghi: yes um so that is that currently exists. i literally did that trade on ray trade today. um before this call um so cool. and uh yeah i mean and and and this same module could essentially solve the problem that you described where a user and and even if you think about it in a practical sense right if a user is basically swapping out signer for a different signer it's most likely they're going to do it for all the chains that their account is deployed on right right. how many of those users are going to be very technical to say hmm i will have a signer this sign on this chain that sign on that chain and if if someone is that technical then you know it's like in web 2. it's very easy for someone to go down a rabbit hole and figure out. you know um you know ways of configuring a software or hardware to their specific standard. right but 99 99.9 of world probably when again um and so i i would say you know you you're definitely right in the sense that there are a lot of open questions on that front and even you know for us we're always talking about. you know how could we um ensure that you know the the like we could work with not not only work with as many signs as possible but also across signers as well um that reduces you know our dependency or maybe you know their dependency as well. um and how could there be sort of an open you know system where you know even let's say your your twitter your oh and maybe one or two other ids kind of can link to the same smart account as well? um and how would that also change? and so we um you know for us we we're more. you know thinking through these things practically if you're going to change your signer then you're probably going to change on all chains um and if there is a more sophisticated user they will know how to do it on chain by chain basis if they really like to

Nicholas: right right. um i i. i don't know if you're deep in the trenches of the details but it is interesting to me. i'm curious how it actually works that you can make one signature and then that can end up causing transactions on multiple chains. normally transactions maybe not in the user op context but a typical signature of a regular old eoa transaction is chain specific.

Ahmed Al-Balaghi: um.

Nicholas: so i i'm a little curious about the technical details of how that works. i don't know if you're in the trenches on that one.

Ahmed Al-Balaghi: yeah i'm i'm gonna after this call. i'm gonna tell sachin who was meant to be here as well and tell him that hey there were. there were really good questions by nicholas. um you would have been the best person to answer. um no i'm unfortunately not in the trenches. um i am more of a user and more of a collaborator in the ideas on all these things. um and so yeah um i mean i think that's something that uh if you'd like we could get a snippet from sachin to answer this and we could include it.

Nicholas: yeah great okay let's try and do that. and in any case there is a blog post about this on the biconomy blog. so if anyone's listening let's check it out. i think there are some details there. uh i know we only have you for a limited amount of time so let's do a little lightning round and run through a bunch of the other things that you're working on. so we talked a little bit about multi-chain. i don't know if there's anything else to discuss there but um that does seem to be like i don't know. people people keep throwing around this number of like a thousand evm chains. i i wonder if there's any thoughts you have on like is is is the reality of smart accounts going to be that people are interacting on multiple chains and that gets abstracted in the ux? or uh is the future more like for regular folks at least apps you know app chains and apps that are going to be abstracted in the ux or is the future more like sort of completely paper over it? but the prime primary interactions are uh like reside on a single chain. i don't know if you have any thoughts on this multi-chain future as it intersects with smart accounts.

Ahmed Al-Balaghi: yeah no no very good question. ultimately um and and this is even something that comes with like. you know things like intense. right i remember i was um uh i was in a flashbots. um they do these like whiteboard sessions whenever they're in different cities. and uh i had no idea. and they and someone asked how do you define intense? i'm just like and again this is the first time i'm hearing about this concept right and it became you know it was becoming a trend. and then i just thought to myself and i said on intense just something that the the application developer or owner would um would essentially prescribe or offer to the user because they know their user like and and and for some of them like they were like oh okay i'm just thinking like and. and then only i realized afterwards that intense had a very different definition. um and and i i but i still hold true to that belief right like if you think about web 2 applications like tiktok they own everything right like if they are on a chain the user would not care what that would they would absolutely not care whatsoever.

Nicholas: and so like knowing if you're on azure or aws?

Ahmed Al-Balaghi: yeah nobody exactly nobody knows and the user shouldn't know. and they wouldn't care. and and um and there is definitely an uh an interesting argument and probably some middleware. um you know software or even a startup idea on its own. where can an app that becomes so scalable you know like tiktok or otherwise where they could like you know um be able to have execution environments on maybe two or three different chains at the same time? and how would that look like? right? um i don't have an answer to that. it's just more of a concept if it um but ultimately it's it's. uh if there is going to be an app chain where an app is as successful as as tiktok for example no one's going to care and those who would care would find a way to. you know um go across different chains and um and and i think you know we if we go back to how website how we kind like if we believe and take the assumption websites can become like roll-ups and layer twos um and and essentially i think that's the thing. that's the thing that i think apps in of itself then uh the way that apps and you know um websites sort of connect today. right they could seamlessly connect in in in a you know in an app chain future. and so um if you it's like how we have like zapier like integrations or how one app kind of can integrate another app. but the difference with web3 is um a you could have portability across your accounts and b there are actual assets right um uh that the user can um uh um can have within that account and that's powerful. we haven't had a contract like this right um. and so i i would say that you know future it's not that it's it's it's blurry. it's more that because as mankind we haven't been exposed to this. it will be interesting to see how um we actually um adopt it because sometimes you know we don't always adopt technology as as how it's meant to be. um. so yeah so sorry i kind of gave more of a philosophical answer but that's um that that's how i kind of think on these things.

Nicholas: i think i agree with you. i i sense a bifurcation between um applications that are attempting to be more multi-chain and a bit they may not know it but in my perspective more prosumer versus applications that are really for consumers where the the fact of a multiplicity of available chains is not exposed to the user in any way. but i think probably you know you see this coming up with people like um agglomerating uh eth across different chains into a single asset listing in a wallet for example which i think makes a lot of sense. but i think probably most people don't even need to know that they shouldn't have to think about they shouldn't have to think about the fact of multiple chains existing. they're there for an application. so i think this uh the adoption of smart accounts as uh like a next gen wallets. so many of the teams are working at creating new wallets that are as complex as wallets but maybe with a better ux in some dimensions. but really there's this whole other domain that's very little explored that is just apps that don't treat themselves as wallets. they treat themselves as apps. they may have wallets inside of them but they don't think of themselves as wallets and they don't present themselves that way to users.

Ahmed Al-Balaghi: yeah yeah exactly and this is why you know embedded wallets. um has become you know quite a uh a trend and you know a huge use case right in the past year as we've seen.

Nicholas: yeah absolutely all right let's continue our. so uh we haven't even talked about it but we alluded to a little bit paymasters. um yeah i don't know if there's anything you want to say about paymasters as something that you offer. i. my specific question is which transactions should an app dev subsidize?

Ahmed Al-Balaghi: very good question. um. so paymasters. um all right to answer your question before we we go a bit more general. uh overview on that. so again uh it's it's going to depend on the app.

Nicholas: i know i'm of course going

Ahmed Al-Balaghi: back to that but but for example right like the sandbox one of our customers they subsidize the first 10 transactions for their users and then post that um they allow their users to um pay gas in their token

Nicholas: and those are only transactions on against their contracts.

Ahmed Al-Balaghi: of course yes exactly it's on their contracts right. um now of course because account extraction isn't enshrined. at the moment therefore there has to be a deployment of of the wallet itself. so we are seeing lots of apps even wallets that we're working with um they will just limit the gas sponsorship to you know deploying the wallet right like that gas transaction cost um we're seeing um some. so of course like for us at by economy we have um uh features around sort of like whitelisting of contracts where they kind of to whitelist certain um you know addresses um or certain transactions for certain addresses right because they might hold an nft or they might you know um you know be a user that that they know and therefore they do want to sponsor um all of their transactions maybe or partial transactions as well. we have webhooks as well. we have other forms of like gas policies and limits to that we're. we're going to be expanding in the future and so um they're you know. the great thing about like paymasters is that it can be very configurable um and it's very much dependent on on the app and its use case. we are working with a huge you know enterprise. they are actually going to be doing a a big poc next week. they're going to be launching that and we're going to be a part of it and paymasters may or may not be involved. that's all i can say. but you know for enterprise you know it makes a ton of sense. for paymasters you know where gas sponsorship is there because they don't want their middle office managers. or you know the the the traders or um the wealth manager people or whoever it is right to. um you know care about gas. um they will always think of this as a way to uh software that is a means and not an end and therefore you know the issue. these things should just be abstracted away. um the the one thing about paymasters i would say apart from the sponsorship is we have still not yet seen to date a very big and successful implementation of where users are able to pay gas.

Nicholas: in any other token we have not hit that tipping point even with all the in the last wave all the gas tokens that were out there still i mean i think like even one inch and people like pretty popular applications were doing gas tokens. but even though paymasters is probably a much more elegant way of doing it um not significant uptake yet nothing.

Ahmed Al-Balaghi: and so yeah i we we are we know that there will be this huge wallet that would come online with account abstraction in in the uh. uh short to near-term future. and um you know the the concept of basically enabling gas to enabling any um any token to be useful gas to become a reality. and again it will be interesting to see how user behavior will will shift. um will it shift? will it not? it remains to be seen. but it's finally. it's something that apps could actually now offer. um and and wallets can now offer because of of paymasters.

Nicholas: it seems like it'll be relevant for all of these stable coin like hedge against inflation specific applications. but it's interesting because there's a bit of a tension between like letting the user pay usdc or die or usdt or whatever for the gas on their l2 where they're um stable coin wallet lives versus just abstracting that away completely like yeah yeah you may still pay for it in some way or maybe you just charge them fees. it's interesting to think about as an app developer if you think about the sponsorship path as you kind of you don't want to be sibbled you don't want to be manipulated by malicious actors to abuse your sponsorship but you also don't want to be so. i mean relatively especially on an l2 depending on the transaction and how long it takes to be written to l1. um you know it's not bad not not you know. compared to other kinds of server costs it's not extreme if you're careful either. so it's uh. to me the the question is like do you consider it a consumer acquisition cost and you take it out of the? i don't know. let's say vc that you've received and just invest? or do you try to make sure that every time that you're sponsoring a transaction it's a net profitable trend or at least break even for you? um and it seems to me like there will be a lot of people who will end up sponsoring a ton of transactions at the same time. they may end up creating products that actually if the transactions themselves are not generating equal or more revenue then they're costing you that it's not really sustainable.

Ahmed Al-Balaghi: yeah exactly exactly. and we're going to see a huge ton of campaigns like right like um quest platforms still have not gone into that realm of enabling like gas. we haven't seen ads as gas right like. we know how big the ad industry is in web 2. um gas could easily be um not a substitute but like an awesome compliment for adding you know to um you know add business revenue. uh because in web 3 you could easily sponsor gas. um for advertisement.

Nicholas: why not right true enough? yeah you can imagine just hitting a transaction off a youtube ad or an instagram ad and hitting the button and it triggering a transaction creating a smart account. all right let's continue our lightning round bundlers. how should devs think about bundlers? is it a service that you pay for separately or is it something that you essentially get for free? how do you work from the perspective?

Ahmed Al-Balaghi: yeah no really really good question. um. so the great thing about bundlers is is it it? the stickiness there isn't as strong as maybe paymaster or the smart account. you can literally swap one endpoint for the other. but typically what we've seen is you know if a developer really likes the experience um why would they need to switch unless it's really expensive? um we've seen um different ways of bundlers being implemented and being priced. um there are you know sas-based fees are basically per transaction fees that we're seeing. we are at the moment um not charging um in sort of a sas-based model. we are more relying on the pre-verification gas that sort of exists um in the whole 437 cell because a bundler needs to kind of you know overestimate gas a bit for the transaction to go through and there is always going to be leftover gas right and so um typically that could easily be nested out at zero. but what lots of bundlers are doing is essentially you know what we're going to apply five percent you know premium or 20 premium and we'll just get revenue from that. so essentially who's paying this cost? it's a gas payer. now it's either the paymaster or it's either the end user right.

Nicholas: is there a reason why like zero devs approach to aggregating all the different bundlers doesn't make sense?

Ahmed Al-Balaghi: oh i think it makes sense.

Nicholas: as a developer i want i might as well propagate the user ops to as many bundlers as possible and then once they're on chain they're going to be able to do that. so i think that's across the rest of the bundlers right. there's no no consequence to even sending them to multiple.

Ahmed Al-Balaghi: so it would be the case that um at that moment of time. um they would maybe pick that preferred bundler at that moment of time.

Nicholas: okay okay so they choose and they don't send it to everybody. is there like an mev dimension here that people need to start thinking about?

Ahmed Al-Balaghi: so there could be um and this is why there's been. you know this is why there's been this. uh like a lot of talk around builders can become bundlers because for a builder to run a bundle is very simple um they just need to get the user ops and and uh essentially do what they need to do as a builder. um again it's still too early. um we uh we haven't seen the same influx of user ops of course like as as normal transactions that are on chain and so until there actually exists mev then we wouldn't really know 100% how that would look like. like because you know builders will just like run up wherever the opportunity comes in. right um and yeah and even for um you know the work we're doing with these platforms. we're also just you know trying to see like you know can we protect mev? will there be you know insane mev that we need to like figure out how we deal with it? um so yeah it's still. it's definitely like still in research mode as as these customers are coming live speaking of builders um will will do you think l2 sequence?

Nicholas: i feel like these l2 sequencers or the l2 operators who are you know de facto the sequencers for the centralized sequencing chains that are the norm today. it feels to me like they should really start subsidizing transactions for apps that they want on their platforms. uh do you think that these l2 sequencers are going to start? uh subsidizing transactions? uh the same way that i don't know. if you sign up for like github for education you get a bunch of aws credits. uh do you think that'll happen to attract apps? or maybe it's already happening?

Ahmed Al-Balaghi: so it's kind of happening in the making i'll tell you who's doing it. so base have just like launched their own sponsorship paymaster um which they which they are essentially partnering with info companies for for them to support. um. and why do they want to do? that is literally the same reason. it is is literally the reason that you you mentioned. it's because they want to kickstart apps on base. they want to maybe support the apps that they like. um but that's more from a foundation where there's a paymaster contract as opposed to a sequencer. um now if we were to think about the sequencer or you know we know all these sequences are centralized. um you know it's all fifo based and we are still yet to. you know wait for uh we're still yet to see. sorry you know how these sequences will actually operate um in the open.

Nicholas: if decentralized sequencing happens you mean exactly yeah yeah um how would you know?

Ahmed Al-Balaghi: decentralized sequencing sequencing operate in um in the open and that's still not there right and so and and once that's there they probably wouldn't care about the stuff that's happening above the stack. right they just want to sort of you know do the transaction processing? they they would do and then go from there. um and and so yeah and so we. we have seen in the past as well where of course foundations of these chains and l2s would come in and say um hey like if you'll come to our chain here's some like gas. um in the form of the native token we'll just give give it to you under the table and you guys you know sponsor fees for your users but through a paymaster it's kind of more. um. yeah it's it's kind of more. uh um open it's it's transparent um it's accounting wise it's way simpler as well um and yeah so i would i would see it more at that level as opposed to the sequencer.

Nicholas: okay because it seems like there's maybe some convergence in a centralized sequencing model between paymasters and the sequencing. but you're saying if we end up going the route and some people say it's more of a centralized sequencing model. say centralized sequencing isn't a problem because you have the trapdoor you have all these other fraud proofs and stuff. so it should be okay although i think i'm more frankly convinced by the opposite the reputation to that which is yes but what? how painful is it to actually use the trapdoor on l1 and how high is the bar of the me like negative mev the negative ev on your l2 transaction that you have to go to the l1 trapdoor? and has anyone even ever done it before it's not here? or if someone's dumping frentech keys and blocking censoring your transactions to do the same on base uh what are you going to do? go to the l1 trapdoor and in order to you know there's a lot of the centralized sequencing. uh is maybe not totally airtight at least as far as i've understood it. but it does seem like if we do end up staying in the centralized path that maybe paymasters and even maybe bundlers all sort of flatten into the sequencing because it's just why why not do it all in the same place? but it sounds like it's basically just not settled yet.

Ahmed Al-Balaghi: yeah no i mean and again if you think about it this who's running that sequencer? right it's the foundation. so if the foundation is kind of doing all of these things and it just becomes this monolithic centralized actor that it just doesn't make sense right where? what's the point of of us building what we're building right just generally in web 3?

Nicholas: right absolutely so. uh. last topic is signers. we didn't really talk too much about it. um are you a passkey maxi or what do you think will be the most popular kind of? uh next gen signer for smart accounts?

Ahmed Al-Balaghi: yeah good good question. i would definitely say it's it's eating up some of our heads at the moment. only because only because it's the case that all right you have a. of course you have the typical ecsa um verification um signer. um you have the npcs um that you know there are so many to talk about and there's so many that that exist. you have the path keys one that you know. um that relies on a different curve um. so and then we ask ourselves okay what's next? can there be other you know signature types um of or where where a signer come in and it would you know enable you know a different um form for for users to sign? and so for us we are i would say you know along with everyone else um who who are also providing you know smart account services. um is essentially working with um. you know the most reliable signers um which may or may not have a ui. um. what i mean by that? those who have the ui are like you know privy or web3 auth or capsule. those who don't have a ui are those like um. uh silence labs maybe dfns and so. and what's great is that working with all these different partners um kind of learn about. you know different approaches as well. although they you know the end result is still the same. you still have that one sign out right for for the small account um. and so you know. what's interesting that we're also thinking about is how can you know we we talked a bit about session keys and and session keys. you know within it you know that there there are keys that need to be stored and then so we're also thinking about how can we maybe um decentralize the security of and the storage of of these keys um right so that they uh when they are used for you know these permissions that we talked about before. we know that they're being done in the most so secure way um so we're kind of i would say thinking along those lines um as well and

Nicholas: more mpc type direction

Ahmed Al-Balaghi: yeah so mpc direction for session keys um uh along with like how we built as a module um and then of course utilizing just the different types of mpc that currently exist for how users could onboard.

Nicholas: the problem is that with all these mpc providers you end up introducing a whole new network as a dependency. and i find it's it's like it's it's it's it's it's it's it's it's it's it's it's it's. it's like we can sort of pretend like it's not an issue but it's it's like as bad as having a a side chain as a dependency for access to the wallets. it seems like very very scary to me. but um it does add lots of convenient features and people seem to for some reason think that uh these networks are legitimate and and their uptime won't be a problem. but it seems a bit scary to me to have access to your. i. my my personal perspective is you should be able to sign a transaction offline and all the mpc uh although i have heard of something. so maybe some future guests will have some some news on those ideas.

Ahmed Al-Balaghi: um eip 7212 yay or nay um yay with a side note of my devs are best to talk about it.

Nicholas: okay got it got it yes um. and then uh closing things out how big is the team? how many people work?

Ahmed Al-Balaghi: uh at biconomy we're now 33 people at the team.

Nicholas: wow that's impressive. and sorry 34 and mostly remote mostly remote.

Ahmed Al-Balaghi: so we're now 33 people at the team and we're now 33 people at the team. we have um six people in dubai and um we have yeah six people in dubai and the rest um is remote mainly spread across um uh india and europe interesting.

Nicholas: um what is the uh dev scene the builder scene like in dubai?

Ahmed Al-Balaghi: oh it's it's amazing um. so i would say pre-covid pre-covid it was terrible it was just like full of you know more. i would say the scene was more. you know amy vibes as opposed to now which you know. there are legitimate builders. you know real teams real developers. um. so i would say you know i would say the binance arbitrage of them coming to dubai has helped because they actually brought quite a few developers to dubai. and so what that means is people. you know of course people leave other companies and so you have the developers who are based here that would leave and joined. you know companies are based here as well that are still operating and went through and so the community is i would say at you know like even during the spare market. it's been at you know the most vibrant i've ever seen to be honest um it's still not like new york or london in terms of the amount of devs you know or the let's say the the gigabrain activity you might expect um but it's it is there if you know where to find it

Nicholas: awesome. and uh to close things out what motivates you to be involved in crypto in the first place?

Ahmed Al-Balaghi: when i first learned about bitcoin i realized that bitcoin taught me more about economics than my economics degree. and uh i would say that was that initial spark. and then what really led me to um stay was the the aspects of like digital economies and that and the fact that in the future we will live in you know a world that will be run by digital economies that anyone could just you know build and i think that's just super powerful. um there's no point in history where you could build your own economy and it's up to you to decide. it's up to you and your efforts if that economy will succeed or not. right and that's what crypto is all about.

Nicholas: absolutely. where should people uh go if they want to learn more about you? and about by economy?

Ahmed Al-Balaghi: so you can uh go to by bycommy.io. um and yeah my twitter is at uh a r a b a l a d h i. um that's the best place to find me and yeah happy to always chat about smart accounts account abstraction and just how on chain ux will evolve.

Nicholas: awesome i'll put links to those in the show notes. ahmed thank you so much for coming through and talking. this was a great conversation awesome.

Ahmed Al-Balaghi: thanks a lot nick really appreciate it.

Nicholas: all right talk soon. thanks everybody for listening. see you later. hey thanks for listening to this episode of web3 galaxy brain. to keep up with everything web3 follow me on twitter at nicholas with four leading ends. you can find links to the topics discussed on today's episode in the show notes. podcast feed links are available at web3 galaxy brain.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.