Web3 Galaxy Brain 🌌🧠

Nicholas: Welcome to Web3 Galaxy Brain. My name is Nicholas. Each week I sit down with some of the brightest people building Web3 to talk about what they're working on right now. My guest today is Henri Stern, CEO of Privy. Privy is an authentication and embedded wallet SDK. With Privy, DApp developers can allow their users to sign in with their existing wallets or generate an embedded wallet associated with an email, SMS, or SSO provider, such as Apple ID or Gmail. Privy's embedded wallet powers FriendTech, the breakout social DApp launched in August. With Privy, FriendTech generates a new embedded wallet for each user that signs in, allowing the PWA DApp to sign transactions at the click of an HTML button element. No wallet connect back and forth required. Privy's two of three Shamir wallet option allows DApp developers to create self-custody wallets for their users, while Privy provides a password-protected recovery service in case users should lose access to their account or their device. On this episode, we discuss Henri's experience studying under Dan Bonnet, working on Filecoin at Protocol Labs with Juan Bennett, and building Privy. We explore the ins and outs of Privy's embedded wallet architecture and discuss what's next in wallets. It was a pleasure diving into the emerging embedded wallet and account abstraction smart wallet stack with Henri, who is a clear thinker and humble, decentralization-minded builder. 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.

Henri Stern: Good morning.

Nicholas: Hey, good morning. Is it Henri or Henri? How do you pronounce it?

Henri Stern: Do you speak French?

Nicholas: I do. I'm from Montreal.

Henri Stern: Amazing. Well, it's Henri to my fellow French speakers, but it's Henri when I'm speaking in English.

Nicholas: Great, great. I'll say Henri, welcome to the show. I'm excited to talk. I've been reading up on your docs, and I'm interested to get into everything that is Privy. So I'm happy to have you here.

Henri Stern: Well, it's an absolute pleasure. Thank you so much.

Nicholas: So Henri, welcome. I'm really excited to talk about Privy. Before we get into that, maybe, can you tell me what were you up to at Protocol Labs? You're working on IPFS, Filecoin stuff before starting Privy?

Henri Stern: Yeah, so I joined Protocol Labs out of grad school. I basically had started a company out of college. And after a few years, went back to grad school and took one class with this guy called Dan Bonet and was like, oh, I need to take all of this guy's courses. And then doing a lot of cryptography and computer security as a result. And coming out of that, I thought I was going to do more research. And a friend of mine, who had started Protocol Labs, Juan Bonet said, instead of doing research in an academic lab for like five years, why don't you come and actually build a product that's using the cutting edge research. And so I spent about three years there, working on a number of things. But a lot of my time was spent on the Filecoin consensus algorithm. And it was kind of fun because I started some of this work in 2017, 2018. And consensus and distributed consensus was sort of this emerging academic field. And by the time we launched Filecoin in 2020, so much of the space had solidified around certain abstractions and certain standards. So it was really cool to see that. But I worked a lot on distributed consensus. And then I worked a lot on Filecoin spec work to sort of translate the research work into engineering work for the engineering teams at Protocol Labs.

Nicholas: Awesome. Dan Bonet and Juan are both incredible people. I've never met either of them, but they're very influential. Obviously, both of them. Any recollections worth sharing about what it was like working with the two luminaries like that?

Henri Stern: Yes, it was a lot of fun. It was pretty incredible. I've a lot of memories of, you know, sitting in Juan's living room with Dan Bonet and other members of like Protocol Labs research teams, just talking about ideas. And I think what was fun about it is that we would sort of go extremely broad and then extremely deep and then extremely broad again. So it was sort of like ideas fusing left and right. The moments for, for example, we started talking about things like single secret leader election. How would you like the leader to publish a block at certain intervals? And we go super deep down a rabbit hole of like, how would you do this sort of thing that would actually help consensus algorithms for any blockchain? And then we get stuck on like one technical question and go very deep into the cryptography of it and then pop back out to some other completely unrelated things. So I think it was a lot of how Protocol Labs worked and saw itself, which was, you know, as a generalist research lab that happened to be putting out products like Fogcoin and IPFS.

Nicholas: That's awesome. What years were you there?

Henri Stern: I was there from the end of 2017 to the middle of 2020.

Nicholas: And then subsequent to that, you started doing research to. that led to Privy directly?

Henri Stern: Yes, I had a bit of a sidetrack. I left Protocol Labs when we launched Fogcoin. I was extremely proud of the work I'd done there and extraordinarily excited about, you know, I think that the Web3 space and this idea of having a centralized state that anyone could manage, which my take was, this is potentially absolutely sort of game changing for this nascent technology, the internet. We get to have users be in control of their own data and of their own relationship with service providers. So that was deeply exciting to me. On the flip side, I think I was pretty annoyed at how sort of technically minded the space was. I love sort of deep research as much as the next guy. But I was like, there's no world in which good consumer products are going to be built here if we're so focused on the technicals all the time. And so I felt like I'd done research there, but I wanted to work on products that cared a bit more about their users. And I was pretty worried about questions of user privacy in Web3. What happens if we start dumping user data and private information on chain? And so I honestly left to look into data privacy and to try and figure out how can I as an engineer have the most impact on the data privacy space. And inexorably, I sort of got brought back into Web3 thinking, well, there's this whole new stack being formed. We don't really know how to combine private data and public data. We don't really know how to use sort of existing infrastructure with the blockchain stack. There might be some really good user management tooling to be built here. And that led to my meeting my co-founder and then starting Privy.

Nicholas: That's great. Who's your co-founder?

Henri Stern: Her name is Asta Lee, and she was a self-driving engineer at this company called Aurora for a number of years. So she worked on data infrastructure for massive, massive data stacks, much, much bigger than anything we have in Web3. And was interested in the same questions around data privacy and data infrastructure. Early on, didn't know anything about Web3. And I think it took us taking a number of calls together with engineers in the space for her to see and come to be really excited about the prospect of helping shape this new stack.

Nicholas: So you thought about working on this privacy related tech or maybe did some experiments, but then ultimately, this led to Privy? Or was it a separate project?

Henri Stern: No, no, this absolutely led to Privy. We started off. basically Privy started off as really a back end data store. How do we help developers connect user data to wallet addresses so that instead of building for you know, 0x123, I'm building for Nicholas. And I can maybe even tell you that you're about to get liquidated in your maker vault. So you don't have to find out about it post fact. And the question was, how do we enable richer UX in the space? by making it easier for developers to take on user data, but to do that, to do so safely. And that obviously then led us to thinking about onboarding more widely. And the problems that developers had sort of onboarding mainstream users to their apps and helping connect multiple identifiers to user accounts in a secure way. And, and, you know, it led to Privy such as it is today.

Nicholas: I guess we should get into. maybe you could give a quick. what is Privy? I have a lot of detailed questions to really tease that out. But how do you describe Privy briefly to people?

Henri Stern: Yeah, so Privy is one library to onboard all of your users into Web3 applications. So whether your users are Crypto OG, and has, you know, 15 wallets across a number of providers, hardware wallets, as well as browser wallets, we build wall connectors that make it that you don't have to sort of wrangle RPC calls across environments and wallets just work out of the box, whether you're on mobile or desktop. And on the flip side, if your user doesn't know what a wallet is, and frankly doesn't care, we help build these embedded wallets that are fully self custodial, and sit flush with your application. So you can actually build much tighter UX in providing users access to sort of on chain state and on chain activity without having to teach them about all the complexities of the blockchain space. So we're this user management platform basically, to help you onboard and then sort of set a standard for the user lifecycle management that you have to do in your app.

Nicholas: We're definitely gonna talk about friend tech and how people are using the embedded wallets. But maybe you mentioned in your recent ETHCC talk, this David Phelps tweet, where he talks about the need to like split wallets into two concepts, wallets and passports, where wallets control the account, the custody, the funds, and passports are like signers that do the signing transactions, signing of transactions inside of dApps. Is that the right way to think about the future of wallets? Or how do you think, especially because you're kind of juggling both existing wallet infrastructure and these embedded wallets? Do you think there's a single paradigm that we're headed towards? Or it's going to be more heterogeneous, at least for the near term?

Henri Stern: I think it's going to be heterogeneous for the near term. And I frankly hope it's going to be heterogeneous in the long term. I don't think it makes sense to have a sort of one size fits all wallets. Users have very different expectations of the applications that they use. And I think if we look at the consumer products that have worked in crypto thus far, it's been super financial. I think in part, because of the nature of blockchains, but also in part, because the tooling that we give these users are initially built around asset custody. The original purpose of a wallet is, let me hold my crypto safely. It's not, let me take on these sort of rich interaction models with public state. So using MetaMask to play a video game, say, where your every move is recorded on chain. If you look at how Dark Forest has built their interactions, they actually use a version of quote unquote, an embedded wallet. It's not at all the same technology. But I think wallets are going to have to come in many shapes and sizes because hopefully, blockchain infrastructure is going to be used for many different reasons. And it makes no sense to use a single sort of hammer to both, you know, obviously hammer in the nail, but then also, you know, tweeze out a splinter. And I could keep going with the analogy, but you get my point.

Nicholas: Yeah. So do you think, because I'm very compelled by the way, Frentech used Privy and forced the embedded wallet, or there's no way to log in with another wallet, right? You just have to, in Frentech, you have to create an embedded wallet. It acts kind of, to me, it feels like a similar metaphor to each video game having its own in-game currency and its own balance. You never really worry that World of Warcraft is going to pollute or somehow endanger your bank account, or your banking app, or your Venmo, or some other app. So each app having its own state and a brand new embedded wallet created within it, to me seems like really simple, especially for onboarding people who don't have crypto wallets. Do you foresee that dApps will be using, like, if you, you know, for people who just use Frentech, if you go look at the Privy demo site and docs, you can turn on all different types of authentication, including, you know, sign in with WalletConnect, sign in with Metamask, sign up with a phone number, sign up with your Discord or Twitter or Apple ID or Google or Facebook. You could do all these different things. But do you imagine that developers are going to be allowing a wide range or are going to be limiting it so that their entire user base has the same type of wallet?

Henri Stern: I think that's well, do you mind if I take a step back before I answer your question and talk about why we do both things?

Nicholas: Yeah, please.

Henri Stern: So, you know, it was an early product decision that we made that I think was pretty non-obvious, which is should we just focus on embedded wallets? Or should we also focus on walled connectors? And the honest take is that they're equally hard to build because building a stable walled connector library, given just the plethora of wallets that you have in the marketplace, is just a ton of work. Making sure that, you know, on mobile, you don't click Metamask and then you get taken inside the Metamask app, you connect and then you click sign and then you get taken to the app store and you're completely fucked.

Nicholas: Yeah, yeah.

Henri Stern: Trying to build a robust library around this just takes a lot of work. And so it wasn't an obvious decision for us to do both as a small team. And the reason we did is because I think there are sort of two invariants in how we thought about the product. The first is a user has to be a user. Whether you're coming in with an email or you're coming in with a wallet, we want the user to be a first class citizen. And that means embedded wallets should be completely indistinguishable from third party wallets from a developer mindset. You should have just as rich an experience with an embedded wallet as you would if you brought your own Metamask. And what's more, if you graduate out of the app, if you decide that actually the embedded wallet model is no longer right for you, given the fact that maybe you're custodying various things or other reasons, then you should be able to smoothly transition in and out of the consumer wallet model. So to me, the embedded wallet is not a rejection of the traditional wallet model. In fact, it's just a really good alternative for certain app experiences. And so to actually answer your question, which was, do we foresee that apps will provide a ton of options for their users or just one or two? What we're seeing today amongst our customers is apps that are trying to grab as much of the market as possible. So they're saying if I have five potential social logins, Discord, Twitter, etc. And all of the wallets, let me turn all of them so I can sort of have as wide a funnel as possible on customers coming in. And I think that's where the market is today. Most existing crypto users have their own wallets and are comfortable with them. And this is one of the cool things Frentech did, by the way, on the bridging experience, which was enabling users to actually connect their existing wallets using Privy in order to bridge assets into their Frentech account. And then, you know, if I want to go after Web2 users, I'll enable all the possible options there. That's what we're seeing today. I think the market will go towards consumer apps being a little bit more discriminating towards what is the actual sort of path that I want my user to have in coming onto the app. And how do I actually want them to start engaging and they'll be a little bit more prescriptive, offer fewer options, and in that sense, create a much tighter funnel. I think that's one of the reasons and I'm, you know, ultimately, the entire credit belongs to the Frentech team. But I suspect one of the reasons why the app has been so fun to use in the UX has been so tight, is because they're not trying to like, provide 18 different entry points for all their users, they're picking the one that makes the most sense for the experience they built.

Nicholas: Exactly, exactly. And because they're mobilizing the latent value

Henri Stern: of the

Nicholas: Twitter accounts that you're signing in with, it makes sense that there be only one path in that is, you know, connected to this specific social media where they're planning to monetize or, you know, tokenize the perceived value around the influence of different people. It makes sense to have a tight connection between the login mechanism and the accounts.

Henri Stern: There was a point that I think John Palmer made on Twitter that I thought was really good around, when do you decide to build friction in your app experience? Do you do it upfront? Or do you do it throughout? And I thought it was an interesting lens through which to look at it. Imagine a version of Frentech where I connect with Metamask. And then I connect my Twitter to that account. And every time I want to buy a key from someone else on the app, I basically have to jump out to Metamask, sign the transaction, come back to the app. That's basically friction spread throughout. Probably the bridging is a little bit easier upfront. So you've avoided some friction upfront because maybe I already have some base ETH in my Metamask. But then every time I want to take a sort of in-app action, I get popped out to this third party wallet, which obviously means as a developer, you lose a ton of control over what your experience feels like. Whereas with embedded wallets here, the entire friction is upfront. You kind of have to load up your account with some tokens in order to start playing. But once you have, the whole experience is controlled by the app developer. And so it's a pretty meaningful difference in terms of what does the user experience look like? And how does the funnel look after users been successfully onboarded?

Nicholas: Right, spreading out that friction over the rest of the experience is cumulatively way more friction for using the app than just having these one click transactions. I mean, I have to say, my impression is that there's so much to be gained, especially because the majority of people don't have a crypto wallet, that for many projects, it may make sense to just completely ignore existing wallet infrastructure in order to achieve this once you're in the app with an embedded wallet experience of completely frictionless transactions, where it's just the app presenting UI for executing transactions. So I realized we kind of jumped into this, but maybe for people who are, you know, they may be playing with friend tech, or they've at least heard of it. Maybe we could explain like, what is an embedded wallet in Privy? And how does it function on a technical level? We could talk about some of the Shamir stuff and where the shards are held. Could you describe the embedded wallets and how they function? Maybe if we walk through it from a user flow perspective, it'll be the easiest to understand.

Henri Stern: Yeah, for sure. So and cut me off as I go. But at a high level, the idea is this, can we provide a user who doesn't already have a third party wallet with a wallet that sits behind an authentication method that they're already familiar with SMS, email, social logins? And can we basically have this wallet sit flush within the application that uses it to provide the best possible UX and on brand UX that sort of feels natural within that application.

Nicholas: So from a user perspective, like landing on a web page, or inside of an app, and being presented with very familiar login options like Apple, Meta, Google, etc. Exactly. And

Henri Stern: the point is, you don't basically have to potentially lose your user as the user has to sort of pop out, download a third party extension, onboard into MetaMask for a new user, you know, the five steps of then having to remember 12 or 24 phrase mnemonic, all of that just causes so much friction. So being able to get them started right here, right then, without having to download a mnemonic, without having to leave your app is just a very different experience. And then throughout the app lifecycle, having transactions happen within the app and signatures happen within the app rather than on some third party surface that you don't control. So that's the purpose, I guess, upfront.

Nicholas: Now, in terms of what actually happens, Just to be super clear for people who maybe don't have a fully internalized that what we're saying is, there's no switching between the DAP experience and a wallet outside of it. Instead, the wallet lives inside of the DAP. So you can imagine like frentech, signing into frentech with your Twitter, and then you your entire experiences within frentech, there's no flipping out into some other environment that's controlled by somebody else. So this is like, I mean, frankly, that experience of typical wallet connect behavior, or window.ethereum on a desktop browser, it's really just unacceptable for it's impossible to imagine that a large number of people are going to adopt that habit. And instead, it makes much more sense that the DAPs, you know, it feels like we're, it will feel as retrograde once this is popular as if we were asking people to think about the encryption technology behind their passwords. It's just not something that users should be expected to deal with. It's something developers should be dealing with. So really like this embedded wallet, one way or another, and we'll get into some of the different varieties of embedded wallet. The main UX advantage is on board using SSO or OAuth. And I mean, we can get into what the difference is between those, but familiar accounts that they already have. And then once they're authenticated, no more wallet interactions from their perspective.

Henri Stern: And I think our take is that this kind of shows because, you know, I think if you ask a crypto user to why they use a certain crypto application, very often, the fact that it's a crypto application, the fact that it runs on decentralized rails, these both, I think, ideological and technical considerations are part of the answer very, very quickly. So why are you using this? Because I want to use crypto. And I think for mainstream apps to emerge in this industry, we're going to have a. why are you using this? Well, because the app does X. And so for example, we have customers that we work with, whose users are pretty unaware and pretty uninterested, frankly, in the underlying technicals. We think the fact that it runs on decentralized rails is really important, both for app interoperability and building ecosystems, and also for user control and user freedom. But the user shouldn't have to care. And so that's, I think, one of the key purposes of embedded wallets is to provide that self-destructive experience without a user having to care. But maybe I'll actually answer your question. Sorry for the huge digression.

Nicholas: No, no, it's good.

Henri Stern: The way it works is this. So let's take SMS for a second. And here, there's some technical complexities. I'm going to just gloss over around the fact that we today have two modes for wallets, one with basically a single factor, and one with a multi-factor where the user has to input a passcode. So I'll actually talk about the latter one. But Frontdeck uses the former one, for instance, and we can dig into that. So I sign into your app. I am asked to provide a phone number. I enter in my phone number. Privy takes care of all the UIs. if you want us to, to sort of manage that interaction with the user. I type in my phone number. Privy will send out an SMS to your user, sort of as a challenge with a passcode that the user then enters to prove that they own the phone number that they've said they own. Once the user is authenticated, what actually happens is we generate an isolated iframe. So there's an isolated iframe that pops up. You don't actually see it. And in it, we generate a secret key. And from that, derive a wallet. So we create a wallet in an isolated iframe and immediately use this technique called Tremere secret sharing to split that wallet into three shares. Those shares are, there's a device share, there's an auth share, and there's a recovery share. And you need two of those three shares in order to reassemble the key and perform any actions with the wallet. And so immediately we split the key and we then send the shares to their respective destinations. So the device share is going to sit in secure storage under this isolated domain. So the developer of an app, in this case, you know, Frontdeck, for instance, can't actually access that share. It's sitting under this isolated domain that we've set up. The auth share.

Nicholas: Which they would access via Privy API.

Henri Stern: Which the Privy SDK basically makes a call to the isolated domain.

Nicholas: Okay.

Henri Stern: To retrieve the device share.

Nicholas: So Frontdeck never even has access to the one third Shamir shard of the private key directly at all. It's inside of an iframe that is mediated by Privy SDK.

Henri Stern: That's correct. And I think that was one of the sort of design constraints that we had, which was developers of apps shouldn't have to mess with the cryptography behind these wallets. So we tried to basically split that apart from their consideration as much as we could. The auth share sits with Privy itself. So the auth share is sort of with us.

Nicholas: Device share is the one in the iframe.

Henri Stern: Device share. So no, sorry. The iframe is basically, you can think of the iframe as this momentary pop up that we bring up and down as we need to recreate the keys. So the iframe up front. when the key is created, the key is created within this isolated iframe. It's split. Their shares are sent to their respective locations and then the iframe is destroyed. And then later on, as you're working through the app, if you actually want to sign something, the iframe is recreated. The device share and the auth share meet. The key is regenerated. The signature is made. And then the key is destroyed immediately again. The iframe is destroyed again. And the signature is sent back to the application to submit, for example, to an RPC provider or to a chain.

Nicholas: So what do we call the shard that stays on the device?

Henri Stern: We call it the device share.

Nicholas: Okay, so the device share, you say, is that is something that Frantec has access to directly? or again, they're just accessing that via the SDK?

Henri Stern: They're just accessing that within the SDK. It is sitting in your sort of browser secure storage under a domain that is this sort of isolated iframe domain. So Frantec doesn't have direct access to it.

Nicholas: I see. And when you say secure storage, it's like in. so it's domain restricted to be accessed only via the Privy SDK. And it's living inside like encrypted inside essentially local storage inside the PWA or app.

Henri Stern: Yeah, that's that's a good way to think about it.

Nicholas: Cool. Sorry to interrupt. So there's these two other shares that are then sent to their respective location, which is Privy's server, right?

Henri Stern: So one of the shares we call this the auth share is sent to Privy and we hold it in a database and and this is basically a share that's keyed so that only the original user can actually access it. But here basically, you when you initially authenticate, we send you what's called a JSON Web Token. This is like standard authentication stuff. You can also use third party Web Tokens if you want. But basically this says this is Henry, the holder of this phone number. And our auth share is basically such that only when Henry makes a request, do we actually send that back inside the iFrame. So this is the auth share. It is only basically fetchable by the user themselves. And we'll forget about the recovery share for one second. If you're working on a single device, basically, you know, I have my phone on which Frantec or any other app is running that uses Privy. Whenever I need to generate a signature in the future, basically, I make a call via the Privy SDK to generate this iFrame and then the auth share and the device share meet inside the iFrame, the keys recreated, the signatures generated, and then the keys destroyed and the iFrame is destroyed. So that is like typical operations on a single device. It's what happens, you know, 90% of the time.

Nicholas: So just a question before we get to the recovery, because it is interesting. In the default case, like typically, if I connect to the app, let's say we're continue with this example of using SMS2FA, I authenticate into the app, which is the equivalent of typing a password into the app, I authenticate with the Privy server, you know, the DAP will authenticate me with a Privy server, thanks to typing in the code that I get on my phone. And that unlocks the auth share. Is that right? That's correct. And then because I'm on the device that has the device share, I now have access to two shares. So I've authenticated in this case using the SMS solution, but it could have just easily been a magic link or you know, some other authentication technique. And then I have the device share. So now those two can be reconstituted inside of the iFrame on the device at FriendTech or the DAP developer. at their will, they can just reconstitute these two because I've already authenticated into the app. And the app already has the device share via the Privy SDK. So they can start signing things by just making requests to sign things which will Privy in the background will reconstitute this iFrame, bring together two of the three Shamir shards, which is enough to reconstitute the private key and be able to execute transactions from this embedded EOA.

Henri Stern: That's correct. Yeah.

Nicholas: Great. Okay. So then next problem is obviously Oh, shit, I forgot my password or I lost my phone, I changed my phone number, or I lost my device. What happens then?

Henri Stern: Exactly. And those are all permutations of the same thing. You know, you've lost one of the shares, either you've lost your phone, or you've lost your phone number. But either way, you don't have access to that second share anymore that you needed to do this. And in that case, you know, what do we do? How do we actually enable you say, to come onto your computer and sign in again? Let's assume you've lost your phone. So now you want to basically sign into your app from your computer. you will. Well, sorry, this is unfortunate here, because we use SMS. So let's switch the example for a second.

Nicholas: Sure, sure.

Henri Stern: Let's talk about, you know, assuming we sign up via email on your phone, you lose your phone. Now you go to your computer, you want to sign in again, you type in your email, you authenticate yourself as the owner of that email. How do you actually then recover the key? because you only now have the authentication share, you no longer have the device share since you lost your device. Well, this is where the recovery share comes in.

Nicholas: If we wanted to continue with the other example, you could imagine getting SIM swapped or somehow losing your phone number being in another country, you're not able to receive the text message to authenticate via SMS for one reason or another, but you still have your phone that you originally logged in on. So how do I how do I get in if I lose access to my telephone? I think that's exactly right.

Henri Stern: It's exactly the same logic. And so this is where the recovery shirt comes in. And now, you know, this is where things get a little bit more complicated. So bear with me. But basically, when you initially set up an account, we have two options, either. So the recovery share, basically, there are two things to consider from it. One, it's always entered and encrypted. We do not want to have any access to the recovery share. By default, we store it encrypted so that we cannot reconstitute user keys on their behalf. But we also give an option for users to choose where to store it themselves. So this is where obviously there's tension between UX considerations and the threat model that you're operating under. But you know, basically, I'll just run through the options really quick. In an app like Frontech, for example, Privy uses what's called hardware security module to generate entropy that is keyed on that user's authentication. So I have entropy that is basically only going to be accessible to the phone number holder that initially authenticated. And that entropy is used to encrypt the recovery share that Privy stores. So that means, you know, I basically lose my device, but I still have my phone number. And I want to sign in on a new phone that has this phone number. When I authenticate with that phone number, what's going to happen is I'm going to make you know, create the iframe, but Privy will detect, oh, this is a new device. There's no device share here. And so we're going to have to go to the recovery share. So you know, we pass in the auth share since you have your phone number. And then we basically have the user call this HSM to make a call then to the Privy backend to recover the recovery share and decrypt it so that then we can reconstitute the key and re-split it again for this new device. So what Privy actually does in the background is it keeps track of devices and it generates a unique set of key shares for every device that you have. And this allows us to do sort of this bookkeeping so that for example, if you lose a device, we can purge the other shares that were associated with that device. So say if your phone got stolen, no one could ever use that device share to then reconstitute those keys on your behalf if you're still on phone or something like that. So we're actually keeping track of like per device set of shares that can only be uniquely used together. And this is where obviously, there's a question of well, you know, do you trust Privy to say, use that HSM correctly in the way that we do? Or would you actually rather provide your own entropy as a user? So here that the UX difference is. when you first sign in, there's a mode that we enable with our embedded wallets, where the user actually has to enter in a passcode. So you'd sign in with your phone number, and then you'd immediately get prompted, please give us a passcode so we can encrypt the recovery share with it. It's not quite how it's presented, but that is what it does. And that way, basically, instead of depending on the HSM, the user is setting up their own pin. And likewise, there's a third option, which is if you really don't want Privy involved at all, if you want to make sure that you have access to your embedded wallet, if Privy goes down, then you can actually say, listen, I want to take care of my own recovery share. So I'm going to connect my iCloud or my Dropbox or my Google Drive here. And I'm going to save my recovery share to iCloud. So that if say Privy goes down, and I no longer have access to the auth share, I can use my device in my iCloud to reconstitute my key. And so these are just like variations that we've provided again, because I think applications and wallets are not one size fits all. And we want developers to be able to sort of tune the UX based on the application experience that they want to give and the threat model that they operate under. I threw a ton at you there. No, no, that's great.

Nicholas: So it's very flexible for the developers to choose what sort of risk profile they anticipate or prefer for their users. You kind of almost touched on a couple things that might even be sort of hard questions in a way. But for example, in the SMS example, if I get SIM swapped, the recovery share will be available to the person who SIM swaps me because they'll be able to prove ownership of the phone number. Yes. So it is ultimately like, yes, you also as a developer are making pretty substantial choices when you choose which single sign on option you want to you want to use for authentication.

Henri Stern: That's correct. And actually, I see I see Ben Beish here on the on the call. Sorry to call you up. But Ben sent me sent me a message saying something along the lines of, hey, you know, these front deck wallets are getting to be pretty valuable. The system should be more flexible than it is today where only the developer can choose this. And so this was. this was sort of part of our design goals all along. We're actually making it that the user can actually choose to upgrade the security model of their wallets themselves. So you could imagine and this is something that's being built right now, actually. But in a few weeks, you can imagine in your front deck profile, you might have a button that says, add a second factory or wallet. that prompts you to then add a pin so that actually recovery share is encrypted with that pin that only you know. So if you get some soft again, the attacker has your phone number now. But when they come to a new device with your phone number, get the off share, which they have access to and try to get the recovery share, they'll be prompted for a pin that they don't know. And here we do all sorts of rate limiting and everything else. So they can't just like try to boot for the pin. Whereas conversely for you, you no longer have your phone number because you just got some soft, but you still have your device and you have that passcode that you set. And so you're actually able to go to a website that you know, we need to build. this website doesn't exist yet, but it's ready to be built basically not actually done to work. You go to this website, and you say, I, you know, have lost my phone number, but I'm on this device that has the device share and here's the passcode. And you think those two factors, we can actually change the authentication method associated to the to the embedded wallet.

Nicholas: Okay, got it. So I think one takeaway from this is there are ways to be very, very secure using Privy and there are ways to sacrifice security for ease of use or acquiring so much from the user such as not not requiring a pin code or any kind of password at all if they just sign in. Actually, I'm before we move on, I'm using these terms a little loosely. What's the difference between SSO and OAuth? And is SMS one of those or neither?

Henri Stern: SMS is neither. This is a very good question. But like single sign on is I think, on their different protocols, they often get used together. But OAuth is very specifically a protocol where you're dependent on basically a third party identity provider to authenticate a user on your behalf. So if you're using, say, Discord OAuth, then you would basically log into say, you know, my app using Discord. And what Privy actually would do as in this case, you know, the onboarding infrastructure is we'd make a call out to Discord, you see a pop up and you'd actually be in the Discord site, entering in your Discord, you know, email and password or something. And then Discord would tell us, yeah, this is the user that you know, this is who they say they are. And here is like the user ID that you should be using. So that's OAuth. And we support basically, email, SMS, and then various OAuth options across a number of different social logins.

Nicholas: And SSO is just like the concept of having a single sign in like using one of these OAuth providers is SSO because you're reusing the same authentication across multiple services. But OAuth is the specific tech they're using.

Henri Stern: I think that's right. I honestly wouldn't quote me on this. I haven't looked into like the technical definition for SSO in a while.

Nicholas: Someone asked chat GPT.

Henri Stern: Yeah, there's a. there's a factual answer to this. I just I don't want to say something wrong. To jump back to the last question you were asking, though, I think, you know, the point you made about that design spectrum, sacrificing security for ease of use and back and forth, is I think just the entire name of the game around this emerging sort of embedded wallet system. It's how do you actually enable apps to appropriately tune their embedded wallets. So it's the right model for what the app does. And obviously, Frontdeck here is an interesting example, because it's a social app up front, where you'll put in maybe, you know, I think the first time I had a transaction, it cost me about 80 cents or $1.20. And then some of these wallets have ballooned in worth to being worth, you know, tens of thousands of dollars. So how do you build in that flexibility? How do you do the user education required to do this? And obviously, on our end, the fact of the matter is defaults really, really matter. What defaults we we push are going to impact where in that spectrum users sit. And you know, maybe the hopeful part of me and the very optimistic part of me is that as this technology improves, the gap between and that tension between ease of use and threat model is going to shrink. So for example, I'm very excited about PASKIs. PASKIs are potentially a much easier way to get that second factor in from the user, where it's less friction, but it's just as secure. Unfortunately, today, PASKIs aren't quite ready for primetime, because on Android devices, they don't work cross device. So that means any Android user who signs up uses a PASKI maybe to set their recovery, to encrypt their recovery share, if they lose a device, they're screwed. But these are the types of things that I think means that, you know, we're at the very starting point of building this sort of set of stuff out. And as time goes on, we'll be able to do a much better job, I think of bridging the gap between UX and custody model.

Nicholas: Definitely. I want to talk about PASKIs in a few minutes. And I also want to ask you about how you're able to change the Shamir shards with these device specific shares. But before that, there are, in a way, two sponsors of this episode. The first sponsor of this episode is my desire to find sponsors for the show. If you're hiring devs or making products to sell to devs, or you want in the know Ethereum folks to have a good feeling about your brand, consider sponsoring a run of Web3 Galaxy Brain episodes, you can DM me. the basic ad format is exactly what I'm doing now. Shout you out in the middle of the show live, and also mention the sponsor during the intro, which I record afterwards, and is included in the podcast version. So if you're listening to this, and you think you are the kind of person you want to advertise to via sponsorships, consider sponsoring the show. We can also do like sponsor a bunch of episodes, the price is not out of this world. And I think could be really good for your brands and good for the show. Second sponsor of this episode is the need for Web3 Galaxy Brain to have podcast reviews. There are four reviews of the show on Spotify. It's embarrassing. If you like this show, please take 30 seconds. go review the show on Apple podcasts and Spotify. It's much appreciated. Almost nobody does it. I hope you will. And it's free. It'll take 30 seconds. And you'd be helping your local indie dev podcast today. So thank you. If you want links to either the show on podcasts or how to get in touch with me, obviously you're here you can check on Twitter. But web3galaxybrain.com is another good place. Any thoughts on that?

Henri Stern: I think both of these are great sponsors to have and I will be writing out our reviews as we're done.

Nicholas: Okay, so how are you able in the recovery process to swap out a Shamir shard? I'm only familiar with Shamir as anybody who's googled SSSS Shamir and gets to that page where you just like type in some string and it generates as many shards as you want with the threshold that you want. For people who aren't familiar with Shamir, Google that site. Basically you type in some string and then you choose you know, I want two of three shards to be able to reconstitute it or two of four to be enough to reconstitute it and then it provides you with the shards. But my experience of that website implied to me that the shards are fixed in relationship to the original data that you have Shamir sharded up. How are you able to swap out shards without like creating an entirely new private key?

Henri Stern: It's a great question. And let's potentially put a pin on a question as well, which is why did we take Shamir Secret Sharing? There are other technologies we could have used like threshold cryptography, like secure enclaves and we thought a lot about our options here and made a very specific choice to go with Shamir Secret Sharing, which I can talk about. But to answer your question, basically, let's say you have your private key on device one. You split it into three shares. So we can call them, you know, share one, one, share one, two, share one, three, with the first numeral is the device number and the second numeral is the share number. And you need, you know, one, one plus one, two, one, one plus one, three or one, two plus one, three to reconstitute the key. Are you with me so far?

Nicholas: Yeah, totally.

Henri Stern: Cool. So then you get to device two and you want to sort of provision your embedded wallet on the second device. And what you're going to do is, you know, say one, one is your, or maybe I'll use it as like device share one, auth share one and recovery share one. So you get to the second device and you can use auth share one and recovery share one to recreate the key. And from here, we split it again. And now you have three new shares. And the three new shares are auth share two, device share two, recovery share two. And basically at that point, if you lose device one, we know that device share one is out in the wild. And so we're just going to purge basically auth share one and recovery share one so that if an attacker ever gets its hands on, you know, not just your device, but then maybe your phone number, they're never able to reconstitute a key. So we purge this and we still have, you know, auth share two, device share two, recovery share two that can be used to recreate the key and potentially again, re-derive it into a number of other shares.

Nicholas: Very cool. So in UX land, that might be something like, oh shit, I lost my phone with Frentech logged in on it. I buy a new phone, you know, get a new SIM card with the old phone number on it. And then I log into Frentech and hit a button that's going to generate new shares that and delete the two shares that were stored on Privy server such that even if they get access to the share that's on the device, it's not useful to them anymore.

Henri Stern: Yeah. And that already happens, which is to say, let's say you have two phones and you're using Frentech today. This is happening behind the scenes without you knowing anything about it. The only delta is that the first device shares are not being deleted because you know, ostensibly, this is still your device. And so this is actually just a separate piece of UX, which would be some version of a recovery page where you could tell Privy, I've lost the device, please, you know, device management. When you go inside, say your Google user management page, you can kind of see whether you're logged in on, you know, a phone in California, a computer in New York and an iPad in France. And you have this button to kind of revoke a session on any of these three. You could think of it in this way. I suspect that's what the UX of it will look like. It wouldn't be something that a user has to deal with unless they actually go looking for it.

Nicholas: I have to admit, I'm a little afraid about the EOAN-ness of it because in evaluating how to do the best way to do a vault, like a, you know, just to hold assets safely in cold storage, I compared Shamir and a multi-sig. And one thing that's nice about the multi-sig is that you can really, with Shamir, you're stuck with the same private key. So if the private key leaks, replacing the shares won't matter, especially in the case like in Frentech, where it's not, it's not that it's a bad thing, but Mike Damaris was tweeting about Racer giving him permission to encourage people to export their keys from Frentech and import them into Rainbow, for example. If you do that, then, you know, at some point the key is sitting on your clipboard, or if in some other way the key were to be exposed, then changing the shards would not fundamentally change the exposure of the PK. Whereas in like a vault context, let's say you have a bunch of ETH on Ethereum and you want to find somewhere safe to put it. If you put it in even a system like Privy, where the wallet shares can be purged if any of them are compromised and new shares can be created, if the PK is ever compromised, the whole wallet is compromised. Whereas with a multi-sig, if one of four signers is compromised, you just swap them out as a quote unquote owner in safe terminology. And it doesn't affect the, there's no, there is no super secret data that you can't lose. Whereas with the Shamir system, there is, even though it's only being reconstituted, it's being reconstituted sort of safely in some sense inside of this iframe.

Henri Stern: Yeah, I think you're entirely right. And what you're getting to in some way is the account abstraction versus NPC question. And I think our take sort of unilaterally is that account abstraction is going to be the future of account management in this space. However, it presents too many trade-offs today to be the sort of main path for a lot of application developers. We actually released last week an integration with this smart contract provider called ZeroDev that builds account abstraction like 4337 contracts. And the way Privy embedded wallets have been designed is to be able to be either EOAs or signers on smart contract wallets. And so this works, you know, obviously I mentioned ZeroDev, but equally well, the Alchemy contracts, the Biconomy contracts, the safe contracts and so on. And the fact of the matter with account abstraction is that you still need a user at the end of the day to be able to sort of prove their intent to add an owner, remove an owner, sign things. You just have a much more powerful system that decouples the account itself from the signer. And so this is something we're really excited about, which is actually having embedded wallets set of signers. So that again, you could imagine it would be completely indistinguishable for you as an end user that your front-end account is actually a smart contract wallet rather than being an EOA, which again, gives us more room to keep chipping away at these tradeoffs that we were talking about earlier. The sort of real politic of it today is that the ecosystem is only starting to solidify around these things. I, you know, I've been super impressed with how fast it's coming along. But I think there's a lot of deep questions around, for example, how do you export assets from a smart contract system? How do you actually take the ETH that you've made and move it out if you don't own the keys? This means that the application developer then has to build an off-ramp. There's also a question around support around different L2s, support for fiat on-ramping. So I think it's just a question of time. But basically, the ecosystem is still a little bit immature on the kind of abstraction front. And that's why we continue to offer this EOA option, which is a bit more straightforward.

Nicholas: So I guess maybe to give some context to people, and please correct me if I'm imprecise about any of this, but 4337 account abstraction, aka smart wallets, the idea is that like a safe today, people would hold their assets inside of a smart contract rather than inside of an externally owned account. EOA, for people who aren't familiar, is that those 12 or 24 words, the private key, that the private key is able to sign transactions. That whole mechanism is bundled under this umbrella term EOA. And account abstraction smart wallets offer an alternative where one of the main advantages is that they separate the authentication for signing a transaction from the EOA mechanism. And you can now sign transactions with an AA wallet using either an EOA, as you were just talking about, or something like pass keys or other authentication mechanisms. I think you could even do things like get a 2FA code on your SMS. And that is the sufficient authentication to be able to sign transactions, if I'm not mistaken. And they also separate out payment for the gas that of the transaction, allowing you to either fund the payment of the transaction by somebody sponsoring it, like, I don't know, Polygon or some sequencer or DAP, or that the funds that are being moved in the transaction that you're executing that you're signing yourself, those funds can be partially liquidated in order to fund the gas in ether, whatever the coin is, the gas coin is on the network where you're operating. So the authentication and the payment of the gas are separated from transaction signing and from the EOA paradigm, which means that we open the door to lots of cool things. And we'll get into this in a second. I don't want to get into it too fast. But for instance, using pass keys or other kinds of authentication mechanisms that don't require you to have a private key at all. However, what you're talking about is continuing to use EOAs as signers on AA wallets, which is to say in short, not making irrelevant the last 40 minutes of our discussion talking about Shmere keys, because you would want to have something like a DAP, something like frentech instead of in this AA world. We'll talk about some of the challenges in getting there. But your assets would instead be held inside of a smart wallet on base, let's say. And the private key and the EOA that are reconstituted inside of the iframe, thanks to Privy on device are just a zero balance signer. They never have any ETH or any NFTs or any assets at all inside of them. But they have special permissions on this account abstraction wallet that say this EOA can sign on my behalf. And so you never need to fund the wallet that Privy holds, but it still can have signing privileges over the smart wallet. Is that a fair summary?

Henri Stern: No. The one thing I'd nitpick here is, you know, the point you made about say pass keys or any or SMS based signatures. At the end of the day, you still need a private key somewhere. You need an encryption key. I think the big difference is that that private key or that not necessarily encryption key, but that key that can sign stuff doesn't need to be on the very specific curve on which Ethereum keys are generated. So for all intents and purposes, an EOA is a signing key like any other. However, it's a curve that can also receive assets. And I'll rephrase your definition of account abstraction slightly, or at least the way I think about it is simply with traditional Ethereum wallets, the private key is the account. Whereas with account abstraction, there is an account. And then separately, there is private keys that can sign things on behalf of the account. And by splitting those two out, I mean, you get a ton more flexibility around who controls the account. But ultimately, all an EOA is, is a cryptographic key. And so whether or not it's on the curve that allows it to be an EOA or not, a sort of signer on that curve, or a signer on another curve, like a passkey or like anything else, are exactly the same thing. So I think the concept of an EOA basically only really matters if you end up sending funds to that address. But it's the exact same underlying system fundamentally. And you still basically need a key management system to enable the user to use keys in order to act on a smart contract account.

Nicholas: So maybe to give some additional context on what you're saying, the ECDSA elliptic curve, the cryptography that's used to generate the EOAs, the private keys that we're familiar with as EVM users on all these EVM chains, is built into the EVM as something that is cheap gas wise. to verify that, you know, the holder of this private key signed this message and therefore I'm allowed to move their USDC or no, in fact, they're not actually the owner of this wallet. And so it's an invalid transaction, and we don't even need to bother including it in the chain. So this, this, or revert, depending on what the context is of the execution. So what one thing that a allows is for us to start using different kinds of curves that are not the ones that are built into the original EVM spec or the evolved EVM spec that we have today. And that includes things like pass keys, which we'll get to in a second, which are much more popular in mobile device land and regular computers than the specific curve that is really popular in or that is that is the primary way to do EOAs or the only way to do EOAs currently in Ethereum land. So it's sort of opening the door to, hey, you could have other kinds of cryptography that are allowed to sign transactions outside of the one canonical kind that is currently available inside of Ethereum. Would you agree with that? Or any any nits on that?

Henri Stern: No, that's, that's perfect. And I think from there, you know, frankly, again, the user shouldn't have to give a shit whether when they sign in, they get an EOA or whether when they sign in, they get a smart account that's backed by basically a key that they own, that they can use. the underlying it just gives you more flexibility. But from the user standpoint, the thing that matters is that they're signing key be self custodial.

Nicholas: Right, exactly. So what we're what we're slowly getting towards, and we're going to keep teasing pass keys for a second, because I want to clear out all the area before we get there. But basically, letting people sign with things that are signed with types of cryptography that are available on their phone, more easily that don't require their phone to learn how to do Ethereum, but instead use native cryptographic affordances of the web APIs, web authentication, things that are now being built into iOS, Windows, Android, Chromium, everywhere. If we move to allowing, AA allows us to use those types of cryptography to sign transactions, which means we can start to get rid of wallets altogether, because we can just use the native affordances of the mobile devices that people are using. There are challenges to that. However, I guess we might as well dive right into it. The is I don't know how to pronounce it. SECP256R1 curve. Shall we get into it?

Henri Stern: Frankly, so this is your land, and I'm very happy to follow your lead. I think the way we've talked about things with developers is really in terms of what capabilities are you unlocking or you letting go of if you decide to go one route or the other. So we support both smart contract wallets, as well as EOAs. In a few years, I very much hope we'll be able to deprecate EOAs altogether and just tell everyone just use a smart contract wallet. Why wouldn't you?

Nicholas: Right.

Henri Stern: But I think, you know, very simple things. For example, one thing we noticed with Frentech is people were sending mainnet ETH to their Frentech accounts. The Frentech EOA works across all Ethereum networks, but in the app itself is basically using the base network. So if you send mainnet ETH to your Frentech account, it's locked in there. And within the app, you have no way of getting it back. You could add a button, you know, the app developers could add a button to say, send out mainnet ETH. But they haven't done that. And it would be like pretty weird to a user to have this like random button that has no place within the app experience. And so one of the things that people have done and where, for example, it's super useful to export your Frentech account to your Rainbow Wallet is because then the Rainbow Wallet gives you a lot more granular control over what you want to do with it. So it's a bit more complicated, but it gives you a lot more control as a user so that you can export your mainnet ETH out of your Frentech account. if you made that mistake. Very understandable mistake for what it's worth. And this is something, for example, that would have been a lot more complicated to enable with account extraction, because you would have had your smart contract account and you would have basically needed to push an account upgrade to the chain that allows you to basically look at this token that by the way, is on another chain. So you would need some cross chain thing. I don't actually know if that's possible for what it's worth, because the AA wallet would have been sitting in the base chain and would have basically had to have a function to look up, can it bridge to like, you know, ETH mainnet and then export these things to the wallet as provided.

Nicholas: So would you not be able to just redeploy the AA wallet if it's like a counterfactual create to a contract? Would you not be able to just deploy the same thing to L1 and just have the same authentication work?

Henri Stern: Honest take. I'm out of my depth here because I don't know. when you redeploy, for example, how do you assign signer? Can you make sure that's the same user who controls both the mainnet AA?

Nicholas: And so I think that's kind of my point. Is there anything chain specific when you're deploying such that sending the exact same transaction on mainnet won't actually yield the same result, the same contract address for the AA wallet or somehow won't set up the signer in the same way?

Henri Stern: I think there are questions around how you deterministically or not generate contract addresses across different chains. So it's certainly not a...

Nicholas: Create to should handle that. It should be okay. It's just if there's anything at construction time where? if you're sending anything specific for adding the signer that is specific to base, then it won't work. That signer won't work on L1. So you may need to do some other stuff. I see Ben is sharing some links. So maybe there's an answer already on Twitter.

Henri Stern: No, you're perfect. But I think this gets to sort of my point again about the tradeoff between ease of use and security models. As the space fills out and basically the AA stack gets more robust and more mature, this becomes super easy. Today, obviously, users handling private keys is absolutely not a good idea and generally absolutely sort of an escape hatch or last resort. However, it was the most straightforward way for folks to get their mainnet ease back without having to wait basically for like three or four teams to coordinate. how do we redeploy the contract? and then how do we make sure this works well? and some testing and you're three weeks away and you don't really know what's happened to your funds. So this is again, I think that the sort of march of technology is. a lot of these tradeoffs are going to improve. And I think for us as Privy, one of our jobs is to try and help our developers make sense of the technology space and the choices they should be making to sort of have the straightest path to building good secure UX for their users.

Nicholas: So, okay, there's a few questions here. And I do I do kind of want to leak a little alpha on this SecP256R1 thing because I think I think people in this audience will actually find that very interesting. But I'll get to that in a second. What is the lay of the land on 4337 implementations between Zerodev, Alchemy, Biconomy? I don't know if you mentioned somebody else who's got an implementation. How do you think about what's out there as 4337 implementations right now?

Henri Stern: Basically I think there's a lot of really great folks to work with. I'll call out Zerodev again, because we've really enjoyed working with them on their implementation. I think there's, you know, basically we're seeing everything get built out across different things and companies building infrastructure on 4337 implementations as well like StackUp are doing amazing, amazing work. I think what we are excited to see a bit more of and hopefully participate in building out is more end-to-end experiences that really go all the way from funding and you know, potentially paymasters to on-ramp into these smart contract wallets, all the way to off-ramp and exporting your assets from these smart contract wallets through everything in between. And so I think basically the pieces are coming together. It's a big answer, but the pieces are coming together. But I think getting the machinery to sort of do full cycles on user experiences end-to-end is what we need to see. And then obviously dealing with all the sort of cross-chain considerations of all.

Nicholas: So Zerodev is cool. Do you have any sense of what the difference is between the affordances that people are? these different teams are building into their 4337 implementations or so far, it's really not shaken out how they differentiate?

Henri Stern: I honestly could not speak well to it. I know exactly who on my team you should be speaking with about this, who's done a lot of work basically integrating all of the solutions to try and specifically fizz that out. I think some of it is questions around like how did they go into different like chain environments or some of them, for example, integrate base. Some do not. Some of them have, you know, easier or harder integrations with different signers. So there's a lot there. But beyond that, to be honest, I'm out of my depth.

Nicholas: Who's the person who should we talk to next?

Henri Stern: You should talk to this fellow who's absolutely brilliant, called Ankur Sornikar on our team, who I think knows as much about it as anyone else. All right.

Nicholas: All right. Well, we'll invite them on soon. So we talked to actually before we get into the PASCY thing, which I do want to touch on and I hope you have a few minutes past the hour because there's so much left to talk about. What are people using aside from FranTech? What are other applications of Privy or what are other dApps that are using Privy out there? And maybe how are they using it? Does it feel like FranTech? Are they doing something very different? What are some examples?

Henri Stern: Yeah, that's a really fun part of it for what it's worth. I think that what's really extraordinary about FranTech is just how good to me at least the UX has felt. And frankly, sort of putting out a roadmap and hopefully, you know, sparking ideas for people on this is what you can build on open infrastructure. And so, you know, the combination of PWAs, L2s, embedded wallets like Privy's is all, I think, really, really exciting. What I love about our customer base is that it's quite diverse in terms of the experiences that are built with it. So you've got folks like Courtyard.io that I think is probably the sort of most elegant, complex implementation I've seen of embedded wallets. This is a marketplace for trading physical cards. But you basically come in, you have, say, a Pokemon card that you want to trade, they'll digitize it for you, turn it into an NFT, and then give you access to the world of open infrastructure and NFTs to trade a card. And the integration that they built with Privy is basically a four-way integration between their own smart contracts, Reservoir, so that whenever you list a card, it automatically gets listed across all of the open NFT marketplaces. So you know, you list a card on Courtyard, it's going to be on OpenSea. Gelato, because they want to do gas sponsorship. If you're coming in to sell a card, you shouldn't have to pay for gas. Privy for the embedded wallets. And then, you know, Fiat on-ramps, so you can pay for cards with credit cards. And so this is where I would recommend checking it out. It's really an end-to-end flow. Looks like a traditional marketplace, but all of the scenes is happening on open infrastructure. And they, I would argue, are very much, you know, Frentech ends up being, I think, very crypto native dynamics, at least to start with, around bonding curves, around, say, showing the prices in ETH. I think Courtyard is building much more towards a mainstream user who doesn't know what crypto is and doesn't necessarily care. I think on the other side, we've got customers like Shibuya, who is building a platform much more geared towards crypto natives. Or, you know, folks like... There's a lot that I'm excited about, but folks like PoApp, who are sitting somewhere in between. So there's a number of basically different applications from very, very crypto natives. We want this to be CabinDao, is another one of these very crypto native, for example, applications, which actually wants to use wallet connectors and use previous user management methods to build a better product. To the end of the spectrum, where, say, Courtyard or other customers that we'll announce soon who want to bring on users who don't know what crypto is.

Nicholas: Yeah, definitely. I mean, it does feel like crypto becoming more subtle from the user experience, but still enabling things that you couldn't achieve in traditional Web2 seems like where most people will end up using. Enthusiasts maybe having access to their own wallet. It does make me wonder about one thing. You mentioned this sort of challenge where people are maybe because of some UX problems or just, you know, familiar, you know, making simple mistakes. People funding their frentech wallet on mainnet rather than on base where the application actually lives, having to export their keys to a traditional wallet in order to retrieve. Do you imagine that people like, is it just up to the app to properly integrate sufficient eyes into your embedded wallet, be that the current Shamir only scheme or some future smart wallet scheme where you can get some like overview of what's going on on the wallet? For instance, this like assets on another chain, you have to export the key just to get there. Do you imagine Privy or someone else offering some kind of dashboard so you can see how a wallet is being used across maybe more than just the one app where it was generated?

Henri Stern: Yeah, this is absolutely something we're thinking about. And this is where I think, you know, my earlier comparison of saying the issue of crypto today is that people use crypto apps because they are crypto apps rather than because of what they do. You know, that line of thought would kind of go to all the way to say, well, you know, blockchain is just another database. And I think the reality is it's not. There's something slightly different and there's something slightly morally valent about the way in which users can control their assets and self custodial systems. And so that interplay between how much can the developer decide around what they want to be building. And frankly, if a developer is building an app that uses crypto under the hood, but gives the user no control beyond the bounds of the application, they probably shouldn't be using crypto. versus how much do we strip control away from the developer and their ability to craft their own experience, which I think is sometimes what happens if you integrate a MetaMask and you basically have your user who's spending half of their time in app outside of your app, because they're having to switch networks, sign transactions, etc, etc. Finding that balance is I think one of the most interesting parts of our work, where it's a really question of how do we empower the user without stripping the developer of the ability to craft the experience they want. But this idea of building, for example, a user forward dashboard, where the user can actually come in. And, you know, for a very simple example, let's say an application that uses Privy shuts down, and a user has assets in their embedded wallet tied to that application, we need to be able to let the user recover those assets, even if the application is no longer around. So I definitely think we have a role to play in that. And that's part of the user management story.

Nicholas: So, okay, can we presume you basically said it before that the future is smart wallets, but they're not really ready for primetime just yet because of some UX impediments, and maybe some technical reasons why it's not possible just yet. But is your impression that like the default path in the future for Privy will be to generate a smart wallet, like a wallet? Or do you still think these embedded EOAs may be, you know, relevant for some developers?

Henri Stern: Yeah, the honest answer is yes. Which is to say both. I think first, standards take time to sort of be brought together. And this is maybe back to my days of protocol labs working on consensus work. I think it takes time for standards to really be adopted. Account abstraction itself has existed as long as Ethereum's existed. And you have really great companies like Argent or Safe that have built account abstraction systems that existed before 4.3.3.7. I think there's questions around, for example, if 4.3.3.7 is actually feasible on mainnet, because you are going to have as a developer to pay 10 or 20 bucks to generate a smart contract account. So I would argue EOAs, unless account abstraction becomes a part of the underlying mainnet protocol in a way that 4.3.3.7 today doesn't allow for, EOAs are going to remain very relevant on mainnet. So for the foreseeable future, I think there's place for both basically. And again, I want Privy to be a place where developers can come in and kind of build the right experience for their user without having to worry about these 18 choices that they have to make along the way. And I think this is kind of the trap of building consumer apps in Web3. is you end up having to ask yourself so many deep technical questions as you're building, which I think from an engineer standpoint is so much fun, but very quickly kind of pulls you out of thinking about your application as something that a layman user is going to have to be sort of contending with. You start thinking about it in technical terms and it shows.

Nicholas: Mm hmm. It does. It does feel like there is definitely room for people providing the type of infrastructure you're providing with sensible defaults because every dApp should not be rolling their own wallet. It's just not the business logic of what makes the app unique. Certainly not if they have some protocol or interesting infrastructure underneath or even interesting like traditional Web 2.5 kind of infrastructure that makes the experience viable. You know, building your own wallet infrastructure is a whole separate task. The real question that I'm driving at with this smart wallet question is I just want to ask, do you think that the future is app specific embedded wallets, be they EOAs or smart wallets? It doesn't really matter, but it's like Frentech has its own space, its own sandbox on the blockchain, whichever chain that might be. Or do you foresee apps sharing access to these things?

Henri Stern: This is my like favorite question. And honestly, our goal as a company is to enable the latter. I think if we fuck this up and we do this wrong, the future will be basically app specific wallets that don't interoperate. And again, I think it begs the question of why are you using Web3 at all? I think if we do this right, and it's a hard problem because I think, you know, even the ability, for example, for a developer to sign a transaction on behalf of the user, if you're using an app specific wallet, it's one thing. But if you're starting to use a wallet that's shared across an ecosystem, the security considerations, what if a rogue app gets access to it and starts to drain your wallet? Are much, much deeper. And so this is absolutely a vast portion of the time we spend thinking about where the space is going. And I think basically, you know, there's maybe a third way, which is there's the completely open system where user brings their own wallet with all the UX costs associated to it. There's this sort of, I would call like, you know, walled garden version, where it's all app specific wallets. And the only way to get your wallet from app to app is to export your private keys, which is not a good solution long term. And hopefully, maybe there's this sort of like, you know, middle sized hedge, developers have the power to craft experiences that feel true to the apps that they want to build. But there's a level of interoperability across these EOAs or AA wallets that makes it that a user is bringing their data identity and assets with them from app to app whilst retaining control over them. And that's absolutely what we're working to enable.

Nicholas: Yeah, I do hear this argument often, like if you're going to do something app specific, why even be on the blockchain? But I do feel the need to push back a little bit. I mean, I think there is something kind of intuitive about each app context having its own sandbox. The alternative, and maybe tell me if is what you foresee in the success case, something like I log into a new friend tech type app in a year from now, and I'm able to. I'm presented with some kind of nutritional facts permissions, like when iOS apps asked me for via the OS for permission to access my camera, my microphone or my location, etc. Notifications. And those permissions in this context would be which contracts is this signer allowed to interact with from the context of your shared smart wallet that you're using across many apps, which assets can it touch and which contracts can interact with. So imagine a new friend tech type app comes along, maybe you only give it access to I don't know, up to one ETH per transaction, and only access to ETH and to talk to this contract directly. Is that the kind of permissions based model that we're headed towards?

Henri Stern: I think the short answer is. I think that's what I hope. I think making sure we don't basically clobber our users with hyper granular permissions that they fundamentally may not care about. And I think this is where you're completely right. I think compare this to iOS. iOS is an interesting model for how do you do progressive permissioning and apps. But basically, the long and short of it is I expect you might come into an app and get asked, do you want to create a new profile? Or do you want to reuse one of your existing profiles for this app? And so maybe, you know, my friend tech experience will fit with my buddy tech experience, which are two apps in which I'm kind of using the same sort of things. Whereas on the flip side, maybe my again, I'll use courtyard as an example, my I would want to log into OpenSea with the same wallet I created with say sound or courtyard, because these are all parts of me trading NFTs. So I think there's going to be a mix of basically app and ecosystem specific wallets. I just think there has to be nice interplay across apps for a given sort of environment that you're in.

Nicholas: I kind of wonder if extremely dominant Dapp with an embedded wallet could not make a run at being the wallet experience and they are the ones to define what kind of permissions you use. Like, imagine some kind of runaway app like a Facebook equivalent, not necessarily in terms of the functionality, but just in terms of popularity. If you have an embedded wallet, be it smart or inside the app, they could then, you know, maybe they don't want to expose just export your keys, but instead want to become a trusted provider. in the same way Facebook is, although Facebook relies on all kinds of web standards for like authentication. Nevertheless, it's the Facebook or meta now account, Instagram account, etc. That is kind of the arbiter of that SSO experience. Does that seem possible? Or it's just so contrary to the values that you're interested in that it's something you're not trying to encourage?

Henri Stern: No, I don't think it's just possible. I think it's likely. I think this is how sort of technology develops and we've seen it, which is to say the dominant player gets to set standards. So I think again, this is back to us having to thread the needle of how to give the developer enough power, but keep the user in control. Ultimately, I think, you know, you probably have about five apps in Web3 today, if they agreed on standards, those would become the standard because ultimately developers want to use products that get usage and having access to users of those apps is just such a powerful draw. And I think it's a huge part of our job basically, to ensure that we create good UX, but that we also balance, you know, power given to the developer with power given to the user.

Nicholas: What you say reminds me, you know, there's like a handful of relevant apps in crypto right now, to paraphrase you a little bit in a more opinionated way. And if they were to agree on something, you know, things could rapidly change. I know, for instance, in the older status quo paradigm of the wallet experience around Wallet Connect, it's often so buggy, it doesn't work, you know, as you say, it'll send you to the app store instead of to the app that you already have installed. Or in my personal experience, if you have a VPN, maybe the signature request won't even propagate to your mobile device wallet, for example. Although it does enable some cool things like a great kind of interoperability, being able to like log in to a Dapp as a party, like a party protocol, party bid, you can do that because Wallet Connect allows for these kinds of connections without having a strict requirement that it be a certain kind of entity. that's or impersonator from a poor, where you can impersonate a wallet and pretend to be them without actually having their private key. Wallet Connect does enable cool things, but it's the user experience is so bad in practice, just that's just the reality right now. And this difficult transition to v2 people have been talking about, can we do an alternative to Wallet Connect, but all of this infrastructure that we're talking about today is an alternative to Wallet Connect, because you don't need to Wallet Connect anymore. If you have some kind of embedded access to a signer associated with a smart wallet, that is the account that you're interested in using in a given Dapp. So that's an incredible like upgrade aside from all the switching wallet stuff, just removing entirely, not replacing with some alternative protocol, but instead just removing entirely the need for this Wallet Connect or Connect Wallet experience. It's pretty interesting.

Henri Stern: Yeah, and this brings me back to maybe where we started this conversation off on around, you know, what is Privy? Our decision was to build both embedded wallets and wallet connectors as part of this new user management system. And the reality is we use Wallet Connect a lot. And part of the reason is, again, because we want to help the space sort of grow out of a phase in which you have to be hyper technical basically to want to use a crypto product into one in which you can actually be delighted by the experiences that you're seeing in the space. But ultimately, I think there's a number of possible ways this goes. And I certainly think there's a lot for the space in general to either learn or remember from the existing wallet paradigm. So I think at least for the foreseeable future, we'll continue to support both because I think, again, it's all about the tradeoffs. And I think being able to play across both is how we make real magic happen.

Nicholas: Do you have a few more minutes? Can I ask you a last couple of questions?

Henri Stern: Please.

Nicholas: Okay, great. So Pablo Moncada from Moondow wants to know about, is it possible to have a UX, an onramping UX where someone can sign up with a credit card and then receive a token and a wallet? I think maybe one way to think about this is like a kind of secure custodial wallet where you can eventually recover it for self custody, which I think is something that Privy offers, right? There's two questions. One is about onramping.

Henri Stern: You lost me a little bit on the second part. Yeah.

Nicholas: So there's two questions I think embedded in this question. One is, okay, let's start with the simple one first, which is on everyone's mind, which is, okay, you're signing up all kinds of new users who never had a wallet with your fancy SSO embedded wallet. How are they going to fund their wallet if they have nothing to bridge? They have no origin point outside of this app. So what is the state of the art for onramping with a credit card inside of one of these embedded wallet apps?

Henri Stern: Yeah, I think to be honest, this is. as I look at where we're going in the next few years, this is not a problem Privy will solve internally, but it's a place where we're super eager to partner with a lot of people. And we've done a lot of work integrating basically various onramp provider. To try and understand what's the best way to do this with the system. I think this is probably the sort of most important problem that we have to fix in the coming few years is this question of onramping. But basically today, at the end of the day, Privy embedded wallets are the IP 1193 providers, whether your user signing in with a MetaMask or an embedded wallet is indistinguishable. And a developer can always add basically an onramp to their experience. And one of the things actually that we're going to release next week, which I'm very excited about, is a default onramp provider. basically that works with Privy. So we'll have a basically a button that allows you to just turn on onramps as a developer without having to build out the whole integration yourself. So absolutely possible. On the second question, I guess my nitpick is simply Privy wallets are self custodial, meaning only the user can take actions. The user has to be signed in and has to be sort of there in order for actions to be taken on the wallets. So I lost the thread a little bit on your second part of the question.

Nicholas: So first on the first part of the question, you heard it here first. So on the second part of the question, I think the idea was, can they just like, I don't know, buy an NFT with a credit card? And maybe I'm not sure I'm totally getting what Pablo was asking. But I think maybe the question is something like, could you imagine them just purchasing an NFT with a credit card and not having the, you know, and receiving it without having a wallet per se? But I think your answer is basically like Privy is going to generate a wallet for them. And that's, you know, it'll be self custody from the beginning. They can do so with just an email, but or whatever you choose, any kind of login you choose, but ultimately, they should have a wallet right away. We're not going to like somehow counterfactually, you know, like there were systems for registering an ENS on behalf of somebody with a dot com and things like this.

Henri Stern: Yeah. So it's a great question. We have this this feature called wallet pre generation. And wallet pre generation basically uses the HSM I was mentioning earlier to generate entropy on behalf of the user, meaning not having the user be required to enter in a passcode, but rather having that passcode be generated on behalf tied to their to their sort of identifier. And so actually, you know, you could imagine a way in which you would call the Privy back end with this pre generation function and say, I want to pre generate a wallet for Henry at gmail.com. You would have Henry purchase an asset with a credit card, airdrop that asset into the wallet that you got back from Privy. And then that wallet is basically unusable by anybody until Henry at gmail.com signs in and takes over. And then we have the whole Sharmir secret sharing process again, where we generate a device key and so on and so forth. But that's actually something we enable with with this thing called pre generation.

Nicholas: Okay, so pre generation is. Privy still doesn't have access?

Henri Stern: No, but basically, instead of having the three shares, we just have the two shares, the auth share and the encrypted recovery share. And basically, the encrypted recovery share could only be accessed by the user for whom the wallet is keyed.

Nicholas: Okay, got it. All right, so we covered on ramping. And I just want to hit pass keys briefly. For anyone who's interested, we'll have a longer discussion next week on Friday. We're going to be doing two episodes actually. And the first episode is going to be with some people who are working on this EIP 7212, I believe it is, which is to include the SCCP256R1 curve, which is the curve used for generating pass keys, which are Apple and Microsoft and Google and everybody's involved in this replacement for passwords, where a pass key is generated using this curve, I mentioned the R1 curve on device on your iPhone in your brave browser, on your Windows tablet or in your Android phone. on every platform, it's available. It's like a Fido to standard that everyone is adopting or has already adopted. It's best implemented on Apple platform right now. And the only problem with it is and these pass keys can be used as signers on account abstraction wallets. So you can generate unique pass key on your iPhone when you connect to an app, for example, and that can directly. we can skip all this Shamir business and the EOA and just have the pass key directly be a signer on the AA wallet, which is very interesting because it gets rid of the pass keys in the first place. However, the challenge that is faced is that doing the recovery to check if the signer is actually authorized to make transactions on behalf of that AA wallet requires doing SCP256R1 recovery, which is not included in the EVM as a precompile. So it's very gas expensive to check if that signer actually is authorized, which makes it essentially nonviable currently for you to use pass keys directly as signers on 4337 AA wallets. That's my understanding of the situation. Currently, there's this EIP and I'll be talking to some of the authors or people who are fighting to get this passed in the EIP process to get this curve included in the EVM. And there's some controversy because some people believe that the NSA may have infiltrated the design of the R1 curve and it may be more vulnerable than the curve that is available on Ethereum now and other curves that people are interested in. Any comments on that summary?

Henri Stern: No, I think it's an amazing summary for using the pass keys directly with AA wallets. The reality is, you can also use pass keys as the underlying auth mechanism for, you know, a Shemeer Secreturing based DOA and stuff like that. I have an unfortunately much dumber reason why we haven't done this yet. The reality is, we're super excited about pass keys. We have been working on prototypes of powering privies and better wallets with pass keys themselves. The unfortunate piece is basically just that the standard is still being rolled out. So it works pretty well on Apple and the iOS ecosystem. It works less well on Google. And then frankly, what happens if you have an iPhone and a Linux or Microsoft computer? And so I think these problems become real user problems when you get to any sort of scale with your apps. Where, for example, if I set up a pass key based system on my Android device, it's not quite clear that I'll actually be able to recover it on my Microsoft device. And so if I lose my device, in spite of having a pass key, I'm done as a user. And so this is a lot of what we're looking at. We want to make sure that whatever sort of, again, defaults matter, whatever defaults we're pushing towards developers or one that actually enable recovery, we're still a tiny bit worried that basically there's a bit of room left before pass keys are ready for prime time from a recovery standpoint.

Nicholas: I mean, so I guess I'll just lay it out what the experience is like for people who've never seen it. But basically, imagine you go to the Frentech page, you save it to your home screen, you sign in with the best implemented, fully fleshed out version of this vision is the Apple stack right now. So you sign in with your Apple ID, it asks you to generate a pass key, you use face ID or touch ID or pin code to authenticate, it generates a pass key on the device, which is you can save either on the device on a UB key, or on iCloud key chain. And what's really cool is that Apple with their advanced protection feature are now offering essentially the ability for Apple to delete their key, their access to recover your iCloud account, your Apple ID account, which is dangerous, because if you forget your password, they won't be able to help you. And thus, it's not something that any of our parents should be using. And frankly, us eventually to that in certain circumstances, we can't predict. However, they have now shared recovery, like they have recovery contacts, so you can add iMessage contacts. And if they accept majority of them, or I'm not sure exactly how the threshold works, but essentially, you can have social recovery of your Apple ID to any of the devices that was previously logged in. So if you pair these three things up, pass keys generated on device sync to iCloud, Apple's deleted their key, and you've got social recovery contacts able to restore if ever you forget your Apple ID password, we start to get to a space where you have a really interesting, especially if that pass key can either be directly a signer on an AA wallet, or indirectly a signer on an AA wallet by that passkey being associated with an EOA, either via a Shamir setup or just deriving an EOA directly from the passkey. And that passkey, that EOA being a signer on the AA wallet, either way, we're in a world where you have something that looks like a really scalable solution for people to have self custody wallets that Apple and nobody else will have access to, including social recovery, and smart wallets, so they don't have to have this wallet flow. It's a very exciting possibility.

Henri Stern: Again, my only concern is what if you have an Android device? For sure. But I completely agree with you. We're very excited about it.

Nicholas: For sure. And to lay that out for people, if they were to sign in with Privy using anything except for Apple ID in this circumstance, obviously, Privy would have to build up the Apple ID piece, but an iCloud, etc. But if you sign up with SMS or with Android, there's no one backing up your passkey. So if you lose your passkey, you lose your signing rights to your AA wallet. So as a kind of stopgap in a certain perspective, assuming that we eventually get to a place where that is easier to achieve and the syncing across different platforms is figured out, Privy in the meantime, is essentially playing that role of being a cross platform kind of Apple custodian, maybe custodian is not the right word, but secure self custody backup provider. Maybe you've got a better way of phrasing that. But you're basically playing the role.

Henri Stern: And I think to be honest, again, I think we're just months out. I mean, my hope is that within a year or two, we've got there's just such good momentum behind it. So we're super excited about it. Again, I think just we kind of want to make sure that we're giving people the faults. that don't just hand them a foot gun in a sense.

Nicholas: Amazing. All right, we've done the full tour. This has been awesome. Thank you so much. Is there anything else that we didn't cover that you think we should absolutely mention before we go?

Henri Stern: No, this was very thorough. We went. we went sort of both very deep and very broad. This was awesome.

Nicholas: Awesome. If people want to play with Privy, is there something they should check out? How could they get in touch with you?

Henri Stern: Yeah, please check out demo.privy.io. So that's demo.privy.io to kind of get a sense of the sort of stuff you can build with it. We have a number of sort of, you know, customer apps out there that you should also check out to see what people are building with it. And then, yeah, please, please reach out. I'm Henry, Henry at Privy.io. We have a developer Slack, and we'd love to talk with you if you're building, you know, sort of user friendly applications in Web3.

Nicholas: How many people are at Privy nowadays?

Henri Stern: We are a 10 person team today.

Nicholas: Wow, wow, wow. Have you raised money? How much? How many rounds have you raised?

Henri Stern: We've raised the one round from a bunch of really great investors a few years ago, and we're still going. We've been very lucky. I think we've had a small team for a long time. And so we have just, you know, kept grinding and working out the product kinks that are needed to help the space grow.

Nicholas: Amazing. Well, I'm sure there's people listening to this who are going to keep their eyes peeled for another opportunity related to that. If you're interested in these topics, this podcast will be available next week on Web3 Galaxybrain.com. On Friday, September 1st, I'm going to be talking to people who are working on the 7212 EIP, which is the EIP to incorporate the passkey curve as a precompile in the EVM. And a week after that, I'm going to be talking to Vivian, the founder of Snowball. Igloo is another kind of player in the space, thinking about passkeys and AA wallets. So if you're interested, please come through and subscribe to the podcast. Don't forget to give it a review. Alright, thank you so much. This was awesome. Thanks for staying late.

Henri Stern: Of course. Thank you for having us on and super excited to listen to next week. Cool.

Nicholas: All right. Thank you, everybody, for coming to listen. This is a pleasure. See you next week. Bye.