Session Authentication for Smart Accounts by Pedro Gomes

Transcript

all right thanks everyone uh so um I'll be talking today about wallets uh as my company works on wallets for six years now wall conect my name is Pedro G I'm founder at wall con and the title of this talk is about session authentication for smart accounts which is quite a mouthful like everything in web and I think it's important that we start off by breaking down the lingo uh because it's going to be a lot of words that are going to be spoken today about wallets and pretty much the biggest difference that you see when you go to a web three application today is that we moved away from this login pattern to a connect pattern but did we really change

much about what is required about an application like there's a lot of words like that are being thrown around whenever you talk about wallets like the daps wallets capabilities sessions permissions Keys authentication external accounts smart accounts signing access but at the end of the day it all comes down to like the same concept and it's always very important that we kind of like revisit the first um Concepts that we have in like traditional like applications that we use every day and authentication I think it's a very important word that we uh have in mind uh which has a definition of in Computing of the process or action of verifying the identity of a user and if

you think from a user's perspective they don't care about all of these words they just want to get in it's like just let me in like that's the whole point of login of connect authentication is just like let me in and if the user wants to get in quick less clicks is more like that's that's something that we always have to have in mind not just for this talk but also for whenever you design a good user experience less clicks is more so why is web 3 different like why do we actually have to reinvent the wheel change things around and make things more complicated why can't we have like less clicks I like to kind of always show this diagram because for me kind of

makes it easier to understand what's different about web 3 in the past we had an application or a client sometimes is called that talks to us server and there's like multiple components in a server but obviously we want to focus on the authentication part because at the end of the day what happened with web 3 is that we moved the authentication part into its own app and we called it a wallet and now what used to be a server is now a blockchain and then you still have an app interface and a wallet interface and then both of them talk to this blockchain and we have like this really beautiful triangle but did we actually make things more complicated unnecessarily

like a wallet when you think about like it's another application but it consists of like these three main things it has a set of credentials it has some signing capabilities and it tracks an account and there's different types of wallets today as some of you may know maybe you're going to learn something new today which I hope so and if you consider these three components like the mobile wallets or the browser wallets that you have they have a set of credentials s that are usually a password or PIN code and they run some local software that has some signing capabilities and they targets an external account and so the hardware devices and cloud and NPC they might

have some differences around like maybe they use Biometrics or a pin code or email or phone or social for credentials and then maybe the signing happens either locally on a hardware or in a remote server but at the end of the day they always follow this pattern of like credential signing an account but we never actually got to the part of authentication because realistically we had to invent authentication all over again because when you connect your wallet you're just saying I have this account but it doesn't actually tell you if you do own this account so sign in withum was the first standard that kind of brought authentication to web3 and it took so long after the ethereum Inception to

actually have signed in with ethereum and when you you look at it it's quite simple it's like a message that says this website wants to sign into your ethereum account at this address and I accept some terms of service which is an optional pattern actually it's like you don't actually have to add that statement but you can do and when you look at it it looks like a lot of like words and what is this like is this really user friendly it's not but it's still better than what we had before which is some people would just like have a hash and say like sign this and consider yourself authenticated then some websites still do in web 3 which is quite worrying but when you look at it like s etherum just recreated a very

normal pattern with social login where you get access for example to a Google account and there is some capabilities and you either accept it or not so s etherum already creates a really nice pattern here where we have a very familiar interface in a text format but some wallets today have already customized this interface to be more user friendly uh which makes s etherum uh a great success as a standard in my opinion one disadvantage of s with etherum is that this only happens after you connect your wallet so in a sense you do create this session when you connect your wallet but then you have to authenticate after so uh we at the wallet con Team U we created a new

standard uh which is called CIP 222 which is called wallet Authentication very simply put and what does it do it's actually just U I like to say like an upgraded version of signing with ethereum it basically takes you from the existing pattern where you connect and then you sign but since signing with ethereum is what we actually want to do why don't we just like skip the whole pattern of connecting and we embed the experience of actually establishing a session into just assigning so we skip the connect we just authenticate right away with sign etherum and you have a session so you could say like is this enough like have we succeeded into

making a more familiar experience and making user uh users happy just like they are with logging in with Facebook or Google or their email and password what about signing transactions this is where things get really really complicated because I started with like the simple stuff which is just authenticating yourself but then at the end of the day the whole purpose you actually want to connect your wallet to the blockchain is because you want to actually do take some actions and sign transactions so most people just close your eyes and approve uh which is terrible if you told people like uh six or seven or eight years ago that like that's what's going to be the normal pattern so we actually have to do something better uh and we still have to

kind of think about how can we balance the convenience and security like the the the challenge with wallets is not creating a wallet wallet connect today has more than 500 different wallet uh applications registered most of you probably use only two or three of these like if we actually did a a survey right now but there's 500 application developers out there building it but balancing the convenience security is really hard it's almost like an art because remember less clicks is more that's what we want to make sure that we achieve here but it's not a easy task so so why is it not an easy task because wallets are based on this simple concept

of public key cryptography which made this whole idea of self- sovereignty and owning your assets possible but this yet again it's more lingo let's try to break it down and understand what public key key cryptography is so you have a private key you have a public key and that's what makes us actually have a wallet and with this public key uh you can actually verify a signature so you take a message sign it with a private key generate a signature and it goes back to a public key and you understand that this message was signed with this private key without exposing it so that's how transactions go into the blockchain every transaction is a

message that is signed with your private key that only you own therefore only you have access to the assets and everything that you own on the blockchain and so this is happens in this manner where you take a message you sign with a private key have a signature it matches to the public key and then we have this really interesting thing here that a lot of people confuse public keys with accounts but it's not the same thing we actually take an address from a public Key by hashing it and that's what's actually looks on the blockchain so you can then ma match a transaction or a message to that specific account and this is what we call an externally owned account if you saw in the previous pattern uh where

I showed the mobile browser wallets and Cloud wallets we had all of these wallets are external accounts but we want to do better we want to make them smarter because externally owned accounts as you saw was taking a public key and just hashing it and you get a single account from that uh with smart contract accounts which is actually quite a mouthful I kind of get tired of explaining it and saying externally owned accounts and smart contract accounts I think it's easier if we just like let's reduce it to just external account and smart account like there's only two types so our goal here is like let's make account smarter let's move from external accounts to Smart accounts because at the end of the day we want to sign transactions better so a smart

account is simply defined by a smart contract that is being deployed as your account instead of you having this public key that owns some assets you deploy a smart contract and that becomes your account but then you now have a problem because we just went into this idea that we're going to sign with ethereum to authenticate yourself so how can you actually validate if you don't have a key no key no signature it's that simple so if you have a smart contract as your account how can you actually sign in there's a standard for that so ERC 1271 means signature validation method for contract so now a smart contract can actually be validating a signature and saying this signature

matches the owner of this smart contract and it's quite simple like I don't want to be showing too much code guys because I don't think that's actually important but I wanted to show you how simple this standard is like maybe you will take like a while to actually read the whole thing but it's just this it's a single method that says is valid signature you pass the hash of the message you pass the signature and Returns what it's called like a magic value which basically just says true or false uh so if the magic value is returned then it means it's a valid signature and you can know that this signature is for the owner of the smart account so what is an account like we talked about external accounts and smart accounts and just

like we broke down wallets into three components I want to also break down accounts into three components which is signer payer and crypto and unfortunately when you talk in a cryptocurrency conference you always have to say cryptography I'm not referring to crypto as cryptocurrency but actual I don't know like traditional cryptography so an external account has a single signer which is the public private key that we talked about that public key is the only signer for the external account and the same thing happens for the payer right so when you send a transaction you have to pay some fees or gas in ethereum and that signer is also the payer and will always be the

payer right there's no way that the external account will have a different payer and we have use the same cryptography as the blockchain so for ethereum we use CP 256 K1 therefore the signer which is the single signer has to be the Single Payer and must use the same cryptography as the blockchain with smart accounts this gets even much better because in reality we can't force every user to follow the same pattern we need to give optionality so by making account smarter we can have multiple signers multiple signers could be multiple people which is what we have the concept of multisig accounts but multiple signers could also mean

multiple devices multiple applications you can have a signer everywhere and also because you have multiple signers you also have the ability to decouple this concept of signer is always the payer you could have a signer and a payer completely separate that could be you have a signer that owns the assets or you could have the account owning the assets but it's not the same as the one that signs or you could have a third party subsidizing the transactions for you and this is currently only possible with smart accounts and the other thing that smart accounts also make it possible is that you can use any curve now you're not limited to the cryptography that ethereum has decided to use which is the same one as Bitcoin you could actually use multiple

cryptography curves uh which makes it much easier for us to actually build better experience for users so now if you do have a smart account and you have like multiple signers and multiple wallets and multiple location like then this idea of like connecting becomes a little confusing because what are you connecting to actually smart accounts makes this much easier because with external accounts you ended up having like one account per wallet if you did not share the C phras around and it's much better with the smart account because essentially you can have one smart account everywhere like we reduce the complexity a lot because now you don't have to worry about having like accounts there and there and then some assets are in another account you can

just have like one smart account and because you have multiple signers those signers can be distributed in multiple applications and wallets but at the end of the day in the blockchain you have like a single smart account being tracked which makes it experience much much easier so what it actually means to be connected because we talked about how we authenticate ourselves we connect we sign some messages but what is actually being involved in that process that actually makes the experience that W has built on top the first thing that you do is actually expose closing the accounts so that's actually the account address that you see and then the application is able to read some blockchain data so for example in the concept of defining if it's a smart account or an exceler

account we can maybe look not only just at the assets but if there's some contract being deployed at that address and then we can create a signer session which we saw with sign with ethereum and then in the future we can request a user approval for for example signing transactions and submitting transactions so this is quite good as a concept because I want us to think about uh 4237 which is a very important standard for smart accounts because the idea of a smart account actually delegating signature to multiple signers and having multiple payers becomes a really fragmented um space and we want to make sure that we keep ethereum decentralized

and the experience is still convenient for the users so 43 7 essentially creates a standard for all of these experiences to be built unified and we all agree and to have the same pattern basically if you think about the triangle that I had before now maybe this triangle is a little bit more complicated now uh because now it's not just an app and a wallet and a blockchain now you have a concept with 4237 of a pay master so the pay Master will be the one paying for the transactions so the wallet needs to be connected to that we have the the signer the signer may be in the wallet may be external to the wallet maybe even in the app perhaps in the future and then we have a bundler and the bundler basically

just takes a signature that the wallet will create uh that is signed by the user with the signer and then the pay Master will pay for it so there's a commitment from the pay Master you did uh a user operation because in 437 we actually change the name because why not make more lingo uh so instead of calling it a transaction you sign a user operation and with this user operation then you send to the pay Master the pay Master commits I'm going to pay for this and then you send them the bundler and the reason it's called bundler is because this is not supposed to use just for this wallet or this account this is supposed to used by multiple wallets and accounts and they just bundle everything

together into one big transaction then includes multiple user operations and it goes into the blockchain as a bundle so this is quite a great pattern that you know it moves things forward maybe it doesn't feel like much progress but if you were here like three years ago this is like uh breath of fresh air because we've been talking about account abstraction and smart accounts for so long but the problem now is like if you're a Dap how do you actually discover if the wallet support smart accounts we always make an assumption that the wallet is an external accounts and it doesn't have all these properties of multiple signers and payers and different cryptography how can you actually Define that the wallet is a smart account without actually just you

know checking if there's blockchain code so there's a new standard called 5792 which is called wallet call Api methods and introduces four different methods um but I I think it's important for us to take a quick look at here because the first one says gate capabilities then there's the second one which is send calls the reason it's called send calls is because as I told you 437 now includes the concept of user operations so instead of calling operations or transactions we just generalize it and call it calls this way we abstract from the DAP a different pattern between smart accounts and external accounts we just send a call and then it's up to the wallet to actually interpret this call

whether it's in an a transaction format or in a user operation format and then because we introduce a new pattern of calls as a a generalized concept we have a call status and a get call status and the show call status but I think the most important thing that we should look at is the wallet get capabilities because with wallet get capabilities we actually get to learn about the wallet so once you actually authenticate yourself you can ask the wallet hey tell me about your wallet what things can you do with this wallet and this is only for illustrative purposes this is not yet in production this is just an example of for example you could have one address a and one address B and one of them supports a pay master service and the

other one supports like pay Master service and session keys and this way we can actually have a little bit more information about the wallet and knowing oh look this is a smart account and it has this pay Master service and maybe supports like some fancy feature like session Keys which we're going to talk about and this basically answers a lot of questions but does it answer the last question which is what is the interface for the pay Master data which is the data that the pay Master actually give us in 4237 that allows us to actually send to the bundler knowing that they will be the ones paying for our transaction there's a standard also for that there's been so much progress in the last 18 months around account abstraction and I want to make sure that

I show you all how we're actually going to have a much better user experience the 7677 defines a pay Master web service capability so building on top of the 5792 you can actually Define this capability in a way that all pay master will work in the same way and therefore um apologize for more code you end up having like these patterns where you can actually say with these characteristics you can actually send uh to a wallet and then you actually know that they have always the pay master and this way we have a more decentralized way for pay masters to actually work in the same way but then if we created user operations um are user operations all

going to work the same way this is still a tricky part because right now maybe there's only a few implementations so we have some libraries today that kind of abstract that and just say if you use this account then you use user operations like this if you use this other account you use operations like this but then you're just going to have like a big list of different user operations so instead we also have a new standard called the user operation Builder which allows you to actually ask the smart account directly how to actually construct the user operation for this particular user and it looks like something like this this is a little bit more complex now that we're getting a little bit into like which entry point does the smart account use

which nons get call data get the signature and everything and we have like an execution Target but these are all steps forward for us to actually have more smart accounts and less vendor lock in such that like a wallet connects to a Dap and authenticates itself and we can understand very easily without knowing ahead which account they use how it will function you construct the use operation you get the pay Master data and you can get started right away so smart accounts as I told you allow you to have like multiple signers and multiple payers and we already covered how user operations and pay masters are going to be standardized but some functionality is going to be very

specific to some smart accounts and we need to make sure that you know we reduce the vendor lock in and smart accounts are as interruptible as possible so there's this concept of modules uh which is a new standard also 7579 which is minimal modular smart contracts that tries to ensure that all smart accounts are built in a way that everyone can use the same modules and this is really interesting because it creates a more competitive market for modules one of the modules that we might start thinking about is when you lose all the signers how can you recover your accounts like a module for Recovery would be really helpful but what if your recovery module works with smart account

a but doesn't work with smart account B so you switch wallets then the recovery only works with that wallet then it gets a little tricky because did you did we really succeed into having interoperability if the recovery only works with that specific one and it gets even more complicated with that because with user operations we have some limitations that are not the same as transactions so even something as simple as swapping tokens can get really locked into a specific smart account so having a module for swapping tokens very efficiently and only working with a specific wallet is not great so having for example I don't know imagine Unis swap building the swap module and everyone uses the same swap module

following the 7579 means that everyone can compete building the best smart account experience without having lock in about specific modules and then I think that if we continue in this mission of like making sure that we have as less approvals and clicks for the user we want to perhaps like remove the wallet I know that's quite controversial because that was the whole point that we started like this self- sovereignty that you have ownership over the private key but I do believe that to some extent we will have maybe 5 years from now the same experience as we have with tradition web to and I think that would be possible if

we take all of the work that we saw before with 4237 and pay masters and user operation Builder and we sign everything inside of AAP but that's a very big task and currently I think that that's the definition of a session key essentially we created multiple signers for an smart account but we always had this concept that these signers would be in different wallets but if we put these signers inside of a dab they would be used specifically for a session and session Keys solve that but how can we make sure that like we're not uh conflating security with convenience because maybe we're so caught up with

like less clicks is more that we're sacrificing security so there is a work around permissioning uh the reason it say XXXX is because the standard is in progress there's big big discussions around this it's a it's a very controversial topic because everyone has very strong opinions about how to do this but I hope that eventually we will have a standard around this and this is in my opinion probably going to be the biggest uh unlocker for user experience where you can actually give the D permissions to actually sign transactions for you and that would be amazing because now you can actually have sign in with ethereum and that's it you sign in with ethereum

you have some capabilities you approve some permissions and all of the transactions are signed with a dab like one example of how this would work you take a dab the dab requests permissions from the wallet you ask the user do you approve these permissions similar to how we saw this in the Google Lo login imagine having the permissions having a similar pattern inside of the sign in with etherum and then the user will say I approve maybe these permissions would say stuff like I only want this dab to act with this smart contract and cannot spend more than $1,000 or something like that the risk factor will then depend on the user will depend on the dab maybe in

some dabs you don't want it to be able to move any assets and it will only sign I don't know votes for a dow or maybe can only submit uh posts for the lens protocols like def finding the permissions has to be granular enough that the user feels comfortable giving that capability to the dep once the user understands the permissions that are given to the dab then it can approve this generates a permissions object that the wallet offers to the DB and then the dab can have its own key for your smart account that will sign transactions and then we skip the whole pattern of talking to the wallet and now the DB because we have a user operation Builder

we have a pay Master service the DA has all the information it needs to actually talk to the bundler directly you no longer need to go through the to talk to the pay Master to the signer because the do becomes a signer itself as a session key and it knows how to actually fulfill the pay Master data to subsidy that transaction and it just sends a call using 5792 with the permissions that we're giving in the permissions object and then the bundler will validate all of that say confirmed and then you can just move on so can we secure session Keys better because session keys this is where things start getting a little like uh tricky because if you do have session

Keys then you're giving a lot of power to dabs I think the way to do this is we've done a lot of erc's but we need to really change evm we need to upgrade evm to actually support this and some things are already in motion so for example uh EIP 3074 introduces the off and off call op codes to actually change how evm works and this means that the external accounts will now earn the capability of separating the signer from payer so this thing that we actually talked before that was exclusive to Smart accounts is now in progress to change in the evm which is really powerful and it's now going to be included in the next hard

Fork this is a big step for evm because we had these three things for accounts which were uh the now I forgot the signer the payer and the cryptography and now we actually going to change the actual payer capability to be the same for both external accounts and smart accounts so that's really powerful because then we can actually have some session key functionality in the actual external accounts which is really good but I think we need to take a step further and I would like to actually propose the all core devs to also include not just 3074 but the EIP 5003 which says insert code into external accounts with this new OP code

of zer so that means that now not only we move away from external accounts into smart accounts but we actually give the ability for people today who have external accounts to upgrade their accounts into smart accounts which is a big deal because a lot of these companies are building a lot of great smart account infrastructure but they always tell you to deploy a new smart contract and that's you know I have quite a lot of nfts that's a lot of nfts going into a smart account and a lot of tokens and some positions maybe you have some loans on a maybe some liquidity on Unis swap transferring all of that is going to cost you a lot so if we have the ability to just upgrade your

external account which is an optional feature this is not forcing everyone to do it you would basically just send a transaction with this off iser new OP code and you'd convert your external account into a smart account a smart account which is really amazing so I think this is going to be a big step but how do we prevent the session keys from actually being stolen um while we did create a lot of great ground with all of these standards with user operation Builder pay Master Services uh 3074 5003 at the end of the day you still have the session key living in the app which is still a little bit uncomfortable because the reason we created wallets was to

actually put the keys outside of the app so are we just always going to be in this like nervous mode the we need to have very granular permissions or maybe something happens and someone steals the session key and starts doing things that are not supposed to do how do we prevent them from being stolen Pas Keys Pas keys are the best session keys and paskis are not the standard for web 3 actually you might have heard about paskis before like um there's this pattern already with like Google and apple where you can actually create a pass key on the instead of a password and that means that the Key Management Services that these companies offer can then be used to log in and authenticate into normal

applications this is supported in for example Dropbox or like Google or there's like so many honestly at this point I think there's a website that shows like more than a 100 applications that support pass keys so how can we actually have ethereum also leverage this and this would be the standard that actually makes it really possible you will notice there's a small difference here because ethereum had a CP 256 K1 and P pasis use R1 it's a small difference but it's big enough for us to actually have a different cryptography from the Pas keis so while smart accounts allow you to use different cryptography it's very expensive to use

different cryptography and if the evm itself supported pasis we could make every user operation Cheaper by having adding this pre-compile so this would be the third upgrade that I would propose to the evm to actually support pasis so we could fulfill the whole experience for smart accounts to just be more embedded into the that so is this the end game for wallets did we complete our mission of having less clicks is more I think to some extent yes because if you look at all of the things that we walked through this path we we started with the differences between web 3 and web 2 and we had an application talk to a server

where the authentication lived but now in a sense we recreated the same thing but we flipped around where the authentication does not live in the server side or in the blockchain in this case but the wallet actually lives in the app we have the ability to have Smart accounts being upgraded from external accounts we have user operations we have pass Keys securing your session Keys session Keys have very granular permissions so Nothing Stops us from one a single click with the wallet authenticate method to get the capabilities and generate an embedded wallet that you can very safely use for that application with very great security and

convenience so what is actually being connected now because we now kind of broke the triangle you could almost ask like what does wallet connect have to do with this because there's no actual connection you just do a sign in with ethereum and everything just magically happens under the hood before W kind of just bridged between daps and wallets and vice versa but now we actually have a much bigger world now uh we have session Keys we have signers bundlers pay masters in a sense wall con's job just got even harder uh because now we have more parties to connect to uh we don't only have to connect dabs to wallets we have to connect to pay masters bundlers signers we have to

manage permissions for session keys so there's a very interesting road map ahead of us for the wconnect team to actually build the infrastructure for what I believe is redefining the Walt experience for web 3 this is something that you know has been the mission for six years for walon and it taken very small steps and that's why it took six years not six months uh but now I think that we're really getting close with these session keys and smart accounts and we really complete here our journey of having having less clicks is more I think this is the end game for wallets I really hope so because if we could just like use web 3 everywhere then we would have succeeded thank

you um do we have time for QA um I think you have to shout or I I'll take the there wait a second the mic is coming there you go thank you uh so this is a problem that's been with ethereum since basically in Inception and one of the big problems is the gas costs like doing anything on ethereum costs gas and gas costs money and it costs more and more money and uh so in addition to having less clicks

we also have this overriding concern of having less transactions uh and now that the user will have to interact with a smart contract and the smart contract will have to interact with uh other smart contracts uh so do you still believe that ethereum is for everyone or is it only for rich people I mean how do you define is it for everyone like for me ethereum is a network of evm so this will the work that was discussed here is not exclusively for etherum mainnet it would be for all the ethereum rollups so like I think the gas conversation um it's a

big topic for sure because for example we had a big upgrade with 4844 which basically introduced the blobs and made the rollups cheaper and therefore also made theum main it cheaper because it create a separate gas market but will the average user use the main it my BET right now is no and I don't think maybe that is even the success metric for iter main it maybe the success metric is to have as many rollups as possible and still be viable for rollups to not go Sovereign because that is that is a mission in itself that all of these rollups are interc connected with each other and etherum Manet is the hub for all of these

rollups and I think that that's one of the reasons uh we've seen uh etherum may not not take so many steps towards user experience because they were focused in lowering the costs and making sure that rollups are more viable um but fortunately we have 3074 now the first step towards like better user experience but don't don't take it wrong like just because it's called the EIP doesn't mean that the rups are not going to adopted in fact I would say that rollups always seek to have as much equivalence to the etherum Manet so any steps that eum Manet takes towards better user experience they get inherited by rollups so we have a better user experience on it main it that goes to the rollups rollups reduce the cost of gas and

essentially uh we can have the best of both worlds where users use rollups uh all the rollups use it your mainnet all have the consistent user experience across uh all the rollups and mainnet as well um so I hope that answers the question um it does thank you thank you thanks um yeah I wanted to ask um I'm trying to not be the party pooper here uh EIP or ERC sorry five five 5803 I think or was it 50003 is it the wallet call wallet sorry aerp oh the 53 yes 5003 right um how long can you do without

it um I mean so this is a big topic so just to reiterate the question how long can we live without 5003 now that 3074 is getting getting included into the hardw um I always think that in this ecosystem there's pessimists and optimists I'm just so happy that 174 is being included but there's a whole school of thought that says that we cannot go forward with 374 or without making sure that external accounts have the option to upgrade themselves to Smart accounts because of the problems of multi-chain where you can have 3074 on one chain and not on the other chain and then if you don't have 5003 you

can't guarantee that you upgrade yourself in every smart account personally I'm on the optimistic side I'm just happy that we have 374 if we do not get included into this hard Fork I don't think it's the end of the world but if you do have some spare time to include both eips in this artwork that would be great I don't think we're going to disappear as an ecosystem because we include 374 without 5003 I know that if you go to the discussions on Twitter some people are of the opinion that we can't do one without the other I believe it's possible to do one without the other especially because 3074 is not just for external accounts it's also allowing the whole ecosystem with 4237

to be leveraged by external accounts there's so much infrastructure being built today with 4237 that external accounts can't use and 374 allows them to leverage that but of course like they would be more U beneficial if they had 53 so I'm going to still push for 53 if we do get it we do if we don't it's not the end of the world right give use for one more question if anybody has one hello thank you for your attention

and uh how we can trust uh provider right wallet connection if uh wallet connection as subjection to censorship for example situation in the Russia and Ukraine will it connect uh disconnected all people from the Russia from Rush IP I think sorry can you speak louder I remember I heard something about censorship resistant and Russia uh yeah for example wallet connect it's a center side provider yes and wallet connection have a censorship for example wallet block at all people from the Russian IP how we can uh trust uh wallet connections and same provider for example if we use more deeper connection

between wallets for example if we have B B connections have uh trust and uh pay connection we are all connect for example in these situations us from the Russia can can get this data this providers and tokens to simplify uh for the audience like how can people still use wall conect that currently today April 2024 is a centralized provider if they're going to um Block in certain countries um maybe there's some misconception because uh back back in the day we did block for 24 hours Russia by mistake uh we did apologize for that that was a unhappy incident uh but it's not blocked today um but wallon is

evolving into a network of providers we did have a big mission to actually upgrade walon V1 to V2 and that made us uh move into a single provider architecture but we're currently onboarding thirdparty providers to service wall conect so wallon will be available as a network of providers not just the current single provider and we are actually going to have multiple node operators in the network and just to reiterate we do not block Russia today um that was 24 hours bad 24 hours but it's it's been solved and it will it will be furtherly solved when we have more node operators serving different audiences so w neck network will be

strong and stable thank thank you awesome thanks everyone