Wallet Security: Past, Present & Future

Transcript

[music] All righty. Hello everyone and um I'm I'm Elliot and today we're going to be talking about wallet security and going from the past uh into the the present and exploring the future of of what security looks like here. Um I would love if we could start off with some introductions.

everyone go around and talk about, you know, what you're working on and yeah, maybe Michael, uh, you could start us off. >> Sounds good. Uh, hey everyone. Uh, my name is Michael. I've been in the crypto space since 2012. Started mining Bitcoin on some random school computers and been doing stuff ever since. Um, was at Open Zeppelin for about four years. Focused mainly on smart contract security, but also operational security for some of our top customers, including Compound and others. Uh, serving on some security councils. So got familiar with wallet security from that perspective and then since uh been working at turnkey which is an embedded key management infrastructure uh platform that's used both for custodial and non-custodial wallets and there have been much more in the weeds on building enterprise wallets

uh policy management and uh you know figuring out how to make wallets work at scale. >> Awesome. All right, I can go next. Uh first of all, thanks for having me. My name is Rahul. I'm CEO of Safe Labs. Uh for those of you who don't know, SAFE is a multisc account that we developed uh 7 years ago, spun out of Nosis. Uh it's used as probably one of the most widely used uh uh smart account infrastructures uh in the world right now. Uh my background is primarily uh product and engineering. Uh lately a lot more security uh by accident I would say. Not not by choice, but I'm still enjoying it. [laughter] Uh yeah, glad to be here.

Let's uh happy to talk more about uh wallet stuff. And hey, >> sorry I'm late. Um I'm Robert. I work at the Ethereum Foundation. I'm on the Kohaku project. We're working on wallet privacy and wallet security. And then I'm also an initiative lead at SEAL Security Alliance where I focus on safe harbor which is designed to help white intervene during active exploits. >> Um hi, I'm Kain. I'm from Coinspit. We've been in the blockchain security space since 2014. And I'm here representing our wallet security team which uh have done a lot of research into wallet for the last three or four years. For you that uh have been at DSS these last few days, I gave a talk about

uh uh Cedor Random number generation flow and um yeah that's me. >> Awesome. So I want to kick things off and set the stage by going back a little bit um way back I guess almost a decade now. So you know the parody style the parody bug um caused a lot of money to go missing and be permanently locked um by a essentially a library being frozen. So this was a smart contract vulnerability.

Um and but in the recent years I would say things are getting a lot more sophisticated and moving much more towards um social engineering. So I I wanted to start off with the question of what are the categories of hacks on wallets that we really don't worry about anymore. Um, and like what really feels like in the rear view mirror? >> Well, we don't worry about libraries getting hacked because everyone stopped using them after parody. Um, so at least that's one gone even though we still have like potential dependency issues.

Um, we do I would say we don't worry about we still worry about a lot of the same problems in the sense that like Mount Gaus reminded us hot wallets can still be hacked and if you put too much money in a hot wallet with Binance, you can still lose a lot of money. So in a way I think we still have some of the same problems that we had before at least from like the enterprise wallet perspective. Um for consumers I feel like we do have like a lot of funds were lost not from like I feel like more money was lost from people losing their wallet than actually having their wallet hacked in the earlier days from a consumer perspective. And I do feel like we built better recovery methods and better consumer awareness there. It's not a problem that's gone but it's a

little bit better to manage. There's more recovery options than before. Um yeah, so some problems the same, some problems different or at least a little bit more improved. Um but I would say that as the adoption curve increases, like I think a lot of the problems still persist and we are still thinking through like how it's going to work at scale. We've gone from let's say more hobbyist users that are a little bit more willing to educate themselves to consumers that are expecting the same user experience as their bank account and are going to need a lot more handholding. Yeah, as Michael was saying, uh, hobist is the right word for like the party era, I guess. Uh, at DSS there was a talk about the party attack and I'm very bad at names. I don't remember the the

speaker talk, but basically he recounted how um the night they they figured it out. He was waiting at the door um with a bat. Uh, so it was very precarious because he was afraid of someone like actually physically coming. But talking a little bit not about parity only but after that I think that uh we have the perception that we should stop worrying about some bugs and maybe that's not true maybe especially with AI coming on in the loop uh which we'll get there I don't want to like um go forward too fast and also I want to mention that wallets are in this unique space I I think I don't I don't believe there's anything

else like that in the block space where past bugs continue affecting funds even after they fixed. Uh so like um Milkad, ill Bloom, the the the vulner researched uh cold cart I mean um and this kind of um also like key stealing uh vulnerabilities with um all my all of what they say will be mostly from the perspective of uh consumer apps. Uh so uh browser extensions mostly or mobile wallets but we've recently enough we've been finding like uh wallets uh mobile extensions or wallets that if you connect to a evil site they will get your seed and that's basically the one

thing you don't want happening and that lives on right after the fix. It's that seed is compromised forever and um you have to do a lot of work to get users to actually move their fans. So, I don't think there are any bugs that we don't have to worry about anymore. I think there are bugs we like to believe we don't have to worry about anymore. I'm not sure we are there yet. >> Interesting. >> Yeah, it's it's actually very hard to say what you don't worry about on [laughter] this panel. I think it's our job to actually worry about different things. Uh but I remember when I started in the space like very early and I would tell my non-crypto friends why and uh

why they should use crypto and they would be like uh oh but is it secure right and I'm like yeah but you need to hack uh bring down 51% of the network to bring it down right like you know that you can't beat that right it's a very big problem that is not that is we've taken that for granted now I think we fairly established that that is not a problem to worry about at the most right now especially given the last week of uh how have things gone and and I think uh uh you're right like I agree with both the points like uh we've uh I wouldn't say we completely solved but we solved a large part of custody uh how ownership of your assets it very much depends on how you craft your access to your custody but I think right now I'm seeing

a lot more uh exposure towards how your assets what they can do what your account can do how should should it be restricted etc. So my worries specifically are around the flow of your funds and your uh your dynamic access from your account I guess. >> Yeah I mean broadly agree with everyone and and what they've said. Um one word of caution I would want to add is that just because a problem is solve right now doesn't mean that it's going to be continued to solve in the future. um account recovery with EOAs and like regular wallets is relatively good. As we add account abstraction, as we work with privacy protocols that don't use traditional accounts, we re-encounter these same problems. And if they're not at a forefront or if someone's not

thinking about them, then we're just going to go through the same cycle again. And we don't want to do that. We want to use the learnings that we've already have. >> Yeah, I think that's uh those are good answers to hear. you know, I feel like um smart contracts, it it does seem like those are are um it it's a lot more wellnown how to secure against smart contract vulnerabilities and I think we see a lot of great work with formal verification and um a lot lower um amount of attacks uh happening there. I think I want to move a little bit to kind of the question of policies and you know where where the space is going um

on the institutional side and on the the retail side. Um I guess I wanted to just ask how do you think about onchain versus off-chain? um smart contracts, they can enable some really rigid rate limits [snorts] and you know we see that in like the zodiac roles and some of the safe ecosystem and then uh we have time locks as well as off-chain systems with TEES that can encumber private keys and set transaction policies. So I guess I wanted to ask how you guys see these two things coming together. This rigid onchain system and then the more

flexible off-chain substrate where we can add a lot more programmability and and richness uh to security features. Uh I guess I'll get my perspective and it's a biased one because turnkey is a off-chain solution using primarily secure enclaves to do policies essentially give people pass keys and or Google login or whatever they want essentially as an authentication method and they can build policies on top. They can add additional users they could grant API keys scoped access. Um, I really like account abstraction as well, but I feel like uh my opinion is like if you're going to be operating a wallet across multiple blockchains, which the vast majority of both users and

enterprise will, you're going to need off-chain infrastructure to manage at least some of the policies and then you could maybe layer your account abstraction on top effectively. Um, but I do think that like over time we're going to need to see ways in which uh essentially we handle the offchain security supply chain really well. We put a lot of work at Durk on like okay making sure the secure enclave can't have malicious upgrades to make sure that it has high availability. Um and to also make sure there are ways to do like backups and essentially escape hatches if availability is an issue even though we plan to never go down. You never plan for it just happens. Um so making sure that like our customers know how to handle that as well. Um so I do feel like over time we're going to hopefully see more account abstraction

improvements. 437 I think maybe it's not controversial at this point to say has been uh a very difficult adoption curve and we're very much hoping to see frames and maybe other things improve that uh but it's clear that like you know for users today we're going to have to build things that are more familiar to them. They're going to need to use pass keys or uh authentication methods that they're familiar with that they have like at least a better chance of securing on their own versus the key material itself. Um, so I do think over time we're going to see more like somewhat managed solutions like turnkey but are still non-custodial as much as possible in the sense that like there's still end user control over the actual authentication of like taking an action on chain. Uh, but the key material

itself is abstracted away from them and only like very hardcore users I think will actually want to host the key itself because then there's a lot more on them. I mean, we saw with Ledger and Treasure, which is usually the gold standard of wallet security, uh, is that like even the hardware itself can be compromised through the wrong reseller, etc. So, um, that's not to say you shouldn't still do it. It's not still a good option, but it just requires a lot more work on the individual to figure it out when the average consumer doesn't know how to do that due diligence. So, they're going to need a provider to probably do that for them to some extent at least. >> Yeah. Uh, I I can share some thoughts like how we think about it at safe. We we actually see both as very complimentary but if I have to give like

a oneline answer like onchain stuff is very rigid. Yes. especially it's very counterintuitive to what we have been used to use uh using right uh but I think uh policies are important because it it it helps us express what it should do and what it should cannot do and you and I think you need different instruments for uh expressing different uh controls uh for example the uh where the off-chain stuff is very useful is you it can be very diverse and you're it's it's a it serves a purpose in the pre-transaction life cycle, right? Uh and and you can you can go as as deep as possible in kind of like uh simulations

for example and kind of understanding what it is it doing what what it's supposed to do. Uh but there are things you can only do off offchain uh better perhaps or I would say right now only offchain. For example, uh a more institutional enterprise uh client would probably do. We've se we we've seen you log in three times uh from Malaysia and then you somehow move to uh LA in the next 1 hour and you're changing the policy of your uh safe account that should flags the systems. I think it's it's a very hard problem to solve on chain but it serves a purpose right it it makes the uh compromise or the threat vector that much more significant by adding it and I think we are I I think

there are fragmented systems but we don't have systems that can just put everything together right that's that's uh and uh that can make the entire life cycle uh of a transaction very fluid and uh I think we we need more of those but right Now uh auditing just the contracts for example is just not enough. You need to audit your entire flow because that's what we come on on chain for. We we have a workflow. Uh nobody goes to their wallet to figure out what they should do next. They already know what they have to do. But that needs to be audited, right? So at safe we we believe in like multiple shapes of safes. Like your treasury safe is not the same as your

payment safe. Uh you have higher velocity of transactions in one. Maybe the cold storage is just like it should not do anything but just send one talk to just one other contract or address and these are very different trust systems and control systems that you have to leverage. So uh in short complimentary but I think the challenge is in as for a wallet putting it all together so that it can be auditable uh at the end. >> Yeah I think I agree with Rahul here. Um I think we as as as humans have this tendency to think that this thing will solve uh security like uh well now we have a count of traction or or whatever or a new curve that we support and now

we can do this um or it's similarly offchain and what what we find I'm talking from a very different perspective here because we review others people wallet right so I don't have a product perspective I have a like a bird's view of many wallets What we find is that sometimes wallets or software in general actually that focuses too much on one security aspect, one safety aspect and end ends up relying so much on that little detail or big detail. It can be the best like system ever, but it ends up relying so much on that that it misses uh the forest for the for the trees so to say.

This is something I'm actually curious to hear your opinion on Mitchell. uh sorry but one of the problems that I have with offchain and to be clear I think the offchain is in general a really good solution for most people but you still need a onchain solution um because if there are seven simultaneous earthquakes and all of turnkeys servers go down then users are going to need a way to interact with their funds even while you're setting up or if the keys are lost worst case scenario and so if you focus primarily on the offchain approaches the off-chain approaches are really good for like improving user experience and making things simpler and maybe reducing the security that is required but you still do need some way of interacting with the tokens the wallets onchain. Um yeah I would be

curious to hear your thoughts on that. >> I would I agree that having onchain recovery mechanisms is good. I think the one challenge with that is making it work in practice and and there are off-chain recovery mechanisms like if you just back up the seed phrase and you have it available to a customer there are many paths they can do to recover it even if turnkey is down. So usually it's like giving them secure ways to do do effective backups and ways and make sure for especially enterprises they know how to set it up and maybe different wallet infrastructure if turnkey was was down or something like that. Um I think the one challenge like when I've tried to do like you know crosschain uh you know onchain essentially management uh is like okay you know if you have for example a recovery setup and an escape

hatch uh if you're using your wallet across multiple different blockchains then you have to set up the same recovery method each chain and then if you have to rotate your recovery method you have to rotate it on each chain and you can you can abstract that a bit. um you know you could have like a bridgebased intent system that tries to abstract away some of those changes but um I think that's the we usually you know whatever that abstraction is is probably offchain it has to be so I think you you usually come back to offchain at some point anyway to deal with crosschain compatibility issues so it does feel like that's where a lot of customers are going to start regardless but but you can combine them in good ways like one way that we've done it at turnkey is like we we do all of our gas

abstraction components and batching through 7702 two based smart contracts and we've actually had like wealth simple which is a big Canadian institution having a lot of their consumers trade on turnkey infrastructure where they're using it offchain but they've also used you know account abstraction in ways that make it easier for the user and they don't have to think about gas so um which is not necessarily specific to security but it does I think introduce the ability to add other security features over time as you know institutions get let's say comfortable with account abstraction but they're usually going to want to rely on something offchain if only because that's what they're familiar with from a traditional key management perspective.

>> Yeah, I mean a big part about security is making it convenient enough that people accept the security trade-offs. Um that's a big problem with onchain stuff is because it's so much harder to cycle. If you've got not just a single users account on multiple chains, but if you've got a 772 delegate that 7,000 people are delegated to and there's a vulnerability within that contract, then what are you going to have the contract be upgradable so that you can patch it yourself? But then there's that malicious attack factor or are you going to have it so that those 7,000 people need to issue their own transactions and then how do you get that to happen?

People are going to lose money either way. And so it is definitely a tough problem in either case. >> I think that's um that's one of the core that cuts to the core of the question, you know, around security. It's it's a trade-off between speed and flexibility and um ergonomics. you know, like a the most secure thing would probably not be good enough for most people to use on a day-to-day basis. And so that's um it's a very hard problem to solve and there's there's unfortunately no uh one-sizefits-all answers. So I wanted to kind of transition here to you know in this age of really really fastm moving exploits

with AI and attackers you know moving so quickly. What does that mean? And you know in the Binance exploit we saw 7702 feature as they attached a drainer contract to that wallet so they could drain everything 50 different assets in a single transaction. I I mean what what do we make of this and and what does that mean for teams today where there's all these new standards that are coming together and they make users lives easier um and the wallets more useful and yet they also add some uh unintended side effects and consequences. Someone's

going to need to search this up for me because I don't want to misquote it, but a very significant percentage of all 772 delegations are malicious. Um, because as you make tools that make it easier for users to use software, you also make tools that make it easier for hackers to use software. It is basically impossible to make a tool that can distinguish between angels and devils. I mean, I think it it practically means that the majority of consumers should move through applications that go through a lot of work to essentially create allow lists of what they should interact with. Um, you know, the majority of users should not be logging on to random DeFi sites and plugging in their wallet because it's very easy to get fished. It's very easy to get hacked. Uh, even, you know, using

traditional wallets like MetaMask requires a lot of steps and seed phrase backup. So I think you know this is what we're seeing with embedded wallets but people being able to go through an app application that is taking on more responsibility to manage the security for the user in terms of these are the DeFi protocols we know are safe. These are the standards we know that are safe. Um you know if there are enhancements that can be provided through these new standards. They will likely get adopted but likely slower um in such a way that like the impact on the user is already well known by the time it rolls out. Um so that that's what I would expect is like the the responsible way to approach it. I think it's good to still allow people to engage with new and experimental things, but I do think that

we should when we're educating the average consumer, it should probably be like yes, you start with using something that is going to provide you a lot of guidance on like interacting with a DEX like you know going back to wealth simple like there are customers that are interacting with Dexes on well simple and they don't need to know what a DEX is. They don't need to know anything about the security posture. they just need to know how to log into their wealth simple account and then the rest is taken care of for them which is the experience they expect when interacting with a financial app. So um I think that's that's generally the path like someone has to make decisions for the users which does mean restricting them.

Um but that's why we should always allow people to have full self-custody and the ability to engage with apps directly if they wish. Um but it it should be like I I think when we're educating people it should just be like do so at your own risk. like when you're doing that that is that is going to be a much more dangerous environment and will likely just get more dangerous over time. So even though I love doing it, it's fun. Um I do it with like a decent amount of paranoia and worry and with a probably limited amount of funds that I would be willing to risk. >> Picking up from where Michael was uh talking about educating users and providing them with options that are relatively known to be safer than others. Uh for us it's really important.

We believe we have our our own wallet ranking um but we believe that other efforts are being done like L2 um L2 no wallet bit wallet bit uh so that's also very respectable I I we like that approach um because users don't have the expertise or the time to understand their own thread model basically uh it's an impossible ask for someone that wouldn't have solved the Binance hack at all but um it's a step forward and then uh as I believe Robert said you can't introduce new features without the features being useful for attackers somehow somehow so it's a matter of deciding basically when do we want to

like stabilize uh step on the brakes a little bit how much innovation are we willing to risk um and if we accept accept our risk maybe in 10 years we are going to have the same panel talking about uh this hack with 7702 as we were talking about the parity hacks, right? Like ours. Yes, we were so dumb then um and so on and so forth. >> Yeah, like maybe [clears throat] a different perspective just like a fresh thought. Uh I I do remember when 7702 for example when it was being drafted and discussed there were a lot of people who flagged certain things who would probably say I told you so right now right? Uh I I I do wonder when cuz I

think one frame of mind we have to uh establish is the attackers will probably be our earliest adopters right and they have too much skin in the game probably it's too much to uh win so they will go above and beyond including reading fragmented docs bad documentation bad prototypes missing they will probably piece that all together uh and I think we We often what I I do remember this discussion at 772 as well like there was a very optimistic view of looking at the value it would create right but but at some point I think we are kind of like in this conjecture of uh does the benefits outweigh the risks and the cost

that it probably created [snorts] and and if it if it doesn't are we in a position can we reverse it or is this irreversible is this a roll forward kind of a issue and I often think And cuz there is no accountability per se. It's a shared accountability like like all things security related as well, right? Uh I I do think when perhaps uh when bringing in new standards when there is no dedication for a follow through of adoption, education and stuff, maybe that's a point for us to kind of step back and uh because there is always going to be an attacker that's going to fill the gaps, not contribute to the open source ecosystem, etc. Uh but I think it's a it's it's a challenge. I I

I don't know how we can solve this but I think we're facing it with probably new standards too. >> One shout out like on like cuz we have made it easier for attackers but like at least one thing for defenders is uh you know we've seen people uh use turnkey on like with 772 to do batching very efficiently. So, we've had people that have created what I like to call like the big red button where if they see anything fishing going on in this DeFi protocol or even on this chain, they can just push this button and even if you have a DeFi position that takes multiple steps to unwind, they can just do it all in one go and like get the heck out of there. I've actually had customers that did that to get out of like a before kelp DAO basically paused the whole

thing. So, like, you know, there's benefits to defenders and attackers. The defenders just need to also make sure they're utilizing it. There's a lot more economic stake for the attackers to innovate than there is for the defenders, especially before the attackers have started. It's it can be really really hard to like predict what an attacker is going to do even if you know that there's like some potential for some issues in some feature. Um you don't know what people are going to come up with. >> Yeah. Yeah. I think that um the amount of exploits that have been generated is it's truly staggering um how how fast attackers have adopted this technology because you know they have a lot of incentive to put things together and you

know take fragmented EIPs and forum posts and poll requests and get a really good picture of of what's going on. So, I I wanted to ask how as defenders you're using AI to keep your software company safe. Um, and I have a a statement, but feel free to push back or challenge or disagree. It seems that there's an asymmetry with AI where it favors attackers because they can just go burn a bunch of compute and start a bunch of different instances to try to break into some system. And so, you

know, what what are we doing on the defense um to counter that and and how how does that work? I I'll start by your statement which uh I agree with but I believe it's true because for years since computers were computers security has been based on the idea that attackers needed resources and we've known that their vulnerabilities existed. We were sure of that everywhere and we just assumed that okay if we can't find them no one can or it's so expensive or well maybe if like the CIA is after you well you're doomed but and that assumption has changed and it has changed too quickly for the for the

defense side to adapt uh with the velocity that they needed to adapt with. I think things will level out after n years. I don't I can't predict that. Um but basically what what the defense side can do is stop assuming that attack is costly. It's not anymore. You you don't need that many resources to steal millions of dollars. [snorts] Um like maybe two perspectives. One is like from the turnkey perspective I myself am not directly involved in the engineering that deploys code to the enclaves but for our team like they are using AI more um certainly to try to develop uh code faster but also safer.

Um but the deployment mechanism, the actual deployment of the code into the enclave is still a manual event. It still requires in our case like multiple UB keys and uh like air gap machines that are actually approving the upgrade. So like knowing where and the the biggest challenge that I think every team is facing especially for security conscious code is like how do you code faster but like are and really in in reality you can try to use code to code faster but like if you have to read all that code you're not actually that much faster. So how do you like find a way to actually write code without having to read every line but still having strong security guarantees, strong test suites, even formal verification. We don't act I think honestly we don't have that answer

yet. We're still figuring it out. Um, so we've just fall back to manual methods wherever we don't have a clear answer. Um, and and just stick to what we know works until we adopt something until we've like fully vetted it in terms of like more AIdriven uh workflows. From a personal perspective, I've done like some payment operations on the side for uh for some teams that I've been advising. Uh, and I've found that like AI is really good for queuing up payment transactions on whether it's you're proposing on a safe or you're proposing through Anchorage or Porto or Coinbase wallets like you know usually most of these wallets have an API based way you can propose a payment and then other people have to come in and approve it through a multi-approval process and the details of that payment are able to be

provided there and I've often found AI is very useful for questioning that payment of like is that the same address you used before? Do you already have policies set up? And then you even programming organizational policies where even though the AI is not deterministic, you can tell it like these are the guidelines you should follow and enforce and the questions you should ask on every transaction um before it moves forward. Um so I have found it useful from a personal perspective of like just putting more security rigor into transactions I might otherwise be putting into a safe with less thought or foresight even though I might say like yeah, I'm going to try to think through every transaction. um an AI is always going to be able to potentially like look at like you know the last year or two of transactions you've made with that same entity and

say does this match the pattern which I would probably not be able to recollect off the top of my mind. So I think that's like from a personal perspective a good way to do it but still like make sure it's a manual approval method and when you're reading and you read the transaction manually before you still approve it or if you want to automate it fully which take that with a grain of salt you you have very restricted policies on exactly what the AI could approve unilaterally if you even want to give it that control or not. >> Makes sense. Um yeah, like uh I've been thinking about this quite a bit [laughter] a lot. Uh I mean ultimately like the uh offensive AI is compounding at a really high rate right now. Uh it's outpacing

defensive AI. uh and I think the reason is because we just haven't figured out how what shape and form defensive AI uh should take for it to compound at the same rate. Um 6 months ago we were at Zapcon in Berlin and I met we we do often security workshops and security events. I met with a lot of security teams and I had the consistent same pitch from all the customer uh security teams. our AI agent is uh really good at finding vulnerabilities, right? Like vulnerability manning uh etc. All of them had the same pitch which is great like I think uh but it for me it was

very clear that that is not enough [laughter] that is just finding right the the real moving of the needle is to patch the systems right and when I took that back to my uh uh my team and like discussing h how what would actually help move the needle it's not discovery it's actually patching so how do we actually patch systems right we need this to sit with us uh it needs to augment our processes, our discovery, our our metrics, our our engineering, our our detection, etc. Everything and I think that the the the shape the defensive AI system needs to take is very complex and fragmented. It's probably why it hasn't compounded at the rate. Uh about 4 days ago actually there

was a report by Andre Horowitz. uh they they studied uh they they had a survey with uh CISOs like chief security officers hundreds of them uh and they were ask them what what are you most worried about or what are you working on and there's like about 15 to 20 uh uh items and all of them that are having increasing trend has a prefix called AI and at the bottom believe it or not included uh that they're worried about less is APS and nation states actors. Uh this is more coming from the tech, big tech, non-crypto. I I think we we overindex perhaps uh correctly [laughter] on the AP especially after

last week. Uh so so what does that tell me, right? Like if you look at uh each of each of those uh trend uptrends, right? like AI sock 2 uh AI vulnerability patching AI uh compliance checks uh which uh and AI screening of your uh IT workers perhaps you know and uh but the point is that we just haven't augmented AI in the systems that already exist and I think a lot of us probably are including myself we were thinking about it look I I need something AI so that I can defend myself but I think it's already here we just need to augment it into our uh everyday systems to to supercharge it. Uh and I think we just haven't had this. Uh so in my opinion, if I were to make a prediction,

people who have figured out how to augment systems are better off than building a product uh uh then that says this can solve everything for you. That's my hot take. >> Yeah. I I tend to be very pessimistic about how AI can be used because I think that ultimately these are human decisions that we're responsible for and an AI is not have the context that is required necessarily to like make full-fledged decisions about uh how everything works and AIs are known to have problems with hallucinations. Um they're known to be able to like prompt injected although that's getting better.

Um you don't want to offload your intelligence to a system which we know is very unreliable. And so with that being said, there are a lot of use cases where offloading where using that additional intelligence to like process data can be very useful. And I think that one of the problems is that there's so much that needs to be looked at. Um because if if you just think of it from a monetary perspective, attackers are going to have so much more resources because the benefit that you get from attacking or successfully attacking a protocol is going to be anywhere from 10% to 100% depending on if they're pretending to be a white hat or not of the protocol's TVO. And a security team is going to get 1,000th of that budget,

one 10,000th of that budget. Like they're going to get nothing by comparison. And so you need to build systems where you can confidently make assertions about the system as a whole. Which is one of the reasons why I think that like formal verification is going to become increasingly important because it it requires very little human effort relative to the security gains that can be given. You can like formal verification and AI actually work really well together because you can have a person that's checking all of the statements and all of the theorems that are being verified and you can make sure that all of that is exactly correct. And then it doesn't really matter how the implementation actually works. If you've got a solid theorem that fully constrains the system, it can just be a black box and you could use an AI to do

the resource intensive task and like you should still have a person look at it, but it's not as critical. Yeah, I mean it's it's so interesting hearing hearing these answers and you know I'm I'm very glad that um we're not fully trusting AI outputs for [snorts] uh for for code yet because it can write a lot of code very fast and then the question is security verification. Um so moving on to to other kind of uh standards and specifically turnkey um you know you guys um let's talk about you know support for

4337 and other uh standards and how do you think about that because there's more more coming down the line and you know what are customers asking for and are they okay with, you know, what are what are they asking for? >> I mean, yeah, I mean, I made a snide comment at 437 and maybe to go into more detail, I feel like that has been a bit of a standard tell. Um, and trying to be like, you know, show me a user op and I'll show you something I don't want to figure out how to read. Um, and uh, we've had a few requests for for like better support for user ops. We have a very detailed policy engine. It can give you great very granular controls over like what an API key or a specific user is allowed to do. You can scope

sessions. You can require step of approval. But like user ops in these very specific standards can only go so far. Like we have support for EIP712. Um but beyond that we have tried to keep our system fairly generic. So we do have customers that can use 437 on us like zero dev for example and then layer on a smart contract layer that they have but like we don't usually go out of our way to support the policies themselves. Um, and it's partly just because like yeah, we I think my thought is like 437 is not long for this world. I think it's bloated. I think it requires too much on offchain infrastructure. It was built before native account abstraction came out. Um, and that's really the path we should be going towards anyway. Um, and if you want to do usually if you're doing account abstraction, you're trying

to do policies at least somewhat on chain anyway. So it doesn't make sense to necessarily support offchain. Um, so I mean we focus on just the cryptographic curve level. Give us a raw payload and we'll sign it. Um but if you want us to also be able to run the same policy checks in the secure enclave before signing it then yeah there's only specific standards that we'll support it has to be like a smart contract um EIP712 or something else that's like fairly common place and ubiquitous already uh and then also parsing the transactions which is like I think the challenge like trying to support new chains uh support move on sooie for example or others uh now you have to completely rethink a whole new like uh programming paradigm and make sure that it works securely and then people need to rely on it. So

right now like we've really only focused on like Bitcoin, Ethereum and Salana. Those are the main ones we've done and we've kind of stayed conservatively focused on those and trying to harden that and improve it over time but generally not going further. So I guess backing up the short version is uh yeah there's only certain standards that we can support from a product perspective and I think 437 is not going to be one of them. But I do hope that over time an account abstraction in the Ethereum world does become there's a very standardized path that we eventually align to. But I hope that we have learned enough painful lessons in the past that we learn to focus on one standard or at least one standard way of doing it over time. But we'll see.

>> This is maybe a bit of a silly analogy, but like there's a reason why aimatic systems are so useful. It's much easier to build complicated systems on very simple rules than it is to build complicated systems on complicated rules. And I'm a bit biased because I work on 4337 8141 um like all the account abstraction stuff. But I think that it needs there needs to be some very simple ways to work with it. Um and the more complexity that you add at a protocol level is complexity that is going to cause problems. And like you could build systems on top of 437 if you wanted to. Um but if those systems are built into 437 from the start, it's harder to get started. It's harder to iterate yourself. it's harder to make sure that there are no gaps in your system that can't be exploited.

>> That makes sense. Um, so transitioning I guess from the the TE world for transaction policies and heading to you Rahul I I wanted to ask you about um safe pro and safet which you guys have have recently launched. Um, it seems like safet is this really advanced policy engine where, you know, you have these knobs and dials that teams can turn to, you know, add a lot of extra security to to their wallets. So, I would I would love to hear kind of how these offerings tie together, how they differ, um, and and where you see that going.

>> Yeah. [clears throat] Yeah. uh uh I I I'll start with this like uh uh I think for for the first time after 7 years launching the multisig smart accounts safe has two new onchain products. One is the uh what we call for lack of a better branding term policy engine. Uh and then something that's probably a little bit more sexier is safeet. uh uh ultimately the our mental model uh when we're thinking about this evolving threat landscape is what one is your account and then express what you can do with that account which through the policy layer and then you should be able to run all sorts of static checks simulations etc and then hopefully what which is what safet is actually is

this was the long-term vision which is onchain enforcement of uh use uh use security providers from a decent centralized network of uh uh design to practically say hey is this secure or insecure you know I think uh from our past we've learned that we can't rely on a single uh provider to kind of get that uh system in place uh where we can actually get that information to the user because I think when you're transacting it's it uh it becomes infinitely more complex and lastly this guard like to kind of really protect this uh we've already had this guard design for a long time but it it hasn't had that much uh adoption. So right now

uh the policy layer is meant to express this uh and the safet is is a a is a protocol layer where we're inviting sentinels to run uh and participate by providing security uh verdicts on whether your transaction is malicious, benign or inconclusive for example. Uh and I think this that's that's our way of kind of like thinking about it and uh also for safe pro the it's our opinionated it's a very opinionated way of building an enterprisegrade product uh because uh what we're noticing is that there are safe is being used for billions of uh value uh it's also securing huge protocols for governance as well and I think when you have a very

complex system to express your governance and security you need a more professional systems that also often invite uh involves coordinating multiple people, systems, processes and stuff. Uh that's why we built Safe Pro. Uh so uh it's been a longterm coming, but uh this week after last week, it feels like this is I'm more confident in our playbook than ever before. >> That's really it's really interesting seeing how the two worlds are coming together. the rigid onchain rules, off-chain rules, and now they kind of meet at the smart contract layer. Um, and I think that that is probably where uh things are are going to be going uh

increasingly. So, we now have uh Q&A and we will start with um what's one safeguard that wallets should offer? So, a single bad approval can't wipe out my balance and what convenience would I give up for it? This is a tough one. >> Uh, I actually will have a talk later this week that kind of gets into this, which is like we kind of have defaulted to users being root users on wallets by default, which means that one mistake can screw it up. Uh, if you make one bad approval, all the money is gone. Um, so one thing that we're we've tried to offer at Turkey is like what we call

scope sessions. So when you are you are signing uh you know when you log into your account you don't initially start with effectively root privilege i.e. you can sign any transaction. Um, ideally you are set up so that you only send to wallets that you already know uh or that are essentially already your wallets. You only will trade on DeFi apps that you already use or if this is like an embedded wallet experience essentially what the provider has already decided that you would normally use and does not essentially result in funds leaving your control. Like if you know funds are being moved, it's going between smart contracts that you control funds on or it's uh keys that you still control or a part of your wallet. um you do give up some friction there where if you do want to like let's say do a withdrawal or

something then you have to do a step of approval. Maybe you also run additional security checks. You could also introduce time delays if you wanted to. There's a lot of ways you could experiment with the user experience but generally you're going to you're you're adding some friction. You're making it it's going to be slower for someone to say, "Oh, I see a new app. I want to go play with it." Uh or new DeFi app. Um and you know you're going to have to either do stepup approvals or find a way to get it integrated in a way that's like maybe going to be slower. But it's I think for the vast majority of users would be worth it. So essentially, you know, your average signing session is very scoped and then your stepup approval is enough that the average user or security check will catch a potential

attack vector or fishing attempt. Another couple things that are relevant to this are um transaction assertions and clear signing which both kind of touch on this but for transaction assertions specifically they're the idea that they're a frame transaction specific thing and they're the idea that after your transaction is executed you can make certain assertions about the state changes that have happened and so I think that it is a really important thing that right now we kind of treat different levels of security as different wallets which is like the idea of having your cold wallet and your hot wallet. Uh, and I think that that should be baked into the wallets themselves, similar to what you're talking about with turnkey. Um, but onchain and transaction assertions are really good way to do that. But you can you can make assertions that if the permission was

given using this particular method, then we can assert that only these changes were made and nothing else happened. Uh, and so for example, you can assert that your balance is at least 90% of what it was at the start of the transaction. um and you know that you will always have that be the case unless some configuration about your wallet changes. I could add a very very quick thing. Um [snorts] I think uh uh wallets should offer uh different shapes of accounts. Uh if you have your life savings in one single account, it is supposed to be very hard to move money from it. It's supposed to be slow, should not be easy.

It's by design. which means uh by byproduct of that principle is that you should just have multiple accounts and and I think uh we should just educate users a little bit more than what are you using it for [laughter] you know just ask that one data point perhaps and that can probably help uh uh design your system of uh accounts and I think most of us do have multiple accounts I think it's just bringing up more purpose to uh your account system >> that makes sense um let's See, we're >> quantum maybe >> quantum.

>> Quantum is fine. >> Talk about quantum. Everyone's talking about quantum. [laughter] >> There are there is a question about quantum here. Um uh yeah, thank you Wen and Coinspec for the great wallet ranking. Can you tell us more about uh how to contribute to it? >> Uh yeah, thanks. Um so I mentioned that it was open and I didn't mention how to how open it is or where it is. Uh if you if you go to wallets.coinsspinspect.com coinspect.com. It's open model, open weight. Uh you can collaborate with us on anything. There are a couple GitHub repos also. So you can basically reproduce your results in your local machine uh offline. Maybe maybe offline, I don't know, but if you're paranoid,

you can try. Um so yeah, that's it. Go there and check it out. Thanks. >> So we have another question here. Does the Binance hack accelerate the push towards self-custody? And what are the lessons from the hack for owners of self-custody wallets? [snorts] This is a hard-hitting question here. >> All this question since the first centralized exchange hack ever. That's all I want to say. >> Yeah, I was like I'm getting a lot of Mount Gaus vibes. every the not your keys not your crypto was very popular after Mount Gaus and then after 10 years of consumer wallets getting fished. Um I so no I think in the sense that like now

right now we're in the enterprise institutional space of like adoption. Um so like yes consumers still matter but like really what all the big crypto projects are thinking about is how do I get institutions using me and the vast majority of institutions will not self- custody. They in fact a a publicly traded company cannot self- custody. they must use a qualified custodian. They literally are practically legally not allowed to self- custody. I mean, not only that, it's just most of these companies probably also don't have the expertise and would have to build it in house. So, um I think unlike before, like today practically a lot of the value is going to be with institutions or at least the new value ideally. Um and that is going to require better custodial solutions or maybe like a mixed custody like using MPC or other

factors that uh you know yes there's you have some share of custody but in practice you're using a provider that's going to do most of the security for you. >> Yeah. Like practically I think that this is probably an endorsement for sexes if anything. Um the worst or not the worst possible but one of the worst possible things that could have happened happened and it looks like people are mostly going to get their money back. find me any self-custody wallet where that would be the case. Um, it is a lot you easier for users to pull their money together into an institution that they can trust and like this is an very expensive advertisement for Binance, but it is basically an advertisement for Binance.

[laughter] >> Uh, yeah, this is a tough one as well, weirdly. Uh, I'm very conflicted like uh uh in one way uh I mean it's it's six billion, right? like something like that. Um, and what blows my mind completely blows my mind is uh the 3Bs, Pybit Binance Bitket. Consistent answer was like, "We got the funds covered." Like how many institutions are out there today that can say, "No, we'll cover your funds. We understand we lost your money, but we'll cover your funds."

Probably less than a handful. And that that puts the pressure on the self- custody because self- custody is a shared responsibility, right? Uh and and ultimately there's one thing I want to say is like it's always the user that's still paying for that money as well. It's not it's not Binance or uh Picket like it's still the user that has been paying for it retroactively at at some point. But then I do come back to this one conclusion like if it's not for self custody, what are we even doing here? Right? Uh, and that that's probably what keeps me going. I would say >> it's basically a form of insurance and it's really really really hard to ensure self-custodial wallets. Uh, I don't think anyone's doing it right now. Um, I

could be wrong about that, but like it's much easier for Binance because they control everything, which is potentially a downside from decentralization. But if I had to pick between decentralization and losing all of my money, I think I'd keep the cash. >> I like to think of it the same way I think about like cash and make accounts. like people the vast majority of people will use bank accounts or they will use like some sort of like financial rail because no one wants to physically use cash but you should always have a right to physically use cash in case the banks uh start to do some funny stuff and then people go back to cash and suddenly they lose business so it's the same way I feel about self- custody we should always have self- custody should always be as usable as possible but we also

have to be practical about a lot of people would prefer a managed solution we just need to make sure the managed providers don't have like a monopoly on like managing the assets >> yeah I think it's um it's very interesting thing because we have Mount Gaus and then uh 5 years six years ago we had FTX and you know now we've had this wave of centralized exchange compromises and yet it still seems that you know people would prefer in many cases to to have that counterparty so that there is you know someone else to you know share the risk with um and I think it will be very interesting to see all the technology that gets built that will help make that decision to to take

control of of crypto assets. Um, you know, the the obviously better move compared to trusting [music]