 There we go. So hopefully you guys already know about WalletConnect, because I've shouted enough times in many conferences. But WalletConnect is an open protocol for connecting wallets and apps. And it's nothing too complicated. It's just a QR code instead of connecting to a browser extension. And it basically just came to the conclusion of browser extensions are not the best way of interacting. And there are so many good mobile wallets if we could just connect it really easily. But with all wallets, because UportConnect has existed for three years, but it only works with UportConnect and Uport app. And now we have WalletConnect, which is a standard that anyone can integrate. You can just go to the quick start. You have examples for dApps and wallets and integrated right now. And there's tokenary, there's trust wallet. Metamask is also going to release with WalletConnect support. Rainbow, balance, and I think that's it. We have six wallets so far. So there has been some good developments. So for example, I released WebTree Connect, which is basically an extension for dApps to have both support for Metamask and WalletConnect with a simple UI that immediately will connect. And trust wallet recently supported with BinanceDEX, which was a big win for us, which has provided a lot of developers came to the community. And Unisox also released, which is pretty cool. So you would be able to bid on the Unisox with WalletConnect. Metamask presented it ethereal. And even Bruno from Metamask also did a demo where he used Connect, which is a state channel platform for paying with WalletConnect, which is pretty cool. Also recently, someone tweeted about how they access the BinanceDEX on a Tesla with WalletConnect. So there has been some quite interesting developments. It's pretty cool because this very simple UI, just allows you to build so many experiences. You just have a QR code anywhere. So you could be in a Tesla. You could be in a tablet. And you get these messages sent across between the dApp and the Wallet. And it's all secure because the private keys are never shared. So you're able to have a loot box like Lee has built to open with your wallet. And you're verifying that you are who you are. And you can always control the session at all times. So what I'm building is called WalletConnect Pay, which is basically, I want all of these wallets to explore the outside world. And for example, this part and other bars and many other bars to have the experience of buying drinks with WalletConnect. This is a UI that I've built that provides a simple enough user interface to create an order where you can add, remove, and you have an order. And you can create different shops. So for example, I have two different shops. This is a coffee shop. And this one is in dollars. This one is euros. It can support multiple chains. The UI doesn't even reflect any of this. It's only when you actually pay that you encounter anything blockchain related. So I'm going to get a mate and a cola. When I get to pay, I get to the WalletConnect screen. So you pick your favorite wallet that supports WalletConnect. For example, I'm going to use Rainbow and just get the QR code. And once you scan the QR code, you will initiate a session and immediately be requested to connect to a different chain or have a transaction. In this scenario, Rainbow doesn't have X-Dyed Chain. But if you had Wallet, you could just switch to X-Dyed Chain and you would be able to pay. In the future, you'd be able to switch between chains and depending on the permissions that the vendor would have. So for example, if the vendor would support X-Dyed Chain and Ethereum, you could use both of them if it supported any other chain. And as long as it's EVM chain, it should be fine. So I'm going to try with the coffee shop. So I get an Expresso and maybe Croissant. I get to the payment. I scan the QR code. And I get a simple interaction, which says with the converted rate, which you can see here 750 and here says 748, given the exchange rate of die. And I can just sign it from my phone. And now the transaction is pending. And once it's confirmed, you'll have your order. And basically, this is just a prototype that I'm building, which is trying to provide a much better use case for just dApps, trying to get some utility to having, because a lot of what I've experienced, even in the crypto communities, that people don't have mobile wallets. And even if they do, they don't actually have value on them because there's not many use cases. First of all, we didn't have dApps interacting with mobile wallets. If you had Trust Wallet or Cypher, yeah, the dApp Browser, that was a good enough use case. But it was still not good enough for a daily use case where you hold like $50 to $100 on your phone. But if you were able to just pay lunch and drinks after work, this would be a good experience. The problem is this is the blockchain. And this is one of the things I want to improve, which is can we integrate Wallet Connect with state channels? And this is something we're still working on, which is providing better standards. Because Wallet Connect, one of the problems is that, like I said, it's an open protocol between Wallets and dApps. Yet as the protocol developer, I have no control either on the Wallet or dApp development. That's why I'm so passionate about EIPs and standard because it provides me like a coordination tool between dApps and Wallets, so that I can tell Wallets to follow the EIP 1328 and go to dApps and say the same. And now we can coordinate between multiple Wallets and dApps to communicate with each other. And one of the things that I'm currently pushing for is the 2015, which is, yeah. Basically, it just provides, wow, that's terrible. There we go. So basically, even if you connect with Wallet Connect or MetaMask, it would be great to have the ability to update the chain to a different chain. And so in this scenario where we had the point where it requested me to connect to a different chain, it would be much better experience as a user if I scan my QR code. And instead of having a transaction request, I would have the vendor is asking you to change chain. And the only thing it would require is for dApps and Wallets to support a very simple request where they provide the enough information to switch to any chain. And here I describe how you could potentially integrate this. This is a proposal so far. It's still in draft. But also it provides a list of best practices where the Wallet, if it knows the Gorley interface, it wouldn't actually require all of that information. As long as you have the chain ID, the network ID, you'd be able to switch to any chain very easily and provide a simple UI. So a lot of this stuff that it's like, part of the Wallet Connect is about the intercommunication between the two devices, but not necessarily what they actually communicate. And that's where EIPs really come forward because it provides a much better user experience for users if we all have better standards to interoperate with each other. So yeah, I hope one day this interface with Wallet Connect Pay becomes very common and we can easily just buy a muffin and coffee or a mate and we all use our Wallet Connect Wallets to pay for lunch. Thanks. Questions? I forgot about that. Who has a question? Will Wallet Connect support polka dots? The thing is, for example, when it came to Binance Dex, Binance Dex is technically a Cosmo chain, well, technically a Tenderman chain. But what they did was basically, they created us an interface using JSON RPC. All the communications between Wallet Connect are JSON RPC calls, so they just created a B&B namespace JSON RPC calls for all their ordering, matching, and whatever. So you can assign all of these transactions on trust Wallet because they supported these calls. So if you have a Wallet Connect enabled Wallet, doesn't mean you can actually sign messages from the Binance Dex, it just means that you can interoperate between the two. So can it support polka dot? If they provide an interface in JSON RPC and the Wallets then follow that interface, yes. Yeah, so maybe, what information is actually encoded in the QR code? Good question. Let's get into the technicals then. So basically, here it is. There's a topic, there's an initial topic for the request. There's the bridge URL and a key for encrypting the messages. You post the session request, which includes a peer ID, which is gonna be used to send messages to the app, and peer meta, which is scraped from the webpage using like an icon, description, a title, a URL. So it basically provides you the same interface as you would get with the MetaMask popup that says, do you wanna connect to this website? And you would get the same thing on mobile. It posts to the bridge server. And the bridge server is a web socket server which has caching that waits until at least one of the parties requests for one of these topics. When you display the QR code, you display the topic, and the wallet is then able to get the session request using that topic, and he's able to decrypt with the key. So you basically just have the minimum information to get that session request. Once you have the session request, you basically just interchange messages that are encrypted using that key, and they all have a topic and a payload. Why would the wallet need to know which chain the DAP is on? It could just sign the transaction and send the signed raw transaction back to the DAP. That's actually not correct. Actually, it's part of the EIP 1155, which provides the simple replay attack transaction, which basically the V field on the signature actually contains the chain ID. As you can see, chain ID plus two plus 35. So basically, you need the chain ID to sign transactions, and in the future, type data messages. The same way we track the network ID, we need to track the chain ID to sign the messages. Actually, we shouldn't even track the network ID. It's pointless. It's just the same, it's a coincidence. Anyway, don't get into that. Yeah, but it could be done like parity signer, where you just provide the wallet is only doing the signing of the raw transaction. But the wallet, so what you're discussing is not whether you have the chain ID, it's whether who decides on the chain ID. So with the parity signer, you're providing the chain ID from the DAP into the wallet instead of having the wallet to the DAP. The reason I did it in this way was to keep the wallet as in control of the session. So just like with MetaMask and other wallets, they decide which chain is the active one, and then they would provide that information to the DAP. With the EIP 2015, you would be able to request this change instead of forcing this change. Theoretically, with WalletConnect, you could force this change, but this would be the wallet developer that would actually... Okay, so thank you so much, Pedro. Awesome, thanks guys.