# Promises and Limitations of Passkey-Based Smart Accounts - Sergey Potekhin | Pimlico

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

## Description

Promises and Limitations of Passkey-Based Smart Accounts - Sergey Potekhin | Pimlico

## Transcript

Um so let me start. Good. Hey everyone. Uh my name is Sergei. Uh I work fin as a lead engineer. Uh so we are building uh usually account abstraction layer pay masters bundlers. We are those who are sending transactions on u ethereum and plenty of other chains. Uh and uh here I'm going to talk about yeah how to make wallets access to wallets uh more human. Uh so yeah we we are all obviously tired and we all tried seat phrases pneumonics writing them down losing them and everything. Uh and um fortunately as of today we have a great uh alternative to it so-called pass keys. I believe pretty much everyone right have tried them at least once maybe in web two not web three. Uh this is the Face ID you're using if you wish on your iPhone. Uh so yeah, we're going to talk about how to make UX feel as bad as good as Apple ID. So yeah, let's see how they work. Um and how to drop them into your DEP. Uh yeah. So here is the demo. You probably use this app. It's called DO. Great wallet. U strongly advise you to try. Why we care about pass keys? You can see on a video how it works. So just a single double tap and uh that's it. So pusks uh first off they're fishing proof. Uh there is no sit phrase. There is no thing that user actually uh got his hands on. So you you can't fish the user into sending you the private key or the seat phrase. And there are also origin specific which additionally increases this uh fishing u I'm sorry uh fishing proof. So next thing is obviously muscle proof. Finally, we have this uh piece of tech that allows us not to onboard users, you know, normal users, they are already familiar with basically how to use their wallet if they're using Pusky powered wallets. Um it it really works well with account of traction. So account of traction, if you're familiar with 4337 EAP, uh it doesn't care about how the signature is made. What is the signature? And uh Pusky has a little bit different signatures than we are used to, but it's not a problem. Again, it works uh smooth with existing account obstruction infrastructure. Uh there was a problem when POS keys first appear in web 3 with how much gas they would consume on verifying the signature again because of the non-standard cryptography. But it's almost not a problem uh anymore and will be probably gone completely in the next few years. So uh again uh it's getting cheaper. platform coverage in this room. Everyone, every device, you already have the POS key support on your phone or your laptop. So, you don't really need to install, you know, extensions as we used to do or even the mobile app. You just have it out of the box. Um, and yes, speaking of security model, the Pusks itself are stored uh in the hardware enclave basically. So, here you can see the moving parts. There are quite a few of them relate compared to you know the common way of signing and sending transactions. So here let me go fast through through them. We have a browser which implements the weban standard which uh exposes the API. So you can create the pass key or you can request a signature from the browser. We have the authenticator. This is where the private key lives never uh never leaves the authenticator. It's usually hardware chip inside your phone or maybe external hardware like a UB key. Uh the pass keys are more or less uh well synced between devices. So let's say if you have two iPhones or uh two different devices with Google Home and both you're signed in into the same profile, they will be synced between those devices which is again pretty cool. You don't need to manually copy anything. And uh the final part if we're talking about web two we would need to you know verify the the login that the user actually logged into your website with the correct pass key. In case of web three we need to verify the signature on the smart contract. We need to check that the signature indeed correct and execution kept can can keep going. Um so few few notes on the cryptography side. Pusks themselves this whole standard I believe it was created before the blockchain became such a big thing. So one um one flaw is that it does not support the so-called CCP 256k1 curve which is native to Ethereum, Bitcoin and everyone else. Uh so you have a few you have a few choices. Basically, everyone uses the same signature which uses the P256 curve. Doesn't really matter what it means. Uh that's an old cryptography, I guess, from the '9s, maybe even older. Uh and this is uh what generates the signature. And uh here comes the question, how do you check the signature on chain? Uh so we have a good news is that since Puski became a thing two years ago, uh it was relatively expensive to verify them on chain. It would take you, I guess, at first half a million of gas, which is, you know, extremely dangerous. And then eventually it dropped down to 3,000 guests, which is the same amount of gas you would spend on the regular uh, you know, signature verification as if you're used to. Uh, so it's it's basically cost the same to send a PKI transaction on Ethereum as to to send uh, you know, the regular transaction. Um there are a few other cryptography um standards supported but they're not really relevant to the blockchain. So just stick with uh P256 and um hope that um the chain you're using the chain you're sending your transaction to it supports this uh pre-ompile uh you can see the name of it is the rollup improvement protocol 7212. So that is that there is a pre-ompile on certain chains unfortunately not on the mainet yet but uh whole OP stack supports it and polygon supports it as well. So base and other chains they all have this pre-ompile and for you if you're using the modern stack uh smart accounts they are automatically detecting this pre-ompile using it and uh this is how you get 3,000 guess perki signature verification that's it. Uh yeah, the rest of the chains will probably fall back to 300,000 guests uh until they uh implement this proposal. Uh so you don't need fortunately to hand roll Pusky's support. There are plenty of existing smart accounts. You can just choose whatever you want to. Uh there is a safe which is you know battle tested everyone knows and they have the Pusky model. There is a Bconomy implementation called Nexus. There is a great product made by ZeroDev. uh they call it kernel account and it also natively supports pass keys and coinbase have their own uh smart accounts which also support pass key uh so you can just choose uh whatever you like uh and yeah and uh from the SDK prosperity perspective we at Pimico maintain the permissionless library which is the most popular library in the space for working with smart accounts so you actually don't even need to figure out the differences uh between those smart accounts you can just use our SDK and it hides on the complexity. So let's say you can stick with kernel and uh probably won't notice the difference between the other smart accounts as well. It's pretty technically savvy uh to find the differences between them. Uh so next thing to remember is there are still a few gotchas if you are implementing pusk smart accounts in your dev. Uh so first off uh remember that this thing uh lives on the on the device and usually does not leave uh the the hardware in cliff. So if user loses the pass key the wallet which has this pass key the account gets bricked. So you should probably think about adding some extra measures maybe alternative ways to authenticate the user. I don't know u social recovery or maybe even zk email things like this. Uh so there may be quite a hustle if you are going to migrate from one ecosystem to another. Again if you're only using Apple products that's fine. If you're only using Google products is fine once you start I'm sorry uh once you start uh migrating from one ecosystem to another it may be tricky to get uh your pass keys with you. Uh and uh last thing that I call chooser fatigue. uh when you're using with uh when you're working with pass keys uh user has to uh to use the standard you know uh UX that browser provides and if you're not accurate if you're not creating the descriptive names the user might uh see something like this and uh well it's probably even worse than the existing UX. So there are still few flaws but they're definitely solvable. Um, next thing about how to add the pass key support into your DEP. So, let's say you decided to build a DEP. You want your smart accounts to be powered completely by pass keys. You don't care about seat phrases and everything. Uh, then you can actually do it pretty fast. So, we at Pimico maintain our own library. We just recently released. It's called Batou. Uh, it works extremely well with VM and Vagme. So if your DAP already uses this text stack uh it will take you just a few lines of code to add uh the support to it. Um and uh since we're doing the account abstruction infrastructure, it's all comes in included. Uh the pay master, the bundler, basically you have to you know put your API key there and uh all transactions they will be sponsored. Your users don't need to have guess they don't have to think about it. They just uh you know do the face ID and the transactions are automatically sent. Uh so another uh important thing that uh we care a lot when building BU is that uh you finally think of it uh since you don't have you don't need the external wallet anymore you don't need a mobile app or extension uh you finally own all the components that uh are involved in your DEP. So let's say before when the user was sending transaction using MetaMask and this uh window appeared and it it is hard to use it right it's hard to read what what's written there this call data or EAP712 signature it's hard to verify it usually users just skip it from now on since uh you own all the ST you can create a way more u better interfaces for your user you can take this screen that's used to confirm a transaction and uh refactor it. So it uh solves exactly your problem and explains very well to the user what's happening here what what type of transaction is sent. You can you know explain it into a plain text. Uh yeah again uh pay master and bundler comes included so you don't think about how transactions are landed on chain uh pimlic or any other account abstraction provider. We don't have a vendor lock so you feel free to replace us if you want to and your transaction will be sponsored and landed on chain. Uh and last thing we're using zero defev kernel smart account implementation which I mentioned before. So um it's heavily outdated and battle tested. Uh so yeah this thing feels secure. This is a short demo of uh how it looks to use the Puski smart account. Uh so give me a second. Uh so yeah you can see there is no connecting wallet no QR codes uh as of now uh all it takes on your Mac is to do the fingerprint transaction will be sent and uh will be included. So on this uh on this connected uh smart account wallet there is no even if to pay for the gas you don't need them anymore. Uh next thing let me mention few other frameworks that are also working on this. Uh so first off there is a great product made by Porto you know this team they're working on foundry they're working on VM and Wagmi and uh they are also uh doing their sort of similar library called Porto uh I certainly recommend you to take a look on it. Uh not only it it works well but it al also implements a few very experimental features that are not here yet in you know general crypto landscape. So, for example, they have this wonderful 7715 subscriptions. You may heard of uh I guess the vast majority of wallets don't support them yet, but you can go to their website, demo website, and see how it works. So uh the problem they're solving let's say with the subscriptions is that user can only approve the let's say 100 USDC spending per hour to a dep with one signature and then the DEP uh itself can uh transfer uh this USDC uh once uh it needs them. So user don't have to you know confirm every single withdrawal they will be automatically and securely withdrawn from his wallet. Uh there is also a third web SDK. Um Alchemy works on their account kit and Privy also supports pass keys in their smart accounts. So yeah, plenty of companies working on it. Um just to recall uh so as of today we have pass keys. They're more or less generally supported uh on smart accounts. It takes just a few lines of code to support them uh in your DEP. uh you there are still few UX gaps but uh you can definitely solve them. Um and uh yeah all the links are available by this QR code. Um thank you for attention. Any questions? >> Can I use my pass key from your wallet and reuse it from? >> Uh no you cannot. So basically pass keys and this is not something that widit or Porto it's part of this uh general crypto standard uh they are origin specific. So let's say if you're creating pass key on github.com you won't be able to use it to log into your Gmail those will be uh like literally different pass keys same with uh Porto and BU just because those are different domains. So as I know Porto works on uh this idea of having u you know sort of the I frame inside of their library which points to their single domain and this is what allows you to reuse the same Pusky which basically uh what what matters is not the Pusky but the address you're getting. So currently if you're using Batu on two different websites you will have two different wallets. Uh so this is how embedded wallets work right now. Let's say same same if you ever used preview privy based applications you're getting different wallets and Porter is experimenting with having a single wallet. It comes with question uh about um fishing proof because but well there is a reason why they were made origin specific because they're very prone to being fished. Uh but yeah, we'll see there there is another interesting idea. I believe Coinbase have a great post in their blog about sub accounts. So the idea is that you have sort of the main account and you have a tree of different accounts. Each one is like origin specific, but they're still connected to your main account. Let's say they can pull the funds if you allow them to do so. So technically those are different accounts. Uh but at the end they're let's say sharing the liquidity which might be interesting. Yeah. >> Hi there. So uh in our de we basically use uh by economy but an older version we didn't yet switch to nexus and for the social login uh part we use the particle wallet >> and we have two or three deps and uh the thing you mentioned before is I think we actually have the same address >> on both of these apps. Do you are you familiar with this? >> Yeah you you can do this. I'm not sure. Uh so which provider are you using for pass uh based smart accounts? uh just by economy. Uh >> well, they they might have the same tweak because again the cryptography originally is uh pretty strict on this. I believe they in their SDK can make it work on different domains and giving you the same addresses. Uh but uh yeah, it's it's not necessary that you want this feature to be enabled. >> Yeah. Yeah. I mean, it's just the way it works. So, I just wanted to check. Thank you. So if the domain goes down, >> sorry, >> if the domain goes down like porter.sh I guess >> also my wallet is pretty much >> Yeah, exactly. Uh same with the like in general again embedded accounts they depend pretty heavily on the domain. Uh I guess uh so there is a term called Pusky server which you usually use. This is the thing that verifies uh your signature. It knows well basically it knows your public key and can verify the authenticity of your request if it goes down yeah your your pass key um is dead we can say this so uh this is the reason and again uh we made an accent while building batour that um you can self-host your this so-called pusky server so you don't depend on our infrastructure or anyone else but yeah if it goes down uh that would be that would hurt Yeah. Then thank you for your attention. Let me