Tiny ecosystem at that point all the projects doing their own Icos doing the 2017 phase 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 that is needed to to onboard like a
billion people to to or three. I would say when it comes to cross train, smart accounts in the short term will bring new challenges in in the long run will actually solve. Frustrating in a way that it can make it irrelevant in what networks you interact with what tabs, but this can be abstracted
away. This episode is brought to you by Gnosis. Gnosis builds decentralized infrastructure for the Ethereum ecosystem with a rich history dating back to 2015 and products like Safe Cow Swap or Gnosis Chain, Gnosis combines needs driven development with deep technical expertise. This year marks the launch of Gnosis Pay, the world's first decentralized payment network. With a Gnosis card you can spend self custody crypto at any Visa accepting merchant around the world.
If you're an individual looking to live more on chain or business looking to white label the stack, visit gnosispay.com. There are lots of ways you can join the Gnosis journey. Drop in the Gnosis Dow Governance form, become a Gnosis validator with a single GNO token and low cost hardware, or deploy your product on the EVM compatible and highly
decentralized Gnosis chain. Get started today at Gnosis dot IO Chorus One is one of the biggest node operators globally and help you stake your tokens on 45 plus networks like Etherium, Cosmos, Celestia and DYDX. More than 100,000 delegators stake with Chorus One, including institutions like Bit Go and Ledger. Sticking with Chorus 1 not only gets you the highest years, but also the most robust security practices and infrastructure that are usually exclusive for institutions.
You can stake directly to Chorus One's public note from your wallet, set up a white table note, or use the recently launched product Opus to stake up to 8000 ETH 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 staking today at.
Chorus .1. Welcome to Epicenter, the show which talks about the technologies, projects and people driving decentralization in the blockchain revolution. I'm Sebastian Krutio and today I'm all by myself. I'm chatting with Lucas Shore, who's the Co founder at SAFE. Safe is of course the leading smart account, multi sig provider in the EVM ecosystem. They're securing over $100 billion in assets and are absolutely crushing it when it
comes to securing assets. We use SAFE at Interop Ventures and I'm sure lots of you out there are also using SAFE. They were spun out of Gnosis 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 is the future of SAFE look like? Hey, Lucas, thanks for joining us today. Thanks for having me semester. So before we get started, how did you become part of the Safe team? Were you previously at Nosis or?
Yeah, because I think you're like a one of the Co founders of Safe. What's the story there? Yeah, that's right. So safe is the spin off from from Nosis. I joined back in 2019 as a product manager responsible for the that Point Nosis safe project within Nosis. Actually I was applying half a year before that to Nosis in the in the marketing department. I got rejected right away. That's just a fun fact on the
side. Then half a year later something that was more relevant to my my background, the product manager role opened up and I was jumping on that and that was luckily successful. So I joined when the Nosy Safe project was quite a bit early stages.
Yeah. Then took over together with Richard and Tobias, my Co founders the the project responsibilities and over time then the the project group and it outgrew to some extent noses as in the kind of the team size crew and the the the focus have expanded beyond what it's originally meant to be and it became its own ecosystem. And that's when we decided together with the Nosys team that it's better off to continue the project outside.
Yeah, maybe a little bit of the history of how this project came to begin with. So Nosys like back in 2016 was was started to create prediction markets. So that's a way to financially incentivize participants to share their knowledge in order to, yeah, expose that knowledge to the public. And that's meant to be as a as a primitive on the film blockchain. And Nosys went ahead and did Nico in order to fund the project and it happened that the ICO was quite successful.
Nosys had to custody a lot of the proceedings from from that ICO and back then the entire self custody infrastructure was quite early on, meaning that they had to create their own solution. So Stefan Giorgi who's the Co founder of Gnosis wrote himself a multi signature contract which is a way to share the responsibility of a self custody set up with other people via multiple keys and that was used for for the ICO funding and was open sourced.
And then it happened that all have the entire ecosystem at that point all the projects doing their own IC OS doing the 2017 phase started adopting this multi signature wallet as well. And that's how the team was formed as suddenly had many projects that were using this solution and there were feature requests coming in and people wanted to have the project maintained. And so the the project formed, it became its own team within Nosis and that's roughly when when I joined. 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 custody.
Bitcoin had an on chain in protocol solution still has and you know in Bitcoin you can create an on chain multi sig 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 only company and but yeah the even even then like it's quite cumbersome to set up the keys and and everything but Etherium didn't have an on protocol solution.
Do you know why that is? Like why Etherium didn't go down the same path as Bitcoin and built build an in protocol 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 solve the layer above from the smart contract level. It actually happened that Etherium originally wants to
have smart accounts. So accounts that's based on logic on smart contracts have have this natively within the theorem it was then yeah it turned out that this is quite complex to do and the team at the Etherium Foundation was a bit of an in a in a time rush to to launch mainnet so that this scope did last minute. And we since then had our have all the infrastructure on Etherium mostly based on EO as
so externally owned accounts. These are the the accounts everyone knows that are controlled by a single private key usually derived from from a seat phrase, 12424 word, secret phrase and that's where the the world 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 logic of of an account.
Because if you look at what you mentioned the the Bitcoin multi SEC implementation, it 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 for example that means that certain use cases such as rotating keys is not possible with the Bitcoin multi sig. So you once can set up your multi signature wallet.
You might have a certain threshold of signatures required to make transactions, but then if you lose access to to one of the keys or it gets compromised you actually have to move your funds to complete the new Bitcoin multi sig. And you cannot just rotate one key and and continue with with
the same wallet. These things are are solved by just leaving the logic up to the smart contract level and allowing different implementations to take different optimizations and different yeah, technical assumptions. And this creates much more flexibility. Then and over time we will probably see certain standards or certain best practices emerge and potentially at some point these can be trained again in if
you're in protocol. Once once we see that these are actually must have and have, the standardization value is higher than the flexibility of having different implementations. Yeah, I think the Entrime in 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 smart accounts are conceived
of in the Etherium space. I think most of the research is around this ERC 4337. Yeah, Give us an overview of what is ERC 4337 and how it aims to implement smart accounts on EVM chains. Yeah, there's actually quite some misconceptions still on what the ERC 457 is. So some people think that ERC 457 is smart accounts and all the logic, all the possibilities that are enabled through this standard have 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. We have SAFE has been around since 5-6 years and a 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 problem that's solved by ERC 457. So as I mentioned the if you're in protocol like it, it has two types of accounts, it's EOA Externally Owned Account and Smart Contacts which can then be used to make smart accounts. And yet a transaction actually in order to be processed needs to originate from an EOA. And that's that's a challenge because you have certain use
cases of smart accounts. You actually might not even want to have an EOA involved if you use certain like new signature schemes, passkeys or so on where where there's no EOA part of the transaction life cycle. Yeah, but so far how it worked is that you had to fulfil the transaction verification requirements, be it in a multi CIC case that you collect the different signatures from the participants.
But then still you need to have an EOA involved in in the transaction in order to actually process that transaction on the FION blockchain should. So usually how that worked is that you had like everyone signed the transaction and then the last person that was signing was, was the poor person that actually had to pay for the transaction fee from his EOA
account. And yeah, that's now now coming to ERC 457. So just just one one, just the 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
safe 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 on chain 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 on chain account. Exactly, at least so far. And it doesn't even need to be
an EOA that the user controls. So even in the past there were relayer systems like a bichonomy or Gelato or private relayers that are just Eoas that are funded that then are instructed that once there's a smart account transaction that's like fully verified and fully signed that then this relayer system would would take with the EOA and and pay for the gas fees and
put on chain. And that's where then ERC 457 comes in where we say that the idea should be that we have sort of like a separate man pool for the smart account transactions where we can just add the smarter account transactions that are fully assigned, fully valid. And then we have a decentralized mechanism how these transactions are then put on chain. There's actually still in EOA
involved. So that's the EOA that the bundler in the in in the standard controls the bundlers are just of collecting all the different smart account transactions and are then bundling them together and and put them on chain by paying for the gas fees and using the the EOA. And they can then get repaid for this gas fee expenses by paymaster which is not a component of this standard which then allows that the the bundler isn't sitting on the cost but actually get out net zero or
ideally with with some profit. And exactly the the standard now allows that there's no centralized relayer involved anymore. Users don't need to fund their own EO AS, 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.
OK, so just to recap here. So ERC 4337 uses existing smart account or leverages existing smart account infrastructure but offsets the execution or or sends the responsibility execution to this bundler network.
That bundler network does the on chain execution of any smart account transaction that is ERC 4337 compatible and that therefore alleviates the initiators of that transaction to have to a execute it and B pay for for the on chain 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. There is some component of of
gas savings 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, that overhead decreases and even at some points that there should be ways to to even have better gas efficiency than just using like a smart account natively itself. Right.
And just to come back to this signing and execution process, So what when you you know I've encountered this a bunch of times where like we start a transaction and then we we realized 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 zero too few right on in in my amount and and so then you know you you you have to go through this process of 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 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 bundle network to then execute it on chain? There's probably 2 steps to that.
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 multi signature use case have access to this partially signed transaction. So they could complete this transaction and send it to the bundler network at the later point. But once it is 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 EO as work as well. If you sign a transaction meta mask today, if you have too low of a gas fee and it's just stuck in the main pool like it can be executed at any point, which you can resolve by sending a transaction again with a higher gas fee in order to speed up the transaction, or by replacing the transaction on the same nonce with a different transaction. So that would also be the case with smart accounts.
They also have a nonce. So once a transaction then is executed at the same nonce, that means that the other partially signed transaction or fully signed transaction is not able to be executed anymore and can be disregarded. But up up in that point, when the nonce 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 your C4337 is related to executing transactions.
Is there an EOA that is creating a standard for how smart accounts should be conceived like 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 requirements towards smarter cons.
For example that it requires that the smart account transaction is starting from the account itself, which is relevant if you think about modular smart accounts. So you might have different execution logic for an account and 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, which, yeah, there's some details there that just define how the account works. There's other ER CS that standardize certain patterns for smart accounts, such as proxy patterns or now more recently again with modular smart
accounts. There's certain initiatives from the 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. 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 actually has certain default logic and you expand that with modules. This can be validation plug-ins, 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 no initiatives that say we want to have, yeah, certain parts of this architecture of this modular architecture be the same across different smart account implementations.
Why should we do that? The idea is that you then don't have to create these modules for different implementations separately, but you can actually assume that they have certain standards that they comply to. And the modules that you create for Smart Account A works the same way also with Smart Account B. These are yeah, there's actually
2 standards out there. As always, it's not enough to have one standard, to have a second standard and then the first standard to get rid of the other two and so on. But they are the ERC 6900 which was started last summer by the Alchemy team and you got ERC 7579 which is a collaboration between Rhinestone by Economy, OK X and others that define different ways how these modular smart accounts could look like with some different technical assumptions.
Completely ERC 6900 bundles the modular architecture also with a permissioning system. So you say you have these different modules and you want to give certain permissions 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 leaves the security, the permissioning system potentially to future ERC and just says we shouldn't overcomplicate things, we should just focus on one thing after the other. And yeah, these standards are in a way competing at this point from the SAFE perspective. We actually want the SAFE Smart account to be compatible with any standard.
So that's possible as SAFE itself has some native modularity built in. So it already has some some ways you can extend the the Smart account 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 which makes it just future proof. It's still unclear how these standards evolve. They're all they're quite early got we have little adoption so far and they might still change
over time. So our philosophy there is that we want to save Smart account really to be as have low level as possible so that no matter how these standards evolve, we can just add another adapter to to support them and we have an account that lasts forever. Incredible. And So what is Safe's design philosophy here? I mean 'cause you got you guys have like Safecore which is the the core of the of the safe product and and the smart
contract logic. And 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 approach to design or do you have more of a a broader approach to design where this core could also include other functionalities that are currently being fulfilled by the plug insurance or or modules? Yeah, I mean there's probably two key philosophies for Safe.
One is that SAFE, as the name says is is very much focused on security. So that's just the defines everything we do at SAFE in terms of like how we approach upgrades to the smart account, how we approach, yeah, how we balance for example also flexibility versus security versus gas efficiency. So we always default more
towards the security side. And the other one is that we want to be as use case agnostic and use a group as agnostic as possible, meaning that the account itself, the core save smart account should be base primitive. But then you can expand it depending on on the use cases and optimize then through its modular architecture to different yeah to different ways to to use the smarter con. And yeah that also means that we very much depend on the
ecosystem and run safe. So that's something that was was was clear early on that if you would really want to bring web free towards smart account adoption, if we want every account to be a smart account which is our mission like we cannot aim to do this ourselves. We really rely on ecosystem and the community of builders to to help us with that. So what the idea is that the safe smart account becomes this very core of of this smart account tradition.
And then we have others that are building the different use cases, speed, different types of wallets with the 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 is it more past keys if you want to build a retail wallet.
And that then have puts us into a role of of building this core protocol and working together with the ecosystem through ecosystem support initiatives to to target these different user groups from their perspective. So in Safecore, there's there's, there's multiple components. We have the smart account which we've talked about. 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 Safecore. And the way I understand, I mean one of the roles 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 cosigner or like another signer in the 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 NOSYS or sorry safes the company's involvement in running infrastructure that's going to centralized infrastructure that makes that possible or is there an on chain component there? I'd love it if you could explain how the API works and who are the the the third parties that it may rely on. The smart account created, the smart contact suite is the the core of it all. But then we provide tooling for developers that just make it
more accessible. If you want to build an application using smart accounts, if you want to use to build a wallet, then things like an SDK or API just make this more accessible, make make the transition from US easier. 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 smarter cons. And right now it's an SDK that just allows us to have yeah to interact with the smarter cons to craft signatures and so on, and to also work with the ERC 457 relaying network and the API as you say, that's it's essentially an indexer. The most part is an indexer, so it just indexes all the safe smart account transactions out there and makes them available for developers. So you can say you can drag different 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 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 sig sign on chain, at least in most cases you you might want to save on the gas cost of signing on chain and you just sign a signature, sign the transaction
off chain. But then you need a way to exchange these partially signed transactions with other participants of the multi sig and that's done also via the the API. So you can just post these partially signed transactions and retrieve them from another user and that just allows to exchange these transactions. Technically, it would be possible to exchange these transactions for any other means.
Yeah, also on chain 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 they run it themselves just as a redundancy 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 yeah sharing these partially signed transactions just because it's it's always better to not rely just on a on a centralized service even though like anyone could run the service themselves and so on.
But the the truth is that it probably would take quite some time until some other service what's what's been up that has a similar performance that would then have step in if if our index will be done or so. So drafted pathway towards this decentralized index network is is something that we are looking into. Yeah. OK. 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 for redundancy. But but you can also share the signatures on chain, correct? Exactly. OK, interesting. Now that might make sense on some networks that have like lower gas costs, but I got Etherium that might be a bit prohibitive. Yeah, and it also makes sense as this service is only run for a
certain set of of of networks. On that networks where the index is not run, you can still sign on chain. And it also is an additional redundancy. If the the service is not available then you could just with some little extra gas cost you could sign on chain and and not be dependent on. It OK, 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 the some of the challenges that you guys face when building in a wallet that you know supports safe core. And you know, I like the 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 is not
working. And I'm getting some weird error message. And I've actually talked to SAFE support like two or three times when executing transaction and they've always been very helpful and have helped to 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 multi sync 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? It's actually interesting because there's like two camps
here. 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 wallet is today compared to where where it is 2-3 years ago. I would say there's like a massive improvement in user experience since then, but obviously it's still a long long way to go. Also challenge there is that we want to have safe wallet, PS user group and use case agnostic.
So we cannot optimize for say someone that's super technical that wants to see like all the information and always be able to to look under the hood of everything at the at the same time optimize for someone that is less technical that really wants to have everything abstracted away. So we always try to be somewhere in in in the middle and then actually work with the ecosystem to provide the the best experiences for the different user groups.
So for example there's and on chain den which specialises really on multi signature in a in a team use case and having transactions. They say that the the the interface that allows you to have side transactions the the fastest and they have like some you 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 them to abstract a little bit more from the details away and have like a more smooth user experience where maybe the trust team collaboration part is less of a focus.
So that's really our strategy that we say say for that it's like a baseline, it should be like an interface that people can start using in order to get experiences with with smart accounts to to cover 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 for different solutions. 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.
So you said on chain den and Nest wallet. Yeah. I mean with like the the some of the issues I've 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 nonce. Like these kinds 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 in app 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
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 signed with and I love that the mobile wallet supports the Ledger and we can just like pull them out and get together and and you assign things.
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 this safe 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 which kind of seems a bit backwards to me. If we're going to have ledgers to to sign safe transactions to then have to have this less safe kind of hot wallet you know on the device. So that's that's, yeah, I don't know, maybe I'm doing something wrong here, but that's always been a little confusing to me. Yeah, are you using Android? No iOS.
IOS OK because technically it should be possible to execute also with Ledger. So the idea about the mobile wallet is that it's it should be just a very smooth way to to cosine transactions and you can add any kind of like wallets to to do so like Ledger via Bluetooth for like mobile wallets via wallet connect. And 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 you're like I I agree with you that the experience generally is, is is pretty good. You know, compared to look like 10 years ago Brian and I used to do Bitcoin transactions, electron wallet and we have to send the partially signed transactions 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 for people who have been in this 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 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 cumbersome. If you want to do full self custody and interact with with tabs and like that's still not that accessible to a wide range of 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 DX works of of wallets today there needs to be so much more that that we should do in next year's.
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 it's still retaining like security that is needed to to onboard like a billion people to to web free. Yeah, I think smart accounts are are huge unlocked there and I'm really looking forward to more broad adoption of passkey and other ways of signing.
So you know. I'll I'll tell you a little bit about what's happening. I don't know if you're familiar with this, but in the Cosmos ecosystem Osmosis which is the major decks there are doing an on chain smart account. Now of course the difference here is that they manage the entire chain and they can really build things on chain and also have certain types of transactions be either gas
subsidized or gas optimized. And so they the idea here is to do a smart account on chain that you can set up using, you know Oauth like a Twitter account or a Google account. And then based on the on the value of the transactions you're doing or perhaps even the value in the on the account itself. Then you you'll be required to add a second factor authentication. So it could be like a passkey or
or a secondary account to 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 safe strategy when it comes to building it's 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 Solana, like Cosmos chains, like the MOVE ecosystem, 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, 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 make it irrelevant in what networks you interact with what dabs. But this can be abstracted away through through smart accounts. But yeah, in in the short term there there are challenges. One of them is that smart accounts, they are, they are just very unique per chain.
So because these are smart contacts, they're deployed on a certain network, they have the logic on that network. 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 Grade 2 counterfactual deployment, they're still very much independent accounts.
Which is a difference towards EO as which are by design because it's kind of standardised especially in the EVM ecosystem like you have a seat race and it's immediately and we count on all EVM networks. So that's that's going to change, it has to change and there are solutions that are being worked on in terms of like key stores that are accessible cross chain and ways to to sync the state across the chains that
will eventually solve that. There was just recently like a spec on that from Michael from base that goes into that that that's one thing and then the the other challenge will be that smart accounts they are very much depend on the virtual machine. So you can have a smart contact that creates your your account but obviously that's very much depend on what smart contact language you use for implementation and all the security assumptions are depend 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 that you can take certain security assumptions and you will have to build up the the trust into this smart account from scratch. So there's similar solutions to save on say Solana, that's like a squats that have been around quite a while and that do similar things.
And for safe the near to mid term focus will still be EVM. I think there's enough that can be built there. In terms of smart account adoption on DVM itself, it's it's a huge ecosystem and there's it just allows to move faster if you can make the technical assumptions on the VM virtual machine. But obviously in the long run this should not be limited to to that and safe in in some way or another should be also, yeah, available outside of the VM
itself. And whether that that means integrating with some of the other implementations such such as the squads on on other networks, that's yet to be seen. But that's definitely in the long term, say three to five years, something that needs to be done. Yeah, I mean I I would love to see safe in other ecosystems been brought mostly because like solutions I think are lacking.
Yeah, I I think that in the next one 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 foothold 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 or you had like a safe account on on Polygon and wanted to control assets on another account by signing something on Polygon. Like is there any progress in, in the in the direction of Interchain accounts as we call them in in Cosmos.
So these are accounts that can be controlled externally by an account on the other chain. Is that also something that can exist within the safe ecosystem in the EVM world? Definitely. So that's what I mentioned before on key stores. So that's actually something that was proposed by Vitalik Buterin last year and now certain teams are are looking into.
The idea is that you should have the ability to have multiple Sparta cons but after 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 say 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 proof that against the the transaction and that can then be taken cost chain as well actually in via designated roll up. So that could be like a keystore roll up that then contains the logic of your account as you have your sub account so to say
on different networks. Could be EVM, could be beyond DVM that just allow you to use a cross chain state proof against this keystore roll up in order to prove what what keys or what validation logic this this account has.
And then this essentially means that you will have cross chain smarter cons 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 pointing at. But this is then exactly the way by having these questions smart accounts. I would still say it's like maybe 6 to 12 months out until we have first production ready implementations of such keystone roll ups.
But there's like major teams working on that and I'm I'm 100% sure that we are going to that direction and it's got to be first maybe optimized for certain sub ecosystems say the optimism ecosystem or the small ecosystem. But over time it will expand and even go go beyond the EVM where you can have like the keystore roll up which is based in Etherium layer one but as a roll up in order to optimize some gas
efficiency. 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 mostly like untapped kind of feature in in the EVM world this, this ability to control accounts cross chain you know again like in you know in Cosmos we have standards for this and and it exists and we're able to do this pretty easily but but in the EVM IT world it's 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, I think it was last year this recovery hub. So it's safe added all these different kind of methods to do recovery and you have some partners there that I guess can act as third party signers 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 user friendly ways to get keys into head to hand of of users, be it like passkey signers or be it social login signers such as like log in with Google or something like that. But still you want to have worst case scenario way to recover access to your account and that actually at least in my opinion it it's something that's very idiosyncratic to the user itself.
So there might be different users that want to have different ways to recover the account. Some like trust their family and friends. They just want to have sort of like a multi say controlled by their family and friends controlling their account. And if they lose their own keys they just approach these social recovery signers and and ask them to initiate the recovery.
Others may trust an institution such as a a bank or a notary or something like that that can execute the recovery in certain cases even in inheritance cases worst case and Yep there's in for others that may trust some like decentralized network of like yeah humanity doll kind of system that then verifies the identity of of someone that then can be used to recover the account through some identity verification.
And how we're thinking then around what we built in terms of the foundations for enabling these use cases is that we created this recovery hub which is very much agnostic system to add different recovery systems and we're working together with partners in order to showcase some of these capabilities. So the very base logic of the recovery hub is that you can add a module which is like a separate Spark contract which has access to your account as an admin key.
But then you add security guards that make sure that this admin key is is somewhere some somewhat protected that and that can be depending on on what the user prefers. It's usually like a a time lock so that the user can say this separate contract can recover my account but only by having a
time lock of like 3 months. So I can't really pre sign the the recovery and in that three months I could cancel the recovery if I have access to my keys and this then allows to have less trusted system where am I may delegate this admin key to my social recovery setup or to this institution but still have to certainly that they cannot go rogue and just run
away with the account. 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 to only exchanging certain signers in
the con. So the logic goes like this recovery module can exchange signer A but not signer BC or D and this can be then configured by the user and they can say just this one signer which I trust signum to recover. I set up and this then just limits what signum can do with the account and again with some time lock. So there's an additional protection for that.
But essentially the it's it's very open-ended what can be done there and there can be vast amounts of different ways that these these recovery setups are being created. And are there any kind of best practices like so if if someone wanted to set up a multi sig account or you know a smart account and then have a recovery. I think one of the things that you internally we spend a lot of time thinking about was OK what is the key distribution setup look like? Like who has keys, where are
they? Where are the seats stored? You know what other third parties outside of our organization might have access to these keys for backup or recovery purposes. Does safe make any recommendations or best practices recommend best practices when it term comes to doing this kind of, you know, smart account set up 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, not just one out of five, where every one of the members of the organization can do whatever they want, so there's at least multiple people looking over a transaction. And then we also recommend to not use a threshold that's equal 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 is not usable anymore in case you don't have
recovery. So that's always dependent on also what the recovery setup you use. Obviously if you have a very trusted recovery setup then it might make sense to have like a 55 out of five if you have this emergency way to to recover the the account, but without that have at least like a three out of five. That's enough for having multiple people cosign.
But that's also allows for some people to not be available at certain times or also certain keys to be lost and in order to to create key rotations afterwards. But then 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 on.
Yeah, that's true. Yeah. And there's also a 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. But yeah it it's I think for a lot of teams that have set up multi sigs and that are managing you know 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 one-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 those 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 I guess that's that's cross ecosystem or cross cross EBM 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 multi sig holders would suffer but I think the entire ecosystem would probably suffer quite a bit. Yeah. What does that evoke for you, and what does the process look like? The process of making sure these smart contracts are absolutely
bulletproof? I must say I was more worried in the early years of safe than I am now because like the the vast amount of the security comes through its linear effect.
So just having like a lot of value controlled through to smart accounts over time without there being any issues and especially with like the safe smart accounts 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 there could be potentially any kind of risks associated
with that. So we are not kind of adding new features just to the base contract, but we we allow this with modules and then there's a different kind of security assumptions that that's beyond there.
But yeah generally also because it's not just $100 billion worth of of assets that are secured but also like critical infrastructure be it like cross chain bridges be it restaking protocols be it stable coins that can use safe smart accounts under the hood in order to control certain upgrade parameters and and so on like it. It is quite critical that the the safe smart account is is really bulletproof and for that we invest a lot into security.
We actually invested a lot of us 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 quite some time and and financial investments that went into that.
Obviously multiple audits are always part of that having a back bounty and the community back bounty challenge that is associated with that and like a big part of security is also just on like in internal processes and how the culture is around security in the team and and so on.
But yeah the the key part is is still like the the linear 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 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 to be part of the theorem 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 consensus issue and to kind of lead automatically to have fix that or they will be like a back in a client or something rather than a back 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 ossified, 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, you know, so the gas issues surrounding, you know, using safe, obviously like on Ethereum main net, like using safe can be quite expensive and having that enshrined 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, OK, this infrastructure should be enshrined so that most, most new accounts would be smart accounts, right. And so let's take a step back here and talk a little bit about the Nosys ecosystem generally. So obviously like Safe is a huge part of that.
There's also Nosys chain, there's Nosys Pay and you guys have lots of other products and teams 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 Nosys generally, but yeah, the Nosys ecosystem. I mentioned at the beginning notices originally wanted to do
prediction markets. It was quite early, it was pre D5 summer and there was a lot of infrastructure missing in order to even make prediction markets work. So there was no secure way to serve custody assets, which prediction markets would create a lot of assets which need to be
self custody. There was not a good way to exchange assets because the prediction markets would create different tokens and they need to be exchanged in a in a capital efficient way and there's like a bunch of different things that were missing and Nosis was basically forced to to build these things out themselves 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 DAO as Nosis Tao. So suddenly there was infrastructure needed to really enable have community governance over nosy style. So that's where safe Snap was created, a way to connect a safe smart account with snapshot space in order to have off chain voting but have on chain execution. And that's then how the Nosy skill team was born as a way, as a team that's optimising on
building DAO infrastructure. Then Nosy style had the treasury which had to be managed and that's where the Kabatki team was born, which is now I think the biggest asset manager for for Dow treasuries and they they manage Dow treasuries like the one from Avatar or ENS like all these were initially internal teams but at some point became spin offs. But obviously it's it's very much still a close ecosystem.
So the different teams collaborate quite extensively and now like the future for Nosis is very much centred around Nosis chain which is another project that was actually picked up as XI in the past, which then was rebranded to Nosis chain. It's an inside chain to Etherium and it allows for horizontal scaling of Etherium block space.
And on on Nosis chain, there's the the payments network Nosis pay being built out which is really the the second focus next to Internosis chain itself which is a way to connect defy with the traditional financial system. Meaning that the idea is that you are able to really have your assets on chain but able to spend them off chain and trigger bank transfers off chain but then result into on chain transactions and really bridge the gaps between those two
ecosystems. As a first step to hopefully then have more and more of the the payment ecosystem actually move on chain and not be yeah rooted still in the traditional financial systems but then get replaced over time with really
true untrained systems. So they're also safe plays a very critical role in in Nosys Pay as it's the underlying account standard for for Nosys pay because something like Nosys pay actually needs smart accounts in order to work because it's it is meant to be like self custodial account which then still allows you to have like a card like a traditional Visa card associated with it which you can use to
spend off chain. And in order to bridge these assets off chain you need to have a way that they can be taken from the account and then put into the Visa network.
But still you don't want to just give like unlimited access of your of your assets to some to the Nosys pay network there but they actually want to limit that and that's that requires smart accounts so that every Nosys 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 Noses pay network and and be used to to pay at the merchant store.
But it's it's in a way that it's still the vast majority of your assets are self custodial and it's just yeah this daily limit that you get then give. And yeah the the long term vision is really that Nosys is focusing on on building out like this decentralized payment network that then leverages things like safe leverages things like cow swap for for exchange of assets and and other parts of the Nos Eco system.
That 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, understanding the the technical implementation of SAFE and also how it fits into the broader Nosys ecosystem.
So thanks so much for coming on and look forward to having you back on the future. Yeah, it was a pleasure. Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it.
To listen to the latest episode of the Epicenter podcast, go to epicenter.tv/subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter so you get new episodes in your inbox as they're released. If you want to interact with us guests or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show and we're always, I'm happy to read them.
So thanks so much and we look forward to being back next week.