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. On today's episode, I'm joined by Stellalabs co-founders Ben Sharfstein and Iman Dezi. Stellalabs' first product is Stello, a browser extension that simulates transactions and provides clarifying contextual information and a risk assessment in a pop-up before the transaction request propagates to the user's wallet. They also provide an API that gives developers access to the transaction simulation and risk assessment backend that powers the browser extension. They've used this API to create Approvals.xyz, a token approval dashboard akin to Revoke.cache or the EtherScan approvals page. In this episode, we discuss how Stello works and get a little bit of alpha about an upcoming Stello API-powered interface they're building to enable safe interactions with arbitrary smart contracts. It was good to meet Ben and Iman and get to know their thought process around wallet security and analytical data service providers. I hope you enjoy the show. Well, Ben, Iman, thank you for joining me for this episode of Web3 Galaxy Brain. I'm excited to talk about Stello today. How are you both doing?

Ben Scharfstein: We're doing great. We're excited to be here.

Nicholas: Awesome.

Aman Dhesi: Yeah, thanks for having us.

Nicholas: Of course. So maybe to start off, I'd love to get into Stello, but first, maybe you could share a little bit about both of your backgrounds before starting Stello Labs and working on this product. What were you up to before? Maybe we can start with Ben and then go to Iman.

Ben Scharfstein: Yeah, absolutely. My background is in product. I was a product manager at Google initially, where I was working on Android and then Search and working on personalization in Search and kind of how you can build personalized content without being social. And that kind of took me down this path of being interested in crypto because I realized that there were a lot of problems with what we were doing at Google related to privacy and data and stuff like that and got very into Web3 social through that. Took a little detour and started a YC-backed social company. We ended up building Social Video Chat during the pandemic. And then right prior to Stello, I left that company and Iman and I started working together on a bunch of different things. We built some identity NFT. We helped start a DAO. I worked on this fun NFT project called Blink. And then about nine months ago, we started Stello.

Nicholas: I'm curious, what was the DAO that you started?

Ben Scharfstein: We were kind of early when Archive DAO was starting. Archive is building a real world museum curated by its members on-chain. And Tom, who is kind of the brains behind Archive, was looking for some crypto-native people to help spin it up. And so we were the first few months helping to get that off the ground.

Nicholas: Is this the Harvard Innovation Labs associated project of that name or something else? There's a Harvard Innovation Labs affiliated project called Archive DAO. I don't know if it's the same one or different.

Ben Scharfstein: Yeah, it's A-R-K-I-V-E.net.

Nicholas: Oh, I see. Okay.

Ben Scharfstein: It's the same.

Nicholas: Gotcha. It's a different one. Yeah. Great. And Iman, what was your background before this project?

Aman Dhesi: Yeah. So I was a computer science PhD student back in the day, ended up dropping out, went to Silicon Valley and was doing product as well for a while. Was at Facebook a long time ago and then worked at Square and DoorDash as well. And at some point I became super interested in machine learning. And so that was most of my focus at Square and DoorDash was building automated systems for logistics and predicting how long it'll take a restaurant to prepare meals and how long it will take for any delivery to be made and giving you accurate real time updates on that stuff. And then I also fell down the crypto rabbit hole. I'd been investing in crypto since 2017, but then really fell down the rabbit hole in 21 and was particularly interested by security because I recognize that crypto adoption is being held back by just poor, poor security, poor UX. The analogy is if you were using your credit card to purchase coffee and every time you swipe the card, there was a 1% chance that you lose all of your money. Basically no one would use credit cards.

Nicholas: And only the real DJ.

Aman Dhesi: That's kind of where crypto is today.

Nicholas: Yeah.

Ben Scharfstein: Yeah. Yeah.

Aman Dhesi: Like you wouldn't use it to buy coffee. You might use it if there was a lottery ticket that could make you a lot of money on the other end. But like actual real world mass adoption will never happen until crypto is way more usable and safe. So that's kind of what got us excited to work on Stello.

Nicholas: Were you going to add something in Ben?

Ben Scharfstein: No, I was just saying, yeah, you know, just the only the airdrop farmer credit card coffee people would be using the credit card in that use case.

Nicholas: Yeah. I'm not sure if that's what the Starbucks loyalty thing on Polygon is about, but maybe.

Ben Scharfstein: Something like that. Yeah, exactly.

Nicholas: I see. So the mission is to make it safer to use your wallet so that adoption can increase and frequency of using your wallet can increase also. And I think of this often. I've talked to a few different players in this wallet security space on top of EBM. And it seems to me like as sign in with Ethereum becomes more popular, the risk becomes greater also because people are being accustomed to signing more messages and more frivolously signing things, maybe not reading them as carefully. So a solution like Stello makes a lot of sense in that context, to me, at least.

Ben Scharfstein: Yeah, absolutely. The mission is to make Web3 safe and easy to understand. And that's, you know, right now, wallets is obviously a focus. And that's really like a key area where we can have a big impact. But we also launched a website last week called approvals at XYZ, which is sitting on top of your wallet. But yeah, as you said, as crypto adoption increases, there's going to be a lot of great things that come out of it. Having more self-sovereign identity and all those things with sign in with Ethereum is great. But it also means that people are getting used to, as you said, signing messages, not necessarily paying attention. And Aman and my background is both on consumer product side. And how do you bring really good user experience and good product insights to the whole flow so that people can actually understand what's going on, feel confident in what they're doing, but reduce friction when it doesn't need to be friction full and introduce friction when maybe there's something weird going

Nicholas: on. Yeah, you definitely do have a kind of bubbly, attractive aesthetic to. I'm looking at approvals XYZ and I've taken a look at the extension also. So it seems like there's three products we should discuss today. This approvals XYZ. But first off, I think we'll start with the Stello extension. And then maybe we can hit the API that you just launched also. Does that pretty much cover the product portfolio thus far?

Ben Scharfstein: Yeah, absolutely. That's the stuff that we launched last Thursday. We launched the two of the extension. So the original version of the extension we launched publicly in September. And last week we launched complete redesign from the ground up. We launched approvals on XYZ and we launched the developer API.

Nicholas: Very cool. So I guess first up, what is the Stello extension and what's the user experience for someone who's a user?

Ben Scharfstein: Yeah, so the extension, you can kind of think about it as like a firewall for your wallet. So it takes transactions that you, you know, you're using any dApp. Let's say you're using OpenSea or Uniswap with MetaMask as your wallet. And when you initiate that transaction, say you sell your NFT, Stello will first pop up and intercept that transaction request to your wallet and say, this is exactly what you're doing in plain English that you can understand and safe. So we'll tell you things like these are the wallets that are entering and exiting. These are the assets that are entering and exiting your wallet. So you know, you're sending to Ethereum, you're receiving one NFT. It will tell you information about those assets. Hey, this is a BordApe NFT. It's verified on OpenSea. This is the floor price. Maybe if you're sending something to someone, it will show you information about the recipient. So like you've done three transfers with this person in the past. Here are some recognizable NFTs similar to, you know, if you were to Venmo someone, you'd be like, hey, we have six mutual friends. This is a picture of them. I can recognize who they are. So this is kind of all in the usability and human readability side of it. And then we'll also give you a risk analysis and say, this is low risk. This has some risk, or this is high risk. And that's based on the Stellar Risk Engine, which basically takes the asset changes, the enriched metadata, and feeds it through our system to figure out if it's safe to do. And then if you click continue, you'll go into MetaMask or whatever browser-based wallet you use and continue from there.

Nicholas: Yeah, I saw that it sort of interrupts the signing and repla- like before you see MetaMask, you see the Stellar extension. So there's no chance that you could click accept without reading through the information that the extension is providing. I just tried it out quickly and one of the warnings that it gave me when I was interacting with the contract, I think on Mint.fun, was this contract was recently deployed or has very few transactions. Be careful, especially if you believe this contract should have significant on-chain history. So these kind of contextual clues that you- maybe give you hints of what kind of diligence you should be doing, rather than categorically saying, you know, this is a bad contract or a good contract. Do you also have warnings when, like, a contract is known to be malicious or is often involved in malicious transactions?

Ben Scharfstein: Yeah, we have those as well. So the Risk Engine has a bunch of different types of warnings. So the one that you saw on Mint.fun is, like, hey, this was recently deployed. But we also have other ones that are like, this is known malicious, either because it's been reported by us. We also look at the transaction itself and say, does this make sense? Is this something that someone would normally do in a legitimate transaction? So for example, when you list something on OpenSea, you have to first set an approval to the OpenSea contract in order to list it. But a very common attack vector is malicious websites setting an approval to their wallet. And so we'll catch that and say, this doesn't make any sense. This wasn't set to a Marketplace contract. This was just set to an external account. This doesn't make sense. We'll flag it as high risk. And we totally change the UI and make it very difficult for you to proceed. You know, you can still do it. We're not going to block you from doing things. But similar to Chrome phishing warning or whatever, where they make it, you have to click some small button. We also look at signatures. So it's not just transactions. When you list something on OpenSea or on any other Marketplace, there's these gas signatures. Uniswap also uses them for listing items. And we'll also interpret those and make sure that they're safe. And these are even harder for you to understand what's happening in your wallet. They just look like a giant blob of somewhat structured text, but you have no idea what's going on. So we will interpret that in the same language. And there's a bunch of other attacks that happen with these auction gasless signatures that we also protect against. The key thing is that no solution is going to be able to tell you perfectly with 100% confidence, this is 100% safe and this is 100% unsafe. And there's nothing in between. Because there just are some unknown things. For example, if you are transferring your NFT to an address that has never seen any history period whatsoever, it's not really possible to know if that is a malicious actor. And it's very cheap and easy to spin these things up. And so that's why we need to give you the context to understand what you're doing in these kind of what we call some risk cases. We give you the context to make sure that what you're doing is what you intend to be doing. So if you think you are minting something and you're actually sending your NFTs, that's not so good.

Nicholas: I see how, Amon, some of your history at DoorDash, that kind of predictive estimation, machine learning, even potentially thinking could be relevant for this work as well.

Aman Dhesi: Yeah, exactly. Exactly. Right now, our system is mostly rules-based, but there is definitely a future where there is a lot more kind of automation and machine learning that can be done here. So we're pretty excited by that. But one of the things that I learned from building these systems is that you never want to start with an ML model. You want to start with something that is simple, that you can, that is tractable, that's understandable, it's easy to build on. And that'll usually get you most of the way there. And then ML is an amazing kind of tool that you can use to get from 80% accuracy to 95% accuracy to reduce the amount of human involvement that needs to be, that kind of stuff. Although our system is already kind of at a point where it can learn from some of the data that it sees. So for example, when we see a new website initiate a transaction that clearly looks malicious, now we have seen that that website is initiating malicious transactions. So that website must also be malicious. And that kind of goes back into our system.

Nicholas: I'm curious about the intake of data. It seems like something. maybe you could be watching the chain eventually and automatedly doing that. But at present, is there basically an intern tagging all the marketplace contracts to sort of green light those relative to proof for all to, you know, a random address? How do you ingest the data about what is malicious or is not malicious?

Aman Dhesi: We use a variety of different approaches. So we try to use any kind of public repositories that are out there where people have either labeled contracts as malicious or websites as malicious. We also try to do what you described. Our intern is Ben himself.

Nicholas: So of course, whenever there's like

Aman Dhesi: a new, yeah, whenever there's a new kind of marketplace or something that's launched,

Ben Scharfstein: if

Aman Dhesi: we actually, you know, manually make sure that that's whitelisted and then we have like a pretty robust logging system that anytime there's there's a website that initiates a malicious transaction, we're able to then go back into our data and say, OK, this website initiated a transaction that either looked malicious or just looked suspicious, medium risk. We can then go and look at it manually and then add it to our blacklist.

Nicholas: Very cool. For now, you're focused entirely on Ethereum, on Mainnet, or are you compatible with other chains?

Aman Dhesi: Yeah, for now, we're Mainnet, but Ethereum Mainnet. But we're actually actively working on adding other EVM chains as well. So we can expect that in the next three to four weeks, we'll add support for the more popular EVM chain.

Nicholas: Very cool. So on a technical level, when Dapp requests a transaction, transaction to be signed or a message to be signed, you're intercepting that package and shuttling it off to your servers where analysis is done? Or what's the flow of information through the technical process that passes it to the engine you mentioned and then back to the client?

Aman Dhesi: Yeah, so we have a back end exactly what you described. The Chrome extension intercepts the transaction. It ships up the transaction or signature parameters. This is all stuff that would go on chain anyway. The only thing that we ingest that doesn't go on chain is the URL that initiated the or the Dapp that you were on, because we use that as part of our risk analysis. But apart from that, everything else is stuff that will go on chain. So we send all that up to our back end. Our back end does all of the kind of collection of third party data as well as using our own data, runs it through the risk engine, and then sends back a response that has the human readable kind of explanation of what's going on as well as the score. And so just to briefly touch on the API that we just launched, we basically took the same API that now powers our extension and made it available to everyone else. So anyone that is building a wallet or a Dapp or even a wallet connection flow, you know, like the Rainbow Kits and other wallet connection flows, Dynamic, etc. They can also all embed Stellar screens into their products. They can also use the API directly, which allows them to choose what they want to show. and they want to show just a subset of the data, whether it's just the asset changes, risk score, they can do that. We also have an embedded version of Stellar, which is essentially what you see in. the Stellar extension can be sort of dropped into any other product and fully customized to suit the styling of the product.

Nicholas: Very cool. I want to get into the details of the API in a second. But before we jump off to that, to do the transaction simulation, do you use something like Tenderly on the back end? or how do you achieve the simulation of the transactions or of the parsing of the signatures or the messages, I should say?

Aman Dhesi: Yeah, so we basically use a standard get node. Get nodes have a function called debug trace call that allows you to get the essentially what's called the trace, which is the all the kind of actions that the EVM took. And then we can parse those and figure out what assets are moving. There's a few different providers that do this too. So for example, Alchemy, Quicknode, Tenderly, they all have this as a service. So we've kind of used all of them intermittently. We've also built our own version. Depending on what we're optimizing for, we can use one or the other.

Nicholas: Got it. OK, I didn't realize that Tenderly was really just wrapping this debug trace call function. Yeah, that's cool. Good to know. Yeah. But you touched on it a little bit. But as long as the maybe if you're an MEV searcher, then you wouldn't want to pass the message or transaction off to some other third party before signing it and sending it to flash bots. But basically, in any case where you're not planning on flash botting your transaction, there's no real danger in passing this data to Stello. Is that right?

Aman Dhesi: Yeah, exactly.

Nicholas: So I guess we covered what the security risks are of using it, more or less. It's really only the highest level of trade or that should be worried about it. So you touched on the API. So why would a wallet provider like Rainbow Kit want to integrate Stello? Or in what case would Adapt or who would be the customer for an API like the one you've built?

Ben Scharfstein: There's a few different instances or types of people that would want to consume us as an API or embedded experience. The first is obvious. It's wallets who want to basically provide the same Stello experience that we provide in the extension, but want to provide it kind of just as part of their transaction flow. And this is something that we're excited about because we definitely want to reduce the frictions and we want to increase the usability of all crypto and web3 products. And that means like not having several different confirmation screens.

Nicholas: Have any wallets assigned to do that yet?

Ben Scharfstein: We have 10 to 15 wallets that are kind of testing it out. None of them have launched publicly yet. But pre-API launch, we've been working with them kind of in alpha. Now we're in the more beta phase. People are building these flows. A lot of the wallets that we're working with are pre-launch in general, like they're launching in the next couple months. I would say I expect in the next four to five months, every major wallet will have Stello or one of our competitors integrated. This is just absolutely going to be table stakes. And I'm not sure about Metamask, but everyone else is. And I know Metamask is also thinking about this through snaps and other things. But everyone is really thinking about how you can get the transaction screens to be safe and simulated and understandable. So we're talking to all the major players and all the minor ones as well that are launching really great new experiences.

Nicholas: Very cool. Yeah, I mean, this has been one of my perpetual questions. Why can third party providers do this, but Metamask can't? And part of the answer seems to be that Metamask doesn't really want to touch the UI anymore and just wants everything to happen by third parties via snaps. But even in the landscape like Rainbow, for instance, unless it's one of the handful of transactions that they have specific UI for, they don't even show you transaction data in the app, which is I have raised the issue with them several times. It's, I think, criminal that a wallet not have any way, no advanced feature, no setting you can change, no way to see what you're signing unless it's one of the handful of like NFT transfer from ERC20 transfer functions. Pretty crazy. What do you think the moat is around this? Why is it that Metamask or Rainbow can't build this and would rather rely on you?

Ben Scharfstein: Yeah, I think that, you know, obviously we've spent the past eight or nine months figuring out the best way to do this. And I think probably major wallets, the top Metamask could. They obviously could. There are more people than we have at our company. But what we're doing is really investing in the transaction engine, in the user experience and then making sure that we have all the right data. Then as we see more of these scams pop up, like Aman described earlier, we're feeding it into our system to block sites and to flag addresses. And all of this data, like malicious addresses, malicious contracts, malicious websites eventually becomes public. Metamask actually has a repository that they maintain of malicious URLs. The problem isn't can you get it two days later? The problem is, can you get it as soon as they launch? And that is really where because we are protecting tens of thousands of transactions, we are able to see the data and immediately make our product respond and learn from it. And, you know, in the same way that anyone can run a node, but, you know, Alchemy and Infura do it like we also can run a node. But we decided to go with Alchemy for our transaction simulation for the time being because it's, you know, it's more things that you have to do. We think that there's network effects on the data side, specifically around getting the data out quicker and making sure that it's the highest quality. Because, you know, even if it just saves one percent more people from getting their stuff phished, that's usually worth it for the major wallets. And then I think as you go down to less major wallets, there are 50 companies right now that are working on next gen wallets. And each of them is not going to be able to build those themselves.

Nicholas: That's a lot. You're aware of them via like the VC ecosystem or just Twitter. Or how did you.

Ben Scharfstein: Well, so so, yes, there's a lot that we've been talking to. But also you just look at the wallet connect page. There's like. I saw some tweet the other day which was 12 pages and each one has 12 says 12 wallets on it. So there's 144 wallets just on like some wallet connect page. And some of these are older or existed. But there are at least that we know of that have even launched. every day. There's people reaching out to us, wanting to use our API and telling us about the exciting new products that they're building. And these products are getting embedded into Dapps. They're vertical specific, whether or not it's for gaming or NFTs or DeFi. They're focused on DAOs, they're focused on institutions, they're focused on trading with your friends. They're built on top of safe or built on top of MPC. So there's a ton of different things. And I think the wallet landscape is going to get very exciting in the next nine months. But all of these people are very excited about having this transaction understanding and transaction safety solve for them.

Nicholas: Yeah, it seems very important. It seems like wallets are something that's particularly sticky, hard to convince somebody to switch from one that's trusted. I wonder if the majority of the users for these new wallets will be new crypto users or or people switching, trying something new, sick of Metamask or Rainbow or whatever.

Ben Scharfstein: Totally agree. We actually started out and said, what if we were to build a better wallet that abstracted away seed phrases and that had transaction security? And we realized it's very hard to get people to switch their wallet. It's a very crowded space and we're not going to have that much value add if we build a wallet because there's already a bunch of great wallets and they don't really need more features, except what they do need is the transaction safety. And that's why we decided to focus on that and less on the seed phrase side of things, because there's lots of great teams doing that.

Nicholas: Makes a lot of sense. You mentioned also like Gnosis Safe frontends. I think that's a really interesting application of this, too. I've played a little bit with Den. I don't know if they have any Stellar integration, but it does make sense to me that you would want that kind of diligence in the interface before you sign a multi-sig transaction.

Ben Scharfstein: Absolutely. And the really difficult thing about multi-sigs is that the transaction that the safe ends up executing is not the transaction that the user signs, right? What the user signs is either an off-chain signature that says this is what the transaction is going to be, or they sign a transaction to the safe contract that says is what the transaction is. But it's in the format of like two from value data, which is how transactions are composed when they're submitted on chain. But it's not in the format of like the transfer from function. And so actually, Stellar will take those. If you use, for example, the Gnosis Safe frontend, Safe.global, and you interact with your Gnosis Safe, Stellar will interpret that transaction from the perspective of the safe and will say, hey, this is a Gnosis transaction, but here's what it's going to do. You're about to transfer these five NFTs or do the swap on Uniswap. And you go to Metamask and it's like you can't understand it at all. But in Stellar, it will make it really easy to understand. And any safe frontend can get our API, feed in the, you know, either the transaction the safe is going to do or the signature or whatever, and get the Stellar response so they can provide that same experience to their users. And they can even just, like Aman was describing, have an embedded version of Stellar where all they do is feed in the transaction and the signature. We feed them back everything that they need to see. It takes like a day to implement.

Nicholas: Very cool. Yeah, I mean, I wish Ether had some of that.

Aman Dhesi: For safe frontends, there's also another interesting reason to implement something like Stellar, which is that if you have five signers and the first one creates the transaction or signature, the other four need to know what they're signing. Right. It's not even about security at that point. It's just like I want to know what I'm signing without you having to send me a message or an email or something explaining what I'm about to sign. So even in the absence of any security concerns, there's just a simple usability use case for a Stello.

Nicholas: Yeah, it makes a lot of sense. I see a number of different simultaneous efforts to clarify multi-sig queued transactions and make sense that if you can have one API that can do it for regular transactions and multi-sig ones, that makes a lot of sense. You also mentioned like Dapps could integrate this. I guess with that, the challenge would be you're going to have to start anticipating people ripping off the UI to make it look like a Stello approved transaction, the checkout flow or something like that. I wonder if there's a way to make that clear. But the idea is basically that the Dapp could integrate it itself so that if you don't have the extension, you're getting some of the intelligence on the transaction before it's even queued up in your wallet.

Ben Scharfstein: Yeah, the idea around Dapps integrating is less focused on security and more on usability. So it's really how can we give people confidence in what they're doing in the same way that they have confidence before they check out in any experience? I think it makes most sense for Dapps that allow for user input. So if you're a simple NFT Mint site, you probably don't need to integrate Stello because you can just design exactly what that confirmation screen looks like. But if you are OpenSea or Uniswap or Mint.fun or anything else. where you're just like allowing either users to enter in addresses or play with numbers in terms of when they're doing swaps and everything, Stello can provide them a lot of confidence that what they did is correct and they didn't fat finger anything. They didn't copy something wrong. For example, one of the things that we do is when you are transferring something to someone, you can see their most recognizable NFTs, the recipient's NFTs. And so you make sure, OK, I didn't I meant to send this to my safe or my ledger. I didn't just send this to someone else. Right. And just that type of usability is really nice. And like I said, it's just a very simple integration. You can see an example of this on approvals.xyz. If you go connect your wallet or search for someone else's wallet, you can preview what that revoke transaction is going to look like. And this is powered by our Stello Embed product.

Nicholas: Right. It's a great point. We can transition to talking about approval.xyz. I guess this is a great demo of the API, first and foremost, but it's also a useful kind of in the same neighborhood as revoke.cash or the EtherScan approvals page.

Ben Scharfstein: Yeah, I would say the functionality is quite similar. The approach that we took is we want to make everything that you do easy, simple and actionable. And that all starts with wallet health score. So when you connect your wallet to approvals, it will analyze it and tell you this is where you stand on a scale of one to 100. You have a 20 and then we'll tell you, OK, here are the top things in order that you should take action on. And we'll give you a recommendation, high risk, consider revoking or low risk and make it very easy for people to understand which contracts they have approved to, the value at risk because of that approval, and then what action that they should take. And I think a lot of other tools like, you know, you go to EtherScan, it's like functional, but it doesn't. it's overwhelming. Right. And we're really focused on how do we actually make this easy and actionable?

Nicholas: Yeah, I like how you're ordering it by the value at risk. And I'm curious, the wallet health score is great. It makes a lot of sense. I'm curious how you're able to achieve the revoke all. Is that a multi-call or how do you do that?

Ben Scharfstein: It actually just queues up a bunch of transactions. OK, gotcha. So you still need to press confirm in your wallet like, you know, 10 times. But instead of having to press one by one in our screen and then go to your wallet, whatever, it will just queue up all of the ones. And you can also select like you could select six of them that you want to revoke. You click revoke selected and then it will like just one by one pop them up. So just trying to add some of that usability stuff. But ideally we could do it in one transaction. Unfortunately, that's not possible.

Nicholas: Yeah, it makes me think I had a small hand in EtherFunk.io, which is kind of like our the read write tabs of Etherscan, but just as a full website. And it makes me think that that kind of site would be a perfect application for Stello's API because you have unknown, you know, not predetermined set of contracts that you're interacting with in the DAP. So you maybe want to have some diligence on before you click the transaction. You're not so much concerned about it's not so much like a mint site where obviously if the mint site is hacked, then the Stello API calls are not that relevant.

Aman Dhesi: But because you're predicting a roadmap.

Nicholas: Uh oh.

Ben Scharfstein: All I'll say is stay tuned.

Nicholas: But it makes a lot of sense to have a page where you can do the transactions that you're maybe most worried about even.

Ben Scharfstein: Yep. Can't give too much away, but stay tuned. We had the same idea. Great.

Nicholas: Great. And you talked also about NPC wallets. I guess that's the last big use case. Maybe you could describe a little bit about how that might be relevant there.

Ben Scharfstein: Yeah, for NPC wallets, there's not really anything different than a normal wallet from our perspective. You know, they can use the API and leverage it. I think the future of seed phrase security is going to use NPC just because it's. there's less room for user error and there's less that the user has to do. And I think it's a tradeoff that many people will be OK. The kind of decentralization tradeoff that many people will be OK with. From our perspective, there's nothing particularly different. They're just going to still give the transaction to to Stello's API. We'll give them back enriched response. But I'm excited just to see all of the people building in this space because it is going to add a lot of, I think, better security around seed phrases and better usability as well.

Nicholas: I've never used an NPC wallet myself. What's what's the like leader in that space? Zengo, I see a lot.

Ben Scharfstein: Yeah, as in go.

Aman Dhesi: Zengo is a simpler version of an NPC implementation that has some nice properties like there's no seed phrase. But I know a lot of institutions use fireblocks, which uses a more sophisticated implementation where you actually have three parties involved. And even if you as the end user loses their their piece of the key, you still have two other entities that can recover it. Whereas in Zengo, I think it's I think it's either one out of two or two out of two. So you either sacrifice decentralization or you sacrifice coverability.

Nicholas: So it's not Shamir under the hood, right, because you're able to swap the pieces of the the multi-party out. You don't. Yeah. With Shamir, you'd have to create a whole new wallet. But yes, exactly.

Aman Dhesi: And with Shamir, you have to recreate the private key.

Nicholas: Right. So you need a someone new private key.

Aman Dhesi: Right. Someone either you or the second entity will have to receive both pieces, reconstruct the private key sign. And then hopefully if they do what they're saying, delete your piece of the key, which is not quite as safe as NPC, where the private key never has to be reconstructed. You can actually create the signature without reconstructing the private key.

Ben Scharfstein: Yeah. And companies like Magic Link and I think Web3 Auth are kind of the. use Google login or use social logins and get rid of private keys. And they I think both started out using Shamir's and are transitioning over to NPC. And there's other companies, you know, it's kind of the. the upgrade path is like Shamir's kind of has the same properties from a user perspective, but not from a security perspective. And true NPC is harder to productionize in a way that's secure. But once you do is is safer. Coinbase also announced I have actually used Bitcoin. Coinbase has like an NPC thing as well. So I think and then just like from the companies that we're talking to in the wallet space, there's a bunch that are excited by it. And there's companies that are also working on the infrastructure layer to make NPC more decentralized and usable. There's a company called Entropy that that's working on like a decentralized NPC network and stuff like that. So there's lots of exciting stuff coming down the line. And account abstraction, I think, is also going to change kind of the usability of wallets in cool and interesting ways. So there's a lot that's going to evolve in wallets. But as you said, it's well, it's very sticky and it's hard to get people to switch. But the total addressable market for wallets is two billion people. And the number of people with wallets today is a lot less than that. So it's all about the growth, not about transitioning over the current users.

Nicholas: Yeah, definitely makes makes a lot of sense. It's a challenging thing, because especially in the bear market, which who knows its duration, it's the only users are whatever, the ten thousand approximately acolytes. But in the long term, they're maybe not the most relevant, although they can evangelize things. They're not probably likely to change their habits as much as as new users who have no prejudices at all. It is interesting. Speaking of different wallets, I guess, how does this interact with hardware wallets? I suppose it just depends on what the software wallet, if you're connecting a hardware wallet to MetaMask, then it just works the same.

Ben Scharfstein: Yeah, exactly. So if you use your ledger, your treasurer with MetaMask, still work seamlessly. Still, it never has access to your seed phrase, private key, any of that stuff. There's no security concern from that perspective. And if you are using, let's say, like a ledger live and interacting directly and using that to compose transactions, then still won't work. So if you want to get the benefits of Stello via the extension, you have to use it through a browser based wallet like like a MetaMask.

Nicholas: Got it. Makes sense. Cool. So are there other applications of the API that you can imagine, aside from just like essentially replicating the extensions functionality inside of an inside of a website of some type or an app? Is there something else people might want to use this API for in order to just enrich their their product?

Ben Scharfstein: Yeah, I think that those are the main things. There's another one, which is like wrapping your wallet connection flow. So you can easily get Stella to work on every transaction you want by just wrapping every call that you make to the wallet connection flow and then popping it through Stello. But, you know, the kind of core use case is wallets, front ends or dApps, sorry, safe front ends or dApps that want to basically preview transactions and make sure they're safe. We're kind of squarely focused on those use cases. And it'd be interesting to see if people have other use cases, but it's very much designed to focus on transaction, understand, understand ability and safety.

Nicholas: Very cool. What's the pricing model for the API?

Ben Scharfstein: It's it's priced to sell. Let's put it that way. So, you know, we're more focused on getting as many people to use this as possible and basically pricing it at cost. So if people want to learn more about pricing, they can reach out. But it's very competitively priced. But, you know, it's kind of like per transaction call in the in the long run, in the limit and free to integrate in the short run.

Nicholas: Cool. Compared to other competitors that are out there, I know I had fire on the show a few weeks ago and also spoke with Harpy who are not really doing very different UX, but maybe some similarities in the back end. How do you think about do you see this as a outright competition, zero sum situation, or do you see each of these efforts sort of specializing in some way? How do you think about the competitors?

Ben Scharfstein: I think of Harpy in taking a very different approach to their solution. And so potentially complementary to what they're doing. I think the benefits of Harpy's approach, just for anyone's listening, they will basically mev any malicious transaction and catch it and basically buy the NFT or transfer the NFT out when someone is trying to transfer something of yours. I think the benefits of Harpy is that you doesn't just prevent against phishing. It also prevents against like a seed phrase or something being compromised. It prevents against using on a mobile wallet and stuff like that. The drawback is that you have to give them approvals and they have to be 100% sure that that's something malicious is going on. Whereas we have this whole kind of gray area in between where we're providing you and understanding what's going on and and basically use a lot more types of checks. So what we're doing can be a lot more robust and have have kind of graceful fallbacks. But I think they're great. The team there is great. Fire, I would say, is very much a kind of indirect competition. We are very focused on our users and making sure that we are providing the best experience for them and less focused on what other competitors are doing. But definitely, you know, it doesn't really make sense to have like both fire and stello.

Nicholas: But I guess it is some kind of confirmation that the you've chosen an interesting thing to work on that other people agree. And also it's such a huge market. So non-use is the.

Aman Dhesi: Yeah. And there's yeah, there are other competitors doing similar things, too. So clearly there's there's a pretty strong need for this. Also, I mean, as we sort of hinted, we have pretty ambitious and expansive plans for where to take this. So, you know, the extension and the API are just. we kind of see them as the the wedge or like the tip of the iceberg into something that is hopefully much bigger. And we're really excited about the next few things on our road map.

Nicholas: Very cool. Well, I think that's the end of my list of questions. Are there any aspects of Stella Labs that we haven't explored that you think we should touch on?

Ben Scharfstein: I'll just say the one. the one thing on the extension is that it's also open source. And that's really important. when you're dealing with these extensions like Stella, Fire or many of the others, is that using one that's open source, because we do need to ask for a lot of permissions in in order to actually execute and wrap the transaction. And so we want to be really clear about exactly how it works, what you're installing and what it has the capabilities of doing. So just would encourage people as you're using these things to focus on open source extensions and not every aspect of Stella is open source or risk and it is not open source because we don't want to expose to the attackers and malicious actors exactly every single case that we protect against. But the important aspect is that how we wrap the transaction and how we pass it back to the wallet is open source. And it is that's the part that actually has all the permissions and you can verify that exactly what we take from the dap is what we're sending onto the wallet. Yeah, I guess people are not doing anything else like changing content on the page and stuff.

Nicholas: Right, right, right. Or changing the transactions in flight before the hit.

Ben Scharfstein: Yeah, exactly.

Nicholas: It wouldn't be possible for someone to build the extension. They still have to go to an extension store because you, I guess, have the API key for your extension inside the built version, the binary of the extension, right?

Aman Dhesi: No, they could actually build from source if they wanted to.

Nicholas: Really? But how would they get access to the API?

Aman Dhesi: The API that's used by the extension is that we have some guards against making sure that it doesn't get DDoS and stuff, but it's open in the sense that it's not. it's not restricted behind an API key.

Nicholas: Got it. Well, thank you for telling me all about Stella Labs. Thank you so much for for coming to tell me all about Stella. I think it's very interesting the API you're building. I could see having even surprising applications like. I think what the next thing you're working on is is pretty exciting, especially because we're sort of working in the dark when we're interacting with contracts on Etherscan that have all the kinds of transactions between other contracts that you maybe aren't aware of. So I think it. I think it makes a lot of sense to build safe interfaces for for writing to the chain. So thank you for coming on the show and telling us about your project.

Ben Scharfstein: Thanks for having us.

Nicholas: This was great. Take care. All right. Thank you, everybody, for coming to listen. Next episode is next week, Friday at 5 p.m. Eastern Time. Hope to see you there. Thanks, guys.

Ben Scharfstein: Thanks.

Nicholas: Hey, thanks for listening to this episode of Web3 Galaxy Brain. To keep up with everything Web3, follow me on Twitter at Nicholas with four leading ends. You can find links to the topics discussed on today's episode in the show notes. Podcast feed links are available at 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.