Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Safe: Securing $100 Billion of Crypto Assets - Lukas Schor

Episode Date: April 18, 2024

What started out as a plan to build prediction markets, Gnosis ended up building crucial Ethereum infrastructure and tooling. Safe is one of its many successes, which originated during the 2017 ICO mania, as a solution for managing the raised capital securely, via a multi-sig. Even back then, the multi-sig model was quickly adopted by the entire industry, as a gold standard for asset security. Smart accounts and ERC-4337 represent the next step towards mass-adoption, through achieving a Web2-like UX.Topics covered in this episode:Lukas’ background and how Safe was foundedBitcoin vs. Ethereum multi-sigsSmart accounts & ERC-4337Safe’s design phylosohpySafe CORE, SDK & APISafe wallet UXExpanding cross-chain supportSafe account recoveryOpSecSafe’s smart contract securityGnosis ecosystem evolutionEpisode links:Lucas Schor on TwitterSafe on TwitterGnosis DAO on TwitterGnosis Chain on TwitterGnosis Pay on TwitterSponsors:Gnosis: Gnosis builds decentralized infrastructure for the Ethereum ecosystem, since 2015. This year marks the launch of Gnosis Pay— the world's first Decentralized Payment Network. Get started today at - gnosis.ioChorus One: Chorus One is one of the largest node operators worldwide, supporting more than 100,000 delegators, across 45 networks. The recently launched OPUS allows staking up to 8,000 ETH in a single transaction. Enjoy the highest yields and institutional grade security at - chorus.oneThis episode is hosted by Sebastien Couture.

Ent tiny ecosystem at that point, all the projects doing their own ICOs during the 2017 phase started adopting this multi-signature wallet as well. In the long run, these smart accounts will be just solutionary 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 onboard like a billion people to Web3. I would say when it comes to cross-drain, smart accounts in the short term will bring new. challenges 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 dops, but this can be abstracted away. 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, KOWSWOP or NOSIS chain, NOSIS combines needs-driven development with D-EGELD. technical expertise. This year marks the launch of NOSIS pay, the world's first decentralized payment network. With the 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 a business looking to white-label the stack, visit nosispay.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 noses chain. Get started today at NOSIS.io. Course 1 is one of the biggest node operators globally and help you stake your tokens on 45 plus networks like Ethereum, Cosmos, the last year, and DYDX. than 100,000 delegates stake with Chorus 1, including institutions like BitGo and Ledger. Staking 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 1's public note from your wallet, set up a white label node,

or use the recently launched product, Opus, to stake up to 8,000 eth in a single transaction. You can even offer high-year-staking to your own customers using their API. Your assets always remain in your custody, so you can have complete peace of mind. Startsaking today at chorus.1. Welcome to Epicenter, the show which talks about the technology's projects and people driving decentralization in the blockchain revolution. I'm Sebastian Quirche, 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 InterOVentures, and I'm sure lots of you out there are also using SAFE. They were spun out of NOSIS a couple of 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, Sebastian. So before we get started, how did you become part of the SAFE team? Were you previously at NOISSIS or yeah, because I think you're like one of the co-founders

of SAFE? What's the story there? Yeah, that's right. So SAFE is a spin-off from NOSIS. I joined back in 2019 as a product manager responsible for that point, NOSIS safe project within NOSIS. Actually, I was applying half a year before that to NOSIS 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 background. The product manager role opened up and I was 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 together with Richard and Tobias, my co-founders, the project responsibilities. And over time, then the project grew, and it outgrew to some extent NOSIS, as in the team size grew and the focus kind of expanded beyond what it's originally meant to be. and it became its own ecosystem and that's when we decided together with the NOSIS team that it's better off

to continue the project outside. Maybe a little bit of the history of how this project came to begin with. So NOSIS, back in 2016, was started to create prediction markets. So that's a way to financially incentivize participants to share their knowledge in order to expose that knowledge

to the public and that's meant to be as a primitive on the Ethereum blockchain and NOSIS went ahead and did an ICO in order to fund their project

and it happened that the ICO was quite successful NOSIS had to custody a lot of the proceedings 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 Giorger, who is the co-founder of NOSIS, 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 the ICO funding and was open-sourced. And then it happened

that all the entire ecosystem at that point, all the projects doing their own ICOs during the 2017 phase started adopting this multisignature 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 project formed it became its own team within NOSIS. And that's roughly 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 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 Bitcoin-only company. But even then, it's quite cumbersome to set up the keys and everything. But Ethereum didn't have an on-protocol solution. Do you know why that is? Like why Ethereum didn't go down the same path as Bitcoin and 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? what should be then solved the layer above from the smart contract level. It actually happened that Ethereum originally wanted to have smart accounts, so accounts that based their logic on smart contracts, have this natively within Ethereum. It was then, it turned out that this is quite complex to do, and the team at the Ethereum Foundation was a bit of in a time rush to launch Mainnet. So this scope did last minute.

And we since then had our wallet infrastructure on Ethereum mostly based on EOAs, so externally owned accounts. These are the accounts everyone knows that are controlled by a single private key, usually derived from a seed phrase, 12-24 word secret phrase, and that's where the wallet infrastructure was built upon. I personally think that it's a better pathway to solve as much as possible on the smart contract level there in terms of logic of an account. Because if you look at what you mentioned, the Bitcoin multi-sick implementation, it works quite nicely for certain use cases, but it's quite limited. Because you have all the logic enshrined in the Bitcoin protocol.

And for example, that means that certain use cases such as rotating keys, is not possible with the Bitcoin multisig. 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 one of the keys or it gets compromised, you actually have to move your funds to have completely new Bitcoin multisig. And you cannot just rotate one key and continue with that same wallet. These things are solved by just leaving the logic.

up to the smart contract level and allowing different implementations to take different optimizations and different 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 a trained again in the Ethereum protocol once we see that these are actually must-havs and have the standardization value, is higher than the flexibility of having different implementations. Yeah, I think the enshriman 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 Ethereum 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 4337 is. So some people think that ERC 4337 is smart accounts and all the logic, all the possibilities that are, enabled through this standard is due to the ERC 4537 standard, while most of the features, such as recovery or like session keys and so on are actually the responsibilities of the smart

accounts. So smart accounts have existed since years. Yeah, SAFE has been around since five, six years, and a lot of what we're now talking when we talk about the potential of 4537 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 4337. So as I mentioned, the Ethereum protocol, it has two types of accounts, is EOA, externally owned account and smart contracts, 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 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, pass keys or so on, where there's no EOA part of the transaction life cycle. But so far how it worked is that you had to fulfill the transaction verification requirements, be it in a multi-sig case that you collect the different. signatures from the participants, but then still you need to have an EOA involved in the transaction in order to actually process that transaction on the fee on blockchain. So usually how that worked is that you had like everyone signed the transaction and then the last person that was signing

was the poor person that actually had to pay for the transaction fee from his EOA account. And yeah, that's now coming to ERC 457. So just one, just the kind of put a pin that essentially what you're saying here is that 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 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 in the EOA that the user controls. So even in the past, there were relayer systems like a biconomy or gelato or private relays 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 Vlayer system would take with the EUA and pay for the gas fees and put on chain. And that's where then ERC-4337 comes in, where we say that the idea should be that we have sort of like a separate mempool for these smart account transactions, where we can just add the smart account transactions that are fully signed,

fully valid and then we have a decentralized mechanism how these transactions are then put on chain. There's actually still an EOA involved. So that's the EOA that a bundler in the standard controls. The bundlers are just collecting all the different smart account transactions and are then bundling them together and put them on chain by paying for the gas fees and using 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 bundler isn't sitting on the cost,

but actually get out net zero or ideally with some profit. And exactly the standard now allows that there's no centralized relayer involved anymore. Users don't need to fund their own EOAs, but they just trust that there's this decentralized networks of bundlers that they can just throw in a digital action and it gets executed in a trustless way. Okay, so to recap here, so ERC 4337 uses existing smart account or leverages existing smart account infrastructure, but offsets the execution 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, well, A, execute it and

B, pay 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 gas savings. In the end, the ERC-4-337 architecture adds some gas overhead itself, but assuming that 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 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 when you, you know, I've encountered this a bunch of times where like we started transaction and then we realized maybe the amount was wrong or there's like some issue with the transaction as we're signing it. This happened recently, right? We're like I had a zero too few, right, in my amount. And so then you have to go through this process of reverting the transaction.

And that's 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, 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 two 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 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 the transaction and send it to the bundle network at the later point. But once it is sent to a bundle, 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 EOAs work as well. if you sign a transaction metamask today, if you have too low of a gas fee and it's just stuck in a mempool, like it can be executed at any point, which you can resolve by sending the 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 nons, 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 at that point, when the nonce is still available and the transaction is out there, like it needs to be assumed that it can be executed. I guess we've clarified here that EURC 4337 is related to executing transactions. Is there an EOA that is creating a standard for how,

smart account should be conceived, like in terms of the architecture of the smart account, or is that up to smart account, like companies 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 to more smartacons. for example that it requires that a 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 so on.

And there the transaction needs to start in the account and then go 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 ERCs 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 have 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 certain default logic.

And you expand that with modules. This can be a better. validation plugins. These can be certain safeguards that are added to an account and that then extends the logic of the account. And there is now initiatives that say we want to have, yeah, certain parts of this architecture, of this modeler 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 a module that you create for Smart Account A works the same way also with Smart Account P. These are, yeah, there's actually two standards out there as always. It's not enough to have one standard, you have a second standard and then the first standard to get rid of the other two and so on. But there's ERC 6900,

which was started last summer by the Alchemy team and you got ERC 75-79 which is a collaboration between Rhinestone, Bichon, Pichon, OKX and others that define different ways how these modular smartocans could look like with some different technical assumptions. Concretely, 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 a 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 SAVES perspective, we actually want the SAVE 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 ways you can extend the smart account. And then you can just add an adapter in order to be compatible with ERC6,900 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 quite early. We have little adoption so far. And they might 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, we can just add another adapter to support them. And we have an account that lasts forever.

Incredible. So what is SAFE's design philosophy here? I mean, because you guys have like SafeCore, which is the core of the safe product and the smart contract, logic. Do you think that this should be kept 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 broader approach to design where this core could also include other functionalities that are currently being fulfilled by the plugins or

or modules. Yeah, I mean, there's probably two key philosophies for SAFE. One is that SAFE, as the name says, is very much focused on security. So that just 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, as a 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 user group as

as possible, meaning that the account itself, the core safe smart account should be a base primitive, but then you can expand it depending on the use cases and optimize then through its modular architecture to different ways to use the smart account. And yeah, that also means that we very much depend on the ecosystem around SAFE. So that's something that was clear early on that if we really want to bring Web3 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 an ecosystem and a community of builders to help us with that.

So the idea is that the Save Smart Account becomes this very core of this smart account transition. And then we have others that are building the different use cases, be different types of wallets, with asset management solutions that then have built around this core primitive and extend with what's needed for them. Is it automation, is it session keys, maybe for a gaming use case? Is it more pass keys if you want to build a retail wallet? that then puts us into a role of building this core protocol and working together with the ecosystem through ecosystem support initiatives to target these different user groups from their perspective. So in SafeCore, 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 safe core. 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 safe transaction and that transaction then pops up on the wallet of, say, your co-signer 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 don't know what is, SACs, the company's involvement in running infrastructure,

it's kind of 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 third parties that it may rely on. The smart account, the smart contract suite, is 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 the transition from EOAs easier. And yeah, we just always evaluate what's the things that we can provide to the ecosystem in order to make it easier to build on smart accounts. And right now it's an SDK that just allows to have, to interact with the smart accounts, to craft signatures and so on, and to also work with the ERC-4537 relaying network and the API, as you say, that it's essentially an indexer.

The most part is an index, so it just indexes all the SAF Smartic transactions out there and makes them available for developers. So you can track 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 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 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. 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 that's why we provide this service. It's also an open-source service.

So there are projects that 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 indexes that participate in retrieving and sharing these partially central transactions. Just because it's always better to not rely just on a centralized service, even though anyone could run the service themselves and so on. But the truth is that it probably would take quite some time until some other service would spin up that has a similar performance that would then have step in if our index it would be down. So we have the pathway towards this decentralized index network is something that we are looking into. Yeah, okay, interesting. 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 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 costs, but on Ethereum, that might be a bit prohibitive. Yeah, and it also makes sense, as this service is only run for a certain set of, of, uh, of networks on networks where the index is not run, we 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 not be dependent on it.

Okay. Great. This is cool. Thanks for clearing that up. Yeah, on the wallet side, I'd like to talk a little bit about the user experience here and what are some of the challenges that you guys face when building, in a wallet that supports SafeCore. And 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 trying to sign a transaction and it's not working and I'm getting some weird error message. And I've actually talked to Safe support two or three times when executing transaction and they've always been very helpful

and have helped sort of 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-sig transaction because there's just all these moving parts that need to work. And it, it always feels like a bit of a lift. to get that transaction sign. So yeah, what are your thoughts on

user experience generally? And how can we improve all this? It's actually interesting because there's like two camps here. Some people say like the Safe Wallet interface is already quite user-friendly and some still have issues. It's probably also to some extent, if you compare where Safe Wallet is today compared to 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 a long, long way to go. Also challenge there is that we want to have, say, for the B as user group and use case agnostic. So we cannot optimize for, say, someone that's super technical that wants to see all the information and always be able to look under the hood of everything 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 the middle. and then actually work with the ecosystem to provide the best experiences for the different user groups. So, for example, there's an on-chain den, which specializes really on multi-signature in a team use case and having transactions. They say the interface that allows you to sign transactions the fastest, and they have like some notification system behind it and so on and 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 retail users that allows them to abstract a little bit more from the details away and have a more smooth user experience where maybe the cross-team collaboration part is less of a focus. So that's really our strategy that we say, say for it is like a baseline.

It should be like an interface that people can start using in order to get experiences with smart accounts to cover certain use cases, but then as you over time, there should really be a wide ecosystem of designated solutions that optimize for different users, yeah, user groups. That's cool. I made a note of these. I think I'll probably try them out as well. So you said on-chain den and nest wallet.

Yeah, I mean, with like some of the issues I've faced were, yeah, I think like ordering of signing 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, you know, 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, or 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 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 sign things. But there's one thing I don't really understand is like why you need to have a, it seems like you need to have an on device account. So like when you create this save for the first time, you need to have like 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 ledger, which kind of seems a bit backwards to me if we're going to have ledgers to sign safe transactions, to then have to have this less safe kind of hot wallet on the device. So that's, yeah, I don't know, maybe I'm doing something wrong here, but that's always been a little confusing to me. Are you using Android? No, iOS.

Yes, okay, because technically it should be possible to execute also with Ledger. So the idea about the mobile wallet is that it should be just a very smooth way to to cost signs transactions and you can add any kind of like wallets to do so, like Ledger via Bluetooth or like mobile wallets via Walletka via Waller 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 U.S. things that I find you know, can be improved. But overall, uh, you're like, I agree with you that the experience

generally is, 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 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 people who have been in this space long enough we'll 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 saying things since

years that we're still early and at some point we cannot allow us to say that anymore because it's still quite cumbersome if you want to do full self-custody and interact with taps and it's still not that accessible to a wide range of people in the world. like even just having pretty much everything default to English, like that's fine for certain parts of the Western world, but we need to have more localized solutions, but also in general how the UX works of wallets today, there needs to be so much more that we should do in the 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 that is needed to onboard like a billion people to Web3.

Yeah, I think smart accounts are huge unlock there and I'm really looking forward to more broad adoption of pass key and other ways of signing. So I'll tell you a little bit about what's happening. I 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 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 value of the transactions you're doing or perhaps even the value on the account itself, then you'll be required. to add a second factor authentication, so it could be like a pass key or a secondary account to sign. And they're building all of this infrastructure on the chain, which is great when you're doing your own chain. And it brings me to another question I wanted to ask you is,

what's 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 Solana, like Cosmos chains, like the move ecosystem, the Aptos and Suey, 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-strain, smart accounts in the short term will bring new challenges 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 daps,

but this can be abstracted away through smartacons. But yeah, in the short term, there are challenges. One of them is that smart accounts, they are just very unique per chain. Because these are smart contracts, they deployed on a certain network, they have their 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 Create 2, counterfactual deployment. There's still very much independent accounts, which is a difference towards EOAs, which are by design,

because it's kind of standardized, especially in the EVM ecosystem, like you have a CET phrase in its immediately and account on all EVM networks. So 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 sync the state across the chains, they will eventually solve that. There was just recently a spec on that from Michael, from base, that goes into that. That's one thing.

And then the other challenge will be that in smart accounts, they are very much dependent on the virtual machine. So you can have a smart contact that creates 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 virtual machine behind it. So it's possible to create a similar smart account then across non-evm chains like Solana or else, but this will necessarily, you remove certain technical assumptions so you can take certain security assumptions and you will have to build up the trust into this smart account from scratch. So there's similar solutions to save on say Sulana, that's like a squat that have been around quite a while and that do similar things.

And for save, the near-to-midterm focus ball still be EVM, I think there's enough that can be built there in terms of smart account adoption on DVM itself. It's a huge ecosystem and it just allows to move faster if you can make the technical assumptions on the Ethereum virtual machine. But obviously in the long run, this should not be limited to that. and safe in some way or another should be also available outside of the EVM itself and whether that means integrating with some of the other implementations such as squads

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 would love to see safe in other ecosystems, mostly because solutions I think are lacking Yeah, 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, have first mover advantage and likely make it difficult for SAFE to really gain a foot hold 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. 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 Polygon and wanted to control assets on another account by signing something on Polygon, like is there any progress in the in the in the, in the, direction of interchain accounts, as we call them in Cosmos.

So these are accounts that can be controlled externally by an account on another 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 looking into. The idea is that you should have the ability to have multiple smart accounts, but have the core validation logic or the logic what keys are

associated with that account separated into a 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 account logic and prove that against the transaction. and that can then be taken cross-chain as well, actually via a designated roll-up. So that could be like a keystore roll-up that then contains the logic of your account,

and you have your sub-account, so to say, on different networks. 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 prove what keys or what validation logic this account has. and then this essentially means that you will have cross-chain smartacons

that can then allow you 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 abstracted away by having these cross-chain smartacons. I would still say it's like maybe six to 12 months out until we have first production-ready implementations of such keystowelops but there's major teams working on that and I'm 100% sure that we're going to that direction

and it's going to be first maybe optimized for certain sub-ecosystems, say the optimistly ecosystem or the scroll ecosystem, but over time it will expand and even go beyond the EVM where you can have a keystore roll-up, which is based in Ethereum layer one, but as a roll-up in order to optimize some gas efficiency but then allows you to prove that very, state towards any other networks.

Very cool. Yeah, I mean, I think that that's a mostly like untapped kind of feature in the EVM world, this ability to control accounts cross-chain. You know, again, like in Cosmos, we have standards for this and exists and we're able to do this pretty easily. But in the EVM world, I think 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 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 is 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 the hand of users, be it like past key signers

or be it social login signers such as like login with Google or something like that, but still you want to have a worst-case scenario way to recover access to your account. And that actually, at least in my opinion, 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-seek controlled by their family and friends controlling their account and if they lose their own keys they just approach these social recovery signers and ask them to initiate a recovery others may trust an institution such as a bank or a notary or something like that that can execute the recovery in certain cases even in inheritance cases, worst case

and yeah, there's even for others that may trust some like decentralized network of like a humanity doll kind of

system that then verifies the identity 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 an 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 smart 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 somewhat protected and that can be depending on what the user prefers. It's usually like a time lock so that user can say this separate contract can recover my account but only by having a time lock of like three months so it can have me pre-signed 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 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 count. There's other ways to add security such as Cignom, 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 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 B, C or D. And this can be then configured by the user. And they can say just this one signer, which I trust the CigNum to recover, I set up. And this then just limits what CigNum can do with the account. And again, with some time lock. So there's an additional protection through that. But essentially, it's very open-ended what can be done there.

and there can be vast amounts of different ways that these recovery setups are being created. And are there any kind of best practices? So if someone wanted to set up a multi-sig account or a smart account and then have a recovery, I think one of the things that 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? were 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 recommend best practices when it comes to doing this kind of 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 a 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 do any five out of five schemes, because that would mean that only one key needs to be lost and the account is not usable anymore in case you don't have

recovery. So that's always dependent on also what the recovery setup use. Obviously if you have a very trusted recovery setup, then it might make sense to have like a five out of five if you have this emergency way to recover the count. But without that, have at least like a three out of five. That's enough for having multiple people cosine. But that also allows for some people to not be available at certain times or also certain keys to be lost and in order to create key rotations afterwards. But that's just very basic recommendations I would do. In general, it very much depends on the specific use cases and 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 kind of catastrophic,

you know, we thought a lot about 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's, I think for a lot of teams that have set up multisigs and that are managing significant amounts of capital on these accounts, they've probably gone through similar reflections and, you know, thinking about the best scenario. I don't think there's a one-size-fits-all solution for everyone, but certainly like some best practices here, I think generally would be useful.

I don't know if anyone's thinking about these things or publishing anything about this, but I hadn't found anything like those very useful 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 cross-ecosystem or cross-EBM chains. That's a lot of responsibility on the safe team. And I would argue that if something were to happen, if there was a bug in this safe smart contract,

that not only the multisig 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 the vast amount of the security comes through its linear effect, so just having a lot of value controlled through the smart accounts over time

without there being any issues, and especially with the SAFE smart accounts, we don't update them that often intentionally because every time you make a change to the smart contract that means that there could be potentially any risk associated with that so we are not kind of adding new features just to the base contract

but we allow this with modules and then there's a different kind of security assumptions that's behind there but generally also because it's not just a hundred billion dollars worth 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 use safe smart accounts under the hood in order to control certain upgrade parameters and so on. Like it is quite critical that the safe smart account is really bulletproof.

And for that we invest a lot into security. We actually invested a lot also into formal verification. the very first major version of the Safe Smart Account was formally verified over a period of six months of quite some time and financial investments that went into that. Obviously, multiple audits are always part of that, having a bug bounty and a community back bounty challenge

that is associated with that. And a big part of the security is also just on internal processes and how the culture is around security in the team and so on. But yeah, the key part is still like the Lindy 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 initiate a hard fork.

And for me, this is also a signal that 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 theory. protocol. So really enshrine that and make it very explicit and say, like, this is logic that we expect to behave a certain way. And if it's not that case, then it would be a consensus issue and it kind of would lead automatically to have fixed that or it would be like a buck in a client or something rather than a buck in the smart contract. And I would assume that eventually we will have to move towards that if we see that certain parts of the same

smart contracts are really ossified. We don't expect them to change much in the future. We should just make them part of the protocol. Yeah, I agree that. I think that would also solve a lot of the user experience issues and also the gas issues surrounding using safe. Obviously, like on Ethereum Mainnet, using safe can be quite expensive and having that in trying 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 SAFs, I think there's like a huge benefit of saying like, okay, this infrastructure should be enshrined so that most new accounts would be smart accounts, right? 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 working on all sorts of infrastructure. How does SAFE fit in with all this? And what's the long-term vision for, I don't know if you can talk about, like, NOSIS generally, but yeah, the NOSIS ecosystem. I mentioned it at the beginning NOSIS originally wanted to do

prediction markets. It was quite early. It was pre-DFI summer. And there was a lot of infrastructure missing in order to even make prediction markets work. So there was no secure way to see. self-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 capital-efficient way. And there's a bunch of different things that were missing. And NOSIS was basically forced

to build these things out themselves. And that's how in the end, SAFE was created. That's also how cow swap was created over the years and other things. Also, NOSIS became a DAO as NOSISDAO. So suddenly there was infrastructure needed to really enable, have community governance over NOSISDAO.

So that's where Safe SNAP was created, the 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 NOSISGIL team was born as a way, as a team that's optimizing on building Dow infrastructure, then NOSISDAO had the treasury, which had to be managed. And that's where the Kapatki team was born, which is now, I think, the biggest asset manager for Dow treasuries.

And they manage Dow treasuries like the one from Avedau or E&S. And like all these were initially internal teams, but at some point became spin-offs. but obviously it's very much still a close ecosystem so the different teams collaborate quite extensively and now the future for NOSIS is very much centered around NOSIS chain which is another project that was actually picked up as X-Dai in the past which then was rebranded to NOSIS chain

it's a side chain to Ethereum and it allows for a horizontal scaling of Ethereum block space and on NOSIS chain there's the payments network NOSIS pay being built out, which is really the second focus next to into NOSIS chain itself, which is a way to connect DFI 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 payment ecosystem actually move on-chain and not be rooted still in the traditional financial systems but then get replaced over time with really true on-chain systems. So there also safe plays a very critical role in NOSIS pay as it's the underlying account standard for NOSISP. pay because something like NOSISPAY actually needs smart accounts in order to work, because it is meant to be self-custodial account, which then still allows you to have 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 you of your assets to some to the nosis pay network there but they actually want to limit that and that requires smart account so that every NOSIS card actually is associated with a safe smart account which has like a daily limit associated with that where HHS actions that are below this daily limit can be put into the NOSIS pay network and be used to pay at the merchant store but it's in a way that it's still the vast majority of your assets are self-custodial and it's just the state limit that you get and give.

The long-term vision is really that NOSIS is focusing on building out this decentralized payment network that then leverages things like SAFE, leverages things like KOWOP for exchange of assets and other parts of the NOSIS ecosystem, it becomes really this combination of the different infrastructure that was built over the last years and builds really something that can then bring as much as possible 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 technical implementation of SAFE and also how it fits into the broader NOSIS 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 slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign that 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 happy to read them. So thanks so much, and we look forward to being back next week.