Wallets Panel

Transcript

Dima from 45 Riyadh from Cubist Shahar from fireblocks Tariq from volume finance and you are from the ethereum foundation and this panel is going to be moderated from Francesco from metamask consensus so please give a warm welcome to the panel and let's get started awesome cool thank you so much for the intro are you guys excited about defy security Summit I know you started at night what 9 30 you will go another like three four hours but are you guys still excited oh cool awesome awesome I see some energy cool so yeah I'm Francisco let's start a quick round of like intros and

uh yeah I'm super excited it's only one hour no I'm joking it's a lot but we will cover a lot so let's start with a quick round of intro and uh yeah yo please kick it yeah so uh I'm your advice I'm a with the ethereum foundation working on security and I'm also a co-author of erc4337 so I'm working on a count of suction which is quite related to water security hey everyone I'm Shahar I'm at fireblocks I lead the security products you need to basically I'm responsible for all the security Parts at the Firebox platform coming from about a decade in cyber security before

that hi everyone I'm Dima I'm a co-founder and CTO in fortify and we're an Institutional NPC wallet purpose built for D5 hello I'm Riyad I'm co-founder and CEO at qist and I'm also a faculty at Carnegie Mellon I'm we're working on infrastructural Key Management Solutions and separately I like them what's the word at night I pretend to be an AppLock photographer hi everyone my name is Clem I work for safe previously known as ignosis safe I worked there as a product lead for safe core so I'm specifically looking at developer tooling SDK API and also helping on some

other initiatives all right my name is Tariq and I'm sorry I'm here by some excellent security Specialists uh I will say that I've been in a crypto space for quite a bit wearing different hats currently working at volume we're working on Cosmos SDK L1 chain called Paloma which incends to be a first response chain uh to very much a lot of the security issues we hear about coming to wallets so great to be here with a lot of the awesome folks there we go nice that sounds good and let's also remind everybody this is really like an interactive session so if you guys want to shoot your spicy questions like feel free to just raise your hand and uh and ask your questions but let's start with

some like context you know what's what's the role of wallets into D5 today what do you guys think about it I have an opinion um there are so many panelists today well so what is the role of of wallet in D5 today is it specific to divide in the question I guess while I thought the primary entry points for any user that wants to execute or interact or perform some action on chain um as of now we currently have two primary ways to execute and execute transactions and make calls and

interact with contracts one is through EOS which um you know uh stand for externally owned accounts these accounts um only constitute a public in a private public and private scheme uh key pair that allow you to sign transactions and messages and the other one are contract accounts which is what safe is offering and you know contract accounts are pieces of code that themselves live on the blockchain and which allow to hold any logic to do anything good or bad and yeah so they are very important wallets are not just like wallets actually I I don't quite

like the term of a wallet because they Define so much more than um the you know what we think as people when we think of a wallet but they also um yeah they hold they're critical um yeah in the for the development of the ecosystem Beyond just I think uh the idea that we only use them for transacting because they can hold so much more so yeah let's me all right so uh my answer is high level it's a however what is the wallet for D5 the wallet is the user agent this is what represents the user and therefore from security perspective it's the user's

last line of defenses probably only line of defense because uh once you go on chain we know it's the wild west and the protocols can do whatever they could do whatever they like they don't represent the user the auditor presents the user and that's what security that's what the user the use of security should lie whether it's an on-chained wallet with a count of suction or off-chain wallet this is a technical detail but it has to protect the user um maybe if I'm if I may say I think like fundamentally I view I I really relate to what you have said I think I really I I viewed a wallet as the system that essentially allows the user to authorize only those transactions uh

that they want to do and make sure that like you know any transaction gets the proper authorization and if you view it from this perspective then obviously a wallet needs to do Key Management because if keys are compromised authorization is completely broken because whoever possesses the key can do anything they want but even if the keys you know remain safe part of the authorization system is to present the user with the correct UI to be able uh for the user to make the right decision about any transactions they want to make and really encode the user intent uh into the transaction that allows um and kind of another angle of it is once you're dealing moving to say institutional wallet things it's on no longer already the say the authorization or the intent of a single user but rather an organization that can have a

policy multiple users need to express their consent and so on yeah just like to edit it I think like if you go on like semi philosophical level connecting like security and everything so the wallet is what actually enables ownership right and the governorship is the key is is the core value that we bring to blockchain to crypto to web 3 to D5 is the ownership through ownership um by the user of their assets and this is what the wallet enables and from there you take the connectivity from there you take um the key management and the intent and the policy and everything together that comes from and enables this kind of true

ownership of your assets and this is what the like this one makes it like the last time defense that this is what makes it um actual the true ownership of the user that's super interesting we will touch on actually an Institutional wallets differences but now that we're speaking about tenancy security like what developer or wallet developers can actually do for enhancing this uh this this security wallets today and not just on the technical side but also like uh on on a more like uh yeah High Level side on structuring their team because that's super interesting I think like different wallets different strategies so um oh sorry

so when you build a volatile because this is the the ownership because this is the last line of defense for the user you got to have uh everything everyone on the team with security at the top of their mind right um and we're seeing this at Firebox all the time when there is like 10 different 10 different ways to do something to take shortcuts right that would be less secure design that would allow someone to potentially Bridge the system or to bypass any kind of protection that we add and I think when you when you build a secure wallet right if it's not security there's no point of it so you

need to make sure to not abuse this trust that the user gives to you um so like you gotta have people you gotta have uh people on your team that know what they're doing in terms of both cryptography and security it always goes like hand in hand but the security part is usually about uh the right way to engineer something the right processes uh to enforce within the organization within the developing process and the cryptography that comes hand to hand is about you know the right cryptography how do you leverage um how do you connect to the blockchain the right way how do you enforce uh all the promises they give your user as some Professor tight as possible

in the last I don't know 10 15 20 years in cryptography sort of maybe narrowly construed there's been this move towards building Primitives that are misuse resistant so you know people say for example uh you know older elliptic curves uh it's so easy to get things wrong if you do something like ed25519 maybe it's harder to get things wrong part of that is marketing part of it is reality so I think taking that notion of building things that are hard to misuse and easy to use correctly I think that's a really important thing and it's not just a matter of the technical part of it it's also of course the matter of providing Clarity to the user what will this do is this the right thing to do if they're I mean we've already heard if

there are seven ways to do something now I'm confused which is the right one if I do the you know one of them here should I do the same thing should I be consistent is there a reason to use some other option so simplifying I think isn't a very important one and the second one is like really understanding like if I give you an interface that interface really should be robust to even what we can think of as maybe not a malicious user but a user that's do you know going out of their way to you know get to the get to the other side get to the end goal without necessarily thinking so much about oh my God what's going to go wrong right so even that user should be safe um I want to jump in I think for us at volume we have a little bit of a

um I think a different Outlook one of the things we're asking for what we like with what metamask is doing is giving the user information about what accounts are behaving badly and whatever comes to be hitting well um and I think for us you know observing state of you know important accounts uh or important contracts is something that developers today don't have like hey tell me which are all the bad contracts coin gecko does a good job of it when you know in gecko terminal they try to tell you here some of the contract sort of states that you might want to be aware of you know things are meantable things are unsafe I mean we at volume view wallets as outputs and the question is how do we maintain the safety and the Integrity of the output in a world in which you know everybody's trying to get

those outputs or devalue those outputs um so for us the way we're looking at it is hey you know let's look at the metamask way like what about these other accounts can put our wallet our outputs at risk and then how do we pass that information along to the user and the dev and I think that's where we're looking at in terms of uh you know we think we talk about cross stream liquidations uh cross chain stop losses you know we're always saying hey can we go a step further to make wallets even smarter about the Dark Forest in which they operate yeah I think also like the the the transparency that we're trying to push in terms of like hey you're building like kametama snaps today us developer you see exactly how the the snap is interacting with your extension and every transaction it's kind of like you

are aware of what's Happening uh yeah and uh I think like in Utah like Simplicity I think like also standardization is extremely important uh without that I think it's uh and we will touch on that I just want to go back super quickly on the institutional side like what are the challenges today that uh you know like institutional wallets has like compared uh you know like I think like and end user wallets or is there any specific things that we we need to know I don't know how many of you guys are doing like institutional security or versus like a specific but but it's definitely a good topic to touch um I think one interesting challenge we're kind of seeing especially when it comes to D5 for D5 transactions times is often of the essence right if you're

doing a swap maybe you know the conditions may change slippage and so on uh but on the other hand you know institutions obviously don't want to have they want to have like multiple layers of security including say an Institutional some kind of approval process where the manager of the person initiating the transactions might need to approve that and so you you find this balance between uh operational efficiency and security of course the more secure the most secure thing would be to have every transaction have like you know four pair of eyes look at it but in you know and maybe if you're just doing like a you know a rare transactions once in a while it's not it it's worth it right but if you're doing like uh uh D5 transactions things that are much more time sensitive it's really how to find this balance between

operational efficiency and security and I think like the the the right tools for it is for example to give uh institutions to encode different kind of rules and heuristics into an automated engine that would say well depending on certain parameters of the transaction this looks low risk maybe the person can do in and and kind of sign the transaction on their own whereas this looks maybe a bit more risky the amounts are higher the protocol is less secure let's kind of run run this through a more detailed approval process you know I would add that if you compare and you say what's unique for institutional so I would say two things one is governance and the second is connectivity so governance again like

you when you provide a wallet to an organization to an institution so you you realize that the wallet is part of a way bigger system that they that they operate so like they come with their organizational structure they come with their constraints they come with their policies that something existed before they went into crypto some days existed before they went into defy and they need to keep complying to these and the quality you provide um needs to compile to these as well so this is the main challenge sometimes organizations have when they go over and the second one um is the the connectivity so again because this is like the wallet is going to be part of something bigger so you

need basically API for everything and they're gonna connect the water to like many other systems for visibility you to control the actions to verify them to approve them um and it's always like part of a bigger system that's that's lived before usually before crypto even and in the wall it has to to properly connect to that yeah so I think the institutional use case is one of the primary reasons to move away from the AOA model that is traditionally been used for crypto because uh with eoa you have like a one-size-fits-all it's the accounts the account works the same way for everybody whether whether you're in the individual

user or a large corporation so um so as it was already explained here it's um you need them you need a way to encode the corporate the corporate structure the the way decisions are made with the authorizations you need a way to incorporate them into the account so some accounts may be very simple like once for individual user but one but some may have very complex policies based on who you are paying how much you are paying whether you are interacting with someone on a regular basis whether it's payroll or whether it's something extreme maybe you want to have time delays and maybe you have to have time delays because you have a controller that is supposed to inspect the

transactions and say and be able to veto them so all of the things should be encodable in an account and we don't want them in all accounts we want them only we only want the account to be as complex as it needs to be so that's a reason to move away from eoa and to have logic in the account I agree with that um so especially in the case of an Institutional um entity um this is presumably an entity that has some structures assigned precisely to the the task of keeping the wallets secure Etc these are the folks that have the best ability to handle this on their own

um and at the same time they have a greater need to hide that information from the rest of the world I don't want to encode my corporate policies in a public blockchain I don't want to reveal what decision-making procedures I'm using in in public I want all of that to be completely hidden and I don't want anyone to be able to tell is this account something with complex policies is this account something with uh with with simple policies I would much rather have everything appear to be exactly the same an eoa and handle all of the this policy question completely off chain I think this is a much much more difficult thing for end users to do in the case of an end user wallet like okay that's putting too much stress too much on the the end user to be able to you know make

all of these complex decisions for them it makes total sense that you give them a you know some more decision making process on chain they sort of Outsource this to somebody else but but in the case of an institution I think this these are precisely the this is precisely the audience where there is the capability of making these decisions and setting up these policies ahead of time and in a way that doesn't involve using the public blockchain and I think that is just a better uh security posture for an institution so I think it's not uh I think it does not conflict the requirements do not conflict you can have privacy for like you don't have to put your actual corporate policies and the old structure on chain you can have a representation of it as a Mercury or something and that's what the zero

knowledge proofs are used are useful for so the transaction can actually prove that all the conditions are made that all the right people have signed assigned a transaction that it has the proper authorization for this amount for this token or whatever all of this stuff can be incorporated in the form of a pro of a proof and still have the on-chain security model with with respect um I I say this as somebody who has been doing research on zero knowledge proofs for the last 10 years if you have a problem and your solution is to use a zero knowledge proof now you have two problems um you've made the solution you've made the situation worse um like you you've actually like the the difficulty of encoding your uh logic in the correct way of making sure that you're approving

is done correctly you're verifying the fact that you're spending a ton of money on gas to verify each thing like all of these things have actually made your problem worse you may as well have had a much simpler and easier to write piece of software namely the thing that's deciding whether or not to allow a transaction or not and just run that offline if you're able to prove it you already have the expression of the computation stored somewhere offline anyway The Proven needs it in order to generate the proof so now the question is like do I run the proof and then post the proof or do I just check the thing and decide whether or not to allow the uh the group and the key Point here is who is I you just say I check the thing now I probably mean some silver some offline

server and so you have a single point of failure If This Server now if you implement the policy on a server the server is compromised you have no additional line of defense there is no there's no enforcement at the asset level at the the account level so it's uh so now you rely on on a single entity or I mean it could be more than one server but it's still a small number of servers where you encode it so it's a trade-off I agree in some cases this trade it's the right trade-off in others it's not I I it's not I generally prefer to avoid the I generally prefer to avoid the central like a central servers and single point of failure but of course it comes with some complexity for example

in the zero knowledge case so either so either you lose privacy or you add complexity that's a trade-off absolutely agreed I want to jump in here um so that was an excellent exchange I think for us we've had we had an even simpler problem uh we were starting a private credit wallet for a real world asset SMB uh payments and lending very simple uh and everybody was kyc to AML on both side uh and then one day they saw a dusting of some random erc20 and it said Tark what do we do and I'm like I don't know I mean anybody can interact with your public address and send funds from tornado cash or elsewhere and I think one of the problems with our institutions is that like how do you protect us against that how do you make sure that the outputs that are in this

account only the outputs that are important to us and have not been poisoned by other outputs and I think that's a that's the thing that we face and we don't have a good answer I don't know if you guys have thoughts about that so we yes please go ahead so I was going to say that uh for for us uh usually the solution is is you deliver the fact that you live off chain right and you allow the organization to have another layer of say abstraction or cleaning uh so to say on top of that and then not necessarily every transaction everything that happens on chain is also like potentially confusing the user and

then you give them the possibility to to clean that or you know worst case go to customer support and say hey this is like something that I don't want to see I don't want like everyone to see and then you can like modify that right um I wanted to kind of touch on the point uh like the point of debate it was right I think there is a uh um a potential Middle Ground here I think that um for example I don't think that the entire organizational policy I agree with Riyadh like that making the entire organizational policy like who's who's manager what's transaction needs to promote I don't think that it much makes it makes sense and it just adds complexity to the launching component but I think that um it still doesn't I mean it it could still we can still do

use account obstruction not use EOS for example you could have the engine com component for example require just some kind of a quorum of uh Quorum of signatures and then one or because fundamentally from the organization's point of view there is like a central centralized policy one one source that you want to enforce and then it's only um and so this would this could encode for example like the inter-organization instructor now of course you could say you don't want the single server in the organization to be a single point of failure to volume but then what you could do is you can have replicate that server and just require multiple signatures from from all of them without still requiring to to actually you know encode the full organizational structure on chain so I think this kind of and I think then the component that you end up

on chain with is much is much simpler right it doesn't have to do zero knowledge proof for example revealing that you need to maybe have five you know uh you know five different signatures to approve a transaction that doesn't reveal much about your organizational policy and still it allows you to enforce every complex organizational policy at each of five points which could be different five servers within the organization and I think that you kind of avoid a lot of the complexity uh and you still you still maybe you know uh can end up with I think overall with a simpler design so yeah in other words what we're talking about is separating authentication authorization which is again one of the weaknesses in eoa where authentication and authorization are the same thing and in a in the traditional security World

these are all very very different things so the authentication can be in a server and you can have multiple server for different departments for different so and these they do the authentication but the authorization the what you are allowed to do once you collect these signatures from this server and that server this can be enforced on chains so now at least you have some so at least there you have some enforcement and um so yeah I think it's a what you describe is basically the separation of authorization authentication yeah I I think that actually like the the even the authorization that could be enforced and changed could be a like it I view it as the only thing that you might want to enforce there is just kind of to avoid avoiding any single policy server uh

being a a single point of first you you can essentially you know it would only kind of collect a a bunch of signatures and the authorization of you know end users could still be done off chain at each of those uh you know replicas let's say of the policy server yeah in the context of of safe um we're actually offering to do that on chain um with the use of modules and guards so you can leverage other contracts to verify that a particular policy has been followed um in the context of what you describe right about having non-kyc AML tokens being sent to an address which I think is a very interesting example I actually

do think that by running a guard you can prevent incoming tokens that are not whitelisted in the contract to actually enter the the smart contract so you can do that and you can also work on granular Access Control policies to allow those roles to uh to live on chain however I think it's a very interesting uh discussion the two of you had I think it's all a big question of opportunity costs for those organizations to actually do the work of setting up those policies and migrating these policies on chain and there has to be a clearer benefit I think than just having that

moved on Chain versus managed by apis and in their own Enterprise setups so I think there's a lot of opportunities to look into how so that that transition and those interfaces can best talk to each other um and uh and I think yeah here like you have said the the distinction between Authentication and identity in your wallet right like I think for me this um like the the contract allows for um I guess defining a wider interface for these two worlds to to talk to each other uh rather than than MPC then not MPA EOS yeah yeah I agree and I think like you know eventually

eventually um I think like different organizations have different view of like what's important for them right some would say I have to have a one-to-one representation on chain and if my wallet on chain has these uh they already let's say say um tokens some in a bad situation because this is what like my Auditors are looking at and some would say no I have like my own database off chain and this is what's important and this is what the Auditors are checking and this is what I need to be airtight and like right on with compliance right so it's like different organization will require different solutions I think if you if you zoom in on the security perspective and you say like okay there's like

authorization versus authentication so you could have this situation where you deployed like multiple policy servers um so to speak at the end of the day you gotta make sure that they are secure right they can you cannot we always try to you know edit add more and more security mechanisms which is good um but if it's very hard to create a system that if all the components that hold uh cryptographic secrets are getting compromised so the system is still intact right if someone owns all the five different policy servers so the wallet is owned right it's like and maybe it's not nice to say this way but

like that's all the security that you have if they own everything so they own the wallet um and and there's like a limit to what you can have if you move everything on chain you might just add too much uh complexity and not uh to learn to add too much value so like you need to find again for the right organization the right deployment model that has like realistic and uh pragmatic security approach two small notes Here one um I think in this case of moving things on chain there is what you say makes total sense of course if all my policy servers are on uh life is bad on the other hand um if I put all of my policies on chain I

now okay the devil's a little bit in the details or forget about all my policies that's that's a red herring let's say I put some policies on Jane and I'm enforcing them on chain and this is my last line of defense right all of my servers get owned and now there's this last line of defense saying no no no no life is okay um now there's a little bit of a question do I will I live with those policies for the rest of my life or will I add some kind of governance procedure that can change those policies which now reintroduces this idea that now something right such as a time delay precisely so this is the this is the kind of thing where the devil is very very much in the details and I think that this ties to the other thing that I

wanted to say which is it's very much dependent on the structure of the organization that's trying to do this and on the structure in general of like what kinds of transactions do I want to see and what do I want to allow and not allow so to some extent a lot of these questions are very difficult to answer in general because for certain applications there will be really nice uh answers that look like mostly on chain for other applications or other organizations the answers will look most more like things should live off chain so I I think maybe this is a cop-out but one answer is there's no one answer uh I think but time look time lock is as close as possible to uh to having this answer because regardless I mean you can have often off-chain policies for deciding whether the change is

authorized or not when someone changes their policy so if the policy is enforced on chain but you always have I don't know like one week of one week of delay where the organization can sign a sign a transaction to cancel the change then now you can you can Implement any you can Implement any logic you like in order to inspect it and to prevent it and authorized changes so it's probably as close as it gets to having something general but and the other point I wanted to make is that uh it's a slightly technical Point regarding regarding getting dusted with tokens that you not want such as tokens from a from tornado cache since we're talking about ELC 20 tokens rather than native if then technically technically I don't see a

way you could prevent it because the changes are not in your account the changes are you some balance in some list of balances in somebody else's contract so if if I send you some if I send you some tokens some you'll see 20 token for a tornado cash you have no way to say I do not accept it you can get rid of it you can burn it even even that can be made quite hard but uh it's a but you have no way to prevent the you know not to accept it and this is something that I wouldn't I wouldn't want to be the one who has to explain this to the corporate lawyers like why did you accept these tokens because I had no choice and of course given that you know regulatory now is looking at transaction analysis in order to determine whether

or not people have complied with you know particular law at the transaction level um you know we as security have to explain well you know there is a possible you know I mean there's some exposure and that's that's for us a tough conversation yeah yeah I think this is it's like a never-ending race right like uh you could like as a corporate create like a garbage account which your smart wallet when when it sees uh those uh tornado cash tokens or something like that it transfers automatically to like the trash can and then nothing moves out of there and like you know on the organizational level that's like this is okay and it's a cool fact token you can't touch that I mean otherwise your

yeah I mean but you gotta choose right to your point I agree yeah I mean that's like the only thing you can do yeah I mean once once outputs now become essentially personal non-grata or they are limited by laws that say that you cannot interact with them um I mean they become weapons right and so we are concerned for our clients and and we just don't have easy answers today but but hopefully we will in the future but yeah it's a big deal for us yeah I mean like you cannot but again like you gotta choose if you live like fully on chain or you're hybrid right if you're a hybrid it's not it's it's like a challenge but it's not like a an unsolvable issue because it can uh quote

unquote just clean this on like the database at the auditory see and everyone agrees that this is how the system behaves if you're fully on chain then like eventually you got to choose which solution actually works for you right I think that like it kind of ties back to the question that was earlier about you know how what's the right principles to build a secure wallet and I think one of the key things you need to do is you need to learn to say no what I mean is that um things that are like I feel like the guiding principle is that things that don't require touching the private key that don't require like controlling the authorizations those can be left kind of definitely outside of the core secure component of a wallet and maybe even like in a third-party system some kind of

integration just to keep the you know keep yourself focused on security keep the system and the architecture clean so I think even uh kind of aspects such as you know what do you do with different types of tokens you really got to ask yourself does do those decisions require the decision on behalf of the wallet or is this some kind of you know maybe treasury management system or something like kind of like logic that can be held externally and I think this is important both like you know from a company building point of view to keep yourself focused but also from a security Point of View kind of to a voting bloat uh in your system architecture uh bloating in you know in the in the architecture and that kind of uh keeping the attack surface as minimal as possible so following on this discussion what are

the third party functionality that you think a wallet should leave to the community or third-party companies this is so spicy this panel that I just skipped all the questions I had before and just following the flow easy life for the moderator um I think I think I think like you know my personal opinion in that is that like the the clear yes things can things that fall in scope are definitely as I said things that are required touching the private key right that's you know you're never gonna give like uh free access to the private key to any external system you're never never gonna do that things regarding to authorization um I think are also very important um and authorization has a lot to do with UI so you cannot just say I'm gonna

build a wallet and like you know leave to UI to somewhere else because because building a secure eye that reflects the the actual you know that can capture correctly the intent of each transaction each action is super important so building secure UI and you see it even like outside of crypto wallets right when you're doing a transaction with your Apple pay there's always going to be some kind of UI component but that the iPhone's going to show you which allows you to review what you're approving so I think that's definitely Falls in scope um and there's also a question of you know of timing right things that are important for them to happen at the time of transaction also in scope for the wallet if you view like auxiliary system you know Frank for instance I think that um even if we think about things like

monitoring we've had this previous panel of monitoring I think there's definitely great synergies between the two but maybe I wouldn't view it as core to a wallet because you know you just need the public key you just need the address uh and you can have an integration for response for mitigation but I would still view it as like complementary systems that can work together but but are still separate so I want to away and go first off yeah so the short answer is it depends on the company I think but I had given this answer so um I agree it starts with like the core of security private Keys uh transaction control right without this you have like nothing and then you build and I think like the the right mindset is always so

like to enable the customers to like do whatever they uh they want and choose to do in a secure manner right with like API and then like when like on your on your own you you extend that for like more core functionality over time um I think that everything that has to uh Clarity which is like for me the essence of ownership right if you do not understand what you're actually doing so you do not necessarily own it right um if just like sitting at yours and you do not understand the request um so it's not enough so it's expanding on that um there are things that you definitely should not be doing yourself right um if you talk about Disaster Recovery

processes for backup and recovery of private keys so it's like by definition should never sit with or just with the wallet provider because otherwise it's not really a disaster recovery right you need to give your users and I think this is especially true with self-custody Solutions So You Gotta Give the users a way to continue operating even if the company ceases to exist from there just like sorry just like from the the advanced security side of things talking about monitoring talk about the advanced tools um it's really it really depends just on the segment of the market you work with

right I think over time we'd see more of these capabilities shift into core wallet offerings right I think like simulation is like a good uh example for that but over time we'd see more and more of these shifting into wallet providers as like default functionality with like the more advanced coming from like third-party vendors and and over time adopted so I think there's kind of two this is I love this answer so there's kind of two P two ways to answer the question generally I think one way is from a technical perspective what pieces live inside of the trust boundary and one what pieces live outside of the trust

boundary of the wallet and I think what Dima said is absolutely correct like we can always ask ourselves does this need to touch the the private key is this something that's interacting with that's standing between the user and the private key right because if I can't have trusted input my life is bad if I can touch the secret key life is also bad okay um but then there's a separate question which is what do you present especially in the case of now forget institutional in the case of an end user wallet what do you present to the end user because anything that seems like an add-on anything that seems optional even if you think it's really important probably 80 of your users will say too complicated I don't want to worry about it right and so you this is another one of these examples of make sure that it's

something that's hard to get wrong like so you the the the sort of the pressure from the other direction to integrate things is precisely that if you make something optional and if it's something that's really important and even if you say in your documentation in really big letters please don't leave this out somebody's definitely going to leave it out because it's just too much trouble and who cares um and so that's the kind of thing where you now you have to make a decision like okay this is important I don't want it touching the private key of course but I want to present a unified interface or a unified abstraction to the to the user such that they're not going to reach in and you know grab the engine in the wrong spot right yeah I think this point is particularly interesting also in the

context of account abstraction how to bring it um because as we strive for better user experience in the context of say for instance you know users typically set up multiple keys and currently there's a trend for people to you know deploy their accounts using MPC using a social login for instance that's already you know one trust party involved right that separates the the connection between the user and their actual contracts and so we just like you talked about optionality right we need to think about ways we can make sure that they they they can connect to their accounts in in

a setup that actually guarantees that they have full self-custody while minimizing trust but still trying to optimize for a user experience that competes with well authorization and authentication of web tool Based Services so here right now is a lot of efforts from different projects to look into this um and yeah I think it's a it's a challenge that's very familiar to me okay so I'll say that um all the companies here are amazing and um I I we take the position it's a business decision we have to compete with fire blocks we are competing with kenosis uh we're competing with metamask

and they're the best in class so we are always looking to say what other features that maybe we can provide that differentiates us from the other security offerings so we can say please take a second look give us a chance right so we see it as acutely competitive that for example currently we are monitoring other accounts that you interact with to look for you know nefarious Behavior we have you know we call cross chain liquidations these are things that we tell our customers hey you know you get something different from us and I think that's important and um maybe the only way we'll survive because if we say A you know we'll just leave it to the third you know third party um something that customers say they want that they're not getting from other

providers then we may lose the business and and the opportunity to grow so I think uh hey there there's just so much out there um to do on it and I feel that we shouldn't close it off if it's a good business decision and if your customers need it but um if the customers don't want it you know hey leave it to community so I think I think I will take the community side here it's because every pretty much every example that came up here that came up in the discussion is something that is part of the TCB is part of the trust base I can I can show at least one example that I've seen in some project where they chose to edit as a model so and everyone is now talking in a in the current obstruction space

about modular accounts so uh now take a say for example so they so they support modules and they support models it's a multi-sig but with the model you can add functionality such as social recovery and social recovery you could say that it is it's as good as touching the key because it can it can add a signer so you can add a signer but it doesn't have to be implemented by safe the company it can be implemented by the community and then users get to pick you get to opt in so it doesn't affect you unless you opt in and you can audit it and decide yeah I want to add this functionality even though it touches the key so it's definitely it becomes part of the trust space and pretty much like any any example that we discussed here is

something that could be done that could be done with the module there are even external things that are done off chain for example the the issue of understanding of an informing the user what's going to happen during the transaction so it can be done by the water provider and some other providers do it on the other hand there are also some great companies doing that are focused on simulation and trying to understand it to prevent red pills and to end so there are vendors that do it as part of the wallet there are also vendors that do this as a separate service and maybe a wallet that doesn't have this will want to work with this as an external model so everything could be a could be modular and the way I'm the way I'm looking at I'm looking at the

modular account is uh since I think the analogy of like iOS came in so it came I came up here so yeah I see it as I see it as an operating system the account is the user's operating system on chain and the account itself is essentially the kernel so you cannot mess with the kernel you cannot make changes there but it has system calls it has a and they enforce certain permissions now each of these modules is an app that is an app and this app requests certain permissions that you can choose to give it or not to give it or not to install this app at all once you install it and you give it permission let's say you install social recovery you say I'm I'm allowing this model to change the to to add an owner to device that's fine you

gave it a permission but maybe you're installing another thing that does spending limits the the spending limit and you're not going to give this permission the only permission you give it is is to prevent a transaction to see what it doesn't prevent it so it's an operating system well hold on a second are you saying that therefore it's a modular by mandate or you're saying it's modular by choice no it's modular I mean if you choose to install a modular account that is built this way for example there is a ELC 6900 that that developers are now working on so if you choose to use such modular account then it's modular by Design you have no way to use it other than by

installing modules and maybe the models come from the same entity from the same order developer but maybe some others come from elsewhere let's say you have a you want to play a game so when you're using session keys for the game so the browser will be able to transact without popping up anything on your on your device so but but this module is only authorized so this model is authorized to uh to send transactions from your wallet but only to one specific contract so you can install this as a model this doesn't have to be written it will not be written by the wallet developer because the order developer doesn't know about it so instead the game developer is going to build this module and it will not ask for permissions that it shouldn't so the only permission it asks for is to transact with that particular

contract you have I think I completely relate to the mother pen just maybe a small observation I think in some of the examples maybe the social recovery like the analogy in the kernel and maybe some of the models will be like a kernel module rather than application and then you need to be careful I hope not I I don't think the the equivalent here would be delegate call and I think the op code this the delegate call opco just shouldn't be in your in your code base don't delegate it don't delegate your kernel okay I want to add one one more thing um back to directory point and I really appreciate like the honest answer but we gotta compete right eventually it's like it's it's a business um and it's a really hard question what

should be left out I think like one one thing that's like very clear to me is if you cannot fully trust that component if you cannot fully trust the com the technology or the input so it should not be part of the of the wallet because this trust between the user and their wallets is like the the highest level possible Right like you trust this technology you trust this vendor with your private keys with the core for your operations and if you mislead right if you put something that you as a vendor you do not fully trust that's like I think that's an issue yeah I think it's also like part of like the standardization side if we need to build like modularity system we need to

have like a fully standardization I mean I'm just looking at the snaps example you know all the vision about like you know adding and giving this power to the community building whatever feature they want to enhance in in the wallet like yes would be cool but think about in the future that snaps can be added to any wallets out there but without this standardization like people will build more and more wallets with the same functionalities and I think this is not where the end user Community want to see where the wallet ecosystem is right um I don't know we have like 10 minutes or any question around like you know wallet security or or anything related to what we discussed and great spicy debate here today please please your hands erase your

hands if you have any questions yeah only spicy questions exactly exactly no snarks question or NPC MPC questions yeah it's interesting okay cool yeah maybe just following up on the the module uh topic that you brought I think it's a very interesting question right the modularity of accounts because right now I guess also your point around standardization I guess as an industry what we're really trying to do is trying to figure out how we can um reduce the security implications of this modularity because naturally uh currently you know adding modules completely overwrites um uh some of the rules that you specify in your initial contracts at least in

the context of save and so there's a lot of like interesting interesting initiatives and teams looking into how we can build Registries for modules that could come and meet certain security standards um and you know I'd say if we're also trying to think a lot about this and how to best operate that and work with you know Security Experts to try and see what can be a process that actually make a particular major trustworthy and yeah hence enabling modularity of accounts again this comes back to this question of like who's the audience right because in the all of us sitting up here are you know we're like we're kind of hackers

right it's like yeah I want to run Linux I want to install some system some kernel modules and like uh fine even on my like mac I turn off the system Integrity protection I actually don't I promise um so like great but I'm pretty sure my mother never once in her life installed a kernel module and like if she were going to I'd be like maybe maybe not and and like this like that's a joke okay fine but like the the problem is like now we have let's say the next billion users uh on the Chain I don't know 90 of them are people who will also never have installed a kernel module and yet there will be scammers telling them please install this kernel module right so then now we end up in this interesting situation where I I there's there's a debate here for a

reason right like iOS pretty locked down I don't know if it's actually better security than Android it depends on who you ask but I mean if you look on the Android App Store there are a heck of a lot of scams right so this is the kind of thing that we will start to see in the future as soon as we have modular wallets we're going to have scam modules and we're going to have people like telling me to install a scam so that they can steal my stuff and so there is a great power here and so there's also unfortunately a great danger here and this is going to be just one of these continuing hard problems how much uh Power do I give the end user versus how much education do they need in order to actually use that power in a reasonable

way and not just own themselves yeah so uh that so I don't think I don't think anyone should install kernel models in this sense that's what I meant with the delegate call delegate call is essentially okay it's like like giving someone access to the entire memory space of your kernel you don't want to do that like ever there's no uh there's no legitimate reason for it anymore you could Implement anything as an external module and um and then since there are since it uses permission model that is essentially like Androids or iOS where each model declares which uh declares what it needs and you could even say that you want to approve it each time dynamically like append the append a permission to your call data so let's

say let's say a scam module tells you that it's going to interact with the game but actually it tries to add an owner to your account so in that case I would expect the account to check for it and to say okay so this is a this is going to add this is going to add another signer so I'm going to revert it with a message that says if the user really really intended to do it then append this string to the call data say I know this transaction is going to add an owner so you have ways to inform to inform the user the models are not the models are not kernel modules these are these are it's like apps with the with the very specific permissions and you can have no permissions by default and have the user approve each operation

absolutely and and then the the sort of the bad side of that is you know the what was it the windows uh 2000 whatever remember the Windows XP like do you want to go into system mode yes of course and everyone just clicks it without reading the the box from then on right so so then this is a UI problem right like now we have to make sure we're not exhausting the user's ability to make a decision because if you ask them seven times on the seventh time they don't care anymore they just push yes yes and there's no perfect answer I think I've been following both the uh I mean I come from a mobile security before blockchain so with iOS and with Android we've seen different models and even inside each of them the model shifted like uh when I was talking to

the Android team in the early days I suggested I think Dynamic permissions and let the user let the user decide when when you try to access the camera they said no way this is not this ux users will never accept it and now this is the default so like it took them nine years nine years to get to that point so I think we'll have to experiment and see what works best with the users and hopefully with as little disasters as possible this is also um this is also you know user education right like to your point the let this app access my camera so it makes sense in a world where way more people are aware of what can the camera access do

right if you just start it on a very early days that no that many people had smartphones and not that many people um took you know selfie every second um so it's not like the the concept of what access to a microphone or access to a camera is for the end user has shifted right I think like today many more people are aware that like letting an app track you means that like someone knows exactly where you live where we work with your friends Etc and if they you give access to your camera and maybe you look at the cat at the at the phone just after the shower so it can snap a picture right and that's undesirable

right so it goes back to the wallets position within the market and with the users and I'm going back to like your first point about what's been the last line of defense for the users it's actually been also the first line that the user is interacting with the external world and this is an extreme and amazing opportunity for wallet providers to actually educate and let the users know hey these are the consequences this is what's going to happen and this is good and this is bad obviously we should not do the Vista UAC thing that's like are you sure you want to do this as an admin and yeah everything requires an admin permission

so we and I think also Microsoft now on Windows 11 saw this right and they are like way more comfortable with making people admin less so it takes a lot of time to change consumer Behavior but this is like all the wallets are situated in a in the right position to educate the users and move the market and let everyone make like more um like wiser and smarter decisions yeah and this is the so this is the role of the wallet like the off-change side of the account the wallet because there's no there's no one size fit all here for some users you want to allow installing certain apps okay installing certain models and maybe for others maybe when

you install a wallet on your on your mother's phone you want to disable it completely and say no if you if you want to install some app talk to me talk to me I want to have a look at it so in that case maybe you want to have a different settings you want to say that in that her wallet should not even offer her to install apps whereas maybe on your on your device you want it to just ask you but to describe very clear very clearly what the permissions May mean so it's a it's a ux problem but it's not it's not identical for everyone so what else we need to have different modes for different kinds of users yeah 100 I think we have two minutes but I want to say education is key and also

having customized uh wallets for different Target Persona I think also is the next next wave cool so any any less key takeaways we spoke about like barriers we spoke about like you know how wallets what's the role of the wallets that we need to solve this like what are other like misconception about this our spicy debate here that we didn't spoke about and how wallets can solve this literally like one phrase of Parlier one phrase of like a solution I know would be difficult but let's uh let's let's do that for for finishing up this panel and don't be afraid to take the mic I can uh I can try and do it I think it's hard um taking you know from a different perspective comparing device security

Summit the first one last year to this one last year was like 90 maybe 95 of the conversations were around auditing security auditing for D5 protocols which is insanely important right this year we see way more conversations about products wallets monitoring tools all these things so amazing work guys and also this shows how the ecosystem has shifted right and we talk more about building more about servicing our customers and wallets again I believe maybe I'm biased that they see that the core of these things of the operations

and we have an opportunity to drive more collaboration more standards more information sharing more security education for everyone I'll jump in and say that um you know a week ago the multi-chain um you know sort of epoch was a time I think the wallets should have I wanted to see more vocalization from wallets once there was risk in the market wallets to say to people if you're using Phantom make a change do something don't just sit there and for us in our company we regret not being more vocal about it we just stared in like you know disbelief as we saw this thing unfold and I think there's more of a place for wallets to be a voice that part of that education which says we see

things happening please be safe metamask does a great job when it comes to suspicious contracts and accounts I think we need to be louder there I think we'll probably start to see a little bit of a culture shift um as as more folks who are kind of really wanting a web to experience move into web3 that will be fundamentally good for web3 in my opinion but it will also bring with it a bit of a change I think many of us have a contrarian streak have a very much like you know it's my wallet I want to do what I want and that's great for us but it will result in probably Badness happening to the vast majority of users that come on in the next 10 years so to some extent we really do have to be willing to make hard decisions and to as you said make

statements like please don't do this please do this instead it you know there's a bit of that resistance to centralized control but at the same time like if we don't give people some amount of guardrail if we don't give them a little bit of education and the opportunity to do the right thing and maybe make it hard to do the wrong thing I I think we will all be worse off for it cool awesome times it up and uh yeah I think uh we are we are literally between like the snacks and the drinks so yeah big round of applause for our panelists and thanks everybody [Applause]