Web3 Galaxy Brain 🌌🧠

Nicholas: Before we get started, Web3 Galaxy Brain is doing a Gitcoin. If you get value from this show, please support Web3 Galaxy Brain today at web3galaxybrain.com/gitcoin. Each unique contribution helps direct quadratic matching funds to the project, so please contribute to Web3 Galaxy Brain's Gitcoin today. Gitcoin 19 is open between November 15th and November 29th, 2023. Visit web3galaxybrain.com/gitcoin to show your support. Thank you. Welcome to Web3 Galaxy Brain. My name is Nicholas. Each week, I sit down with some of the brightest people building Web3 to talk about what they're working on right now. My guest today is Nitya Subramanian, founder of Capsule. Capsule is an embedded wallet SDK that leverages passkeys, MPC, and AA smart accounts to simplify the user experience around wallet creation and transaction signing. Apps that integrate Capsule's embedded wallet SDK authenticate users by their email address. Capsule creates a passkey for each user, which is configured as a signer on a two-of-two multi-party computation. This MPC, in turn, is the signer on a 4337 smart account. Users that have created a Capsule account in another app will be able to access it in any future app as long as they log in with the same email address. In other words, Capsule is a cross-domain embedded smart account provider. In this conversation, Nitya explains the MPC setup underlying Capsule and provides hints at the team's forthcoming release, which aims to allow secure cross-app smart account access, programmable MPC permissions, and automations for common actions like dollar cost averaging. It was great talking to Nitya about Capsule, which is making strides in the challenging domain of cross-app embedded wallets for a mainstream audience. I hope you enjoy the show. As always, this show is provided as entertainment and does not constitute legal, financial, or tax advice, or any form of endorsement or suggestion. Crypto has risks, and you alone are responsible for doing your research and making your own decisions. Hey Nitya, how's it going? Good, good. How are you? Good. I'm excited to talk about Capsule today. So, actually, I'm curious. I don't know. I know a little bit about your background, but how long have you been interested in crypto in the first place?

Nitya Subramanian: I guess with crypto, I had almost two phases of getting excited. So, first, in college, I got really interested in Bitcoin. This is around 2014. I was a college student and thought that this idea of cryptographic proofs, that secure value, I thought that was really cool. I also thought the distributed systems aspect of it was really cool. It was mostly a technical interest and more of an academic one. But then, a little bit later on, I was working in fintech for several years after that and started to just understand a lot more about how lending and credit systems worked and how those worked in the US, especially in the mortgage context, which is what I was doing. That was when I got really excited about the EVM, about smart contracts, and just the vision for crypto being this world where you can have a lot more different options for how you manage your value, manage your life. I got really excited about the idea that crypto gives people more options to really just live their life on their terms.

Nicholas: Yeah, because I guess between when you first started paying attention to something like Bitcoin in 2014, and then when you looked at it later, this whole ecosystem of programmability had emerged.

Nitya Subramanian: Exactly, exactly. It was initially like digital gold, store of value, which was definitely cool. I think there's something about crypto where once you understand more about how certain elements of the "real world" work, and in my case, that came through finance, you start to understand why it's so important to be able to have a neutral rail or have a way that you can do things without intermediaries. For me, my own journey of understanding that was very critical in my crypto journey.

Nicholas: Yeah. It sounds like it's something about access. that's important to you. Is there something in particular you saw where people were locked out of something for some arbitrary reason that these kinds of things would solve?

Nitya Subramanian: Actually, yes. There was a very specific thing that happened. I was working in lending. I was a recent college grad, and I actually went to apply for a credit card and realized that I just assumed that if you were a responsible person, your credit score and all that just worked in a very quantitative, straightforward way, and then learned a lot more about how credit systems worked. I was like, "Oh, no. Turns out all of the different parties in the system have a lot of power over who does and doesn't get any kind of credit and on what terms," and things like that. That was really a wake-up call for me. It was just realizing that these aren't mathematical equations or direct, transparent systems, and that having options where that is the case could do a lot for a lot of people.

Nicholas: Yeah. I think I've mentioned it on the show before, but I was really surprised when years ago, almost 10 years ago maybe, I was talking to some people from MasterCard, and they told me that they don't perceive a visa as their competition, but instead, the unbanked are their target market. The greatest opportunity for them is not their competitors' clients, but instead, all the people who are locked out of the system for one reason or another. I imagine it's even more the case for lending, I imagine.

Nitya Subramanian: Yeah. I think there's something about when, and especially those of us that we learn math and we learn computer science, and it's like, "Okay, these are the inputs, these are the outputs.". Then we realize that there's a whole set of people who, for one reason or another, don't have access to the systems that have been built over time and have been built with certain assumptions. I think that's where crypto just gives us this really golden opportunity to be thoughtful about building those systems in ways that are default open. Just agree with everything you said.

Nicholas: What did you do when you first decided to move into the space? Where did you go?

Nitya Subramanian: Yeah. I went to work on the Selo Protocol. I was one of their early engineers, and then later on, was focused on the product side. A lot of what I was working on there was actually peer-to-peer stablecoin payments, which I think are definitely having a moment now as well. And we were really focused on building alternatives for either underbanked or unbanked communities. It was something where crypto has just always had so much promise in this area. I think what I learned there, which has ultimately led to Capsule in a lot of ways, was that in order to build those flagship consumer applications that uniquely leverage crypto and that bring that value of cryptorails to end users, there are a lot of infrastructure problems that need to get solved along the way. In particular, the problem of being able to sign transactions easily and safely were really motivating to me. It felt like there needed to be a focus on that specific problem within the space.

Nicholas: Because Selo is quite interested in this kind of global population, not particularly like crypto degen population, but instead access for everybody. I guess it's some continuity there.

Nitya Subramanian: Yeah. I would say that a lot of people I know have come to the space for different reasons. If you have an open rail that people can't actually access, then in some ways, it's just the same system again. Being able to actually take advantage of the open property of rails and actually make them more accessible for people who maybe don't have access to the versions we have right now in Web2 and traditional systems, that's been really important.

Nicholas: What are these big obstacles in the way? Is it mostly UX or what other kinds of things come to mind for you with this barrier to entry for people?

Nitya Subramanian: Yeah. Of course, at Capsule, we're really focused on making transaction signing easier and safer, making self-custody a lot more accessible and appropriate for folks depending on their context and what they want to do in crypto. I would say the other problems that we were inspired by then that I'm still really excited about are things around fiat connectivity, so just making it easier to go between Web2 and Web3 systems. That's something that we think about a lot at Capsule as well with how do you make things like, let's say, dollar cost averaging a lot easier to do in a native non-custodial on-chain way. We think about a lot of these, like how do we make Web3 and make CryptoRail something that can be more embedded into our day-to-day lives and how we just interact with all the systems we already work with, in addition to more Web3-specific type of experiences. But thinking a lot more about how do we almost turn Web3 into this value fabric of just how we use the digital world more broadly.

Nicholas: Yeah. You mentioned this word "embedded," and I guess there's something about Wallet UX that is maybe not totally figured out. Capsule is working on that, right? But what are the problems with the embedded wallets that we have today, or maybe even compared to things like software wallets, hot wallets? What's the gap? that, what's the problem that you're trying to solve overall?

Nitya Subramanian: Yeah, that's a great question. With Capsule, what we're really building are secure cross-app embedded wallets, and I'll unpack each part of that. But the way we see it, there's really two different categories of wallets today. There's the wallets that we know and love and have had for a long time, like MetaMask, like Rainbow, like standalone wallets that are great in that you can use them everywhere, but they require someone to go through an onboarding process. That was a lot of the singular friction point that led to the rise of the embedded wallets that I think we've seen a lot more of recently. I think the embedded wallet space has done a good job in easing that initial friction, but we're going back to something like a one wallet per app type of paradigm. that can be a challenge in terms of taking advantage of the interoperability that you get with crypto. So what we're doing with Capsule is basically building wallets that are easy to be provisioned and easy to get started with in the context of the applications that you're using, but you can then take those wallets with you to other places. So we think about the wallet as something that should be able to follow a user or be with them throughout their journey in crypto from the very beginning to minting an NFT from someone they've been following the work of to then maybe using that NFT to unlock a token-gated experience elsewhere, and wallets as being this kind of container for state. And what's really important about that is the state in crypto is uniquely portable, and so the container for that state needs to be as well.

Nicholas: That makes sense. So basically we go from soft wallets where just to onboard you're asked to save a seed phrase somewhere, which is pretty weird for a regular person to have to think about. It's an unusual requirement, to then these embedded wallets where maybe we step away from that and get the advantages of SSO OAuth login type experiences or essentially just skipping the seed phrase, and yet they're typically app-specific. So Capsule is going to take the next step into cross-app embedded wallets.

Nitya Subramanian: Yeah, I think that's a great way of putting it where. we almost think that when we were all first using, maybe I'll age myself here a little bit, but we were first using different apps in Web2, we had a different username and password for every app. And that's nice in some ways because we can create a new login and do that with every app, and there's nothing that you need to think about in a multi-app context. But then we later on had SSO or single sign-on or ways to leverage a shared idea of a login or a shared idea of state, even if it's just your email and your login, and take that to different places. And in crypto, we're almost uniquely positioned to be able to do that because all that data is on chain anyways. So we're thinking about it in this way of just allowing people to bring the state that they're creating or bring the history that they're creating with them across the different products they use.

Nicholas: So what kind of user experience would I have if I was using an app with, I guess, like devs are kind of the users of Capsule directly, and then they embed it into their apps, and then I as a user of the apps would encounter Capsule. Is that a fair summary?

Nitya Subramanian: Yeah, yeah, that's exactly right. So the people who are integrating with Capsule are typically developers who are working with either dApps or other existing crypto wallets. And then the folks who kind of see the powered by Capsule end up being the users of those products. And as you mentioned, the end user experience, I'll first maybe drop a shameless plug. We have a hosted demo app that people can feel free to check out. I'll drop the link in here a little bit later. But the core experience is that we use a combination of email auth and then pass keys to then create an MPC-based wallet that people can first use in the context of that application they're signing up for. But then later on, let's go back to that NFT example. Let's say they want to access that NFT from somewhere else. They can do that.

Nicholas: Got it. So I land in an app that's got a Capsule-powered embedded wallet. It's going to ask me exclusively for email, or would there also be options maybe for like Facebook or Gmail, something like that?

Nitya Subramanian: Today, we're pure email, but we're adding some social login options really soon.

Nicholas: Got it. So I pass in my email and then there's like a account creation flow. And in the course of that, you're grabbing my email, but actually it's a passkey-based wallet. Maybe you could explain a little bit about how the passkey relates to the MPC and the AA experience. Yeah.

Nitya Subramanian: Oh, that's a great question. So with the MPC itself, so Capsule uses a two-of-two MPC scheme. Also, probably most folks here know, but for those who might not, MPC stands for multi-party computation. So MPC is basically a way of two parties or end parties securely collaborating to create a shared secret. And in this case, that would be something equivalent to the private key. And so you can do things like distributed key generation ceremony to create that secret and then collaboratively sign. And you can do all of this, which is a really wonderful property. You can do all of this without ever having to put the whole private key in one place. And so it's really nice from a security perspective because you don't need to trust any single party to hold onto the private key and keep it safe in that capacity. But yeah, so as we're creating this wallet, the email and the passkey are both used to kind of help the user participate in this process. And so the user participates in this process, Caps participates in this process. And then at the end of that, the user has a wallet that can sign ECDSA transactions.

Nicholas: Got it. So basically like the two-of-two, part of it is the passkey that the user has created and part of it stays with Capsule more or less?

Nitya Subramanian: Yeah, that's exactly right. In addition to that, one thing I'll mention is in some criticisms of two-of-two MPC schemes can be that in some cases they don't offer kind of recoverability or censorship resistance. So we've kind of built additional mechanisms to provide both of those capabilities because that's something that was back to the ability to recover, to exit systems, like that's really important to us.

Nicholas: Right, right. So maybe MPC is used differently in different applications for this signing experience, but I guess here the passkey and the signer that Capsule hangs onto, at least unless we're in a recovery situation, are used to sign on an MPC distributed key generation or distributed key signing event. And then that key that is signing, this key that doesn't exist on any one computer in memory anywhere in particular, is EOA, I suppose, that's a signer, a validator on an AA contract?

Nitya Subramanian: Yeah, also a great question. So exactly right. I would, you can think about the end kind of signed transaction from an MPC signer as very similar to the one provided in an EOA signer context. Capsule actually doesn't have any sort of strong opinions about specific kind of smart contract wallet or account abstraction structures. This is actually one of the really early decisions we made in building Capsule. We were super excited and had always been kind of big fans of what smart contract wallets and smart accounts are doing for kind of on-chain programmability and making it and bringing generally the on-chain benefits to the wallet space. We felt that we could uniquely help by being an off-chain signer complement to that and focusing really specifically on this portability problem. So Capsule works with a bunch of different smart account kind of providers or smart contract wallet implementations, but we've made the decision to be more or less neutral to that and focusing instead on the sign layer since there's a lot that we feel we can help with there.

Nicholas: So as an app dev, I would be the one to choose which AA implementation my users get?

Nitya Subramanian: Exactly right, yeah.

Nicholas: Got it. And then you mentioned earlier, but one of the kind of crazy things that this allows for or that Capsule's approach allows for is that I can then connect this, use the same wallet across different apps that have Capsule embedded. Is that right?

Nitya Subramanian: Yeah, that's exactly right. And so I went through like a lot of different kind of specifics on the above, but almost every decision we made was really kind of made because it was critical to making a cross-app experience that still kind of felt embedded in nature. And the reason for that kind of goes back to like actually the very first thing I said around kind of crypto uniquely being this open system. And our belief is that in a world where crypto is uniquely useful and where an open real is uniquely useful, the application developers should be able to take advantage of all of those benefits and the infrastructure provider or infrastructure that they work with shouldn't limit that in any way. And so that's, I would say, the specific problem that we've really wanted to focus on is making sure that app developers have access to wallets that work across apps.

Nicholas: So at a high level, if I create a wallet in an app that uses Capsule for its embedded wallet SDK, and then I go into another app that also uses Capsule and I sign in with the same email, then I'll be able to use the passkey on device to sign transactions with this MPC distributed key signing process, right?

Nitya Subramanian: That's exactly right. And then there's a lot of work that we've done on top of that to make sure that happens securely. So we'll definitely have, we'll have a bit more on that that we're sharing soon. But yeah, there's been quite a bit of work to ensure that this happens securely.

Nicholas: Right. Because I guess the risk would be that if someone convinces me to sign into another app with a malicious app that has the Capsule SDK integrated, then if I'm not careful, if there's no security provisions, I could potentially be giving them permission to, although I guess you'd have to face ID to get access to the passkey. So they could misrepresent what actions are happening inside the app and maybe exfiltrate ETH or something from my AA account if there is no security. So, right? That's the danger.

Nitya Subramanian: Yeah. There was a very interesting parallel in the non-custodial wallet world, I think about a year ago, where there were, as we've had more and more different like mobile wallets or kind of non-custodial wallets. One thing that, one behavior that we started to see more often is people using the same seed phrase across multiple different wallets. And that's, it makes sense why that happens from a convenience perspective, but it of course opens up users to risks of maybe one wallet that gets compromised, that compromises funds across a lot of different ecosystems. So in any time that we're kind of leveraging this composability, whether it's in an MPC context, an EOA context, there's just a lot of care required in that.

Nicholas: We've talked a little bit about MPC, but I know you have some pretty interesting perspectives on using MPC in advanced ways that maybe people listening aren't familiar with. We've talked with other guests on the show about putting kind of permissions into the smart account, but there's interesting stuff you can also do in the MPC layer that can have all kinds of advantages. Can you share anything about that?

Nitya Subramanian: Yeah, yeah, absolutely. So the way that we kind of think about it is that permissions on wallets, and this is something that I think smart accounts have done a lot of really amazing kind of work evangelizing the property of, is we have the ability to program things. We have an EVM. We have assets. Why can't we combine those two things and make our access to assets programmable or in some way even just automate certain things and do so in a way that leverages crypto? So with us, we've thought a lot about permissions in more of the complement to that, which is more of the off-chain context. And so thinking about permissions as something that in some cases, they could make sense to have in a smart contract wallet, or it could make sense to have on a particular signer. But there even, there are cases where you may want to enforce a permission before you even sign a transaction. And so that can happen at the point where you're aggregating a signature, which is where the MTC comes in, in our case. And so we think about permissions as something that can happen at every level. So there might be certain permissions where you want to wait until the transaction signed on chain, and then you execute the logic in a smart contract and determine if something's allowed or not, or you could even do that before the point of signing. And so a lot of that, in our view, depends on the context in which that logic is being executed, what the types of permissions are, who needs to be able to see them or who shouldn't be able to see them, those types of properties.

Nicholas: So essentially as an app dev using Capsule, I could add some permissions, some limitations on what kinds of transactions the MPC is able to sign so that they don't even propagate to the bundlers and certainly not to the chain.

Nitya Subramanian: Yeah, we basically think about this as a way to allow users to set more expressive automation on their wallets. And so it's exactly that. There could be certain cases where a transaction that maybe the user has already said they want to maybe add a different level of authorization to, or they want to have a spending limit on. Some of those things, if the user is the one setting it, and the user is the who's able to bypass that system, if they don't like it, then there are fewer disadvantages to doing that off-chain. And then you get some advantages, like the costs being lower.

Nicholas: So one could imagine I have an app with Capsule integrated and I'm storing a CryptoPunk or some valuable asset there. And what you're suggesting is that the end user is the one who might say really require a third factor of authentication or something like that. before you let me move the punk.

Nitya Subramanian: Yeah, exactly. I think what we can uniquely do with crypto is put people at the center and make people the arbiters of anything that happens with their assets and uniquely put people in the driver's seat there. And so the way that we hope the space can move is towards one where exactly people can set the permissions and set the automations on what they want to do on their wallet. They can do that on their terms. And yeah, that's something that MPC, we're excited about what it uniquely enables in that context, in terms of the trust assumptions.

Nicholas: I guess, do you think there's any circumstance in which an app dev would want to set some of these additional MPC permissions?

Nitya Subramanian: Yeah, certainly. I think there's actually a lot of parallels here between how things like OAuth and SSO work and how different applications think about the set of data that they access. So what we've thought about here is making sure that this is, so maybe taking one step back, permissions, automations, multi-app, these are really, really hard problems. And it's all of these things that you're mentioning that make it a really hard problem to solve, where application developers definitely, there's always a balance between allowing users to give permissions to things versus making sure that users are in control. And so we've thought a lot about how do you make sure that we give application developers the ability to request permissions and the ability to take certain expressive actions on chain, but making sure to do that in a way that is transparent to end users as well.

Nicholas: Got it. And I guess these programmable MPC limitations can also be useful for maybe ensuring some of that security you were alluding to between cross-app applications of the same wallet or same signer?

Nitya Subramanian: Yeah, that's right. What MPC uniquely allows here is that you can provide a signature, but you can have many parties collaborate on that signature and on the validity of it. And you can effectively program whether a transaction should be signed or not. And that's something that's really valuable in this context when it comes to multiple different parties, each that have different requirements and preferences in terms of some on-chain execution and being able to coordinate those parties.

Nicholas: Yeah, on the Jose Aguinaga episode of the show, we talked a little bit about MPC being used for things like even multi-sig. But it sounds like what you're saying is that in Capsule's implementation, it's more than just Capsule withholding its signature, but actually the MPC will have some settings in it that would. even Capsule would not be able to sign transactions that are against the will of the user.

Nitya Subramanian: Precisely. I think what these systems are all about is they're primitives that we then build layers and layers on top of. And so at its most foundational level, it's about which parties have which privileges in a system and how do you make sure that those are really transparent and open, both in their initial default state, but then also as they change and are updated over time.

Nicholas: You mentioned this idea of things like dollar-cost averaging, which actually on the Conrad Kopp-Rhinestone episode, we talked a little bit about things like dollar-cost averaging as modules in ERC 6900 modular account abstraction contracts, which we'll get to in a minute. But when you think of dollar-cost averaging as a feature a user might want to enable, at what layer of the stack in a Capsule wallet would it make sense to do dollar-cost averaging?

Nitya Subramanian: Yeah, that's a great question. So certainly there's different levels of this. And I think a lot of it depends on the specifics of which parties are involved. So there could be a world where that is an on-chain, more like session key type of privilege. And that might make more sense in a world where it might not change very often or where there's less sensitivity to any kind of fees associated with it or things like that. And then there might be a world where a given application wants to enable a dollar-cost averaging feature and have a more automated signing type of functionality. And then that's something where something like Capsule or our layer in terms of MPC could make more sense to encode that in.

Nicholas: Okay. So you could have something like a payment or some kind of action where the user might not have to take an action at transaction time, but instead could be setting some kind of cron job or some Capsule service that could initiate the transactions on their behalf.

Nitya Subramanian: Yeah. Where we think about this is there are so many things that crypto has really done that have kind of pushed forward a lot of the boundaries of what we can do and what guarantees we should all expect. But one thing that we've kind of taken a step back on a little bit is that we're still kind of setting reminders to check, to go and go to one application and claim something every day or to go every week and check some number and then take some action based off of it. And in some ways we're still kind of sitting in front of our laptops, clicking buttons based on my calendar events. And so I think what I think that both, I mean, Account Abstractions is doing a lot here, but then also a lot of the work that we're doing with Capsule can also help here.

Nicholas: We glossed over it a little bit, but also one of the advantages of the system is that you can do this kind of programmable permissioning or automation features in a gasless way where you don't need to do validation of these things on chain because you have the options of things like MPC. That's pretty cool too.

Nitya Subramanian: Absolutely. I think something that, and this, the amount that we're talking about it changes usually depending on how expensive transactions are. But ideally if we're taking an action really frequently and we don't, maybe everyone has, and every different user has a different cost premium that they place on having something on chain. And so if something has very similar guarantees from a user's perspective, being kind of enforced in this off-chain way that they can modify whenever they want and they can update, there's a lot of advantage to doing that in an off-chain way. Also from the application perspective, there's a lot of advantage to being able to set up some of these things with users without the cost of having an on-chain contract footprint. And so those are two of the kind of reducing barrier to entry-wise things that we think about. Yeah.

Nicholas: I guess you also have a couple other advantages. You avoid the R1 verification problem by having it be a K1 curve EOA and the DKG that's signing. And you also don't have the problems around cross-chain state for adding and removing signers and permissions when everything is living in the smart account. If you, I don't know, change the passkey, rotate the key or something, you need to now go update all of your other contracts on all the other chains. So maybe this also facilitates a multi-chain smart account.

Nitya Subramanian: Exactly correct. Yeah. You said it better than I could. I think the beautiful thing about so much of our on-chain systems is that they are based off of a cryptographic primitive. And that is, of course, public key cryptography, like having ECDSA signatures. And the way this is going back to our initial decision with Capsule to be focused more on the, like before things get to the chain and the more often side of it is that we think a lot about ourselves as almost a way to get an ECDSA signature. And that can work across chains. It can work across different contracts on different chains. And overall, the on-chain world has just exploded in complexity. There's now more places than ever to transact, more networks, more protocols. And if we can do something to simplify what that explosion of opportunity looks like to end users, that's kind of the approach that we're hoping to take. And even from the developer experience, like reducing the friction to switch networks, things like that are all things that we think are really important.

Nicholas: Yeah, I didn't really ask, but I assume Capsule's EVM-focused, or do you imagine supporting other chains as well?

Nitya Subramanian: Yeah, we've been mostly EVM-focused for now. There's a couple of other chains that we've explored adding to, and more broadly, our SDKs work across ECDSA chains. So we have some Cosmos compatibility as well, and yeah, are definitely kind of, depending on interest, just adding support for more and more ECDSA chains as we can. Similarly, just trying to also smooth the ease of access across different ecosystems is something that we think is really important.

Nicholas: I know you have some upcoming announcements, so don't want to spoil those, but we did cover a little bit this idea of recovery and even key rotation. Maybe you can give the broad strokes of just what Capsule supports. Is it possible to change the passkey or add another device that's maybe from a different OS ecosystem and doesn't share a cloud keychain solution? How do those things come together in the Capsule package?

Nitya Subramanian: Oh, great question. So we use passkeys to authenticate individual devices. Users can always add more devices if they want to. So that's something that we definitely support today. We'll support at launch. As you mentioned, we have an announcement coming up in November around this, but yeah, we're definitely multi-device compatible out of the box. And then key rotation and recovery is, I think, a really cool one where there's actually been a lot of discussion in the space around how MPC and account abstraction and different structures enable different types of recovery key rotation refreshes. So maybe just to give that overview. Yeah, so smart contract wallets and account. abstraction, multi-sigs as well, all fall in this category of having multiple different signers that sign on a smart contract. And so in those schemes, let's say that you have one signer. that, let's say it's a social recovery context. And my roommate was one of the signers. Let's say we're not roommates anymore and I don't want her to be a signer. I can take her off and put someone else on. And that's what people tend to talk about a lot with key rotation. MPC is a little bit different where MPC instead relies on quorums. So let's say when you first instantiate an MPC scheme, you maybe have a two of three set up, in our case two of two, but you can always generate a new kind of two of two set or a new two of three set, assuming that the MPC scheme supports key refreshes, which not all do, but many do. But the difference here is that you can do a refresh, which is basically the same as saying we're going to have a new set of keys that can sign on this protocol. But you can't say like this one specific signer can no longer produce a valid signature with some other set. And so you basically are generating parallel sets. And there's definitely been some criticism of this in terms of the account recovery context. I think there's a lot of gray area in here. And so while MPC does have this property, there is also a kind of critical point that I think people miss in the nuance here, where depending on the MPC scheme, so in our case, it's a two of two system. The user actually still has control of both shares. And so in an environment where there is some amount of trust in that quorum, so let's say it's my friend who might no longer be my friend or something like that, but it's my device, you can pretty strongly get the same guarantees there. So that's kind of how we think about the differences between the two.

Nicholas: So in that idea of a key refresh, that would be like adding, like ultimately you'd be creating a new MPC set with maybe the same, like. I understand that both keys are ultimately in the custody of the user, but the key that belongs to capsule in typical signing scenario and a new passkey, and then you would add the corresponding EOA to the smart account and then remove the one that was from the previous key signing set?

Nitya Subramanian: Oh yeah, great question. That's actually something I didn't go over. So in the kind of account obstruction example I shared, where you're removing one signer and adding a new one, that new signer has a different address than the old signer. And so let's say this was just a pure like EOA type of context. If I ever wanted like a new key, I'd need a new address. And this is a problem that we're all familiar with in the space. In a key refresh context with MPC, you can keep your same address. And so this is a way to generate a new set of key shards, but to have the map to the same underlying address. And so that's really the main difference here.

Nicholas: Very interesting. But you mentioned this, like some amount of controversy over this approach. Does it mean that the old set is still able to sign or it is possible to really remove that original passkey, for example?

Nitya Subramanian: The old set, in a pure MPC context, that old set is able to sign. And so what you end up with is the classic problem of provable deletion. And so in a world where you, let's say my old iPhone had one passkey and my new iPhone has the other passkey, I have my old iPhone. Or I can kind of deprecate that, so I can report it stolen. And so there's like different kind of measures that you can take when the parties involved are trusted. But there is, of course, this element of trusting old quorums.

Nicholas: Got it. I mean, this is kind of one of the topics that's interesting because you're trying to ride this line of sort of the trade-offs between security and convenience. I'm curious if you have kind of a broad thought on what the right solution is, or maybe even for Capsule, is the target user, end user of the product, like a kind of regular mainstream user? And how does that influence your decision making in this security convenience? trade-off space?

Nitya Subramanian: Yeah, that's a great question. So I would say our view is that there's always going to be kind of, there's always going to be different kind of trade-offs in all these systems. And I think so much of the explosion of the wallet space right now is there actually being more flexibility to actually explore those different trade-offs. And so what we think about on this side of it is that because we think about capsule wallets uniquely as being cross

Nicholas: app and

Nitya Subramanian: wallets that will kind of last with you as a user throughout your journey, we believe the security standard needs to kind of match the same as what you would be used to with really like any kind of product that you use that you would want to kind of stay safe. And so we think about that a lot, but then also on the convenience front, our whole goal is to bring more people into this space. And so there needs to be kind of different kind of dimensions to explore here. And so what we've kind of settled on is thinking about the role of crypto as always being exitable. So as a user, you can always take your keys, take your assets and choose a different on-chain system if you want. You should also always have the right to know exactly what trust assumptions you're making. And so we kind of take the role of introducing some default trust assumptions because trust assumptions exist everywhere in crypto already, whether they're kind of implicit or we're just used to them, but we make them really explicit and then we also allow people to exit. And so that's kind of the place that we say, let's make these things explicit and then do that to bring convenience to a place where the barrier to access is as low as possible.

Nicholas: You mentioned that, I mean, I totally agree that this ability to exit is crucial and kind of a crucial component of genuine self-custody. MPC solutions, one thing that can be a problem is that you require access to wherever the MPC computation is taking place. You need access to like maybe a majority of the nodes on a network or depending on the setup. But you alluded to the idea that the shares of the MPC computation ultimately are custodied by the end user. So I'm curious, does this mean that even if Capsule were to disappear completely, users would still have access to their wallets ultimately?

Nitya Subramanian: Yeah, this is something that's really important to us is preserving that quality that if a user either wants to exit a system or has to exit a system for whatever that reason may be, that they have the ability to do so. And so that's something that we've kind of structured into the Capsule scheme where from day one, people have that ability. And then there's actually some more stuff we're doing here. that's like a little bit kind of coming soon TM that we can't share much about just yet. But yeah, this is kind of an area where we're doing a lot of work and even kind of in today's version, Capsule users can have access to all of the material that they need to sign transactions on their own.

Nicholas: Great, something to look forward to. Is that something we'll find out more about in November maybe?

Nitya Subramanian: Definitely the structure of where things are of the current scheme. And then some of the future stuff, it'll probably be a little bit after that, but we're pretty excited about it.

Nicholas: Great, sounds interesting. Something to look forward to. We touched on it a second ago, but I was curious if you had any opinions on ERC-6900 modules. Is that interesting to you? Do you think that's something that developers will want to take advantage of if they're using Capsule?

Nitya Subramanian: Yeah, I definitely have. I'm by no means probably as much of an expert as other folks that you might have had on the show or been talking to around this stuff, but I think what's really cool about having more of these programmable modules on chain, if I'm understanding what ERC-6900 does well enough, I think what's really nice about that is that you can start to leverage the composability between these modules really well. And we think about this even in the off-chain context of how do you make sure that the different ways that people are maybe setting automations or thinking about what can happen to their wallet or what they want to allow, making that be as easy to build on as possible. And so I think it's really exciting. And as mentioned, us having compatibility with anything that can be done on chain is always important. And it's for reasons like this where we can continue to leverage the best and newest and greatest.

Nicholas: Great. You touched on it before, but I wanted to ask again. Let's say I sign in on an iPhone and then I sign in using the same email address to maybe the same, maybe a different app using Capsule on an Android device. Would the system add a separate passkey? It would now be a two of three situation or how would you think about that?

Nitya Subramanian: Yeah. So in this context, what we basically allow are for people to add passkeys to their wallet. And we do that as an extension to the existing cryptographic setup. So there's a couple of things that we're doing here, but really what we'd allow for is for either of these passkeys to allow the user to initiate a transaction on the same wallet.

Nicholas: Very interesting. So zooming out a little bit, I'm curious how you think Capsule fits in and what kind of the lay of the land is. I mean, there's a lot of options out there. There's obviously the software wallets, the MetaMask rainbows of the world. There's embedded solutions, Privy and others. There's more passkey centric solutions that are slowly and then quickly emerging. I'm curious, how do you see the whole landscape? And maybe one way to think about that is in a year or two from now, how do you think people are going to be using crypto apps? Is it mostly going to be embedded wallets or how do you foresee this playing out?

Nitya Subramanian: As you mentioned, I kind of think about there being a couple of different categories. So there's, I'd say, the more protocol-based MPC schemes that are usually really decentralization-focused, more focused on allowing a ton of different flexibility. Then on the other side of the spectrum, there's more social login-focused, more app-specific wallets. And I'd say those tend to be hyper-opinionated about a given setup, but as a result, offer a very standard user experience. And I would say we view ourselves as somewhere in the middle. And the reason that we are is we think a lot about our end goal as making it possible to transact from anywhere. And I think that is actually a big part of how, I would say, our vision for the future of the space, kind of what that vision is, which is that we think a lot about crypto transactions as something that are very context-dependent. So I might see something on a website and take some action and that might result in an on-chain action. And then I might open up maybe a mobile app and then similarly have some other action that I want to take. And crypto, in our view, shouldn't be this separate kind of weird thing that you have to go to a separate app or go to a separate product to use, but rather something that should offer you the magic of being able to access the same stuff everywhere. And that's something that is really the goal that we're singularly focused on, on making possible. And so it's led to a lot of the maybe more specific decisions that we've made, but that's really how we think about things going forward. And I think what's nice about this is that there are a lot of options. And so I think what the beauty of crypto is that it's not going to be one size fits all, but we think about ourselves as being the way for people to access their on-chain state anywhere and doing that without having to jump through hoops. And so that's, I would say, like sort of the user and the action kind of set that we're really excited about making possible.

Nicholas: Got it. We talked a lot about the wallet aspect of this, but does Capsule plan to do anything beyond the wallet creation and signing experience? Yeah, yeah.

Nitya Subramanian: It's a great question. I would say right now, there's so much to do in this particular side of the space where we can just make signing easier and signing less of a weird thing that people have to sit in front of their laptop to do. And so until we've kind of done that, I think that's going to be our core area of focus. And then of course, just making that easy for people to use, adopt, things like that. I would say there's more that we're always going to be excited about solving these problems of making kind of end access easier for users and making it easier for developers to give their users the experience they want. And so if there's stuff that we can do to keep helping there that kind of fits within what we're building, never say never, but we're definitely focused on this area.

Nicholas: Do you think apps that use Capsule will also be like Wallet Connect enabled or would they strictly be tied to an embedded wallet experience?

Nitya Subramanian: I would say we're starting to see a trend of different apps making different decisions here, where I think until a few months ago, it might have been unheard of to only have an embedded wallet within an application. I think we don't have any prescriptions there. Our view is that there are certain apps that are primarily focused on crypto natives with existing wallets and accessing those wallets via a Wallet Connect or similar standard. And then there's also apps that want to really focus on having like an abstract the crypto way fully type of experience where no matter whether someone has a wallet or not, they'd want to kind of focus on an embedded first experience. And so we're pretty flexible to developers there. Our view tends to be that builders know their users best. And so we just try to offer a range of options.

Nicholas: Got it. Yeah. I mean, it's obviously a very different UX if you are signing in a separate application or an extension than if you're using an embedded wallet. But I agree, it seems like, at least for mainstream adoption, it seems like having to go to a separate context in order to sign will never really be truly competitive with a fully embedded experience.

Nitya Subramanian: Yeah, we think about it as there's like certain contexts where we're having a standalone experience is really valuable. So we specifically say that we're not when we think about the category of folks that are using a ledger to do cold storage or to do some kind of offline storage, that's much less of the context that we're trying to really, really change. Because there's in terms of all of the things we talked about with us trying to make easier, we're less kind of focused on that side of things. But where we think we can help is these more embedded contexts, making it easier to take actions directly, and then also to kind of bring your state around the internet with you.

Nicholas: Do you envision having a general purpose interface outside of the context of the embedded wallets? Because I know this is kind of a problem. I mean, people with like Frentech, for example, have had to export their keys all together in order to be able to import them into another application in cases where they, for example, deposited funds, funded their base wallet, but on the wrong chain. In order to get that out, they've had to plug the private keys into Rainbow or Metamask or something like that. Do you imagine that you'll have some general purpose interface for Capsule, or is that not really in the cards right now?

Nitya Subramanian: Yeah, it's a great question. And I said to someone who built a wallet before working on Capsule is building a wallet is really, really hard. And our hope is more that we can offer signing wherever people need help signing. And so our hope would be more to partner with other interfaces. And there are definitely like really great interfaces that let you kind of do things like transfers or swaps between chains or all of these specific actions. And the hope would be that because of the interoperability and the portability that we offer, that you wouldn't have to then go in and export or exit a system in order to just access enough kind of state to do a swap. It's more that you can go to another interface, do that, and then come right back to the action that you want to take in the first place.

Nicholas: Right. Because I guess given that you have the cross-domain support for these accounts, you could just use any number of a variety of options, of third-party options for like a general purpose wallet experience that would have access to some or all of the shared liquidity, shared assets that the embedded wallets have access to, the very same wallet or account, I should say.

Nitya Subramanian: Exactly, exactly. And so the idea is like you shouldn't need to exit to take a single action. Just go to the interface. that's really good at taking that action and then you can come right back.

Nicholas: Makes sense to me. We reached the end of my list of questions. Do you think there's any topics that come to mind that we didn't cover that would be worth discussing before we call it?

Nitya Subramanian: I feel like we covered a lot here. Yeah, so I think the only things for us are like really thank you. It was so much fun to get the chance to talk about Capsule, what we're building, kind of some of the decisions we've made along the way. And yeah, we're super keen to also be sharing more with folks about kind of the beta opening up in the next few weeks.

Nicholas: Yeah, so people can check it out at usecapsule.com. There's docs there as well. I don't know, did you have the name of the demo link?

Nitya Subramanian: Yeah, it's just demo.beta.usecapsule.com.

Nicholas: Great. So people can check that out and get a feel for how Capsule works. Nitya, thank you so much. This was a really great conversation. I'm happy to learn so much about Capsule and I'm excited to hear what you announce next month.

Nitya Subramanian: Thank you so much. Really appreciate getting to have this chat and thank you so much. I've been a big fan of this podcast, so it feels like a nice full circle moment.

Nicholas: Awesome. Thanks. All right. Thank you, everybody, for coming to listen and see you next week. Bye-bye. You can find links to the topics discussed on today's episode in the show notes. Podcast feed links are available at web3galaxybrain.com. Web3 Galaxy Brain airs live most Friday afternoons at 5 p.m. Eastern Time, 2200 UTC, on Twitter Spaces. I look forward to seeing you there.