Web3 Galaxy Brain 🌌🧠

Nicholas: Before we get started, I want to encourage you to listen to Web3 Galaxy Brain at whatever playback speed you prefer. If you love this episode, please write a review for the show. Thank you. Welcome to Web3 Galaxy Brain. My name is Nicholas. Each week, I sit down with some of the brightest people building Web3 to talk about what they're working on right now. My guests today are Himanshu Rattarakar and Jebu Ittyachin, two of the three co-founders of Obvious. Obvious is a smart wallet company with three products. The Obvious Wallet is a multi-chain 4-3-7 account abstraction smart wallet that was among the earliest full-featured AA consumer products on the market. Obvious Embed is an AA wallet that third-party devs can integrate into their own dApps. Obvious Money is a stable coin-focused smart wallet app aimed at emerging markets in Africa and South America. On this episode, we discuss the team's path from building a traditional EOA software wallet to account abstraction smart wallets. We get into the trade-offs of Shamir, MPC, and Passkeys, and the challenges building smart wallets in a massively multi-chain world. We also talk about fiat money platform incumbents like M-Pesa, India's unified payments interface, IBAN, and how crypto fits into the mix. It was a pleasure chatting with Himanshu and Jebu, who are moving quickly at the intersection of cutting-edge smart wallet tech and global consumer applications. 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. All right, Himanshu, Jebu, welcome to the show. Thanks for coming to talk about Obvious.

Jebu Ittiachen: Hey, thanks a lot for inviting us, having us over.

Himanshu Retarekar: Thanks a lot for having us, Nicholas.

Nicholas: Yeah, absolutely. I'm excited to talk. So maybe just to start off. for people who don't know what Obvious is, could you just explain quickly what you get up to in general?

Jebu Ittiachen: Sure, I can do that. So Obvious started off as an EOA wallet. The intent with which we started off was to solve and make it easy for users to do transactions on Web3. Soon we realized the sort of ways we can make it easier for a user goes beyond transactions, for example, seed phrases, abstracting that out, abstracting out chains, etc. So Obvious evolved in May 2023 to be one of the earliest and leading account abstraction wallets. And we are really excited. Over the last eight months, we've managed to have over 20,000 users use our platform, our app, have over $16 million in AUM, over $250,000 transacted on our platform. And we are incredibly excited about this new direction we are headed in.

Nicholas: Awesome. So maybe, yeah, could you each describe what your role is and how you got involved in first? And maybe Himanshu, you can go first.

Himanshu Retarekar: Sure.

Jebu Ittiachen: Hey, so I am a co-founder and CEO at Obvious. But to be very honest, all of us sort of dabble in different things. It's a very small team. We are a team of 10 people. So of course, folks wear different hats. My journey in crypto started three years back, thanks to Jebu. He was the one who introduced me to crypto. It started with sort of dabbling in new protocols, participating in their governance, and then sort of taking small positions. And off late, it has been mostly just sort of trying out different chains, different protocols, and more importantly, sort of stable coins and a lot of things around on ramp, off ramp and things like that.

Nicholas: Got it. Awesome. And Jebu, how did you get involved in first place?

Himanshu Retarekar: Oh, yeah. So my role here in Obvious, I'm co-founder and CEO here. As to how I got involved in crypto, being always interested in crypto as a story, right? So since the early days, being interested in what Bitcoin was up to when Ethereum came around, what they were being doing, but never got around the fact how it's going to scale, the fact that the program of money is all great, but how do you make that operate as well? It was never, I couldn't really wrap my head around it. With Bitcoin doing 10 minute blocks in Ethereum, a little better during that time. During the COVID downtime is when I think I started looking back at it again. That kind of time is when I think BSC, Polygon chains were starting to get around. That at least gave us the ability to kind of maybe interact with these chains and Ethereum as a concept. Touch and feel it because gas was not that high. You could do transactions in there. So tried a lot of things around that kind of time. Then slowly the concept of L2s and the scaling story of Ethereum started forming around. That's when things started getting very interesting. So decided to jump into it. Then otherwise finance has always been of interest to Himanshu and myself. And we got Pradeep also on board. And the three of us then started looking at, if we're going to get down into crypto, what is it that we do? And what is the biggest thing that we could probably go behind? I think one thing was very clear that interface that you have, wallets is where you get into crypto. And that was badly broken for somebody who's coming in fresh. As an outsider, you try to give them a wallet interface. And that it's pretty hard for people to wrap their head around what is going on. So that's probably one of the reasons that we said, okay, let's get in and see if we can do something on this space. That's also the reason why we got in and said, okay, multi-chain wallets is a concept. How do we show the balances across all these? Switching of networks was really not making sense at all. So said, okay, let's segregate the balance on one place and give the ability to do transactions, easily move funds around from one chain to the other, easily swap assets from one to the other, all of that in one place. That's kind of how we got started with the obvious wallet itself. And then along the way, smart contract wallets came in, 4337 came in. We said, okay, I think probably that gives us another opportunity to even cut down the experience story of wallets and make that even better. So that's how we got on board with the 4337 wallet, smart contract wallet as a vehicle. And then became probably one of the first wallets to have fully embedded, full-fledged support for 4337.

Nicholas: That's awesome. So maybe could you describe what the app experience is like today for creating one of these 4337 wallets? If a user were to download the app on, it's on both iOS and Android, right?

Himanshu Retarekar: That's correct. Yeah, the app experience, we want to create 4337 wallet. It's pretty straightforward because you come in, you say you want to create a wallet, what it creates for you is a 4337 wallet. It doesn't, it underneath, there is a UA signup, but we kind of hide that away from you. And what you get is a 4337 compatible wallet.

Nicholas: So when I opened the app for the first time, do I create an account with an email or SSO? or how do I generate the account? Or is it just automatically made when I opened the app the first time?

Himanshu Retarekar: It's automatically generated when you open up for the first time. It gives you an option to either restore with a seed phrase or create a new wallet. If you create a new wallet, we underneath create a signup, which is a seed phrase backed one. And we give you the ability to kind of save away the seed phrase using something that we call a seedless backup. And that wallet is there behind the scenes for you. But what we expose to you is the derived 4337 wallet.

Nicholas: Interesting. So how come, and I have some idea why you might be doing this, but what's the, I mean, sort of the idea of AA is to maybe get away from having EOAs in the first place. So if you previously were making an EOA wallet, what drove you to switch over to doing AA wallets? And in doing that, why did you retain the EOA signer under the hood?

Himanshu Retarekar: Probably a couple of things, right? So I think gas was one of the first things that we wanted to take away. The ability to do gasless transactions or pay in any token is something that really made sense with EOA, with a smart contract wallet. So that's something that we could get done. We ideally wanted to get away from. seed phrase and social login is something that we are coming up and it's going to be there in one of the versions, which probably in the new direction that we're talking about, we can talk about that too. But as a first step in the early days of what we had, it's kind of saying it makes sense to give an easy start with abstracting away the EOA and give you the experience of what a wallet could do.

Nicholas: And you retain the EOA signer because it's, I guess, the primary way to administer an EOA wallet is still to have one like an EOA at the end of the day.

Himanshu Retarekar: That's correct. And you can go into the settings of the app and then it will expose the EOA wallet for you and you can interact with the EOA wallet.

Nicholas: So I want to jump into some real details, technical stuff here. But first, I think maybe it's useful if we get like an overview of the company and the products. From what I understand, there's three main products, right? There's this obvious wallet. There's the embedded product for allowing other people like third party developers to use to build an obvious wallet into their PWAs or apps. And there's obvious money. Is that a good overview of the company? Maybe you could describe what each one is about.

Jebu Ittiachen: Hey, I can take that. So that's perfectly correct. So we started off with the obvious wallet, as Jaimu mentioned. That's the account abstraction wallet. For the first six months, we sort of managed to build a good presence online where we've sort of distributed the app directly to the end consumer. But along the way, especially after account abstraction came into the picture, we realized a lot of dApps out there really want to make the experience seamless,

Himanshu Retarekar: really easy

Jebu Ittiachen: for their end users, where at the end of the day, they want to abstract out gas, they want to provide a simple sign in with Google kind of an option to the end user. They want to be able to submit batch transactions, etc. So hence, we came up with a way to experience the obvious wallet, but inside the context of a dApp. That was also a way for us to sort of make ourselves available on desktop because we started off as a mobile app product only. So we are very early in the obvious embed journey. We are piloting our product with a few early customers. And the third product that that's the new direction we're taking is obvious money, which is digital dollar banking for certain pre or early emerging economies such as Africa, Argentina, Turkey, etc.

Nicholas: So I'm curious, I guess, what we're talking about is kind of a spectrum of crypto nativeness for the product. So like an AA wallet, even with a EOA signer, an app that gives you access to the EOA wallet is, I guess, fairly crypto native. And this new product money is maybe for people who really just want a way to transact stable coins and maybe don't care to learn as much about crypto.

Jebu Ittiachen: That's correct. That's a very fair way of putting it. It's at the end of the day, we want. it's a spectrum of how savvy you are with crypto. We started off with the extremely savvy user, which is sort of trying to make their lives convenient. And we overall, you could sum up the journey of obvious being as moving from the savvy Web3 native to early to Web3 to someone who just sort of looks at the utilitarian aspects of crypto.

Nicholas: So maybe for that money product, what do you imagine the experience? Is it available now?

Jebu Ittiachen: It's not available. It's in development. It should be available in a couple of months. Experience is we are essentially trying to abstract out as much as we can. So for example, abstract out the volatility of crypto itself, right? One of the things about crypto is, it's volatile. What we wanted to singularly focus on, essentially was the ability to retain the worth or the value of your money, right? Essentially, that's the biggest problem that some of these users are facing in countries which have extremely high inflation, right? Which is, even if their money is lying idle, they are losing the worth of their money, just lying idle. And what they really seek is access to stable currencies like euro and dollars. So that's predominantly what we're looking to do, which is essentially give them access to stable currencies like euro and dollars underlying using crypto and stablecoin rails, and singularly focusing on making sure that they are able to preserve the value of their money.

Nicholas: That's interesting. So it's even more about preserving value in a stablecoin in a context of inflation, rather than even transmitting it or, you know, sending it across country borders or anything like that.

Jebu Ittiachen: That's correct. I mean, but once you start preserving it, and once you start doing a good job at preserving the value, of course, our job is to make it ubiquitous in your daily lives. And to that effect, the idea would be to then supplement it with like a debit card, making it seamless to send your money, be able at least having the ability to send your money to anyone using just a phone number, etc. So we're trying to add those as sort of the peripheral features, but with a singular focus on preserving value of your money.

Nicholas: Makes sense. Do you imagine that the users of this have? I know, I spoke years ago with people from MasterCard, I think it was, and they were telling me that their greatest competitor is not Visa, but cash, and actually the unbanked are the biggest population that they would like to address. Do you imagine that the users for this money product already have a bank account and are able to, like, as you say, send from a debit card or transfer from a bank account? Or can you imagine people even getting on board who don't have a traditional bank account?

Jebu Ittiachen: I think it'll be, to be very honest, I think it'll be easier for users who have a bank account to get on boarded there. We see if you look at the people who are unbanked, right, probably you can say a large chunk of it is just folks who don't have enough money as an incentive to for them to bank realistically. For the other half, yes, this is a solution. But the earliest segment of users that we are going to sort of going after is folks who are banked today, but are looking at banking in a way where they can preserve the worth of their money, which is a digital dollar banking.

Nicholas: In these contexts of hyperinflation, is it complicated to do KYC? Or are there restrictions because the countries are concerned about capital flight? Do you have any sense?

Jebu Ittiachen: Being a non-custodial wallet, that's one advantage of being a non-custodial wallet, which is, we don't have, there aren't regulations today around mandatory KYCs as and when that does come up, and depends on the region that when it comes up, we will be complying with those regulations. But to be very honest, KYC is not that big of a problem. The users are totally comfortable doing that.

Nicholas: Right. I guess if they can get a money product that gives them some serious advantage, then it's worth it. And it's no more onerous than maybe even quite a bit less onerous than signing up for a credit card or something like that, where there needs to be a credit check on top of just getting your driver's license or passport.

Jebu Ittiachen: That's correct. Besides, credit card sort of almost just solves one particular aspect, which is the ability to spend using your funds, but just the ability to save it and not lose your worth itself is a big boon for these guys. Right. You have to understand it's a flight for survival for most of these guys.

Nicholas: So yeah, that's right. Is that something that's relevant in the Indian context domestically for you as well? Or it's something that you're really looking at other markets outside of your local market to deliver this product?

Jebu Ittiachen: That's a very interesting question. Not really, it's not relevant in the Indian context. We don't have as high an inflation in India. From that standpoint, it's not. Where it is in some ways. similar is just how advanced users are, the banking ecosystems in India is. So we have a very good sense that gives us a very good perspective on how to solve the challenges with respect to banking. And that helps us leverage that knowledge and apply it to certain markets outside India. Besides, the other good point is users in these markets are also used to sort of advanced banking. Africa, a lot of people might believe otherwise, but has really advanced banking solutions. So it helps us sort of offer these kinds of solutions built on cutting edge technology like crypto and stable coin rails. And for the users to not have that big a hurdle to adopt them.

Nicholas: Yeah, for people who aren't so familiar, I'm only superficially aware of things like M-Pesa. What is the kind of state of the art for money transferring and holding assets in Africa, for example, right now? Obviously, Africa is a big place, but maybe the more advanced parts.

Jebu Ittiachen: So M-Pesa, mobile banking, right? At the end of the day, if you look at it's basically something like India, right? Where at the end of the day, a merchant just puts up a QR code, the customer just scans it. And the money is sort of instantly wired to the end user's bank account. That's how advanced it is in Africa as well.

Nicholas: So maybe people have played with WeChat, WeChat Pay kind of experience. It's something similar?

Jebu Ittiachen: Yep. Yep.

Himanshu Retarekar: If I may add, Nikhil, something similar, but I think there's a bit of difference between what the M-Pesa ecosystem is and what a UPI kind of ecosystem is here in India. M-Pesa is more of a closed wallet or a prepaid wallet where money moves around from account to account in the wallet ecosystem itself. Whereas something like UPI, it's a direct bank to bank transfer that happens instantaneously. Something like a FedWire in the US, I think, where money moves from one bank account to the other instantly. So that's probably the biggest difference between what an M-Pesa system does and what a UPI kind of system does.

Nicholas: And UPI, for people who don't know, is this Unified Payments Interface. It's quite new in India, right?

Himanshu Retarekar: Oh, no, it's been around for five years now.

Nicholas: Okay, five years. Long time. Yeah. So, okay. So Unified Payment Interface, UPI is more like a debit transaction, interact transactions in Canada where I am. And I guess M-Pesa is more something like Venmo, where you have a balance inside a corporate app.

Himanshu Retarekar: Exactly. That's correct.

Nicholas: So do you think this is kind of, I guess, it's somewhere in between. You have some of the best of both worlds. what you're proposing with this money product, right? Because you have kind of the standardization of being on a, ideally, decentralized blockchain. But at the same time, the feeling of the app can feel as slick as something like an in-app transaction. Although maybe UPI feels that good too.

Himanshu Retarekar: Yeah, exactly. Plus one more plus point, which is the self-custody aspect of the entire crypto ecosystem.

Nicholas: Right. Very cool. I'm curious. So the company is based in Bangalore, or at least some of the team is. Is that right?

Jebu Ittiachen: The company is a corporate in Delaware, USA. The team is based out of Bangalore.

Himanshu Retarekar: Yes, that's correct.

Nicholas: Very cool. I'm curious what it's like building a product like this in that context. Maybe for people who've never been to Bangalore, what's the feeling of the place? Is it like a lot of startup energy? Are people adopting crypto? What's the feeling of building this thing there?

Jebu Ittiachen: Oh, yeah, absolutely. They call Bangalore the Silicon Valley of the East. So yeah, absolutely. It's buzzing with energy. There are a lot of startups building out of Bangalore. Talent is readily available. A lot of crypto startups have emerged out of Bangalore, including something like a Polygon, etc. So access to information, access to capital, access to knowledge, access to talent is abundant. And it's a pretty good place to build out of because you're also always sort of closer to the cutting edge technology in finance and banking because pretty much all the big startups in India originate out of Bangalore. So absolutely, it's a great place to be running a startup from.

Nicholas: Polygon to me is like such an amazing success out of India. Is it perceived of as like a real hometown hero kind of product?

Jebu Ittiachen: Oh, yeah, absolutely. You should visit some of the meetups here. Absolutely. Those guys are legends. They're looked up to a lot and pretty much aspirational in every way possible.

Nicholas: Very cool. Yeah, I think to me, it's also sort of indicative of this thing that blockchains have unlocked where global talent that previously would have to either migrate to California or New York or work for some satellite office for a company based there to have global impact, in many cases, truly global impact, now can just stay at home and build the globally impactful products without relocating to the US or some other traditional Western tech hub. Is that kind of your experience of it also?

Jebu Ittiachen: Yes, absolutely true. So a lot of things have changed over the course of last 10 to 15 years. For example, the venture capital ecosystem has evolved a lot. The access to capital is a lot more, it's a lot easier than what it used to be. The sheer ability to be able to the press of buttons, sort of launch apps across any app store, right, for that matter, makes it really easy for you to sort of have presence. Even in fact, the ability to have, let's say a company incorporated in the US with a button click, click of a button, a bank account set up with a click of a button just allows us or anyone for that matter to really be global in nature. In Veptri, especially I've seen companies where there's no sense of a headquarter as such, where employees are like geographically and of course, that did accelerate a lot during COVID, where the employees are working out of India, Bali, Dubai, US, Europe, Africa, etc. So there's basically no limit or boundary in any sense.

Nicholas: Yeah, definitely. It's very, very cool, very exciting to be able to access all this global talent and ideas and see people succeed from all over the world. It's super inspirational and exciting. We talked about crypto cards a second ago about sort of the advantage of people having a card in order to be able to spend using traditional credit or debit rails. I know you have a crypto card product. Is that something that you think is relevant going forward? And how does that tap into the AA wallet?

Jebu Ittiachen: Jay, would you want to take that?

Himanshu Retarekar: Sure. So the entire story has always been how to make crypto more accessible, how to make crypto more relevant in real life. That's been probably the underlying thing in the entire story that we've been doing till now. And card essentially, what it does is to make crypto available in day to day life. Of course, you can do crypto payments one to one, but it always has a chicken and egg problem of when do merchants start accepting crypto and how do you make payments if the merchant is not available, even though I have crypto houses that somebody else starts putting. So that's where the card product comes in and then it simplifies up, solves the problem of the merchant network. So the ability to have a card which is powered on the wallet itself solves the entire problem of making crypto available in real life. To your question of how is it done on the wallet itself, the product of the crypto card itself is not fully out there in the market yet. It's because it unfortunately requires cyber bans and the ability to get bin sponsorship and all that stuff. It's a lengthy process. It's something that's going along.

Nicholas: Sounds complicated.

Himanshu Retarekar: Yes, it is. It's not like a self custody wallet where you can just have a seed phase and then start getting things moving. It's not as straightforward. You need a bin sponsor, you need a program sponsor, you need to get things going all across, even up to central bank approval to get even the card programs allowed. So there's a whole baggage of stuff to get done. But in the context of how do you power a self custody card, what happens is with an AI wallet, you get the ability to add modules into the wallet. A card module or a card essentially becomes a signer for a wallet which has limited capability. So you think of it as when you swipe a card, the Visa or the master network relays that card transaction to your backend, which then looks at whether there is enough balance in there, whether you want to authorize the transaction. And that point of time, this signer module which is added on into your wallet has the ability to move funds, the required amount of funds, always again going back, the funds are backed as stable coins. So USDC or USDT is probably what the card balance is going to be. So the required funds, if you say swipe for $10, 10 USDC is kind of moved out of your wallet and taken to Neskro. And then the approval is given and the end of the day settlement then moves the entire funds back and the settlement is done. So that's kind of how it fits into an AI. It's completely self custody. There is no centralized actor coming into play at all. It's completely from your wallet.

Nicholas: That's very cool. But it sounds complicated to have a credit card that acts as a signer. So I guess when someone swipes the card, it will send a message to like the credit rails will ping a server of yours, which will activate the like propagate a signer, a sign message to the very interesting. That's good. It's pretty ambitious. I guess. Do you know if like I was I saw also I was quite impressed that they managed to pull off like Gnosis Pay. Is that a similar kind of system?

Himanshu Retarekar: Something similar. Something similar. So Gnosis Pay is something exactly similar to what we are talking about. That's how the step also works.

Nicholas: It's very cool. It's kind of impressive that people would be able to, I guess, glue together the fiat system and crypto signing so effectively.

Himanshu Retarekar: And what's really interesting is something like Monarium that is there also, its partnership with Gnosis Pay, the entire stuff becomes really seamless, right? Because there's something like Monarium gives you is the ability to have an IBAN account, which kind of moves funds in and out. So it's like it's a bank account on the outside, but once the funds hit that IBAN, it's instantly converted into Euro and then Euro on chain. And the Euro on chain is what you have in your balance. So the entire stuff kind of abstracts away the fiat trails and everything happens in crypto.

Nicholas: Very cool. While we're on the topic, I'm curious, I've never done it myself, but how do you manage to do the paymaster piece where people can, or maybe it's not paymasters, but at least where you can spend a stablecoin to pay for the gas on whichever network you're located on to execute a transaction? How does the liquidation of a stablecoin for the gas coin work?

Himanshu Retarekar: So we use Biconomy underneath. So the infrastructure is powered by Biconomy. The Biconomy paymaster, what it does is when we do a transaction, when you create a user op, which contains a bunch of transactions, probably a single transaction or a bunch of transactions, which is there, we create the payload, which contains all the user ops. You do a gas estimation of how much is that going to come up to. It uses the Biconomy backend, then uses the on-chain exchanges to get a fee code. and how much would that translate to with the existing gas price. They do some amount of markup on top of it to account for the fluctuations. Then they upfront do the payment for that and do a batch conversion of the held funds into the native currency using on-chain exchanges.

Nicholas: Very cool. So basically, if people want to do that in general with AA Wallets, they can just rely on Biconomy and they charge a small fee, I assume, and it just works.

Himanshu Retarekar: That's correct. So a token paymaster, like what Biconomy does, is abstracts away that infrastructure for you. You use a token paymaster, they give you the ability to do all of this stuff. And we, in fact, with the obvious embed product, what that does is it's almost like embedding a wallet like what a RainbowKit or a ConnectKit does. You can easily embed a wallet and it gives that ability to choose. The dApp developer doesn't even have to worry about how to do a transaction with gas or something else. We give you the ability to select which gas token that you want and then send a transaction across.

Nicholas: Very cool. And if someone were to integrate the embed product when it is fully, or I forget if you said, is it available yet or it's coming?

Himanshu Retarekar: Not yet, it's coming.

Nicholas: So when it is available, if someone were to integrate it into their dApp, would people be logging in with like Apple ID or some other ID or email address or would they be logging in with Obvious?

Himanshu Retarekar: So you have a couple of options, right? You have the ability to connect your existing self-custody wallet like a MetaMask or a RainbowKit. You have the ability to connect your Obvious wallet directly into it. In this case, it is underneath a smart contract wallet. You have the ability to log in with Google. It's using a social app to kind of do a derivation from that and then do that.

Nicholas: So all these options And it will remain self-custodied?

Himanshu Retarekar: Yes, it is self-custody. The entire thing is self-custody.

Nicholas: So maybe we could jump in a little bit to how the self-custody piece works and how the Seedless Recovery works. So let's say I create this account. We talked about it a little bit already, but there's an EOA that's created in the background on the device. Maybe where does that live? How is it secure?

Himanshu Retarekar: So the EOA currently, when you create a smart contract wallet, it is generated on the. It's a standard 12-word seed phrase which is created, which underneath is giving you the entropy for creating the wallet. So that big number that we create underneath is what is giving you the 12-word seed phrase, right? So it's easier for you to read and kind of backup and restore in different wallets. We give you the option to either see the 12-word seed phrase, or you have the ability to do a seedless backup. In the seedless wallet backup, what we do is use that big number, which is a backing for the seed phrase. We kind of do a shammy sequence sharing on that. It's split into three pieces. It's a cryptographic technique which allows you to kind of restore that particular fact for using two of three pieces. So we split that piece into three pieces and three pieces are stored in three different places. One is on a local device. The second one is in a cloud account at the office. So you can sign into Google and place it on a Google Drive. And the third, you can share it with any of your friends, right? So and for you to restore when you want to restore it any place, you kind of get any of those two pieces and it reconstructs the seed phrase, which is the backing EOA wallet.

Nicholas: Very cool. So you're not hanging on to even one third of it. It's totally not in your custody. Interesting.

Himanshu Retarekar: Not at all in our custody.

Nicholas: If people are interested in this. on an episode a couple of weeks ago, I talked to Henri, the CEO of Privy, and they do something a little bit similar. But in their case, they keep two of the three. One of them is password encrypted and the other one they have full plaintext access to in order to do recovery. So in the obvious wallet, and this, I guess, applies to both the original product and the embed product. Is that right?

Himanshu Retarekar: That's correct. So in the embed product, you don't give the ability to kind of create a seed phrase wallet at that point of time. If you don't have a wallet, you have. the option is for you to do a social login and then kind of get that. In that case, it's covered by one of the social wallet login providers. But if you connect your obvious wallet, then of course, it is backed by the same seed phrase, seedless recovery portion.

Nicholas: When you say it's if you use a social account, that's like something like lit protocol or someone who's handling the SSO piece.

Himanshu Retarekar: Exactly. Exactly. A lit or a magic or one of those things.

Nicholas: And in that case, is it possible to have the Shamir setup or it's just a EOA on device?

Himanshu Retarekar: No, it's not because it's an EOA. Because then it uses whichever the third party provider for the social login. We don't give a social login access. We don't bootstrap that.

Nicholas: So in the case where I do log in with a social account, if I were to lose my device, I would lose my wallet. There's no way to do recovery.

Himanshu Retarekar: Depending upon who the provider is, for example, if you're using lit. Currently, we have gotten the embed working with a particle network. Particle network uses Google Autosign. And yeah, particle is similar to what a magic does. So you can use that. It's a Google login and you restore it with the same login again on a different device.

Nicholas: So the secret material is where? Because what you're saying is basically I could log out, lose my device and log in somewhere else and regain access to the account.

Himanshu Retarekar: Correct. In that case, the secret is controlled completely by particle network.

Nicholas: Okay. So because this is interesting, in talking to so many of the wallet providers, it seems like a lot of people are coming up with solutions where you need this EOA in the middle somewhere, even if you want to have some kind of social login or email or phone number to make it easy for people to onboard. But you also want to have a signer on an AA wallet. And it seems like an EOA is just the simplest way to go about that. So people often put something in the middle, like we're talking about particle or lit protocol, or you can just have an EOA on the device, or you can split it Shamir wise and store the shards wherever you choose. But in any case, you have some kind of EOA that's able to sign on the wall. So it sounds like you're still pretty committed to that kind of path.

Himanshu Retarekar: Yes, that is that's as far as we're doing right now. We also have been working on doing something with PASKY, which kind of takes away the entire dependency on the secret system. But that's something which is still nowhere near close to production yet.

Nicholas: Yeah. Okay. So I'm super interested in this. I don't know if you saw, but a few weeks ago, I also interviewed the authors, or one of the co-authors, Ullash from Clave of the EIP-7212, which is proposing to put the PASKY's elliptic curve, R1 curve directly as a precompile in the EVM, especially for L2s. If people are interested, they can go back and listen to that episode. But I was also looking yesterday at ThirdWeb's AA options for deploying 4337 wallets, and they have three different versions of it, which offer different levels of like upgradability, essentially. But in all cases, in the ThirdWeb contracts, at least, you need to have an admin of the account that has kind of full write access to the AA wallet. And then you can add additional signers, such as PASKY signers with like more limited access. But they always require this EOA wallet to be the admin of the wallet. Is that like a strict requirement of AA? Or is that something that will eventually get around with PASKY's?

Himanshu Retarekar: We should be able to get around with it. I think, unfortunately, the problem with today with PASKY's is that you cannot easily back it up and restore, right? If you lose the device. Today, iTunes and Google, of course, does sync it across devices, but it's still proprietary to what an Apple does and what Google does. There's no way to easily take it out and then restore it somewhere else. So in case you lose your device, in case you lose access to that particular account, there is no way to kind of get it back again. So that's unfortunately the case. And I think the problem with PASKY's alone is that there is, because it's a signer which is there on the account itself, right? So in the code, what you're looking at is, is this authorized? And there's this balance against as per the list of authorized signatories out there. So if you want to replace it or add a different signer, you need somebody to kind of authorize it. And probably the easiest way to do that today is within UA because UA is something that you can easily back up and restore and then kind of get access to it. If your PASKY is your unique admin account, which allows you to add a second signer and you lose access to that root signer, which is there, then unfortunately, that you lose access to that entire stuff. So you need some way to kind of say, how do I add additional people on top of it? It's also additionally complicated by, you know, if it is across different networks, for example, when your wallet is deployed today with Kreative, you have the ability to end the same address on all the different networks. Because the configuration of that wallet is on that particular network, on the deployed network only. So I might have an instance of the contract deployed with a certain PASKY which is authorized for it. But that same configuration is not in effect on other chains. It's not easy to kind of port it and make it make sure that it doesn't sync across all the various EVM networks on which the contract could be applied because it's not the code, it's the state of the code which says which are the authorized signatures. So that's the additional problem with this. Whereas in an UA, that is not the case because the UA tells you which is the actual account, which is an authorized sign. And that's true irrespective of which account you're going and deploying on, which network you're going in and acting on.

Nicholas: Totally. OK, so this problem you just mentioned, I think, is a huge problem that the configure the signer. So if you add additional signers, you need to add them on every single network where that wallet exists. Can you summarize what the first problem is that you were explaining?

Himanshu Retarekar: The first one that I was talking about is the ability to add. You were talking about adding an additional signer, right?

Nicholas: Yeah.

Himanshu Retarekar: So why do you need the UA and why is it that you can't have just a PASKY alone as a particular admin key? Why do you need an UA for that? It's easier for an UA to be restored in case you lose access. And the PASKY, if you lose access, you have to use a root PASKY.

Nicholas: Platform specific backup is the problem. So, right. Because, yes. So I have a couple questions about this. First of all, with the Shamir setup that you're doing, are you able to do key rotation or no? It's pretty much stuck with that Shamir.

Himanshu Retarekar: No, there is no key rotation. Because it's exactly the same. The same C-trace is restored all over the place. There's no key rotation. that Right.

Nicholas: So it is really an EOA that you have on, you know, excuse me, on device or, you know, in the synthesis between the device and the other shards. But then you have the AA wallet. So really, you're focusing on the AA wallet as an advantage for making it easier to do like, I see on the site, you describe it as like one click transactions, but mainly like a lot of the sort of ergonomic benefits for sending transactions rather than flexing any of the potential future advantages of signers.

Himanshu Retarekar: That's good. That's good. Probably, probably that's where you will see the thing morphing in an obvious money a bit because in obvious money, we are using and denying the AA wallet itself. The funds are held in an AA wallet, but the signer there in that case is something which is going to be powered by a signer, which is a social signer. It does not, it's not an EOA in that case.

Nicholas: Oh, wait, can you, sorry. So in the money product, it's going to be a social signer. And so there won't be an EOA. or what do you mean by that?

Himanshu Retarekar: There won't be an EOA. So for now, what we're looking at is covering that with the Lit Protocol, where the Lit Protocol is going to be, you will be able to log in with something like a phone number, and get access to a particular account derived from the phone number basis and have a passkey added on there so that you can authorize with the passkey to kind of get in and authorize transactions in it.

Nicholas: Okay, so relying on Lit's MPC and distributed key generation through their network. This is very interesting because I see several people who are considering using or are committed to using Lit or other options that do similar kinds of things. But essentially using like MPC in the middle with this DKG, the point being that there's. no, the EOA doesn't exist anywhere in particular, as long as I think it's two thirds of the Lit Protocol network agree to whatever their rules are, then you're able to sign. Well, actually, I'm curious, do you know much about how the Lit Protocol works? Because I haven't had them on the show yet. But I don't know exactly how that network functions. Do you have any insight into how it works?

Himanshu Retarekar: Probably I think it would be best for you to talk to them. What you described is the best it's in right. So it's it uses a key generation across, assume that they have a 10 node network across the 10 nodes, they have various shards of these particular key, and then they do a threshold signature across these. And they collect the various pieces from the nodes. And as long as you get two thirds of these, it finally reconstructs the signature at the end, and then it delays the transaction. That's in a gist, I think that's how it works. But it's best to talk to the Lit guys. I might be totally off.

Nicholas: Good, good. I'm gonna be scheduling them for a little bit later in the fall. So actually, you know, it's interesting, because when I need to clarify with Henri, because I'm not sure how Privy is able to do it, but they are able to do key rotation over their Shamir shards, so that if you lose a device or lose the password to the password protected share of their system, they are able to transition you to an entirely new set of Shamir shards. He explains it on the show, the interview that we did, but I didn't fully understand, I'm gonna have to go back and ask him how exactly it works. But I think the essence is that there's like MPC that is allowing it, it's not just straight Shamir sharding in EOA. It's some kind of lit protocol style setup, where you're able to, because I also think they're not. they're avoiding this problem. And I'm seeing this across a lot of the projects that there are advantages to putting the multi signature or permissioned access computation in an MPC, and only having a single signer via this like MPC DKG process on the AA wallet, rather than putting those permissions into the AA wallet itself. Because exactly what you mentioned earlier, if you have wallets across different networks, you have this nightmare of state where, let's say you want to do maybe key rotation is not the exact word, but signer rotation, then you're gonna have to do signer state changes across all the network before you abandon the old keys. So it's a big problem.

Himanshu Retarekar: And, and with the increasing number of L2s that are popping every day, it's going to be a nightmare to kind of make sure that it's in sync across. And the larger vision of Ethereum, of course, is to be scaled via all of these various L2s which is there. So I don't see a place where the number of L2s are going to go down. And this is going to be a nightmare to manage across all of these L2s.

Nicholas: Totally. It seems to me that as a developer, especially who's integrating these things, it seems like you want your users to have as similar type accounts as possible and not have to think about such things and just have it work from a cryptographic sense rather than state management sense. So it seems like MPC is potentially here to stay for additional advantages also because you can also do things in a much more computationally cost effective way by offloading the multi signature or permissions to an MPC. You don't need to be doing those computations even on an L2 as cheap as L2s might be. Do you anticipate doing the same kind of thing like doing some kinds of permissioning at the MPC layer?

Himanshu Retarekar: Yes. So which is where I was talking about? the lit allowing us to add a passkey on top of it, right? So you have additional authorizers on top of that. So you can have a passkey as an authorizer so that you don't need to log in always with your social. You can use your passkey at that point of time to authorize the signature from the MPC.

Nicholas: Interesting. You mentioned that one of the barriers is that the even if you, let's say, create an account with a passkey in a, so we're talking about something different than what you're actually building today. But in this passkey future where, you know, passkeys are available natively on all the operating systems and all the browsers, so they're easy to generate. But the big obstacle today seems to be synchronizing passkeys between different platform ecosystems. Like if you have an iPhone where you generate the passkey, then your PC with Google login, there's not going to be an easy way for you to log in with your Apple ID and transition the iCloud keychain state. That seems like one of the biggest problems. Are there other, I guess the state is the other problem. The multi-chain state management are two real reasons why having just straight, because there is some real elegance to just having passkeys as signers on AA wallets, of course.

Himanshu Retarekar: Yeah, correct. But you know, like the guys at Clay were talking about it, if you have the ability to do the R1 code verification instead of the K1K verification on chain, that would have been ideal, right? So in that case, the EVM itself verifies the signature and then you can go through. But unfortunately, the passkey algorithm uses a different signing mechanism and that is something which the EVM doesn't support. So, which is why you need to have code in there to kind of verify and that's where everything stems from. If it was built in into the EVM and that was there and all the EVMs which is there, the L2s which is there, it was very straightforward. You can use a passkey natively to kind of verify. That's apart from how we sync between various operating systems, but at the virtual machine level, at least you can have the ability to kind of make sure that the signature is verified. But yes, that's the biggest problem that the network, the EVM doesn't support verification signature by something other than the algorithm that passkey standard uses.

Nicholas: Right, this is R1 elliptic curve, which people can check out that 7212 episode if they want to hear more about that. So yes, there is this ledger implementation, which is I hear 60,000, 70,000 gas approximately for a smart contract that can verify signatures produced directly by a passkey native to iPhone, Android, etc. Chrome. But that dependence on a 70,000 gas per transaction every time you want to do something, especially across like a huge user base, starts to become pretty painful.

Himanshu Retarekar: So we had, I think, an early version of that, which did something close to about 100k gas on our version of that, which allowed you to do the verification of the R1 signature on chain. On an L2, it's probably okay because gas is not that costly. The problem is that how do you sync it across different one? That's something where we got stuck.

Nicholas: I also have heard people suggesting that, you know, other L2s could just go ahead and bundle that R1 verification directly in as a precompile, regardless of the 7212 EIP and its status for Ethereum.

Himanshu Retarekar: You could, but you could, but then again, you bring the compatibility across various networks and you will have your code only work on those networks in which you have the ability to do R1 verification.

Nicholas: In the other direction, I've also seen people doing things like, instead of, maybe it is in a sense a kind of NPC, but instead that people are using this Halo 2 ZK technique to do something similar. It has even worse gas costs for verification if you want to deploy the smart contract to the chain. But people are clearly experimenting with things that you could put in between a passkey and an AA wallet on a variety of networks to make it work. I'm curious, do you worry about, because what concerns me with the LIT protocol stuff is, if the LIT protocol is not as decentralized as one might hope, and I frankly have no idea how decentralized it is, if the LIT protocol goes down, then everybody who's going through that NPC loses access. Do you worry about that?

Himanshu Retarekar: Yes, of course, it's a worry and I think this is one of the reasons why LIT probably today is one of the better ones out there because it's a decentralized version of it. You have, depending upon where the production network goes in, a decent amount of nodes to make sure it's sufficiently decentralized. So that should be there. But I believe there are other versions also which is coming across, which gives you the ability to do threshold signature across maybe a device and one of the aspects which is there in the cloud. So there are probably other variations which you can do where you don't have to depend upon a decentralized network. I believe people are experimenting with all of these kinds of stuff and we currently are looking at it and I don't think that we have found something which is good to go to production yet.

Nicholas: Yeah, that's really why I bring up this Halo 2 solution. I'm going to look up the name of them and I'll put it in the show notes, but there is someone building this ZK solution. It's not better in terms of gas or breaking the compatibility across chains, so it doesn't solve that. But what interested me about the Halo 2 solution is that it's a standard where anybody can spin up the server and there's no secret material on the ZK Prover that's required to create the, I believe they're Starks, but in any case the ZK Proof is not something that requires any kind of special ASIC or any kind of secret on the server side. So should you be depending on something like that, if the service provider were ever to go down, you could just spin up your own server to be able to have access to your AA wallets. That to me seems like a real advantage. If we can sort of remove the requirement for a network of NPC nodes to be able to sign on your own AA wallet, if in such a case where such a thing no longer exists or you have assets in a wallet and we're 25 years down the road and you want to get back to your AA wallet with some signer that's a passkey, it would be very interesting to be able to at least conceptually, if not in practice today, be able to spin up that other party that's able to do the multi-party compute so that you can actually sign and get access to the assets inside your AA wallet. Does that seem like something that we're going to find? Do you feel confident about that?

Himanshu Retarekar: Very interesting. I've never come across the Halo thing that you're talking about. We've been talking to, in fact, our implementation of the silenced, the recovery, the seedless recoveries done by Silenced Repositories and you should probably talk to Jay who is the head of Silenced Repositories. They're working on various aspects of these with something similar, I think, where they're looking at. I think he's best to explain. Yeah, I have a little bit of idea what he does, but he's the best. You should talk to him to get a better idea of what they do. They have a sequence or an ordered list of the shards through which you can go. The one on your device is probably the highest and then you have something which is in the cloud and then you go back to the network. If you have between the three nodes, if you have your device as well as your cloud, you can then probably do a threshold signature between those two and don't have dependency on network. That's something I believe those people are working on.

Nicholas: Very cool. SilencedLaboratories.com, the versatile toolkit for MPC, TSS, that's threshold signatures, and privacy preserving compute. I'm definitely going to talk to them. The one that I was thinking of is KnowNothingLabs, which is at KnowNothingLabs on Twitter. They have this demo, no seed phrases, plural, dot xyz, which is very cool. That's using the Halo 2 ZK tech, which I think just came out earlier this week. September 13th. That one's worth looking into. It's very cool. It's exciting to see so many people working on these new solutions. I think it's very promising to see that people really do care about this. To me, I just feel EOA remains best in class for one reason only, which is you really don't need to be online to even sign using an EOA. If we can get there with passkeys, that would be really, really awesome. Aside from the little gap.

Himanshu Retarekar: You don't need to be online. But I think the other biggest gap is the other biggest thing that EOA gives you is the ability that you're not tied into any vendor. You can take the seed phrase, add it to any particular wallet vendor, and you're good to go. So there's no dependency on anyone as long as you have the seed phrase.

Nicholas: Right, exactly. And also no state requirements on-chain. Of course, you can sign with passkey, but if the passkey requires the existence of a smart contract to verify on-chain, or some kind of MPC solution in the middle, that's what I mean by being able to interact offline or without any kind of cloud or distributed backend is the ideal. So hopefully, we're going to get there and not land on something more centralized than that. Despite the little inkling of fear people may still retain about whether or not the constants in the R1 curve are safe, which is not entirely clear. But we can hope.

Himanshu Retarekar: Anyway, it has been a lot of debate, I believe, a lot of debate on who holds the bag for that particular constant. But I have no idea. I've been good with what they do. So it's been pretty okay.

Nicholas: I think basically the answer on that for people, at least so far, what I've come to is if you're using an iPhone or an Android or any Chrome keychain kind of thing, then you're already pretty bought into this, all the dangers of that stuff. So if you want to have a vault with thousands and thousands of ETH or something like that, maybe you want to use some source of entropy and a curve that is not the R1 curve. But if it's just for having apps and a few thousand dollars of money, then it's probably okay. In the same way that it's the same technology or same level of risk as saving your banking password to a keychain or something like that. So do you think this seedless recovery as you have it today is kind of where you plan to go with the products in the future? Or do you think you'd like to go to something more sophisticated that could allow for key rotation or other kinds of recovery? How are you thinking about rotation? Sorry, how are you thinking about recovery for the next, I don't know, six months or something like that?

Himanshu Retarekar: So definitely we want to look at more advanced mechanism, which is why we're looking at how we can do probably an MPC-based signer for the money product, which is where the the idea is to kind of make it as dumbed down as possible. So that you can go to a new B and they can start using it. So even today, you tell somebody to back up the wallet with whatever mechanism they give them, I'm sure that not everybody is going to appreciate what is the detail in them to do and what is the exposure when you tell them to back up and what is it they might lose when you do that. So anything that helps you to take it to that level. So if you want to get decentralization and self-custody to that level of what we have today with custodians, we should be able to kind of make it as dumbed down as possible. It's easy for people to kind of recover. It might be a legitimate case of losing or it might be a case of, you know, a case where you might be in health and kind of use cases where the person is no more and you still want to add that particular thing. So I think we should be able to get to a state where we are there so that people are comfortable with storing funds. And that's probably where custodial use cases come in a lot more handy today because you have some way to kind of make sure that there is a little bit of a store and we should get to that level where we can make sure that you can restore in case the person is not around physically.

Nicholas: That's a very, very good point. So far, it seems to me like the best thing if you want to do a passkey style is to just rely on something like the Apple ecosystem, iCloud keychain and wait for the others to catch up. I have some intuition that I don't know if this is the best way to do it, but it does seem like if you're social, if you have a social login and the social login is available across platforms, then that should be the way in which you either add a second signer on another platform ecosystem and sync it with their keychain, or you just sync it somehow directly with the social service if they offer something. Or you could imagine something like where you create a passkey on your iOS ecosystem devices. And then if you'd like to log in from another ecosystem, you know, like a two FA challenge is sent to the devices that are already face ID connected to add a new signer, like say on an Android device or on a Chrome browser. And then you can have separate passkeys in different ecosystems that are synced using their own native keychain, but are kind of segregated from one another because you have multiple signers. Does that make sense to you? Or does that seem like too much work, too complicated?

Himanshu Retarekar: Not make sense. But again, you have to understand that it's the weakest link which comes in there at that point of time. So if you have a social login at any point of time, you have something, you again go back to how much funds you're willing to put in there, what is the risk that you're willing to take. And because your social login is at the end of the day, that is that's what allows you to add more keys in there and you can do whatever you want with that. So how much of how much value would you put in that? where you have that amount of risk or something which you should be able to let the user know that there's a risk that is there and which the user should be able to comprehend, make a decision which supports them also. Right. So that's something which probably I'm not comfortable with putting it in the hands of the user, which to tell them that, okay, this kind of risk exists and whether they will take an educated call and how much of funds will be put in once you know that there is a risk of an attack which might happen because of a social login, which is added on to your your key store, which allows you to add additional access points.

Nicholas: So you're saying like if their Facebook account is compromised or something, you don't want them to lose all of their money and not realize.

Himanshu Retarekar: Do you not want them.

Nicholas: I know you're moving towards this like more simple product focus towards the money product. Do you intend to continue to work on the full fledged app experience as well at the same time?

Himanshu Retarekar: Yes, of course.

Nicholas: So then you're kind of spanning this sort of more crypto native to, to, I don't know, Fiat native, what we should call the other end of the spectrum. But do you have any sense of speaking of like, you know, the risk of having keys or signers of one type or another leak? Do you have any kind of idea about what the permissions architecture should look like or what the UX should feel like for someone adding a new signer and then maybe I don't know, limiting it to only be able to maybe move 100 USDC or something like that? Do you have a sense of how that will be presented to the user?

Himanshu Retarekar: Not, I don't think we're strictly clear on how the UX would look like, but it would depend again on on the particular product itself. But for an obvious money product, probably you will put enough limits in there to say that, OK, what is the kind of pull off period that you want to do before a newly added chain, a newly added key can come in, move funds? What is the free value amount, which is a, it depends upon the market, right? Like a hundred dollars might be a small amount. For you, a hundred dollars might be a very big amount for somebody else. So that depends a lot on the context, on the place, on the market and a lot of other factors. It's not a black and white call. And what is it exactly? And it's not a steady figure across the world.

Nicholas: So I guess starting off, if you create a wallet, you get, you know, just whatever the login has 100% access to that wallet. And then over time, you develop some kinds of notions about permissions for limiting access in less secure contexts.

Himanshu Retarekar: That's correct.

Nicholas: And for the money product, are you sticking with the embedded for now? Or is that the one that you said you're going to be using social logins for?

Himanshu Retarekar: That's good. That would be. that would be something in the back.

Nicholas: Do you have a sense, do you feel like people, there will be regional winners in smart wallets, or even maybe people will have like multiple smart wallets with different specific applications in the same way that we have like at the same time, Facebook, Gmail, Apple ID, etc. Do you think smart wallets will go that way? Or do you think there will be like a single dominant wallet that's popular in a specific region or even globally?

Himanshu Retarekar: I think there will be a multitude of wallets within the region, then we'll have their own versions of it. And each one would have their own specific features. My biggest worry is that all of them would not be something to play along well with each other. You add features in there, which kind of brings in wall garden features around that. And then you start kind of breaking the interoperability of these things and start messing around with the thing. That's my biggest worry with these kind of things going wild.

Nicholas: I wonder, I guess, maybe you've seen something I haven't, but it doesn't seem like people have really figured out exactly. Everyone is moving towards integrating various OAuth solutions so that you can sign in with an account that you already have. But it's not clear that if you sign in with an account that you already have, but you have an AA wallet provided by some other third party wallet provider, just because you log in with Gmail into two different dApps, if one is using the obvious embed and one is using somebody else's embed, they're not going to know about each other. So yeah, it does seem like there's a little bit of a missing piece in terms of standardization. And also speaking on pass keys, there's another problem there where dApp devs are not able to access the information about whether the social login has access to a pass key or not. So it's really up to the user when they log in to decide if they're going to give access to the pass key or sign something with a pass key related to a certain dApp. So there are several pieces where you can imagine someone getting really confused about, oh, I logged into this smart wallet app with my Facebook and then I logged into another one and it doesn't show my balance. Did I lose my money? No, actually you created a new account, but it's not so obvious.

Himanshu Retarekar: Right. So that's probably, I think, one of the other reasons why pass key becomes a little more complicated, because pass key is tied to the domain or probably the app context, which is there. So it's not something that you can take the pass key and then use it in a different app or different website altogether. It's created for that particular domain. So it's not portable across and I can't take that and then use it with something else altogether. I need to be on this domain to use that particular pass key.

Nicholas: I've seen that, but I think people are also experimenting with some kind of technique where the pass key is associated with, I don't know, some iframe JavaScript, something inside of the application rather than the application's domain itself. So you can have a shared domain across applications, but it requires still that the other applications have that integrated third party wallet provider.

Himanshu Retarekar: That's good. It's still tied to some domain versus something like today what you have within UA, at least there's no such thing where you can take across and as long as the signature is valid, you can use it with anybody else.

Nicholas: Right. Right. Shifting gears a little bit, how are you thinking about the address book and contacts off-chain? I know on the website you mentioned something about address books and for regular users, you know, contact book on your phone is really how you get in touch with people for the most part or maybe Facebook contacts. How do you think about contacts? Because it's something that crypto apps usually shy away from completely.

Himanshu Retarekar: Very interesting. So I think on that aspect, I take probably three things that I would say that it's. the one is we're building an address book in the app itself. It allows you to, it's like a standard address book you can add in your known contacts anytime you interact with a particular crypto address, it's automatically added in into your wallet and you can have the ability to name that address and so on. And that's one. The second is we have launched something called NOVVI.ID. It is a completely compatible CCIP ENS L2 ready name. So you can get for your smart contract wallet, you can get a free OBV.ID. So it resolves completely on the ENS system itself. So you can grab something like nicolas.obv.id and it will resolve your smart contract wallet. I can use it across any wallet that supports the ENS L2 name system and that's something which I can freely use across the board. For the money product, we're going one more level deeper and then saying that the phone number should probably be the identifier for the user because we're going down and making it more easy for people to start using, which is why the derivation would be from the phone number. You log into LIT with your phone number and the derivation that happens from the phone number, which gives you an address and you take it off from there. So you should be able to send on the money product, you should be able to send your friend using a phone number, which is the address book. So that's the three levels that we're looking at on how we are looking at this problem of the address book itself and simplifying the address book 0x blah blah blah across to make it more readable.

Nicholas: Yeah, for sure. It seems like 0x is not something that regular people should be interacting with. The CCIP, that's a ERC3668 CCIP read at least. Maybe there's other EIPs also involved. I was looking into this a little bit and I know it's very, very cool, but tell me if I understand correctly. But basically, you can make a call to a contract and the call will revert and give you a URL that you should access to go find some data on the regular old web and then pass the data that you retrieve from that server in a subsequent call to a different function on the contract. that the CCIP revert error also told you which function to call. Is that basically how it works?

Himanshu Retarekar: That's correct. So if you look at how obb.id is implemented, you set the resolver in ens for obb.id. So ens has the ability in addition to .p to register any other domain, right? So obb.id is in ens. The resolver for that is set something where when you look up, say, jboo.obb.id, it will give you a revert with a web callback address. You go talk to that address, it will give you back a package of information with a signature. You come back and ask the contract, the resolver itself, whether this signature is valid. If it is valid, then you look at what the data is returned and figure out what is the return packet that you got from the web. It could be on an L2 also. So you could have probably a callout into an L2 network which gives you back the data and then verify whether the data that you got back is a valid signature as per the resolver that you've set up on this.

Nicholas: It's very cool. But maybe can you explain what this gives you? What's the advantage of this for you? What's the difference between this and say, maybe people are familiar from like NFT mints where there's like a server that signs your mint permit. So you need to get permission from some server by, I don't know, signing in with your Twitter account or something. And then if you sign in with your Twitter account on a website, it's going to allow you to mint by signing a message that it passes to you and you propagate as a transaction on chain. Is this similar to that? Because ultimately you're just like relying on the server to sign something for you, but it's more standardized? Or is there something specific that CCIP read gives you that just having like your own server would not?

Himanshu Retarekar: See, the biggest thing that you're trying to solve out here is that on ENS, everything is deployed on chain. It's completely decentralized. It is, it's permissionless. And you can be sure that the data that is hosted on the Ethereum L1 network that ENS is resolving is completely available there. Nobody is tampered with it. So that's the guarantee that you get with when resolving ENS name because the contractor is resolving for you and you know the data is held on chain. That's what is returned to you. When you go to an external system, you don't have that guarantee, which is why you don't know whom you're calling to is good or not. And the data that is returned is good or not. So anybody could return back and back. What the second leg of that does is that you go back to the main resolver and ask, is this data that I got, is it a valid data or not? So you're verifying on chain whether this packet that you got is valid because the data that is the ENS, the resolved data that you get back, that is completely signed. That the entire packet is signed and then you verify on chain whether the signature is good or not as per the contract, which is deployed on the resolver. So it kind of probably gives you a way to verify and extend without having a dependency on the L1 itself.

Nicholas: And this allows you to do, how does this enable obv.id?

Himanshu Retarekar: So obv.id works completely on top of the ccp everything. Two things, right? Because it's a full-fledged web2 domain, you can go into your browser and just type in java.obv.id. You can even present it with a webpage. It probably shows you a simple representation of what my address is, what are the assets that I have, what are the NFTs that I have. It's all available on web. So it's easy for me to kind of give it off to somebody who's probably not familiar with the web2 ecosystem. It's an easy handle for them to see what my address is. And if you want to transfer funds, it's easy for you to connect probably an existing wallet that you have and then move funds in there, right? So that's one way. The other one of course is that any wallet which is compatible with the ENS and has, Ethers has built-in support for resolving these ccip domains. So you have a wallet like for example, Coinbase does support it. Metamask on the browser supports it. So you can enter this id in there and resolve it properly for you and you can send it across, funds across from there.

Nicholas: Wow. So basically there, when Coinbase is resolving Ethers, when you resolve something like jboo.obv.id in Ethers in a website that anybody could build, it's going to make a call to the L1 contract to find out where it should find, like to talk to a server. and then what is the server return at that point?

Himanshu Retarekar: That gives you a signed data packet, assume that it's a signed data packet. It then goes back again. So it's completely built into the Ethers library itself. And this whole ccip lookup is in the Ethers library itself. You do a first call. So as a developer, you're just doing a resolve name on the Ethers thing. It will give you back the address and the text records also. So it's all happening underneath for you. You don't have to worry about any of that stuff.

Nicholas: That is so cool. So basically anybody can spin up their own ENS style service like obv.id. And yeah, I encourage people to go check it out. jebu.obv.id and you can see a kind of wallet summary. And then you could, so I guess that just because it's possible to do it inside of Ethers, I mean, that's very convenient, but it doesn't mean that it's, for example, included in Metamask or other wallets necessarily, does it?

Himanshu Retarekar: So ideally, I think everybody should include it. If you have Ethers, you get it for free. And I think all the other libraries also include it, like Wagme and does give it to you out of the box. So it's available for you to print. That's great.

Nicholas: That's very impressive. So it means it's very easy for whether or not Metamask literally does it, it would be very, very easy for them to do it. And it's not really a security risk because you're typing in some actual, you know, .obv.id, for example. So, you know, if you type in some bad address, that's kind of on you. That is very, very cool. Okay. CCIP read, sexier than it sounds. Okay, that's great. All right, well, we're rounding up with just about all of my questions. I just had a couple more. You mentioned on the site, a smart asset roll up. Is that something that's relevant going forward for you? And if so, what is it?

Himanshu Retarekar: Definitely, yes. Right. So if you look at what we do, because today in a multi-chain world, the assets are spread across different formats. For example, I have ETH in my wallet on the main net. I have wrapped ETH in my main wallet. I have ETH on optimism, on arbitrum, on base, whatnot. Right. And it's the same address, which is there, which is all of these assets. So smart asset roll up, what it does is just puts them all together on the one single asset and then shows you that this is my net ETH holding across various down there. And then you expand that out and show that, okay, what are the various forms that you have? It's just a simpler way to kind of represent the entire portfolio that you have.

Nicholas: I see. Okay. Okay. So just like summarizing across chains.

Himanshu Retarekar: Yeah, it's just a representation format of the assets so that it's easy for you to comprehend. In a multi-chain world, as it's more and more becoming, it's easier for you to kind of comprehend where your assets are and how it's spread across.

Nicholas: So this is something like what people would see at jboo.obv.id?

Himanshu Retarekar: Yes, we haven't added the roll up feature out there, but in your wallet, an obvious view will see that happening. If you have assets, which is there across various chains, the same assets in various formats, it will all be rolled up in one.

Nicholas: When you say all rolled up, you mean, I mean, what I'm looking at, it does seem to show your OP and base balances. But you mean it will even show ETH across all of them as a single line item, or it would still break them out?

Himanshu Retarekar: It'll show up as a single line item in the app. We don't show it yet on the .obv.id page. But on the app, it shows it up rolled up and you have the ability to expand that and then see what are the various actual forms of that. So

Nicholas: I guess what we're heading towards here is that if I were to try to send you, if I had a wallet, if I had Nicholas.obv.id and I wanted to send jboo.obv.id some ETH, it would do some kind of coincidence of wants and give you ETH from an ad from a chain that I have it on at a chain that you maybe already have a balance on or have indicated some preference for?

Himanshu Retarekar: That's where we want to get. We are not there yet. Of course. Today, you have to go and select the chain in the app. You have the ability to kind of select that asset on the particular chain. In the portfolio representation, it shows you all of them clubbed together. But we want to get. there is what you're talking about, where you just tell me that I want to send Nicholas this much amount of ETH and we will kind of aggregate all of that across various chains and move it across with what the end network is. And then we'll find it to Nicholas.obv.id.

Nicholas: Awesome. I know Vitalik has written something about this, like even having some kind of registry where you indicate what you're interested in receiving or something like that. I don't know if that will literally happen, but very cool to see these kind of multi-chain, reducing the cognitive burden of living in a multi-chain world. I think it's exactly that.

Himanshu Retarekar: As a new chain spins up every day, it's going to become a cognitive overload on the user to kind of keep tab on what is happening. So I think whatever we can do to lessen the burden, we should as developers, we should do that.

Nicholas: Awesome. The last question I really wanted to ask you was, is there anything about what you're doing or the context in which you're working where you see people who grew up or live in a Western context just like lack some obvious context? We talked about inflation and stuff like that, which I think people can kind of abstractly understand. But is there anything about like building this kind of stuff, maybe in Bangalore or in other parts of the world, aside from the West that you feel is just like a blind spot for people in the West. that would be interesting to share here?

Himanshu Retarekar: Interesting. So things that we have definitely seen happening with the UPI revolution, which has happened here in India the last five, six years, is the ease with which you can move money and the same ease that you see sending across crypto from one address to the other. So when I pay a margin today, I don't carry cash at all in my wallet. I do have a couple of cards with me, but pretty much any day to day transaction I do using a pair of transactions. And it's as simple as it's doing it. It should be what you are doing with a crypto transaction. It should be as simple as that. So that kind of gives a context. It's not something I've seen in the US where people are still very much doing transactions with a card or cash. When you use that and you know that a system like crypto can enable that for you on a global basis, that probably opens up a lot more ideas for you to see. what is it that you can do when you have the ability to move funds, not just from one person to the other sitting right across you, but right across the globe. You can move funds at whatever level that you want in a stable coin manner. If you want to or in something like a new Bitcoin, that gives you a good perspective on what a properly implemented crypto without any burden could, a crypto system without any burden could be. And then you can reimagine a financial system which probably is not burdened by what's holding back today with various third parties who are sitting in the middle and then moving funds across for you to move funds across today, across the globe. It's a mess, right? So it takes anywhere from two to three days to move funds across. And then we use it today in the company to move funds across. We have spent anywhere from two to three days to move funds across from the US to India. So that it should happen ideally in seconds. Why is it that we have to do that? I think the exposure to UPI has given us that thing. Okay, why we couldn't be able to build that something similar at a global scale on crypto. And that's probably been in the back of our minds for some time.

Nicholas: I had a similar experience in Tokyo, taking the subway and just feeling like, I don't know, even thinking in terms of even Polygon, Solana, etc. It's just the speed with which you can use in, I don't know if you've been to Japan, but they have these subway cards you can use as a kind of load cash onto them at physical machines. And then you can use the cards at 7-Eleven and other kind of like convenience stores. And they're very, very fast. And it just makes you realize like, how inadequate the speed of transaction resolution in really any kind of crypto stack currently, it's just not, it's not as slick as that kind of thing. Of course, that's very centralized, and you lose a lot of the interoperability and decentralization advantages. But we have a long way to go before we can really compete on something like the speed and ease of use of some of these centralized systems. For the UPI experience, is that a specific app that everybody uses, or it's integrated into different apps?

Himanshu Retarekar: It is integrated into different apps. So the UPI system itself is backed by something known as an NPCI, which is the National Payment Corporation of India, which is a consortium of banks that provide the entire backbone for this. And there are a number of apps, including Google Pay, which operates on top of UPI. So you can use Google Pay, you can use something like a Phone Pay, which is a local app. There are other ways, Amazon Pay has support for it. All of these have integrated into the UPI system, you can use any of them transfer from one to the other, it's interoperable among these.

Nicholas: Very cool. Very cool. So a preview of hopefully what we get in a more decentralized stack soon enough.

Himanshu Retarekar: Yeah, ideally, you should be able to move from obvious to MetaMask without any issues.

Nicholas: Or the other direction.

Himanshu Retarekar: Yes.

Nicholas: Very good, Jaibu. Thank you so much. This is a wonderful conversation. And thanks to Himanshu, who had to run a little bit earlier. But this was very educational. Is there anything we didn't cover that you think we should mention before we call it?

Himanshu Retarekar: No, I think you got it all. And thanks a lot for your time, Nicholas. Thanks a lot for taking the time to talk to us.

Nicholas: This was great. If people want to check it out, it's obvious.technology. Is there anywhere else? people should check you out?

Himanshu Retarekar: That's where we are. And our Twitter handle is it's obvious tech.

Nicholas: Wonderful. Jaibu, thank you so much. And thanks, everyone, for coming to listen. I'm going to be doing another episode in just a few hours with Jose Aguinaga, who is an expert on pass keys and increasingly on MPC at 5pm Eastern Time, which is three or four hours from now. So if you're interested in these topics, please come back. And I'll see you in the next episode. Thanks again, Jaibu.

Himanshu Retarekar: Thank you. Bye bye.

Nicholas: All right. See you. find links to the topics discussed on today's episode in the show notes. Podcast feed links are available at web3galaxybrain.com. Web3 Galaxy Brain airs live most Friday afternoons at 5pm Eastern Time, 2200 UTC on Twitter Spaces. I look forward to seeing you there.