# Enabling the Future of Blockchain UX with Session Keys - Luka Isailovic | WalletConnect

- Channel: [ETH Belgrade Community](https://streameth.org/eth-belgrade-community)
- Date: 2024-10-07
- Duration: 20:19
- Topics: People & Blogs
- Watch: https://streameth.org/watch/yt-HNHW3aV4p8M
- YouTube: https://www.youtube.com/watch?v=HNHW3aV4p8M

## Transcript

thanks man okay thanks thanks for the introduction um so hi everybody my name is luko I'm the web team lead at wallet connect um so we're going to be speaking about the blockchain ux specifically session Keys what those are what is the impact and some couple of the new standards that enable all of this uh but before that we're going to start with how do we use DS currently what are even session Keys how do we use them with smart accounts EIP 7702 and finally what is the blockchain ux that we want or we need rather to I guess gain some Mass adoption so um starting with like how do we use daps currently um when I say dap I'm going to use some examples of well-known daps like Unis swap 1 in openc U something like that something we all know so um usually I'll visit this website and in the top right there's this connect button I click connect um I'm prompted with the QR I open up my mobile wallet because most connections are now from mobile I scan the QR I proove on mobile and I'm good I'm connected I'm in uh this is just authentification so next thing is I do something on the app whatever it is I prompt some interaction is it a swap I buy nft whatever the call is sent to my wallet I'm again prompted to approve to approve the call response is sent back to dab and that's it and I'm stuck in this uh send call approve call Loop uh there's this Con context switching between the daap and the wallet which is not great I'm not using I shouldn't at least be using two apps um at the same time like when I use Twitter I I don't want to be prompted by Google to authenticate again and again and again each time I want to tweet and this is just when I'm authenticated like if I for example go back and not use my dab for a week I'm not here I'm back here like I need to authenticate again and this is just not great uh because again when I use Twitter I don't I don't want to or X um as it's like as popular now uh I don't want to be authenticated every week like I want to authenticate once and then maybe once in a year or something I'm back here authenticated again in the same Loop so lots of con switching not great um lots of gaming talks today so U happy to see gaming folks also innovating uh this is the video I found uh that kind of OV exaggerates how stuff is done on the gaming side but to an honestly it's not too far off to how it actually is uh the point is again the context switch I I'm playing the game and then I constantly have to go back to the wallet and approve stuff um question is like why do I do that like why do I have to go back to the wallet why can't just daap do everything on my behalf uh the reason is because wallet is the one that's in control of my private key like wallet is the one that is able to sign transactions or if we want to stick to the uh smart account terms user Ops and we should probably still stick to the smart account terms because uh most new users are actually going to be smart account users they will not use EAS so um why can't do just sign transactions like for that to be possible I would need to share my private key with the DAP uh obviously issue with that is security I don't want to share my entire wallet with the DAP because then dap can do whatever it wants um another issue I guess solution to this was the embedded wallet which most daps now um use that is the like sign in with Google or whatever and then they generate wallet on your behalf um issue with that is I guess interoperability I'm in one dab I use wallet I go on another dab I have to generate a new wallet and I don't want to have thousand wallets I just want one mobile wallet and then I want to sign in with every app and use it like normally as everybody else would so with smart accounts I have this concept of signers so I have my like Master signer which is my wallet but then I have I can assign multiple different signers so I can make da Aigner on my Smart account uh that's a solution but again it's not great because daab is not limited in what it can do like it can send transactions that it wants but it can set any transaction from my smart account that's just not great from the security perspective at least um so then we come to the concept of session Keys like what if instead of making dap Aigner or God forbid sharing my uh private key with the DAP uh I generate this cryptographic key specific to the session or Limited in permissions in what you can do with my smart account but still it can sign transactions on my behalf U now this concept is not new um it's been around for a couple of years and implemented by different smart account implementations like zero Dev economy safe uh but the issue is like everyone has their own definition of session key everybody has their own definition of permissions and everybody implements this differently so if I if I'm a da and I want to support all wallets I have to implement like 10 different sdks the solution to this is the newp 7715 uh which is by the way still in the pr stage in the GitHub it's just been announced two weeks ago it's called the permission standard uh and this standard defines how does the dab request permissions from the wallet and what permission is in fact um so to give some I guess simple examples permission in in in the case of 1 in or or Unis swap would be um I'm asking the permission to swap 100 usdc for E once every week that's a permission in in case of one or some training dab whatever uh the permission standards again Define the flow uh not all the possible variations of it and it looks something like this um by the way the wallet issue permissions RPC call that's introduced has been the renamed to wallet Grant permissions but but I kind of forgot to update the slides which is fine uh the IP is still pretty new by the way it's my first EIP so super happy about that one and totally not um I guess um yeah all right so um that requests permissions from the wallet with the new RPC call wallet is responsible for displaying this permissions to the user in some n ux friendly way so it should display what do is asking for hopefully correct ly uh user overviews this and clicks approve Returns the permission object back to the dab which stores it somewhere this could be database this could be local local storage doesn't matter like this is safe to store anywhere it's completely fine after that daap wants to send user Ops on behalf of the user it uses this permission context and signature uh from the session key um and submits user Ops directly to the bundler so if if you see the flow here uh T is completely skipping the wallet in the user and is sending user Ops directly to the bundler on user's behalf coming back to the session key um definition like what exactly is session key I just added some cryptographic key uh which is true in this use case it could be the same type of key you are using to um I guess have your own wallet like ecdsa K1 key however there are multiple I guess possible uh definitions of session key and one definition is Pass key so um I could be the type of user that doesn't like this type of background behavior and someone doing something on my behalf instead I just don't like being prompted all the time by my phone I want to connect like once and then every other transaction should be approved by my pass key if I'm using um I guess mobile device if I'm using desktop device I have Pass key on on the on the browser as well so the point is I want to stay within the dab context I want to be aware of every interaction but still I want to explicitly approve everything that's just one type there are other types that are like um useful for other purposes like BLS signatures for aggregation and stuff like that but still the standard is completely open to to any other key type the issue with pass Keys is they're really expensive to verify like verifying signature from p on chain is like 10 to 15 times more expensive than the standard signature thankfully in the next hard Fork like we have included EIP 7212 uh which makes this super cheap and then pasis are basically viable authentification methods for all wallets one more EIP uh 7702 uh this one was a big one a couple of weeks ago like written by Vall himself uh in response to 3074 um like the gist of it is that aot it allows EAS so accounts that are not smart accounts the traditional like old accounts D accounts uh to execute any uh bite code or the I guess compile solidity code uh in in in a transaction so for the duration of transaction I can use any smart account features I like so uh I can make pay pay Master sponsor my transaction I can bundle multiple different interactions in one transaction so as an EA I can use any smart account capability but still not deploy smart accounts still maintain my account the the as as an eua what's good about this is that it allows EAS to issue permissions as well so for now this has only been scope with smart for smart accounts because uh uas can't really issue permissions they don't have any code they're dumb uh but with 7702 I can basically issue permissions with every current wallet um and then use it as a smart account wallet and that's pretty great uh again it's expected for it to be included in the next hard Fork uh which is probably like AUM still uh but still it's not like finalized when I explained the um the flow um it's it's expected for the I guess connection to be established beforehand before I request permissions which is fine uh but then like the issue is like when I visit the dab um I connect I'm prompted by my wallet to approve connection that's fine um if the DAP is using CV or siging with ethereum for authentification I'm prompted again so that's second click and then um if the daap once to I guess utilize the permissions I'm prompted again to issue permissions so I just want to use app and I'm prompted three times by my wallet uh in order before I even like started using anything so that's not great uh thankfully we have Cape 222 uh which is allowing us to bundle all of these interactions into one call and one approve what side um for those of you who are like unfamiliar with capes we have eips that are like ethereum Improvement proposals for ethereum and we have capes that are chain agnostic so chain agnostic Improvement proposal uh that just means it's like as it name said like chain agnostic it works with like Bitcoin Solana ethereum whatever so um with all of this like what's the I guess ux that we are like striving for um when I authenticate with like web 2 apps using SSO it prompts me to uh click accept on my Google account but it specifies like what it can do when I authenticate with my Google account I don't expect someone by default to put some files uh in my Google Drive or read my emails um I just wanted to I guess use my email for the authentification purpose and nothing else and Google does this pretty well because it's ask me what I want to do and if I'm not okay with it I'm going to like reject so um the equivalent experience for the web 3 would be the image to the right uh which is by the way uh internal prototype we have this is not um it's not just like theoretical or made up um it's it's working like wallet uh that connects um specifies some permission like interact with donut contract which is just some dumy contract we made up uh spend up to.5 e in a transaction maximum five e and session key is valid for seven days because each session key has validity uh I click approve I'm back on the dab and basically uh I'm authenticated issued permissions and dab can use uh whatever it does like in a standard way so it it doesn't need to change any additional logic everything is happening like wallet side how is that possible well um most dabs and wallets already utilize wallet connect protocol uh now and wallet connect test the case so we are striving to make all of this not a breaking change for the DAP because if you say yeah permissions are great uh but you have to spend weeks or even months um changing your code in order to support support this like nobody's going to support this um so if if you're an adap you just use VM vag me ethers whatever to send transactions in a normal way and you shouldn't really care if you are using like full-fledged wallet connection between the DAP and a wallet uh if you're using permissions if the wallet is deployed if it's not deployed if you should be using Cape this or EIP that like everything else should be handled by wallet connect and it will be handled by wallet connect if you're a wallet uh if you're smart account wallet thankfully this is going to be shipped as 7579 module uh which is the standard that defines how smart accounts um install and use different modules uh currently basically our implementations like safe by economy zero Dev are compatible 7579 so again instantly this is compatible with basically most most used smart accounts um finally like why why do we why do we bother like why does it matter um for this I guess um web two products that we use today don't have great ux but it's pretty good like if I'm on Twitter and I tweet I don't expect to be authenticated for the Tweet like I know I know what it does uh but for web products it's kind of uh we compromise for the sake on the on the ux for the sake of Technology like it because it's cool to use something because it's web free uh but usually these products are so much worse that than like what are we expected to use and then what we should use and as long as it's like that um like we can't really expect any mainstream adoption because users they don't care about the weap technology session Keys zps like it's there's no point like user is only going to use your product if it's simpler and better than the VAP 2 alternative that they are already using and as long as like we are working on promoting technology instead of promoting ux that's not going to be the case I see the industry like shifting now in into the ux focus like everything was about scaling a couple of years back now it's pretty good like scaling is mostly solved and basically every big company is working on the ux as it should be and U yeah I'm super excited like we're going to contribute from volet connect side as much as we can starting with this like we already do so much for the ux otherwise everybody would still be stuck on the browser wallets um for everything but yeah permissions is going to unlock so many things I'm super excited about that uh and with that said if there are any questions uh yeah feel free okay no questions interesting okay have questions so if you could just like quickly compare uh this new AIP with what we have in terms of uh seway and capability uh Recaps resource capabilities like like it seems very similar I just want to know like what the key differences are which require a new EIP uh so are you asking between the capabilities like Recaps right yeah yeah exactly so um Recaps basically Define a way to send a call and so basically CV can be uh structured in a way that it's a recap right uh but it's a CV right uh I can't issue permissions with CV so I need new new stuff to issue permissions but when I said Cape 222 it means that there is a way to bundle the new call wallet Grant permissions as a recap so it's going to be sent to the user as a part of the connection request and as a part of the cway so it's going to be another recap and then I'm going to be basically prompted one more time uh or actually not be prompted one more time and just click once approve and it's done so the goal is yes to be structured as as a separate call so you can call it uh like you would use e personal sign but still it's possible to structure it as a recap so it could be bundled with other request happy you're happy that's a very politically correct answer I'm glad you're do we have any more questions yes um I have two questions so the first first one is where is the session key stored is it stored within like one specific wallet and it I guess it then doesn't synchronize across the other wallets and then related to this can I revoke sessions so if there is like the session key is exposed or something is there some kind of Blacklist where it then says hey this session is invalid and I I can invalidate it myself yeah those are great questions so uh where is the session key stored uh we Define session key uh as something that the app owns or at least it should be d d side because the point is I want to connect with my wallet once and then I I don't want to use my wallet for the next X whatever the validity of my session key is so it should be dep side uh however if if it's if you want it to be like synced uh it's up to DAP to sync it like dap can like securely store it in its database uh because if you modify session key it's no longer valid so it's completely safe to I guess trust the daap to store it and uh the the other question is uh revocation of the permissions so um that's a tricky one because um the AIP doesn't Define revocation because uh revocation doesn't necessarily need wallet connection and if we were to introduce uh wallet revoke permissions that would mean that I expect um I expect the connection between the DAP and the wallet however um revocation is totally like POS possible with just smart contract code and any like any signer that is not a wallet like session key should be able to revoke permissions as well and if I uh if I introduce a new call that's not possible so for now it's out of the spec and it's out it's up to the account implementations to define the revocation logic uh but it's definitely something that is being like worked on like actively by basically all account implementations are you happy everybody's happy anyone else looking for a dose of dopamine okay then uh we can wrap it up thank you Luka so much thanks give it up for Luka thanks everyone