Web3 Galaxy Brain 🌌🧠

Nicholas: Welcome to Web3 Galaxy Brain. My name is Nicholas. Each week, I sit down with some of the brightest people building Web3 to talk about what they're working on right now. My guest today is Pedro Gomez, better known as @pedruid on Twitter. Pedro is the founder of WalletConnect, the most important software for connecting wallets to dApps. On this episode, Pedro joins the show to discuss WalletConnect's origins and the architectural changes introduced in WalletConnect v2. We also go in-depth on the recently finalized EIP-6963, multi-injected provider discovery, which brings together the most popular browser wallets to solve the instability caused when more than one wallet provider is injected into the same browser session. Finally, we touch on how WalletConnect will intersect with embedded wallets and smart accounts. It was a pleasure getting to know Pedro and WalletConnect better in this conversation. 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. If you enjoy Web3 Galaxy Brain and would like to support the show, please send me a tweet or DM saying why you listen and what makes Web3 Galaxy Brain special for you. I'll post the best testimonies to the show's website. Thank you. Hey there. Hey, Pedro. How's it going?

Pedro Gomes: I'm good.

Nicholas: Thanks for coming on the show. I'm excited to talk about the EIP and WalletConnect and everything. It's great to have you.

Pedro Gomes: Yeah, I'm really excited. I've been enjoying the podcast that you've been putting out.

Nicholas: Oh, thanks so much. It's great to hear. Were there any episodes in particular you enjoyed?

Pedro Gomes: Well, I like the direction of the last episodes with the past keys. I think that's a very important topic and we're not talking enough. And with the 7212, I think that should be the main priority for Ethereum.

Nicholas: Let's get right into it. So you're a supporter of 7212?

Pedro Gomes: Yeah.

Nicholas: So you think on-chain verification of the R1 curve would be a big unlock?

Pedro Gomes: Yes, absolutely. I guess we can start from the beginning. What is a wallet? Where should wallets go and stuff. But 7212 is just a big unlocker. And smart accounts are required to make 7212 nice. But you can lead the way. But if you want me to rant for an hour, I can rant for an hour.

Nicholas: Okay, let's go with my plan. And then we'll definitely come back to this in a few minutes. So first off, where did you get the name "Pedroid"? Because it somehow sticks in my head, your handle.

Pedro Gomes: Interesting. Honestly, it's just very hard to have such a popular name, at least in Portuguese and Hispanic culture. It's a very popular name. And I just wanted something unique. And I thought of UniqueID. And I was like, "Oh, I'll just append UniqueID to it.". And then it became a thing. And then I kind of just stuck, you know?

Nicholas: Wow, okay. I never made the connection. I wasn't sure. Okay, that's great.

Pedro Gomes: Yeah, it's a very techie thing.

Nicholas: So, WalletConnect has been a fixture of Crypto UX since before I started paying close attention to the EVM ecosystem in around 2020. How did you end up founding WalletConnect in the first place?

Pedro Gomes: So this is quite interesting. Because the idea of even founding WalletConnect is actually at 2021.

Nicholas: Oh, okay.

Pedro Gomes: It's not something that has happened early on. At the beginning, WalletConnect was just an open source project. And it had a very humble beginning where it's just a solution to a problem. And that problem was remotely connecting a wallet. In 2018, if you were to build a dApp, you weren't building an Ethereum dApp, to be honest. You were building a MetaMask dApp. There was just no other way. Right. You either connect to MetaMask or you don't have an Ethereum Xperia. And that didn't feel right. That just felt a little backwards. Because if you have one wallet solution, you might as well just build the application in the wallet itself. So I was working on a wallet at the time. I was working for a company. I didn't found that company. It was called Balance. And Balance was building a portfolio application. And then we wanted to build a better experience beyond MetaMask. And that solution was, "Let's build a mobile wallet.". That's just where things are going. Mobile wallets are the future. How can we build a mobile wallet? And at the time, actually...

Nicholas: What year is that? Wow. Okay.

Pedro Gomes: And at the time, there weren't that many mobile wallets. Yes, there were some Bitcoin wallets, but actually Ethereum wallets, they were pretty much like Trust Wallet and Cypher Wallet. And those applications actually had embedded browsers because everything was so biased towards how MetaMask works. If you wanted to create a mobile experience for wallets, you have to embed an in-app browser in your wallet. And that was the only way. So Trust Wallet and Cypher Wallet just recreated what MetaMask did on desktop, but on a mobile Web3 browser.

Nicholas: Right. I remember this paradigm where you would navigate to a dApp inside of your wallet on your mobile app. But honestly, I don't think I ever even used it. But I remember that was kind of the way people were thinking about it back then.

Pedro Gomes: Yeah. This kind of goes back to even before I joined Ethereum, where the Mist client existed. And the Mist client was essentially another browser, right? So MetaMask in itself was innovation at the time. MetaMask thought, "Why build a brand new browser from scratch like Mist and not reuse the existing browser like Google Chrome that everyone uses it and just add an extension?". So MetaMask in itself was like, "Wait a minute. We can't expect the whole world to download a brand new browser to interact with Ethereum. Let's use the existing browsers and just add an extension.". And that was already a big catalyst for innovation. But then the problem was, now we're all desktop-focused. Everyone is doing everything on a desktop Google Chrome. How can we go mobile and then trust wallet and Cypher wallet? They were just like, "I'll just recreate what MetaMask did for the desktop Google, but in this little application. And I'm just going to call it a Web3 mobile browser.".

Nicholas: Now that sequence of browser-oriented, is that all off the back of EIP-1193?

Pedro Gomes: This is interesting, right? Because 1193 actually happened after WalletConnect. And WalletConnect actually struggled a lot. So going back, in order to build an app, you had to build it with MetaMask or be compatible with TrustWallet and Cypher wallet. And I just didn't think that was the correct approach. People want to be able to use any application anywhere and just remotely connect. So WalletConnect fixed a simple problem of remote connections. You can have a wallet in one device or another, and the application in another, and they just magically connect using this QR code. So that's the problem that it solved. But then it also created a different way of connecting wallets. So everyone was used to the browser experience. How does it now function for you to actually connect with the remote connection? At the time, the only SDK that existed was Web3.js. And Web3.js didn't even accept WalletConnect, right? So what I had to do was try to mimic the experience of MetaMask in a WalletConnect way, and it was extremely clunky. So EIP-1193 was actually a standardization that came from MetaMask, WalletConnect, Ledger, Trezor, all of these different connectors and saying, "Can we all just agree that connecting a wallet has a singular interface and we do not have to do the WalletConnect way or the MetaMask way?". And so EIP-1193 was revolutionary in 2019 because it catapulted all of the adoption for WalletConnect. Once it went live, it was so easy to add WalletConnect because it was just as easy as adding MetaMask, Ledger, or Trezor.

Nicholas: I've heard people refer to, and I think they're talking about 1193 as like MetaMask is just an implementation of this EIP. It sounds like the order of operations there is maybe reversed, but in practice, like window.ethereum comes from this standardization process? Yeah.

Pedro Gomes: 1193 is even a lighter version of... MetaMask is a wallet. That's the definition of MetaMask. And in order to interface with the wallet, you have this API. And this API is standardized by the specification of 1193. So it was much easier to just have MetaMask, Ledger, Trezor, and WalletConnect adapt their APIs on this singular API. It was like a unified API. If we all follow the same API, then that developers don't have to figure out how does MetaMask work, how does WalletConnect work, and they kind of just can focus on their application. That was the magic behind 1193 that allowed for a multi-wallet universe.

Nicholas: So this is going to lead us straight to '69, '63. I don't know if there's anything we want to cover in the middle, but I mean, there was this evolution. I mean, the development of things like RainbowKit, ConnectKit, all these other SDKs people are importing to let you pick between wallets. Maybe could you explain how we got from? everything is just MetaMask compatible to WalletConnect is integrated all over the place?

Pedro Gomes: Yeah. So when 1193 actually became widely adopted, the first thing that WalletConnect did was actually build a second SDK that's called Web3Model. And Web3Model wasn't an SDK just for WalletConnect. It was actually an SDK that would use 1193 and create a very easy-to-understand interface for the user to select which wallet. So the actual first SDK that allowed you to select wallets with 1193 was Web3Model. And this was at the end, like late 2019. So 1193 started being adopted early 2019. By the end of late 2019, we had Web3Model. So any data developers that only supported MetaMask could just integrate Web3Model. And Web3Model became the biggest SDK for wallet selection back in the day. Wow.

Nicholas: So that was the first time people would be presented with that "pick your wallet" provider from a list.

Pedro Gomes: Exactly. Very cool. I mean, we also have to consider that there were big applications out there building their own experiences. Like Uniswap and OpenSea, they never actually used Web3Model. They just created their own custom experiences around wallet selection. But the biggest, widely adopted SDK that any developer that goes to a hackathon can just use in a couple of minutes was Web3Model.

Nicholas: Got it. And then when did the conversion happen? I remember when I was first paying attention in 2020, 2021, there were still people who were maybe like lower key dApps were launching with just MetaMask support. And there was kind of a pressure to support WalletConnect so that you get the broadest access, like a kind of maybe decentralized isn't exactly the word, but at least a variety of wallets supported in apps.

Pedro Gomes: I wouldn't say there's like a particular moment. There were definitely a few moments that kind of pivoted the balances towards WalletConnect. Everyone back in 2018 would just look at me and be like, "Well, MetaMask is fine. Why change things that are not broken?". I got that response a lot of times when I was trying to build WalletConnect. And people didn't see the value because it was like, if you are a dApp, you want to know which wallet supports it. So if no wallet supports it, the dApps don't support it. And then vice versa, wallets want to support which dApps support it. And we had this really weird chicken and egg situation where you have to get both of them to support. So there were a couple of moments that big wallets actually pushed the adoption. So the first one, I would say, was TrustWallet. TrustWallet actually adopted it. One of the biggest wallets that adopted it back in early 2019, that actually pushed the needle a lot. And then MetaMask launched their first mobile wallet in mid-2019. And that also pushed the needle. But I actually saw a bigger shift into people's perception when SafeWallet actually adopted it. That's when we started seeing a lot of influence. When SafeWallet adopted WalletConnect, we actually started seeing dApps rushing to integrate WalletConnect. And I assume that because the SafeWallet user is usually a whale or someone who has influence over a big budget. So you might have seen some MetaMask and TrustWallet users ask them to integrate WalletConnect, but it wasn't necessarily like. these guys are carrying millions of dollars that could tip the balances of these particular dApp applications.

Nicholas: So Trust was pivoting or at least adding the functionality so that you could connect like cross-device or between web browser and the wallet rather than having to visit the dApp from within the TrustWallet. Whereas MetaMask on mobile, they needed a way to, I guess, bridge the gap between two devices if you're connecting from a soft wallet on the phone.

Pedro Gomes: Actually, MetaMask had also an in-app browser, just like they have today. So both. I actually have to thank the MetaMask mobile team for being so receptive. MetaMask team has matured and things have ossified a little bit. It's not as easy to actually make changes to the MetaMask wallet, but I was lucky enough that the MetaMask mobile team was very receptive to changes. And I proposed upfront to have WalletConnect at launch and they listened to me. And I'm really thankful for that day because it really influenced today that we have MetaMask with WalletConnect and the in-app browser.

Nicholas: That's awesome.

Pedro Gomes: For TrustWallet, it was actually... They actually needed it. So Apple actually just pulled them the rug and said, "You can't deploy to the app store anymore. We noticed you have this app store built into the application.". And it was kind of bullshit because how can you call an in-app browser in an app store? They kind of used this really wrong narrative. And then TrustWallet had to temporarily actually remove the in-app browser to make Apple happy. And the only option they actually had was, "Okay, we'll just integrate WalletConnect.". That's why people are not disconnected from the web through work.

Nicholas: Fascinating. Okay. Where's TrustWallet from? Are they from Asia?

Pedro Gomes: No, no, they're not actually. So Victor actually lived in San Francisco, but he's originally from Russia.

Nicholas: Oh, interesting. And you mentioned balance in passing. And I mean, Rainbow spun out of that also, right? So I guess it was a productive space for gestating new projects in wallets.

Pedro Gomes: Well, yeah. The Rainbow team and I have actually worked together when we were at balance. So we actually were co-workers for about nine months.

Nicholas: Very cool. Okay. So we were up to, I guess, starting to be into 2020, WalletConnect is getting broader support, Safe, et cetera. Wales are into it. All kinds of app wallets are into it for various reasons. Is there any other major step? I guess this is the era of WalletConnect V1. Yes.

Pedro Gomes: So WalletConnect V1 was, I would say, a prototype that got out of hand. I genuinely built the protocol in a week and I just published it. And I was just really more focused on adoption rather than technological excellence. And I'm glad that my ignorance put me in that mode of like, "Let's not try to be perfectionist here. Let's try to focus on the adoption.". But those things started to break in 2020 by the DeFi summer. So DeFi summer, we saw this massive explosion of adoption. And the servers couldn't just handle it. It was just so badly designed that we had outages pretty once a month. And that was super stressful because everyone was starting to depend on WalletConnect and it was going down very frequently. So that's when I started thinking about WalletConnect V2, about just completely redesigning it from scratch. And that would need to be a breaking change that everyone would have to essentially adopt a brand new protocol. And it was in 2020 that we started the work in V2. It was only in 2023 this year, in June, that we actually performed the upgrade. So it took three years.

Nicholas: Okay, so we have a branching path now. We can either focus first on 6963 or WalletConnect V2. I definitely want to get to both in this conversation. You choose.

Pedro Gomes: I mean, I can do a quick trip on the V2. One thing that I definitely want to highlight with V2 is that it allowed us to build a way more modular system. So WalletConnect V2 allowed people to essentially build sub-protocols. And we currently think of WalletConnect as just a way to scan a QR code and sign a transaction. But that's actually just a sub-protocol or what I consider like the Web3 communications layer. That layer essentially allows you for end-to-end encryption messaging between wallets and dApps. And you can do it in a very secure way. And we started building other sub-protocols like chats and notifications and authentication. And that's like the magic for me that WalletConnect V2 will be not only significantly better technologically, but also explodes into innovation where people can build on top. And I'm just so glad that it's over the hump and it was upgraded in June 28. And it went really well. And we can focus on the future. But yeah, it's up to you. Congratulations, by the way. Thank you. Honestly, the team put so much effort into this. During the transition between 2020 to 2023, what I skipped was I didn't just write the protocol, I also built a company. And I realized that WalletConnect adoption was exploding. So in 2021, we did our first seed round. And from 2021 to 2023, we grew a company from zero to 40 people. Wow.

Nicholas: Yeah, you've raised almost $25 million over three rounds with USV and 1KX leading since, what is it, March 2022? Something like that? Yes, that's correct. I do have questions about that also. I mean, what's it like working with 1KX who led the seed round and have participated in the subsequent rounds? It's

Pedro Gomes: amazing because 1KX has been able to take us a leap forward and realize that WalletConnect isn't just this open source project, but it's actually a community with a very strong brand and a very important mission that can build the infrastructure to actually enable a much better experience for web trade. And taking that leap was very rewarding for me because at least I could validate that it is very impactful. And if I didn't have that first money in the seed round, I wouldn't be able to validate it to them, like onboard big investors like USV and Shopify and other strategic investors that have been able to support us. So I'm really grateful that 1KX had that vision early on in 2021.

Nicholas: That's awesome. Does WalletConnect have a physical headquarters or is it all remote?

Pedro Gomes: It's all remote. So we actually, I think we have on average 1.3 people in the same city. That's to say that sometimes you have three people in a city, sometimes only one, but we're extremely distributed on the 42 people. So it's very hard to coincide in the same city.

Nicholas: Very cool. Do you meet up at conferences or anything like that? Or you have off-sites, I guess?

Pedro Gomes: Yeah, we have off-sites. Off-sites are quite critical to balance out the remote work.

Nicholas: Very cool. Okay, so back to WalletConnect v2, maybe without being too general, maybe if you give some specifics on what the architectural difference is between v1 and v2 that enables this communications layer you're talking about.

Pedro Gomes: So there were some improvements in terms of cryptography. We use brand new algorithms that are quite popular nowadays. Honestly, a lot of the inspiration behind WalletConnect v2 cryptography comes from the internet. This is not reinventing the wheel. When you connect to a SSL lock in your website, that uses battle-tested technology that we're essentially using for WalletConnect. The only difference in Web3 is that you're not engaging between a client, let's say a browser and a server, you actually have a wallet and a dApp. So kind of recreating what SSL does for the internet for this more Web3 paradigm. So that's the first thing. And the second thing, which I think is quite important as well, is the actual web socket management. A lot of the technology that enables this experience is having really good web socket resources. And the reason for most of these outages was actually just the servers being bombarded with too many web sockets. So we had to completely re-architect how we manage these web sockets. And now we have a fully regionalized server where anyone in the world will be connected to the closest server with very low latency. We cut down, for example, someone in Australia that was connecting in two seconds to 300 milliseconds, for example.

Nicholas: That's great. Yeah, I remember when there were troubles in 2021, that people were talking about changing the relayers, and that it was a challenge with them being overwhelmed. Is that what you mean by too many web socket connections to too few servers? Yeah.

Pedro Gomes: Honestly, we even hit problems, even at the Linux level, where there were too many sockets open, even for the operating system to handle. That's how bad the situation was. And now we have servers that not only can regionalize, but they can also auto-scale. So you can just automatically spin up more servers if needed and distribute the load without having any interruption in the user experience.

Nicholas: Pardon my kind of silly question, but is it required that you have some kind of relaying infrastructure? It's not possible to have a direct connection to the RPCs, or I don't know, maybe you could explain a little bit about why it's necessary?

Pedro Gomes: So the good thing about 1.1 Connect V2 is that it has a way more modular approach, and it also has some interfaces that allow you to negotiate how you're actually going to create an interaction. One of them is actually picking the relayers. One thing that we would like to explore in the future is that, what if you could actually use different mechanisms than web sockets? One of them being WebRTC. WebRTC, or web real-time communication, is commonly used for having video calls. And the way it works is that instead of having a relay server, you actually have a signaling server. So you still have a server, but the server is only used for the initial handshake, and then the communication is actually happening peer-to-peer. However, there's other considerations to take about how often will the user be online and offline, and then wallets are not very reliable because if your phone puts your app in the background, the WebRTC connection disconnects, and you have to do the handshake all over again. So there's some advantages to WebSockets given the current context, but involving WebSockets to WebRTC is a path that is possible to do with WebLogin V2 without requiring people to upgrade the whole community.

Nicholas: I know that there are some things like GunDb that package the WebRTC handshake server into the client even, so you can maybe, at least hypothetically, there are ways to potentially even remove the need for that third-party centralized handshake server. I don't know if you've seen that stuff.

Pedro Gomes: Well, the good thing about WalletConnect V2 is that we're actually decentralizing the servers, and we're actually creating WalletConnect network. So you could potentially do the signaling through the peer-to-peer network that we're creating and not actually use it for the actual whole session. So the WalletConnect network itself, as it decentralizes, and if you add WebRTC into the mix, then the network can be the signaling server for you, and you don't have any centralized components. And then you connect peer-to-peer to reduce the latency.

Nicholas: Got it. Is there an incentive for people to operate those nodes in that network?

Pedro Gomes: It's actually quite a hard problem because a lot of the centralized messaging networks that have been built in the past, like for example, if you consider Whisper, which was part of the Ethereum project and then it was killed, Waku, which was part of the Status project, and the other one would be Matrix, they all had huge compromises in latency. And if you think about the WalletConnect experience, latency is one of the most important things. Nobody's going to scan that QR code and wait two seconds for it. You need 300 milliseconds or less. And decentralizing it actually hits the latency very badly. So we actually are doing this in a very, very, very progressive way. So the first thing we're going to do is not actually do a fully decentralized network, but actually a federation of selected partners that actually can run the nodes to slowly onboard more partners. And then we hit the point where we feel confident to actually make it into an open network.

Nicholas: I guess the latency is probably the reason, but there is no other network that you could piggyback on. I don't know. Farcaster is probably not an appropriate one, but it's sort of hot lately. There's no other existing. Even just looking at Farcaster, one of my reactions to it has been like, "It's awesome. I love the application, but is it really necessary that we create entirely separate gossip networks when we already have one built into the mempool, and we're already doing another one for bundling transactions for L2s and for AA wallets?".

Pedro Gomes: Well, gossip networks are cheap. There's no problem in segregating gossip networks, and especially when they have very different considerations. Farcaster is an amazing project, which I personally love. And you have to consider that Farcaster talks about multi-party interactions in public data. So that in itself has very different considerations of how it would work as a network compared to WalletConnect, which is like a two-party system in private. So it already has to be designed completely different about the networking, and it would have completely separate gossip networks.

Nicholas: I guess maybe gossip is a sort of commodity thing to spin up, but getting that installed base of nodes operating a new network seems like a... I see this also, and we'll talk about it later. But in AA, a lot of people are using MPC from Lit Protocol, for example, to get a K1 signature from a passkey, for example. They use Lit Protocol. But of course, then you introduce this dependency of the Lit Network, which is a whole separate network with its own centralization or decentralization challenges.

Pedro Gomes: To be honest, the goal shouldn't be that we all use the same gossip network, but that all gossip networks are interoperable. That's a big distinction. Because if you try to actually make everything into the same gossip network, you might actually hit huge latency problems, because then a message now to propagate will take significantly longer. And it's much easier to just have points where they actually bridge between each other.

Nicholas: I guess the big problem is, well, two things. One, censorship. You don't want to be relying on some network of a proof of authority. WalletConnect network could potentially censor users, I guess. And the other thing maybe is some amount of liability or responsibility if you're able to censor transactions. Do you have any thoughts on those things?

Pedro Gomes: Well, we actually have a very easy problem here, right? Because we're end-to-end encrypted, we have zero addresses, we have zero transaction information. We actually know nothing about these wallets. The only thing we know is that there's some message that needs to be routed from A to B. So we actually have no concerns there regarding censorship.

Nicholas: Okay, that's great. And so is there any reason why someone would be motivated to do this? Or it's just something that maybe WalletConnect will pay for the foreseeable future?

Pedro Gomes: No, we have a good draft about how we actually can build incentives in this. But even with the most optimistic use cases, the incentives wouldn't hit within the next two to three years. And we would need to bootstrap some reward mechanism where running a node would be just blindly being incentivized without actually being KPI-driven. So there's a lot of things to consider. It's very hard to get people to run nodes. So you essentially have to subsidize for the first two or three years by having this massive treasury that rewards people for running nodes, and slowly fading away. Kind of like how Bitcoin halvings work. And then eventually, you just have a network that's based on fees exclusively.

Nicholas: I was wondering if there's any crossover with restaking and eigenlayer. But I guess, given that all the data is encrypted, there's no real risk of censorship. So you don't really need to have a stake associated with it.

Pedro Gomes: Yeah. Honestly, even if there was a stake, the stake would be considered more about availability. It wouldn't really have many. It's very different to what eigenlayer is building.

Nicholas: Right. Why do I need to register a project ID when I use WalletConnect v2?

Pedro Gomes: That's actually a good question. So when we actually had WalletConnect v1, one of the main problems that we had was number one, we actually couldn't track who actually was driving the most traffic. And number two, we actually had people just taking down the network, and we couldn't actually see who was it.

Nicholas: Oh, wow.

Pedro Gomes: So the project ID gives us two things. Number one, actually tracking down who's actually blocking other people from using it. It was really annoying to have one project take down the whole server, and then the other project were complaining and they did nothing wrong. So with project ID, we actually can have some quotas in place so that people can actually behave. Sometimes it wasn't even malicious. Some people just misimplemented the SDK, and they were just DDoSing the network because they just did it wrong. So it's not always malicious. It's just people sometimes need to be a little bit handholding.

Nicholas: Classic.

Pedro Gomes: And the second thing is, we actually have to have customer support. And when I say customer support, I don't think about the end users. I'm thinking here about developers who use WalletConnect. They need to have a much better experience. And with project IDs, we can actually give you actual data about, "Hey, this is happening with your project. You can improve your experience by doing X, Y, and Z.". And this has been very helpful even to detect which wallets have the best experience. How many wallets actually fail to connect? This is a metric that we didn't have in WalletMV1. And now we actually can go back to the wallets and say, "Hey, we noticed that there's a 0.5% rate of people failing to connect.". And then we track down working together with a wallet and we actually gave them some QA and then they came back and improved their experience. And we can see the numbers going up with people having a much better experience.

Nicholas: That's great. Are there any limitations on who can get a project ID? If I recall, it's just an email. But do you anticipate limiting people or requiring, maybe KYC is an extreme term, but some amount of revealing who they are in order to get a project ID?

Pedro Gomes: The beauty of building an end-to-end encryption communication layer is that we don't actually have many concerns there. We just follow the most basic rules that you would have had if you create a Dropbox account. You can go to our privacy policy and pretty much if you're not doing illicit behavior, then basically you're good. It's very, very basic. We're not a financial company. We don't need to do KYC. We're basically just providing software for developers.

Nicholas: Would TornadoCash today be allowed to use WalletConnectV2 or would you have to kick them from the network?

Pedro Gomes: We wouldn't even be able to actually know if it's TornadoCash because the TornadoCash is being censored because of the actual addresses, not because of the actual interface. So if TornadoCash.com creates a WalletConnect account, that's very different than the smart contract, right? So we actually don't have information over the smart contracts that are being used. We only have information about the actual domain that's being used. And the domain was not censored. It was the smart contract.

Nicholas: You mentioned analytics being one of the advantages of the project IDs. Can you give us any insight into how many wallets are actually popular in the world? I'm curious how many wallets there are, but I'm even more curious, how many wallets have actual traction?

Pedro Gomes: Well, we don't currently have any public information other than the WalletConnect Explorer. We currently have more than 600 wallet projects in production, which is kind of mind-blowing to even think that there's 600 teams out there. Even if the team means one single person building a wallet, building a wallet, which we would believe there's only two or three, there's actually 600 projects registered today in WalletConnect that are wallets. And on the dApp side, we're ranking between 12,000 dApp applications. But then when you actually look at the traffic distribution, the Gini coefficient is very, very high.

Nicholas: Yeah, my impression is that there's a handful of popular wallets and many other wallet projects, which is great to see. But just as we head into a transition into, at least a part transition, to things like Passkeys and AA wallets, it seems like maybe if your wallet is not in the top 50, maybe there are better technologies to restart with today than competing with Metamask and Rainbow and company.

Pedro Gomes: I would even say top 50 is quite generous.

Nicholas: Yeah, I was being generous. Okay, so maybe we can look forward to some public data on that one day. You mentioned the safe connection being a kind of watershed moment for the adoption of WalletConnect. When someone connects as a safe to a dApp, is that just WalletConnect under the hood? Or I've seen some sites have to, maybe because of course or something, have to make special affordances to allow the safe to connect. Is it really just WalletConnect under the hood?

Pedro Gomes: Yes. So there's two ways to connect to the site, right? There's the safe SDK, which basically you're essentially embedding the safe experience in the dApp. And that's not WalletConnect. But when you actually go to the safe app.safe.global, and then you connect your wallet, and then you connect the safe to a dApp, those are actually two WalletConnect connections. This is what we call a hybrid. It's very unusual that we see these applications where it's not a dApp, it's not a wallet, but it almost proxies through a wallet to go to another wallet to go to a dApp. And basically, you have to have two WalletConnect connections, one for the wallet that's signing the safe, and then the safe to actually interact with a dApp.

Nicholas: I guess it's unusual, but going to become much more common in the very near future with 4337.

Pedro Gomes: Well, I don't know. I don't know. Actually, I would like to discuss a little bit the terminology what it means to be a wallet. A wallet isn't an address or even an account. A wallet is any software that manages multiple accounts and signers. So safe technically is a wallet, but then it also has wallets connecting to it. And these wallets are in the context of safe, not wallets, but actually signers. And the big difference with 4337...

Nicholas: Even worse, they're owners in the safe context.

Pedro Gomes: Right. Yeah. Honestly, I think the terminology needs to be consistent across the board, because otherwise we're going to get everyone confused. And when I say everyone confused, I'm not talking about end users. Developers will be confused. A difference between a normal account versus a smart account is that the normal account is single signer, single payer, and single recovery system and single signing scheme. So basically what smart accounts make is that accounts are now multi-signer, multi-payer, multi-recovery and multi-signing scheme. Right. So basically it just makes everything more broad. Multi-signer means that you have multiple signers. These signers could be different owners or it could be the same owner that just has different devices. Or it could even be broader, where the idea of a wallet isn't so much the application on your phone that then connects to the dApp, but actually it lives on the dApp as well. The wallet could live on the dApp by just having its own signer in that dApp. And that would be the major difference that could even kill WalletConnect, if you think about it. Why do you need to connect your wallet if the wallet can live in the dApp? Smart accounts are revolutionary in that way, right? So we need to kind of stop thinking about wallets as the actual addresses or accounts, but actually thinking of them as dedicated applications for managing your accounts, which the dApps are not designed for.

Nicholas: Yeah. If you think of something like Frentech and the way they're using Privy, although it is an EOA via Shamir embedded into the app, you could imagine that being a passkey or even Shamir that is EOA on a AA account on an L2 base or somewhere like that. So in those circumstances, yeah, there's not really this need, at least as long as you're staying within the Frentech experience for WalletConnecting at all, because you've got your signer right there. Yeah.

Pedro Gomes: But then that still doesn't solve the problem, right? Because the problem with solutions like Privy, Web3Off, Magic, I don't know, we can name a few, and they're all just signers, right? They're just decentralized signers, right? Instead of having the key in one place, you have the key sharded in multiple places and now it's accessible across different applications, but it still has all of the inconveniences of the normal account. You have to pay for your own gas. You always have to recover in the same way. It's not really a solution to the accounts. It's a solution to the signers. And I think that what we actually need to solve here is the accounts need to become smarter. And that's what Fortune Crew 7 really fixes here. And that's what I would believe is the bet for WalletConnect to go forward.

Nicholas: So right, because what you're saying is experiences like Frentech with Privy are very convenient, but they've basically jettisoned the whole thing that WalletConnect was trying to solve for, which was the interoperability of an account with multiple different applications. So of course, you don't need WalletConnect in a world where you have just embedded signers directly inside of the apps, but you also can't sign into other apps without something like WalletConnect in the middle. So yeah, I'm curious if you have any thoughts on where that's going.

Pedro Gomes: Yeah. So one thing that's important to note is that the definition of WalletConnect used to be just a protocol, but then the WalletConnect, the company, actually builds significantly more technology than the protocol. The protocol is just like 20% of what we do. We build Web2Module, which is like the best experience for you to actually select your favorite wallets. And we're also going to have, similar to how Privy has email login, we will have email login also embedded in Web2Module. And I actually view the world going forward with smart accounts. So smart accounts will be embedded into the Web2Module experience. And then again, we also have Web3 inbox, which allows you to have all of your notifications and conversations in Web3 world aggregated in a single place where you can port around your inbox in your wallets and your dApps and basically have all of those conversations following your wallet. So it really doesn't seem to affect the vision. It might affect the remote connection part, which is what got us here. But like remote connection was always doomed in the beginning, right? It was a temporary solution to a very archaic ecosystem like Web2.

Nicholas: So this is, I mean, there's a number of companies. It would take too long to list all of the efforts that are trying to build this kind of new generation of wallet provider that is compatible with this kind of embedded wallet, embedded signer experience. And some of them are angling, it seems, to create a cross dApp experience. so that, you know, let's just say your account that you're used to using inside of Frentech is now maybe eventually going to be useful in other contexts as well, which is great for interoperability and just the liquidity that's in those accounts makes a lot of sense. Maybe you would prefer to call them wallets instead of accounts. You tell me.

Pedro Gomes: They're still called accounts, right? Like the definition of an account is an address in a specific chain, right? So account equals address plus chain. Like the address is not the account, but the wallet is also not the account. Like you have an account on Optimism and you have an account on Base and you have an account on Ethereum. They might have the same address, but there's three separate accounts. They have separate states, separate assets, and separate balances.

Nicholas: So you're saying about the future for Wallet Connect. in addressing this kind of smart account system rings a little bit of a bell with what I heard Mike Damaris mention on the recent Bankless appearance that he did relative to Rainbow and RainbowKit in particular. And he didn't give too much detail, but part of what he suggested was that maybe RainbowKit would be able to offer you a shared wallet between different experiences, different dApps where you could have your Rainbow wallet accessible with some kind of signer that's embedded in the applications, but sharing an account. So I guess that's kind of similar to what you're thinking. a one path forward might be for at least a part of Wallet Connect's feature set.

Pedro Gomes: Well, we're going to ship that like very soon, like definitely before the end of the year, hopefully next month. And we will have a cross dApp account. And what that means is that you have a normal account. So it's a single signer account. And we will essentially port around your signer across different applications, which is something that is not very common with these NPC providers. Because the NPC provider usually, when you log in with that signer, it only works for that app. So if you have a cross dApp experience, that means that signer is usable across different applications. Therefore, you have the same account. This is still not smart accounts. Like, this is just the beginning, right? We're solving the user experience by just porting the signer around. But ideally, you would have one signer per application, but the same smart account everywhere, right? So this is just like our intermediate step before we actually go full on on smart accounts.

Nicholas: Right. Do you think that the shared, porting the signer around, that signer is in your mind, a passkey or something else?

Pedro Gomes: Right now, it's email. So we're going to start with email and social logins, and then passkeys might follow up.

Nicholas: Okay, so basically, you do the authentication off-chain that gives you access to essentially, WalletConnect. under this part of the service that WalletConnect provides will basically hold like an EOA that will be the signer, and you'll authenticate to access that EOA via email. Exactly.

Pedro Gomes: So basically, any dApp that uses Web3 model SDK will have the same email account that will be ported around, right? So you will get the exact same address of the same chain with the same signer, as long as that dApp has integrated Web3 model.

Nicholas: Very cool. So I guess you just have to make sure that the dApp is safe, because if a dApp, if you grant access to that signer to a dApp that is manipulative, could they do one-click transactions? Or will you need to verify the transaction, sign the transaction in some other interface?

Pedro Gomes: The user still approves the transactions. We don't have blind signing built in. This would be something that would kind of go against a lot of the designs that we have. Users must always approve the transaction. Honestly, anyone who promises blind signing, I would just say, "That's just bullshit.".

Nicholas: So that would be something that the SDK from WalletConnect would implement and display inside of whatever dApp integrates it. So you could always rely on that. If you see this UI, you know that you're signing with WalletConnect.

Pedro Gomes: Exactly. We have a secure website where you can manage your email wallet, and then you can have this little prompt that tells you, "You're about to sign this from this dApp.". Otherwise, you would compromise the whole security of the wallet.

Nicholas: Okay. So last question on this. So if I sign in with an email using this new WalletConnect service or a social login, like you mentioned, which is very cool, when I go to do an action inside of, let's say, this Frentech2 alternative kind of application, I press the button to purchase a key, I'm then kicked into a different context, a different application on my phone in order to sign that? Or it can still happen within the context of that app?

Pedro Gomes: It's still within the browser, but a different application. So it's almost like its own wallet, right? But it's embedded into the browser experience, right?

Nicholas: So it'd be like a different tab, or it would be in the same window where Frentech2 is?

Pedro Gomes: A different tab.

Nicholas: Okay, got it. Very cool. And you touched on permissions, the ultimate destiny for this stuff, and I totally agree, is that we have separate signers for each application that share a wallet, but with some kind of permissioning scheme. Are you interested in EIP-6900 and the modular stuff coming out of AA, features related to that? Or do you have a different idea for how permissions might be managed?

Pedro Gomes: I love smart accounts, but it definitely is still maturing. Whether it's going to be SafeCore or 6900, it's still too early to say. I think it's amazing that we're going towards... 4237 just started this amazing movement, and kudos to the authors for starting this movement. But it's still too early to say what's going to be the modular smart account that we're all going to use.

Nicholas: Awesome. Okay, let's round out the Wallet Connect V2, and then we're definitely going to get to this EIP we want to talk about. No worries. So lightning round, why do transaction requests sometimes not propagate to Rainbow for me when I'm on a VPN?

Pedro Gomes: Interesting. There might be some problems with the specific VPN. VPNs are not always the same. I also use VPNs, and even within the Wallet Connect team, we've seen inconsistencies with this problem. But unfortunately, there's only so much that Wallet Connect can give. We've handled many, many edge cases on when sockets might be cut off by some proxy server or VPN or people having custom DNS servers. But without much more context from your specific situation, I can't give you a straight answer. And maybe you should report that to the Wallet Connect team.

Nicholas: All right, we can talk about it offline. Yeah. All right, we'll do. I've complained to Mike a few times, but I'll get in touch with Wallet Connect directly. So do you anticipate --we kind of touched on this just a second ago-- but do you anticipate that mainstream users like a year from now, two years from now, will still be doing this flipping between authorization, like signature request, two different contexts where there's the DAP, or maybe we move to calling it an app like Arbitrum is pushing for, and the wallet or the place where I'm signing, be it a signer or whatever kind of software in another tab, in another app. Do you still imagine that people are going to be flipping between one and the other, and that things like the frantic experience will be perceived of as not as safe? Or do you think that we will eventually achieve a world where you'll be signing pretty easily but securely inside of the context where the transaction was initiated?

Pedro Gomes: I think it will be like, I'm going to give a very negative view. It will take 10 years until we actually have blind sign.

Nicholas: I love it.

Pedro Gomes: Like blind signing is like an extremely hard problem to solve. And the only way that we could solve it is by having very granular control over delegate keys. And this would mean that you as a user would have a smart account where you would delegate a key, let's say a pass key to a particular application, and could only sign in very constrained rules, and then you could have blind signing. But then in order for you to have like that control over like the rules that that key can sign, then you can't have blind signing. So blind signing is very, very hard. So 10 years, I don't think it's even negative. I think 10 years is actually very optimistic.

Nicholas: I love the realistic long term predictions. I'm always telling people, maybe it's going to be like the transistor and it'll take 50, 60, 70 years before there's real mainstream adoption in the end user context of the technology. And we should be prepared for like really long durations like that for adoption of crypto stuff.

Pedro Gomes: Well, when I started Wallet Connect, I thought it was going to take six months to solve all my problems. And I've been doing this for five years. So like, even I made terrible predictions in the past.

Nicholas: We're going to be old and still talking about this stuff. That's great. So, okay, this is a bit of a big question for rounding out the conversation on V2. But can you just explain to me, like, what is it? Like, what is being propagated when I click a button in an app and I'm connecting my wallet or when I'm triggering a signature request? What data is being passed from who to who? Who are the players in the system?

Pedro Gomes: It's JSON-RPC. So basically, a dApp and a wallet talk through JSON-RPC, just like a dApp talks to a node. Like the whole Ethereum ecosystem is built around JSON-RPC standard. And it's amazing. And I really enjoy it. And the only thing that changes in Wallet Connect is that you actually encode that JSON-RPC into an encrypted message that is sent to the relayer. And then the relayer delivers it on the wallet, and the wallet is able to decrypt that message and read the JSON-RPC. So it's just a bunch of encrypted JSON-RPC. That's the only difference between Wallet Connect and any other wallet connections.

Nicholas: Amazing. So it's encrypted for the private key. So the wallet, having the private key, is able to read it?

Pedro Gomes: No, no, no, no, no, no. There's a completely different set of keys and key management and encryption. We don't even use K1. We use like ED25519. We don't need to use that wallet private keys. In fact, none of the Wallet Connect SDKs have access to wallet private keys ever, which is also something that makes me sleep much better at night.

Nicholas: That's great. So the wallets basically have a whole separate system of private keys in order and it's encrypted for those?

Pedro Gomes: Exactly. So Wallet Connect SDKs have their own key management system built in. So wallets don't have actually to think about this. We do this for them and embed it into the clients that we deliver for them.

Nicholas: Wow, very cool. And that's a since V1 thing or that's new in V2?

Pedro Gomes: Since V1. It's just like V2 would actually use much better technology rather than V1, that was kind of like a prototype.

Nicholas: Very cool. And so because that's the infrastructure, that's why you get encrypted chat for free?

Pedro Gomes: Because Wallet Connect V1 and V2 are basically a chat conversation between a dApp and a wallet. But instead of actually talking about life and the weather, they're just talking about JSON-RPC.

Nicholas: The important subjects in life, really, right?

Pedro Gomes: Exactly. Everyone wants to talk about the weather.

Nicholas: So you built this encrypted chat thing. Is that something people can play with today?

Pedro Gomes: Not yet. We're focusing on dApp notifications as the main use case. We will slowly evolve into the chat use case, which is something that people have been asking for. But we're focusing on our customer demands first.

Nicholas: So once that ships, that would be something like I hit a transaction on Uniswap and then Rainbow Wallet on my phone or whichever Wallet Connect-enabled wallet would then be able to prompt me with an iOS native notification, but that was propagated via Wallet Connect? Yes.

Pedro Gomes: So that's basically the use case. And it also allows you to actually have notifications before, right? So it can actually prompt you to say, "Hey, your liquidity pool is actually going to go out of range. Maybe you should go and visit Uniswap and actually adjust the liquidity.". So it's not just for things that happen off-chain. You can also have off-chain notifications that prompt you to actually make new transactions.

Nicholas: Super cool. We love re-engagement. And it does feel like crypto apps are kind of stuck in the Stone Age with regard to modern app design and notifications is definitely a huge part of that. So that's exciting.

Pedro Gomes: All right. I think we should talk about...

Nicholas: Do you have a date on that?

Pedro Gomes: Well, notifications is coming very, very soon. So I don't want to jinx it, but like...

Nicholas: Sure, sure. It is October 13th after all.

Pedro Gomes: Everyone who's listening to this will have notifications very soon and they should follow Wallet Connect on Twitter to see when it's happening.

Nicholas: Very cool. Okay. But we should talk about 6963.

Pedro Gomes: Wallet Connect is such a big topic.

Nicholas: Let's talk about it. Totally. Okay.

Pedro Gomes: All right. So 6963. Why did we even do this? The first thing that we wanted to achieve with Wallet Connect was bigger diversity of wallet applications, allowing an open market where anyone can build a wallet. But unfortunately, this wasn't the case for browser extensions. Like people, when they downloaded a browser extension, what it did essentially had this JavaScript variable that was called window.Ethereum. And that's how you actually had the API between MetaMask and the dApp application. However, if you had two wallets installed, then they both were using the same API and were conflicting with each other. And a lot of wallets tried to gain market share. As a browser extension, they failed because people would then have to uninstall one of them. And most of the time, they actually uninstalled the new one rather than MetaMask. And then MetaMask kept having this big mode because it owned the window.Ethereum. Everyone used MetaMask for the window.Ethereum. But what about the new one? So 6963 solved this problem.

Nicholas: I think I remember experiencing this when Brave put out their fork of MetaMask and it started conflicting with MetaMask. Is that possible?

Pedro Gomes: That's exactly true. And Brave being the browser, they actually had to circumvent this by actually changing how the browser works. And they had to block any other window.Ethereum injection and have the Brave wallet overtake that. So even Brave, who actually delivers an end-user browser, was facing this problem, right? So even if you own the browser, this was a big, big problem because it wasn't designed in an interoperable way. So 6963 is the Wallet Connect team working together with the wallet to actually have an interoperable experience, not for mobile wallets, but for browser wallets. It's essentially what Wallet Connect did in 2019. We did it now for browser wallets. And it was an amazing effort because we went from an idea to implementation in less than six months.

Nicholas: Wow. And with the cooperation of a bunch of wallets, you said, too.

Pedro Gomes: Absolutely. So we had Encrypt, which was one of the first wallets to implement this in production. Then we had Zerion, we had Brave, we have Talisman, we have Frontier, we have xDeFi, we had Rabi, MetaMask, Rainbow. It's a huge list. By the time the EIP was actually approved, we already had 12 wallets in production. And in the following weeks, we will see pretty much another six wallets implemented. And maybe by the end of the year, every single browser wallet will support 6963.

Nicholas: And by the sounds of the list that you just named off, those are probably a good majority of the number of active wallets actually are already kind of on board.

Pedro Gomes: Active accounts.

Nicholas: Active accounts, right.

Pedro Gomes: So that's a big difference. So yes, that's true. If you have, for example, MetaMask is predicted to have it by the end of the month and Coinbase by next week. And I think Trust Wallet is also coming soon. So if you have MetaMask, Trust Wallet and Coinbase, and we already have Brave Wallet as well, we have Xerion, we have Rainbow. We have a lot of wallets already supporting this. We pretty much cover the 95% of users or browser wallets with a standard that was built in six months. It was an amazing effort. And I'm really glad that not only the wallets collaborated on this, but the Wallet Connect team, we have the DevRel team, Tom, Boydew and Glitch working together with dApps and wallets. And Elio, who's the Web3 model lead, he worked on a new upgrade for Web3 model that enables 6963 by default. So if you install a Web3 model SDK, not only you're preparing yourself for the future email login that we're shipping, but you're also having 6963 built in by default.

Nicholas: So let's run through what the UX is like for someone who's using a dApp that supports this to start, and then we can get into some of the technical details. Is this similar to how wallets are presented in the Wallet Picker screen? Or what's the experience for someone landing on a page and hitting Connect Wallet?

Pedro Gomes: That's exactly true. So as you would use an SDK like Web3 model, you would have a prompt to essentially select MetaMask, Coinbase, Ledger and Wallet Connect. But you didn't have much choice. And sometimes some dApps would actually rephrase or rename MetaMask to detect the actual wallet installed or just have a generic name like Browser Wallet. And basically, it was like a guessing game. I'm going to press this Browser Wallet and something will come up. If you had multiple wallets installed, you never actually knew which one is actually going to be hit. So with 6963 instead, you will see exactly the wallets that you have installed listed. So these wallets, if you have installed, let's say MetaMask, Trust and Zerion, those three wallets will be listed in the wallet selection and then you can hit the wallet without any conflict. So now not only can you connect multiple wallets at the same time, but you can connect exactly the wallet that you want with the dApp that you want.

Nicholas: Yeah, I saw in the EIP that wallets were having to resort to tricky things like delaying attaching themselves to window.ethereum in order to try to get to be the last one.

Pedro Gomes: It was actually much, much worse than that. There was actual war between them. It was really funny because they were having all of these games where they would delay it, but then some wallets would actually have an event listener when they saw the window.ethereum being overwritten, then they would overwrite it on top. And then Coinbase actually would scrape any wallet that was installed and put it in an array, but then overwrite it to put their wallet first. It was like every wallet had their own strategy to take over the other ones. And instead of collaborating, they were fighting with each other. And that's what I find beautiful about WalletConnect because we don't build a dApp or wallet. So we're so neutral in this ecosystem that we don't care who wins. We just want everyone to work in this beautiful experience.

Nicholas: That's great. So we're talking exclusively now about browser extension wallets, or would this also include things that connect through WalletConnect, like the typical mobile wallet experience?

Pedro Gomes: No, because the mobile experience has already been solved. As soon as you hit that QR code, you're able to connect as many wallets as you want, and it will work with any wallet that supports WalletConnect, which is pretty much every wallet since there's like 600 wallets that support WalletConnect. 6963 is doing what WalletConnect did back in 2018, but now doing it for browser wallets. So thanks to WalletConnect, we actually saw an explosion of mobile wallets, which we now count on 600. We right now count that there's around 35 or 36 browser wallets. With 6963, now everyone will be able to create a browser wallet. So we might see that number of 36 now exploding to 600 as well. And now everyone will have both a mobile wallet and a browser wallet. So now you can actually pick, right? So if you're downloading Rainbow, you download a Rainbow browser wallet or a mobile wallet. If you're downloading Zarian, is it a browser wallet or a mobile wallet? It will always be that choice, right, if you're doing desktop or mobile.

Nicholas: So if I land in a new, let's say a pet.tech and I hit connect wallet, let's say it's not got an embedded one, I hit connect wallet. So I'm going to be presented with WalletConnect, which would allow me to scan with QR or copy the link. And then all of the wallets that I have installed in my browser, assuming I'm logging in from a web browser in this case.

Pedro Gomes: So it obviously will depend how many wallets you have installed, right? So if you only have one wallet installed, the experience might not change at all. Like you only see the wallet that you have installed. But as soon as you have like two wallets installed, let's say you have like Metamask and Brave, you will see Metamask and Brave listed side by side with WalletConnect because WalletConnect is the only option for mobile wallets. And for browser wallets, they will be listed in your screen.

Nicholas: It's interesting because some of the, I don't know what you call them, wallet connection kits, the SDKs, will like break out WalletConnect into multiple. So they're not like, some will show the different in the pre-6963, they're showing different like Metamask, Rabi, et cetera, and WalletConnect. And others will show Metamask, Rabi, Rainbow Mobile, other like specific mobile wallets. Do you think the UX going forward is that? I guess because 6963 allows it to detect which extension wallets are installed to the browser, it'll only show surface the ones that are actually installed and then like a generic WalletConnect. or maybe some providers will break that out if they have like a branding reason that they want their own icon to show specifically?

Pedro Gomes: Yeah, honestly, it's always a branding reason. Like technologically speaking, there's only two types of wallets. There's browser wallets and there's mobile wallets. So theoretically, there should be one button that says browser, one button that says mobile, right? But obviously this doesn't work for marketing reasons. And wallets will always be competing for the attention of the users. So having those logos up front in every single DAP when you connect, it's extremely important for them for adoption. So they will break down even something that is a WalletConnect wallet into its own button. Like it's not a technological problem. It's a business problem.

Nicholas: So I guess given the adoption that you're previewing here, there's going to be 6963 wallets. And is there an EIP for WalletConnect? No, not really, right?

Pedro Gomes: Actually, there is. The QR code is standardized as 1328. Great.

Nicholas: So there's only two kinds of wallets, 1328 and 6963. And then I guess backwards compatibility with 1193.

Pedro Gomes: Well, so this is the misconception of a lot of people. like 6963 is not replacing 1193. What it's replacing is the window.Ethereum, which was not actually a standard. It was something that MetaMask did. So you could actually say this is replacing MetaMask API with 6963. So 1193 is still a dependency of 6963. You still interface with the wallets the same way with 1193. 6963 solves the discovery problem. So that's how you actually discover. And technically, the EIP 1328 for WalletConnect is also the QR code. It's not actually how you connect the wallet, it's just how you actually find the wallet. So you could say that those are two wallet discovery mechanisms.

Nicholas: Right. So if people want to experience this UX, there's EIP6963.org, which is very cool. And if you have installed wallets, you can see this in action today, right? Absolutely.

Pedro Gomes: And that was built by our DevRel team. But you also can go and download Web3model.com. Well, you can go to Web3model.com to try it out, because it will be embedded into the Web3model SDK. We also have lab.web3model.com, which essentially is a way for you to kind of play around with our Web3model SDK. So actually, you will see in the coming days, people upgrading their Web3model SDKs. So you don't need to go to EIP6963.org anymore. You will see this in the wild in production in your favorite apps. Wow.

Nicholas: Very, very cool. So under the hood, what are the things that 6963 is doing? And maybe you can explain some of the relationships that it's teasing out that were not specified previously.

Pedro Gomes: Well, it's actually one of the simplest standards that I've ever written. We have narrowed down to such a simple concept of announcements. It uses this event-driven mechanism where instead of you actually having the wallet inject the API, it announces itself. So that way, the dApp can observe all of these announcements and then collect a list of "I've seen all of these wallets announced. Which one do you want to use?". And only then you actually pick the wallets to interface with 1193. So 6963 is just a standardized announcement mechanism that it's using like a window events that is based on like JavaScript API that allow a dApp to actually find a wallet.

Nicholas: So basically, each wallet announces its presence and then can be presented to the user using something like Web3model.

Pedro Gomes: And one of the things that we allowed with this announcement is that before 6963, the SDKs actually had to create a list of all existing wallets with a name and an icon. And that actually increased the size of these SDKs because they basically had to pre-bundle a bunch of images, even if these wallets were not installed. And now SDKs like Web3model and Wagme, they don't need to do this anymore. This will now be part of the announcement. In the announcement, it says, "I am this wallet. I have this name and I have this icon, and you connect to me through this 1193 provider.".

Nicholas: Very cool. The EIP also mentions fingerprinting protection. How does that work?

Pedro Gomes: Yeah. So fingerprinting protection is basically us trying to think that when you actually have the window.Ethereum, you're essentially opening the interaction with the wallet upfront, right? And with 6963, you could almost have a decision to expose itself. So because the wallet chooses to announce itself, then the wallet can actually not announce before it's necessary, right? Fingerprinting means that every time a website renders in your browser, it can detect which wallets you have installed. And if you have a wallet installed, with 6963, you can actually announce yourself only if it's required. And you can even choose in your wallet --some wallets have added this feature-- whether to announce or not, right? So to prevent fingerprinting, you don't always announce unnecessarily.

Nicholas: That's interesting. So they might choose to, maybe, I guess, if the domain name is not like one of the top 15,000 dApps or something like that, or 12,000 you mentioned, maybe it wouldn't expose that it has the wallet?

Pedro Gomes: Obviously, the spec doesn't want to go as deep as like, "What kind of rules do you want to do to actually prevent fingerprinting?". But the spec is designed in a way that does not force the wallets to blindly expose themselves. And they can actually make an informed decision whether or not to expose themselves. So it has some privacy-preserving properties in the spec. And that's what it's really...

Nicholas: Very cool. Are there any other technical aspects of the spec that you think we should dive into before moving on?

Pedro Gomes: Honestly, no. I think the spec is one of the shortest specs that has been written, but really impactful.

Nicholas: That's great.

Pedro Gomes: So basically, the only thing I can ask people is, "Add Web2ML SDK to your dApps. And if you're not a dApp, go and visit the dApp that has Web2ML. And you'll have a 69/63 experience right now.".

Nicholas: Awesome. One thing I noticed about the EIP is that there are, like you mentioned earlier, lots of contributors. There's you, there's Kosala, Richard, Gregory, Kyle, Glitch, Jake, Pierre, Daryl, Jaroslav, lots of people. Can you say anything about the EIP process? You mentioned that it was particularly quick to spin this one up and it's going to have a lot of impact. So I feel like maybe people can learn something about your experience in the EIP process.

Pedro Gomes: Well, what I've had in my experience in the past is when you have a single offer or one or two offers, things don't move as fast because people don't take as much ownership. So I purposely added as many co-authors as possible. So as soon as someone even expressed a little bit of interest in making this impact, I would try to get them involved as much as possible. And whenever they made a contribution, I added them as a co-author. And the side effect of this was that then people actually take ownership and they start actually promoting it and going out of their way to actually build something for 6963. So adding more co-authors definitely accelerated the process. So I didn't want just to say, "Pedro is an author of this.". I wanted everyone who was heavily involved in this to be a co-author and take ownership and become a champion of this.

Nicholas: That's nice because you do hear people sort of complaining about some people treating the EIP process as something of a vanity process sometimes, when really it is about improving things for everyone. So it makes sense to add lots of co-authors. That's a great idea.

Pedro Gomes: Yeah. And at the end of the day, this is a community effort. This is not about Wallet Connect or me or anyone that was doing this. This is about us making Ethereum a better experience.

Nicholas: Awesome. Well, I think we've kind of done the tour of 6963. If people are interested in implementing it in their dApps, what's the best place for them to go?

Pedro Gomes: Well, obviously, if you want to go all the way to actually implement it, you can go to EIP6963.org. And there's a link to the spec. You can try out the demo, but you can also read the spec. But personally, I would just go to Web3model.com and you would install the SDK and you wouldn't need to even know how it works because it's already embedded into the experience of our SDK.

Nicholas: Very cool. And that Web3model is a project of Wallet Connect, correct?

Pedro Gomes: Correct. And we also had the participation. You will see one of the co-authors of the EIP6963 was Jake Moxey from Wagme. So this experience is both available on Wagme and Web3model SDK.

Nicholas: Very cool. If you want to keep up with Wallet Connect or future projects that you're excited about, where should people check you out or what should they keep tabs on?

Pedro Gomes: Well, if you're a developer and you haven't registered and created your first project, I definitely invite you to go to cloud.com and create your first project. But definitely, if you want to just keep updated with all the exciting announcements that we have around notifications and we have the email login coming in soon, follow Wallet Connect on Twitter @WalletConnect and you will have all the latest news. And you can also follow me because I tend to retweet the same thing.

Nicholas: Awesome. Pedro, this is great. Is there anything else you wanted to mention to people or should we call it?

Pedro Gomes: Yeah, we should call it. This was amazing. I just love talking about wallets and I loved your podcast focusing on the user experience.

Nicholas: Thanks so much. This has been super informative. It was a pleasure to talk to you and get to know about this exciting EIP and everything going on at Wallet Connect V2. Thanks so much for coming through. Absolutely.

Pedro Gomes: Thanks for having me.

Nicholas: Take care. All right. Thanks. Thank you. Thanks, everyone, for coming to listen. Later on today, I'm going to be talking to DC Posh and his co-founder at Daimo about their new P256 Verifier Solidity contract. So if you're interested, come back at 5 p.m. Eastern time. Talk to you soon. Pedro, thanks again.

Pedro Gomes: Talk to you soon. Bye.

Nicholas: Hey, thanks for listening to this episode of Web3 Galaxy Brain. To keep up with everything Web3, follow me on Twitter @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.