Safe: Securing $100 Billion of Crypto Assets - Lucas Schor. Ep. 544

Transcript

entire ecosystem at that point all the projects doing their own iOS during the 2017 phase uh started adopting this multi signature wallet as well in the long run these smart accounts will be the solution and there's no way around smart accounts in order to get to the user experience while still retaining like security uh that is needed to to on board like a billion people to to web free I would say when it comes to cross train uh smart accounts in the short term will bring new challenge es in in the long run will actually solve CR train in a way that they can uh make it irrelevant in what networks you interact with what DS but this can be abstracted way welcome to epicenter the show which

talks about the technology projects and people driving decentralization and the blockchain revolution I'm Sebastian guu and today I'm all by myself I'm chatting with Lucas sha who's the co-founder at safe safe is of course the leading uh smart account multi- provider in the evm ecosystem they're securing over hundred billion in assets and are absolutely crushing it when it comes to securing assets we use safe at interoute ventures and I'm sure lots of you out there are also using safe um they were spun out of nosis a couple years ago and I'm going to be talking with Lucas today about the technology behind safe but also the strategy moving forward and what does

the future of safe look like before we talk to Lucas here here's a quick word from our sponsors this episode is brought to you by nosis nosis builds decentralized infrastructure for the ethereum ecosystem with a rich history dating back to 2015 and products like safe cow swap or nosis chain nosis combines needs-driven development with deep technical expertise this year marks the launch of gsis pay the world's first decentralized payment network with theosis card you can spend self- custody crypto at any Visa accepting Merchant around the world if you're an individual looking to live more onchain or a business looking to wh

label the stack visit nois pay.com there are lots of ways you can join the nosis journey drop in the nosis Dow governance form become a nosis validator with a single gno token and low cost Hardware or deploy your product on the evm compatible and highly decentralized chain get started today at nosis doio car one is one of the biggest node operators globally and help you stake your tokens on 45 plus networks like ethereum Cosmos celesia and dydx more than 100,000 delegators stake with chus one including institutions like bitgo and Ledger staking with chus

one not only gets you the highest years but also the most robust security practice and infrastructure that are usually exclusive for institutions you can stake directly to chus one's public note from your wallet set up a white label note or use the recently launched product Opus to stake up to 8,000 e in a single transaction you can even offer high yield staking to your own customers using their API your assets always remain in your custody so you can have complete Peace of Mind start sing today at chorus. one hey Lucas thanks for joining us today thanks for having me Sebastian so before we get started um

how did you become part of the safe team were you previously at nosis or uh yeah because I think you're like one of the co-founders of safe what's the story there yeah that's right um so safe is a spin-off from from nosis uh I joined back in 2019 uh as a product manager uh responsible for the at that point nosis safe project with nosis actually I was applying half a year before that to nosis in in the marketing department I got rejected right away uh that's just a a fun fact on the side uh then half a year later something that was more relevant to my my background the product manager role opened up and I was uh jumping on that and that was luckily successful so I joined when the nosis

safe project was quite its early stages yeah then took over uh together with Richard and Tobias my co-founders the um the project responsibilities and over time then the the project grew uh and it outgrew to some extent noes as in the kind of the team U size scw and the the the focus kind of expanded beyond what it's originally meant to be and it be became its own ecosystem and that's when we decided together with the nosis team that it's better off to uh continue the project outside yeah maybe a little bit of the history of this project came to begin with um so nosis like back in 2016 was was started to create prediction

markets so that's a a way to financially incentivize uh participants to share their knowledge in order to yeah expose that knowledge to to the public and that's meant to be as a as a primitive on the eum blockchain and uh nois went ahead and did an Ico in order to fund that project and it happened the Ico was quite successful uh nois had to custody a lot of the uh proceedings from from that IO and back then the entire self- custody infrastructure was quite early on uh meaning that they had to create uh their own solution so Stefan bi who's the co-founder of nosis wrote himself a

multi signature contract which is a way to uh share the responsibility of a self custody setup with other people by multiple keys and that was uh used for for the Ico uh funding and was open sourced and then it happened that all have the entire ecosystem at that point all the projects doing their own iOS doing the 2017 phase uh started adopting this multi signature wallet as well um and that's how a team was formed as suly had many projects that were uh using this solution and there were feature requests coming in and uh people wanted to have the project maintained and so the the project formed

and became its own uh Team within nosis and that's roughly when when I join yeah cool I mean I think it Bears reminding also that like you know back then like you said there were no good solutions for doing multi-stakeholder asset uh custody Bitcoin had an onchain in protocol solution still has and you know in Bitcoin you can create an onchain multisig and you know this is something that a lot of people like including myself have used you know with epicenter we've used this also quite a bit in the early days when we were a a Bitcoin onlyi company um but yeah that even even then like it's quite cumbersome to set up the keys and and everything but

ethereum didn't have an on protocol solution do you know why that is like why ethereum uh didn't go down the same path as Bitcoin and build build an in protocol uh way to do multi-stakeholder asset custody yeah I mean it's always the question what should be really enshrined as part of the protocol and what should be then solved the layer above on the smart contract level um it actually happened that ethereum originally wanted to have Smart accounts um so accounts that base their logic on Smart contracts uh kind of have have this natively within etherium uh it was then uh yeah it turned out that this is quite complex

uh to do and the team at the foundation was a bit of in a in a in a Time Rush to to launch main net uh so the this scop it last minute and we since then had our wallet infrastructure on Theo mostly based on EAS so externally owned accounts these are the the accounts everyone knows that are controlled by single private key uh usually derived from from a seat phrase 124 24 word secret phrase and uh that's where the the wild infrastructure was was built upon I personally think that it's a better Pathway to solve as much as possible on on the smart contract level there in terms of like the logic of of

an account because if you look at what you mentioned the the Bitcoin multis implementation it uh it it works quite nicely for certain use cases but it's quite limited because you have all the logic enshrined in the in the Bitcoin protocol and uh for example that means that certain use cases such as rotating Keys uh is not possible with the Bitcoin multisig so you once can set up your multi signature wallet you might have a certain threshold of uh signatures required to make transactions uh but then if you lose access to to one of the keys or it gets compromised you actually have to move your funds to completely new Bitcoin multisig uh and you cannot

uh just rotate one key and and continue with with the same wallet these things are are solved by uh just leaving the logic up to the smart contract level and allowing different implementations to take different optimizations uh and different uh yeah technical assumptions and this creates much more flexibility then and over time we will probably see certain standards or certain uh best practices emerge and potentially at some point these can be drained again in the eum protocol uh once once we see that these are actually uh must haves and have the standardization value is higher than the flexibility of having different implementations yeah I think the inren

question is one that needs a lot of of course reflection and we need to be careful what we enshrine into the protocol or not but yeah taking a step back from that let's maybe dive into smart accounts or at least the way uh smart accounts are conceived of in the ethereum space I think most of the uh researches around this ERC 4337 yeah give us an overview of what is ERC 4337 and how it aims to implement smart accounts on evm trains yeah there's actually quite some misconception still on what ERC 4537 is

so some people think that ERC 457 is smart accounts and all the logic all the possibilities that are uh enabled through this standard is is due to the to the ERC 457 standard While most of the features such as recovery or like session keys and so on are actually the the responsibilities of the smart accounts so smart accounts have existed since since years um yeah safe has been around since 56 years and uh lot of what we're now talking when we talk about the potential of 457 has been possible before with one exception which is actually processing smart account transactions in a trustless way that's a

big uh problem that's solved by ERC 4337 so as I mentioned the ethereum protocol like it it has two types of accounts is eoa externally owned account and smart contracts which can then used to make smart accounts and uh yet a transaction actually in order to be proess cess needs to originate from an EA and um that's that's a challenge because yeah certain use cases of smarton you actually might not even want to have an EA involved if you use uh certain like new signature schemes pass keys or so on uh where where there's no EA part of the transaction life cycle yeah but uh so

far how it worked is that you had to fulfill the transaction verification required ments be it in a multi case that you collect the different signatures from the participants uh but then still you need to have an EA involved in in the transaction uh in order to actually process that transaction on the eum blockchain so so usually how that worked is that you had like everyone signed the transaction and then the last person uh that was signing was was the poor person that actually had to pay for the transaction fee from his uh youa account and yeah that's now now coming to ERC 457 so Ju Just one one just to kind of put a pin in that essentially what you're saying here is

that a a smart account like safe can can have multiple types of signers verifying and executing sort of signing for the for the transaction but at the end of the day at the end of the transaction an eoa needs to execute that transaction on chain and pay the gas fee so like we encounter this basically every time we do a save transaction you know all of us sign and then we have like one account that has just like a bunch of eth on it and it's just used to pay for gas and you know that account basically executes the transaction and sends it onchain and that has to be an EO account it can't be some other sort of signer or even another smart account it has to be an onchain account exactly at least uh so

far and it it doesn't even need to be an EA that the user controls so even in the past there were uh relayer systems uh like a bony or gelato or private three layers that are just EAS that are funded that then are instructed that once there's a smart account transaction that's like fully verified and uh fully signed that then this relayer system would would take with the EA and and pay for the gas fees and put on chain and uh that's where then ERC 457 comes in where we say that uh the idea should be that we have sort of like a separate M Pool for these smarton transactions uh where we can just add the smart account

transactions that are fully signed uh fully valid and then we have a decentralized mechanism how these transactions are then put on chain there's actually still an EA involved so that's the EA that bundler in the in in the standard controls the bundlers are just of collecting all the different smart account transactions and are then uh bundling them together and put them on chain uh by paying for the gas fees and using the the EA and they can then get uh repaid for this gas fee expenses by pay Master which is another component of this standard uh which then allows that the the bundler isn't sitting on the cost but actually get out Net Zero or ideally even with with some profit uh

and exactly the the standard now uh allows that there's no C centralized relayer involved anymore users don't need to fund their own EAS but they just trust that there's this decentralized networks of bundlers that they can just throw in the transaction and it gets executed in a trustless way okay so to to recap here so ERC 4337 uses existing smart account or leverages existing smart account infrastructure but uh offsets the execution or or sends the responsibility execution to this bundler network that bundler network does the onchain execution of any smart account

transaction that is ERC 4337 compatible and that therefore alleviates the initiators of that transaction to have to well a execute it and B pay for for the onchain gas costs does ERC 4337 by bundling these transactions I suppose it also implies gas optimization because you're bundling all these transactions together and possibly saving on gas by doing so uh there is some component of of gas savings um in the end the ERC 457 architecture adds some gas overhead itself but assuming that like there's a lot of adoption of the standard over time the overhead

decreases and even at some points that there should be ways to to even have a better gas efficiency than just using like a smart account natively itself right and just to come back to this uh signing in execution process so when you you know I've encountered this a bunch of times where like we start a transaction and then we we realize maybe the the amount was wrong or there's like some issue with the transaction as we're signing it this happened recently right where like I had a 02 few right on in in my amount and and so then you know you you you have to go through this process of um reverting the transaction and

that's because because you've already signed part of that transaction at any point in the future other signers could sign for the rest of that transaction and actually execute it now when it comes to this bundler network you know a transaction that has been fully signed is basically ready to be executed is there another step then that the signers of that transaction um have to make in order for that transaction to be made say public or does it remain within the hands of the signers and kind of private until an action is taken to reveal it to anyone including this bundler network to then execute it on chain there's

probably two steps to that uh one is that after the partially signed transactions can stay private until it's fully signed and it's sent to the to the bundle Network yet still like others that are participating for example in the multi signature use case have access to this partially signed transaction so they could complete the transaction and send it to the bundler network uh at the later point but once it is uh sent to a bundler then you need to assume that it's out there and they could be executed at any point but this itself is not different than to how EAS work as well if you sign a transaction metamask today if you have a too low of a gas fee and it's just stuck in the men pool like

it can be executed any point which uh you can resolve by sending the transaction again with a higher uh gas fee uh in order to speed up the transaction or by replacing the transaction on the same nons with a different transaction so that what also be the case with smart accounts they also have a nons uh so once a transaction then is executed at the same nons that means that the other partially sign transaction or fully sign transaction is not able to be executed anymore uh and can be disregarded um but up and that point when the nons is still available and the transaction is is out there like it needs to be assumed that it can be executed I guess we've clarified here that USC 4337 is related to uh executing

transactions are is there an eoa that is uh creating a standard for how smart accounts should uh be conceived like uh in terms of the architecture of the start smart account or is that up to Smart account like companies and and service providers to decide as long as they are compatible with ERC 4337 they can do whatever they want on the software side yeah so ERC 457 itself has already some uh requirements to smar conss uh for example that it requires that the smart account transaction is starting from the account itself uh which is relevant if you think about modular smart account so you might have

different execution logic uh for an account and uh have it depending on what type of transaction it would require a different signature scheme or or so on and there the transaction needs to start in the account and then go to the to the module which contains the execution logic uh which yeah there's some details there that just Define how the the account works there's other erc's that uh standardize certain patterns for smart accounts such as proxy patterns uh or now more recently again with modular smart accounts there's uh certain initiatives from the Comm community that say the idea should be that we can create these different modules which you

can imagine to be in a way like apps on a smartphone uh so we shouldn't go to a world where you change your account in order to kind of add a new feature to it be like a session key recovery or something like that but instead it should be like downloading nap on your smartphone and that's enabled through these modular smart accounts which means that you have your base account which has has certain default logic and you expand that with uh modules this can be validation plugins these can be certain safeguards that are added to the account and that then extends the the logic of the account and there there's now

initiatives that say we want to have yeah certain parts of this architecture of this model architecture be the same across different smart account implementations uh why should we do that uh the idea is that you then don't have to create these uh modules for different implementation separately but you can actually assume that they have certain standards that they comply to and the module that they create for smart account a works the same way also with smart account B these are yeah there's actually two standards out there as always um have it's not enough to have one standard you have a second standard and then a third standard to get rid of the other two um and so on uh but there there ERC 6900 uh which was started last

summer by the Alchemy team and you got ERC 7579 which is a collaboration between rhinestone B economy okx and others uh that Define different ways how these modular maricons could look like uh with some different yeah technical assumptions concretely RC 6900 bundles the modular architecture also with a permissioning system so you say you have these different modules and you want to give uh certain permission to these modules as a security function and ERC 7579 is a very minimal standard that really just focuses on the modular architecture of smart accounts and uh leaves the security the permissioning

system uh potentially to Future ERC and just say says we shouldn't over complicate things we should just focus on one thing after the other and uh yeah these standards are in a way competing at this point from the saves pers we actually want the safe smart account to be compatible with any standard uh so that's possible as safe itself has some native modularity uh built in uh so it already has some some ways you can extend the the smarton and then you can just add an adapter in order to be compatible with ERC 6900 or add another adapter to be compatible with 7579 uh which makes it just future proof uh it's still unclear how these

standards evolved they're all still quite early got uh yeah little adoption so far and they might still change over time so our philosophy there is that we want safe smart account really to be as low level as possible so that no matter how these standards evolve you can just add another adapter to to support them and you have an account that lasts forever incredible and so what is safe's design philosophy here I mean cuz you you guys have like safe core which is the the core of the of the safe product and and the smart contract uh logic and do do you think that that this should be kept as at as minimal as possible in terms of features

and all extensions sort of bring into the functionality or are you more like this conservative uh approach to design or do you have more of a a broader approach to design where this core uh could also include other functionality that are currently being fulfilled by the plugins or or modules yeah I mean there's um probably two key philosophies uh for safe one is that safe as the name says is is very much focused on security uh so that's just the defines everything we do at safe in terms of like how we approach uh upgrades to the smart account how we approach yeah how we balance for example

flexibility versus security versus gas efficiency so we always default uh more towards the security side uh and the other one is that we want to be as uh use case agnostic and user group as agnostic as possible uh meaning that the the account itself uh the core safe smart account should be base primitive but then it can expand it depending on on the use cases uh and uh optimize then through its modular architecture to different yeah to different ways to to use the smart Eon and yeah that also means that we very much depend on uh the ecosystem around safe uh so that's something that was was was clear

early on that uh if you really want to bring web free uh towards smart account adoption if we want every account to be a smart account which is our mission like we cannot uh aim to do this ourselves we really rely on Nicos system and the community of Builders uh to to help us with that so what the idea is that the safe smart account becomes this very core of uh of this smart account transition and then we have others that are building the different use cases be different types of wallets be um yeah Asset Management Solutions that then have built around this this core primitive and extend with what what's needed for them is it automations is it

session Keys maybe for a gaming use case uh is it more pass keys if you want to to build a retail wallet and uh that then kind of puts us into a role of uh of building this core protocol and working together with the ecosystem through ecosystem support initiatives uh to to kind of yeah Target these different user groups uh from their perspective so in safe core there's there's there's multiple components we have the smart account which we've talked about uh there's also the SDK that sits on top of it which allows like you said you know wallet developers to utilize the safe infrastructure but we haven't talked about the API which I think is kind of an overlooked aspect of of safe core and the way I understand it I mean one of the rules of the API of

course is to kind of coordinate around the signatures so like when you're signing a a a safe transaction and that transaction then pops up on the wallet of say your co-signer uh or like another signer in the um in the wallet configuration that is happening via an API that I'm not exactly sure how it works so I I don't know what is nosis is or sorry safes the company's uh involvement in running infrastructure it's kind of centralized infrastructure that makes that possible or is there an onchain component there I'd love if you could explain how the API works and who are the the the third parties that it may rely on the smart account really the smart contact Suite is uh the the core of it all but then we provide tooling

for developers that just make him more accessible if you want to build an application using smart accounts if you want to to use a uh to build a wallet uh then things like an SDK or API just make this more accessible make make the transition from EAS easier uh and yeah that we we just always evaluate what's the things that we can provide to the ecosystem in order to make it easier to build on smar conss and right now it's an SDK uh that just allows to have yeah to interact with the smart accounts to uh craft signatures and so on uh and to also work with the ERC 457 relaying Network and the API as you say that's it's essentially an indexer uh the most

part is an indexes so it just indexes all the safe smart account transactions out there and makes them available for developers so you can say uh you can track different uh saves for example there's also an event service to it so you can track if there's any updates to it if transactions are triggered if any incoming assets and and so on in order to display this to the user but it also has a component of the Signature Collection which is especially in a multi signature use case quite critical because you don't want to have every signer in a multi sign onchain at least in most cases you you might want to save on the gas cost of signing onchain and you just sign a signature um sign the transaction offchain but then you need a way to exchange these partially signed

transactions with other participants of the multis and that's done also via the the API so you can just post these partially signed transactions and retrieve them uh from another user uh and that just allows to to exchange these transactions technically it would be possible to exchange these transactions for any other means yeah also onchain signatures of course but also by just downloading a file and sending it to someone else obviously that's not very user friendly but yeah that's why we provide this service it's also an Open Source service so there there are projects that run it themselves uh just as a redundancy uh and we eventually also want to get to a place where there's actually a

decentralized network of of indexers that participate in in retrieving and uh yeah sharing these partially sign transactions uh just because it's it's always better to not rely just on on a centralized service even though like anyone could run the service themselves and so on but the the truth is that uh it probably would take quite some time until some other uh service would would spin up that has a similar performance uh that would then kind step in if if our index would be down or so so have the pathway towards this decentralized index network is is something that we are looking into yeah okay interesting so so currently for all of the safe wallet products I guess safe is running that

infrastructure in a kind of centralized way but as a user you can choose to either run your own infrastructure or if you're a company using safe you can also run that infrastructure yourself or redundancy but but you can also share the signatures on chain correct exactly okay interesting now that might make sense on some networks that have like lower gas cost but on ethereum that might be a bit prohibitive yeah and it also makes sense um as this service is only run for a certain set of of of networks on networks where index is not run you can still sign on chain and it also is an additional redundancy if the service is not available then you could

just with some little extra gas cost you could sign on chain and and uh not be dependent on it okay great this is cool thanks for clearing that up on the yeah on the wallet side I'd like to talk a little bit about the the user experience here and what are some of the challenges that you guys face when building in a wallet that you know supports uh safe core and you know I like to preface this by saying I've had my share of moments using safe where I didn't really know what was happening or where my transaction was in the queue or whether like you know trying to sign a transaction it's not working and I'm getting some weird error message and I've actually talked to Safe uh support

like two or three times when executing transaction and they've always been very helpful and have helped sort clear things up but yeah how do we how do we come to a better user experience around around these things because it's still super cumbersome I mean especially if you're using a ledger and then you sign with metamask and it all feels very cumbersome and I still like I still stress every time I do a multis transaction because there's just all these moving parts that need to work and it it it always feels like a bit of a a lift to to get that transaction signed so yeah what are your thoughts on on user experience generally and how can we

how can we improve all this this actually interesting because there's like two camps here uh some people say like the the safe wallet interface is already quite user friendly and and some still have issues it's probably also to to some extent if you compare where safe W is today compared to where where it is two three years ago I would say there's like a massive Improvement in user experience since then but obviously it's still uh long long way to go also challenge there is that we want to have say for b as user group and use case agnostic uh so we cannot optimize for say someone that's super technical that wants to see like all the information and that always be able to to look under the hood of

everything at at the same time optimize for someone that is less technical that really wants to have everything abstracted away uh so we always try to be somewhere in in in in the middle and then actually work with the ecosystem to provide the the best experiences for the different user groups uh so for example there's an onchain Den which specializes really on Multi signature in in a team use case and having transactions they say that the the interface that allows you to have sign ructions the the fastest and they have like some yeah have some notification system behind it and so on and some some gas abstraction and they do certain optimizations there and then there's others like a nest

wallet which is optimizing more for individuals and and and Retail users that allow allows to abstract a little bit more from the details away and have like a more smooth user experience uh where maybe the cross team collaboration part is less of a focus uh so that's really our strategy that we say sa wet is like a a baseline it should be like a an interface that people can start using in order to get experiences with with smart accounts to to cover uh certain use cases but then as you over time there should really be like a wide ecosystem of of of designated solutions that optimize for uh for different Sol uh yeah user groups no that's cool I I

made a note of these I think I'll probably try them out as well this uh so you said onchain den and Nest wallet yeah I mean with like the the some of the issues I faced were were yeah I think like ordering of of signing and and then you know not able to post a transaction on chain and you know having to update that transaction with a new nons like these kind of of things are very unintuitive I think for most people and even me and you know the error message really doesn't explain much of what you need to do so I think having kind of a inapp resolution mechanism to kind of fix this problem you know without having to reach to support or look you know look for things online and

the other thing is I think there's I find there's like some inconsistencies between the way the wallet the mobile wallet works and the the desktop works uh or the the kind of web version and one thing I've never really understood is with the with the mobile wallet and by the way the mobile wallet's great like I typically do transactions on the mobile wallet I think that that's the best user experience I think for you know for what we do and and we have a bunch of ledgers that we sign with and I love that the mobile wallet supports The Ledger and we can just like pull them out and get together and you know sign things um but there's one thing I don't really understand is like why you need to have a it it seems like you need to have an on device account so like when you

create the save for the first time you need to have like a a seed phrase that you have to store somewhere it's generated on the it's generated in the app and I haven't found a way to be able to sign the transactions with anything else than that on Wallet account I can't execute with the with the Ledger uh which kind of seems a bit backwards to me if we're going to have ledgers to to sign save transactions to then have to have have this less safe kind of hot wallet you know uh on the device so that's that's yeah I don't know maybe I'm doing something wrong here but that's uh always been a little confusing to me yeah are you using Android no iOS iOS um okay uh because technically it

should be possible to execute also with lecher um so the idea about the mobile wallet is that it's it should be just a very smooth way to to call sign transactions and you can add any kind of like wallets to to do so like ler GL to for like mobile wallets by wallet connect and uh yeah I can look into this I think yeah we'll have to talk after but yeah so there's like these kind of minor ux things that I find you know can be can be improved but overall uh you're like I I agree with you that the experience generally is is is pretty good um you know compared to look like 10 years ago Brian and I used to do Bitcoin transactions electron wallet and

we'd have to send the partially signed trans actions over slack and you know it was a huge mess right I mean like this is definitely a huge leg up from having to do this kind of shenanigans which you know for people who have been in the space long enough will will be will be familiar with yeah and I mean that's something in terms of user experience that's very close to my heart because I think in general the web free space like we're staying saying things since years that we're still early and at some point we cannot allow us to to say that anymore because we it's still quite cber some if you want to do full self custody and interact with with Ds and like that's still not that accessible to a wide range of uh of people like in in the world like even just having pretty

much everything default to English like that that's fine for certain parts of the western world but we need to have more localized Solutions but also in general how the uix works of of wallets today uh they needs to be so much more that that we should do uh in next years and that's also why I'm so excited about smart accounts because I think in the long run these smart accounts will be the solution and there's no way around smart accounts in order to get to the user experience while still retaining like security uh that is needed to to onboard like a billion people to to web yeah I think smart accounts are are a huge unlock there and I'm really looking forward to more broad adoption of Pass Key and uh other ways of signing

so you know I'll I'll tell you a little bit about what's happening I you're familiar with this but in the cosmos ecosystem uh osmosis which is the major decks there are doing an onchain smart account now of course the difference here is that they manage the entire chain and they can uh really build things uh on chain and also have certain types of transactions be uh either gas subsidized or gas optimized and so the the idea here is to do a smart account on chain that you can set up using you know oo like a Twitter account or a Google account and then based on the um on the the value of the transactions you're doing or perhaps even the value uh in the on the account itself then you you'll be required to add a second Factor authentication so it could be

like a pass key or or a secondary account sign and you know they're building all of this infrastructure on the Chain which is which is great when you're doing your own chain and you know brings me to another question I wanted to ask you is What's um safe strategy when it comes to building its cross chain presence and by cross chain I don't mean just evm chains which I know you guys are supporting very well but other ecosystems like salana like Cosmos chains like the move ecosystem uh the you know Aptos and sui you know are you guys looking at those ecosystems at all and thinking of ways that safe can support those or is your focus really just the evm and you'll stick to you know what you're great

at I would say when it comes to cross chain uh smart accounts in the short term will bring new challenges in in the long run will actually solve cross chain in a way that it can uh make it irrelevant in what networks you interact with what DS but this can be abstracted away uh through uh through smar cons but yeah in the short term there are challenges one of them is that smar accounts they are they are just very unique per chain so because these are smart contracts they deploy it on a certain network uh they have the logic on that network uh which means that while it's possible to have a similar smart account on a different network

with the same logic potentially even the same address through create two contactual deployment uh they're still very much independent accounts which is a difference towards EAS uh which are by Design because it's kind of standardized especially in the evbm ecosystem like you have a seat phrase and it's immediately an account on All evm networks so that's that's going to change has to change uh and there are solutions that are being worked on in terms of like key stores that are accessible cross chain and uh ways to to sync the state across the chains that will eventually solve that there was just recently like a a spec on that from Michael from base uh that that goes into

that that that's one thing and then the the other challenge will be that smarter cons they are uh very much depend on the virtual machine uh so you can have a smart contract that creates your your account but obviously that's very much dependent on what smart contract language you use for implementation and all the security assumptions are dependent on the the virtual machine behind it so it's possible to create a similar smart account then across non evm chains like a Solana or or else but this will necessarily you remove certain technical assumptions so you can take certain security assumptions and you will have have to uh build up the the

trust into this smart account from scratch so there's uh similar solutions to save on say Sol that's like a squats that have been around quite a while and that do similar things and for safe the near to midterm Focus will still be evm I think there's enough that can be built there in terms of smart account adoption on devm itself uh it's it's a huge ecosystem and there's it just allows to move faster if you can make the technical assumption on the virtual machine but obviously in the long run this should not be limited to that and uh safe in in some way or another should be uh also yeah available outside of the evm itself and whether that that means

integrating with some of the other implementations such as the squats uh on other networks that's yet to be seen uh but that's definitely in the long term say 3 to 5 years something that needs to be done yeah I mean I I would love to see safe in other ecosystems I mostly because like Solutions I think are lacking yeah I I think that in the next 1 to two years we'll see safe competitors emerge in those ecosystems like native Solutions emerge in those ecosystems which will you know half mover first mover advantage and likely make it difficult for safe to really gain a a a foot hold in in those ecosystems maybe you know with the

exception of like existing customers on the safe on the evm side that have assets there that want to move those assets into other ecosystems what when it comes to the evm ecosystem and the cross chain compatibility What's the progress in terms of being able to control cross chain accounts from like a single account so for example you know if you had assets on uh or you had like a safe account on on polygon and wanted to control assets on another account by signing something on poing on like is there any progress in in um in the direction of interchain accounts as we call them in Cosmos so these are accounts that can be controlled

externally uh by an account on another chain is that also something that can exist within the safe ecosystem in the evm world definitely um so that's what I mentioned before uh on key stores uh so that's actually something that was proposed by vitalic pterin last year and now certain uh teams are are looking into uh the idea is that you should have the ability to have multiple spart accounts uh but have the the core validation logic or the the logic what keys are associated with that account separated in two separate contract which is a key store contract which then allows you to have less of that logic in the account itself and you just save

from the account you then make a state proof towards that key store and then it allows you to see what's actually the the account logic and and uh prove that against the the transaction um and that can then be taken cross chain as well actually in Via designated rollup so that could be like a key store rollup that then contains the logic of your account and you have your sub account so to say on different networks um could be evm could be beyond evm that just allow you to use a cross chain State proof against this key store roll up in order to uh prove what uh what keys or what validation logic this this account has and then this essentially means that you

will have cross chain smar accounts that can then be allow you to think to to achieve things like complete Network abstraction where for a user or a developer it doesn't even matter where the transaction is starting and where it's uh pointing at but this is then abstracted away uh by having these cost chain smart eons um I would still say it's like maybe 6 to 12 months out until we have first production implementations of such keyo wups but there's like major teams working on that and uh I'm I'm 100% sure that we're going to that direction and it's going to be first maybe uh optimized for certain sub ecosystems say the optimism ecosystem or the SC ecosystem but over

time it will expand and even go go beyond the evm where you can have like a keyo roll up which is based in eum layer one but as a roll up in order to optimize some gas efficiency uh but then allows you to yeah prove that that verification State towards any other networks very cool yeah I mean I think that that's uh a mostly like untapped kind of feature uh in in the evm world this this ability to control accounts uh cross chain you know again like you know in Cosmos we have standards for this and and exists and we're able to do this pretty easily but but in theit world I think it's it's still needs a little bit of time in order to become production

ready so you guys recently announced this uh I think it was last year this recovery Hub so safe added all these different kind of methods to do recovery and you have some um Partners there that I guess can act as uh third party signers is in the event of lost Keys what does this look like and what are the kind of trust assumptions that users of safe have to make in order to be using this recovery feature yeah so the idea behind recovery is that you may have more userfriendly ways to get keys into the hand of of users be like Pass Key signers or be U social login signers such as like login with Google or something like that but

still you want to have uh worst case scenario uh way to recover access to your cont and that actually at least in my opinion it's something that's very ID in critic to the user itself so there may be different users that want to have different ways to recover the account some like just their family and friends they just want to have sort of like a multi controlled by their family friends controlling their account and if they lose their own keys they just approach these uh social recovery signers and and ask them to initiate a recovery Others May trust an institution such as a a bank or a notary or something like that that can execute a recovery uh in

certain cases even in inherit cases worst case and um yeah there's even for others that may trust some like the centralized network of uh like a yeah Humanity D kind of uh system that then verifies the identity of of someone that then can be used to recover the account uh through some uh identity verification and how we're thinking then around what we built in terms of the foundations for enabling these use cases that we created this recovery Hub which is very much uh agnostic system to add different recovery systems and we're working together with Partners in order

to Showcase some of these capabilities uh so the very base logic of the recovery Hub is that you can add a module which is like a separate smart contract which has access to your account as an admin key but then you add security guards that make sure that this uh admin key is somewhere some somewhat yeah protected that um and that can be depending on on what the user prefers it's usually like a a time lock so that's user can say this separate contract can recover my account but only by having a time lock of like three months so I kind of needs to pre sign the the recovery and in that three months I could cancel the recovery uh if I have access to my keys and this then

allows to have less trusted system where I I may delegate this admin key to my social recovery setup or to this institution but still have the certainty that they cannot go Rogue and just run away with thecount there's other ways to to add security such as Signum which is a Swiss licensed bank which is building a recovery system for the recovery Hub what they're doing is that they limit the capabilities of this this recovery module uh to only exchanging certain signers in the con uh so the logic goes like this recovery module can exchange sign a but not sign up B B C or D uh and this can be then configured by the user and they can say just this one signer

which I I trust uh Signum to to recover uh I I set up and this then just limits what Signum can do with theond and again with some time lock so there's an additional protection through that but essentially the it's it's very open-ended what can be done there and there can be was amounts of different ways that uh these these recovery setups are being created and are there any uh kind of best practices like so if someone wanted to set up a multisig account or you know a smart account and then have a recovery I think one of the things that you internally we spent a lot of time thinking about was okay what does the key distribution setup look like like

who has keys where are they where are the seats uh stored you know what other third parties outside of our organization might have access to these Keys uh for backup or recovery purposes does safe make any recommendations or best practices or recommend best practices when it term comes to doing this kind of you know smart account setup within an organization I mean we usually recommend to use a threshold of more than one that's obvious you want to have multi signature uh not just one out of five where every one of the members of the organization can do whatever they want uh so there's at least multiple people looking over a transaction and then we

also recommend to not use a threshold that's equal uh to the number of signers so not to any five out of five schemes because that will mean that only one key needs to be lost and the the account uh is not usable anymore in case you don't have a recovery so that's always dependent on also what recovery setup you use obviously if you have a a very trusted recovery setup then it might make sense to have like a five five out of five if you have this emergency way to to recover the the con but without that have at least like three out of five that's enough for having multiple people cosign uh but that also allows for some people to not be available at

certain times or also certain keys to be uh lost and in order to to create key rotations afterwards uh but that's just very basic recommendations I would do in general it it very much depends on on the specific use cases and like how many people are involved like what's the trust assumptions between these people and so yeah that's true yeah and there's also kind of catastrophic you know we we thought a lot about this this catastrophic scenario where since the team often travels together if there was a catastrophic scenario where we were to all perish how would you know heirs or other stakeholders be able to recover keys in that event and so we had to think about safeguards there as well um

but yeah it it's I think for a lot of teams that have set up multisig and that are managing significant amounts of capital on on these accounts they've probably gone through similar Reflections and you know thinking about the best scenario I yeah I I don't think there's a on size fits-all solution for everyone but certainly like you know some best practices here I think generally would be would be useful I don't know if anyone's thinking about these things or publishing anything about this but I I hadn't found anything like that was um very useful for for our for our use case I wanted to also talk a little bit about security at safe so you guys recently passed $100 billion in assets secured by

the protocol I guess that's that's cross ecosystem or um cross cross evbm chains that's a lot of responsibility on on the safe team and I would argue that if something were to happen if there was a bug in the safe smart contract that not only the uh multi holders would suffer but I think the entire ecosystem would probably suffer quite a bit yeah what does that evoke for you and um what do the process looked like the process of making sure these smart contracts are absolutely bulletproof I must say I was uh more worried in the early years of safe uh than I am now because like the the vast amount of the security comes through its

Lindy effect so just having like a lot of value controlled through the smart accounts over time without there being any issues and uh especially with uh like the safe smart account we we don't update them that often intentionally because every time you make a change to the to the smart contract that means that there could be potentially any like risks associated with that uh so we are not kind of adding new features uh just to the base contract but we we allow this with modules and then there a different uh kind of security assumptions that that's behind there but yeah generally also because it's not just a 100 billion uh dollars worth of of assets that are secured but also like

critical infrastructure uh be it like cross chain Bridges be it reaking protocols be it stable coins that uh use Save smart accounts under the hood in order to control certain upgrade parameters and so on like it is quite critical that the the safe smart account is is really bulletproof and for that we invest a lot into security uh we uh actually invested a lot also into formal verification the the very first major version of the the safe smart account was formally verified over a period of six months of of uh quite some time and and financial investments that went into that obviously multiple audits are always part of that having a bu Bounty

and a community bu Bounty challenge that is is associated with that and like a big part of the security is also just on like in internal processes and uh how the culture is around Security in the team and so on but yeah the the key part is is still like the the lind effect and that's something where I would argue at this point with that much at stake if there would be any major issue with the safe smart account no one could tell but like I would assume this would almost be a reason to uh to initiate a hard fork and for me this is also a signal that if if people assume this would happen at some point it would make sense to even make certain components of the safe smart account

really part of the theum uh protocol so really enshrine that and make make it very explicit and say like this is logic that we expect to to behave a certain way and if it if it's not that case then it would be a consens kind of consensus issue and it kind of would lead automatically to fix that or it would be like bu in a client or something rather than a bu in the smart contract and I would assume that eventually we will have to to move towards that if we see that certain parts of the safe smart contract are really rified we don't expect them to to change much in the future we should just make them part of the protocol yeah yeah I agree that I think

that would also solve a lot of the user experience issues and and also the uh you know so the gas issues surrounding you using safe obviously like on ethereum mainnet like using safe can be quite expensive and having that ined in the protocol I think would make sense long term and also in terms of just adding new features and having smart contracts being able to leverage safes I think there's like a huge benefit of saying like Okay this infrastructure should be enshrined uh so that most most new accounts would be smart accounts right and um so let's take a step back here and talk a little bit about the nosis ecosystem generally so obviously like safe is a huge part of that there's also nosis chain there's nosis pay and you guys have lots of other products and

teams is working on all sorts of infrastructure how does safe fit in with all this and you know what's the long-term vision for I don't know if you can talk about like nosis generally but uh yeah the nosis ecosystem I mentioned at the beginning nosis originally wanted to do prediction Market uh it was quite early it was pre defi summer and there was a lot of interest structure missing uh in order to even make prediction markets work uh so there was no secure way to sa customer the assets which prediction markets would create a lot of assets which need to be self custo um there was not a good way to exchange assets um because the pric markets would create

different tokens and they need to be exchanged in a in a capital efficient way and there's like bunch of different things that were missing and nosis was basically forced to uh to build these things out themselves uh and that's how in in the end safe was created that's also How cow swap was created over the years and and other things also nosis became a DA as nosis Dow so suddenly there was infrastructure needed to really enable have Community governance over nois St so that's where U safe snap was created a way to connect a safe smart account with snapshot space uh in order to have offchain voting but have

onchain execution and that's then how the NOS skill team was born as a way as a team that's optimizing on building da infrastructure then nois da had the treasury which had to be managed uh and that's where the katki team was born which is now I think the biggest asset manager for for Dow treasuries and they they manage dou treasuries like the one from arow or ens and like all these were initially internal teams but at some point became uh spin-offs uh but obviously it's it's very much still a close ecosystems so the different teams collaborate quite extensively uh and now like the future for nois uh is very much

centered around nosis chain uh which is another project that was actually picked up as iy in the past which then was rebranded to nosis chain uh yeah it's a side chain to ethereum it allows for a horizontal scaling of ethereum block space and uh on on nosis chain there's uh the the payments Network nosis pay being built out which is really the the second Focus next to inos chain itself uh which is a way to connect um defy with the traditional Financial uh system uh meaning that the idea is that you are able to really have your assets on chain uh but able to spend them offchain and

uh trigger Bank transfers offchain but then result into onchain transactions and really Bridge the gaps between those two ecosystems uh as a first step to hopefully then have more more of the the payment ecosystem actually move on chain and not be yeah rooted still in the traditional Financial systems but then uh get replaced over time with really true on train systems so there also safe place a very critical role in in nosis pay as it's the underlying um account standard for for nosis pay because something like nosis pay actually needs smart accounts in order to work because it it is meant to be like s custodia account which then still allows you to have a like a card like a

Judicial Visa card associated with it which you can use to suspend offchain and in order to brid these assets offchain you need to have a way that they can be taken from the account and then put into the Visa network uh but still you don't want to just give like unlimited access of of your assets to some to the nosis pay Network there uh but they actually want to limit that and that's that requires smart account so that every nosis card actually is associated with a safe smart account which has like a yeah a daily limit associated with that where any transactions that are below this daily limit can be put into the the nois pay Network and and be used to to pay at the merchant store uh but it's it's in a way

that it have uh still the vast majority of your assets are self custodial and it just uh yeah this daily limit that you get then give and yeah the the long-term vision is really that nois is focusing on on building out like this decentralized payment Network that then leverages things like safe leverages things like cow swap for uh for exchange of assets and and other parts of the no ecosystem it becomes really this combination of of the different infrastructure that was built over the last years and builds really something that can then bring as as much as possible of of today's payment volume on chain great well Lucas thanks so much

for coming on the podcast today it's been great learning about safe uh understanding the the technical uh implementation of safe and also uh how it fits into the broader nosis ecosystem so thanks so much for coming on and look forward to having you back on in the future yeah that was a pleasure