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

This episode discusses the advancements and challenges in securing vast amounts of cryptocurrency through smart accounts and multi-signature technologies.

1. Smart accounts and multi-signature wallets are crucial for improving security and operational efficiency in the cryptocurrency domain.
2. ERC 4337 is a pivotal development that facilitates trustless smart account transactions by minimizing the need for externally owned accounts (EOAs) in processing transactions.
3. The evolution of Safe from Gnosis reflects a broader trend towards specialized security solutions in blockchain technology.
4. Cross-chain compatibility remains a significant challenge and opportunity for smart account technologies, promising seamless integration across diverse blockchain networks.
5. Future advancements in smart accounts may include standardized modular architectures and decentralized networks for executing and verifying transactions.

1: Introduction

Sebastian Couture introduces the episode's focus on securing cryptocurrency assets and the role of smart accounts. Lucas Schor: "Smart accounts are the future of secure, scalable blockchain operations."

2: History of Safe

Discussion on the origin of Safe and its evolution from Gnosis. Lucas Schor: "Safe was born out of necessity during the early days of blockchain development."

3: ERC 4337 and Its Impact

Exploration of ERC 4337 and its implications for smart accounts. Lucas Schor: "ERC 4337 is a game-changer for processing smart account transactions without an EOA."

4: Cross-chain Challenges

Insights into the challenges and solutions for cross-chain smart account functionality. Lucas Schor: "Cross-chain functionality is complex but critical for the future of decentralized applications."

5: The Future of Smart Accounts

Predictions and hopes for the future of smart accounts in securing digital assets. Lucas Schor: "Modular smart accounts could revolutionize the way we think about blockchain security."

1. Implement Multi-Signature Wallets: Enhance security by using multi-signature wallets for asset management.
2. Explore Smart Account Solutions: Consider integrating smart account technologies for improved transaction safety and efficiency.
3. Stay Informed on ERC Standards: Keep up-to-date with the latest developments in ERC standards like ERC 4337 to leverage new security features.
4. Prepare for Cross-chain Interoperability: Develop strategies for cross-chain compatibility to stay competitive in the evolving blockchain ecosystem.
5. Engage with Modular Smart Account Developments: Participate in the development and standardization of modular smart accounts to influence future security practices.

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.

People

Lucas Schor, Sebastian Couture

Companies

Safe, Gnosis

Books

None

Guest Name(s):

Lucas Schor

Content Warnings:

None

Lucas Schor

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 the solution and there's no way around smart accounts in order to get to the user experience while it's still retaining security that is needed to onboard like a billion people to web three. I would say when it comes to cross chain, smart accounts in the short term will bring new challenges in the long run actually solve frustrating the way that it can make it irrelevant in what networks you interact with, what dapps. But this can be abstracted away.

Sebastian Couture

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 cowswap or gnosis chain. Gnosis combines needs driven development with deep technical expertise. This year marks the launch of Gnosis Pay, the worlds first decentralized payment network. With ignosis card, you can spend self custody crypto at any visa accepting merchant around the world.

If youre an individual looking to live more on chain or a business looking to white label the stack, visit gnosispay.com dot. There are lots of ways you can join the Gnosis journey drop in the gnosis Dao 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 IO cars. One is one of the biggest node operators globally and help you stake your tokens on 45 plus networks like Ethereum, Cosmos, Celestia and Dydx. More than 100,000 delegators stake with chorus one, including institutions like Bitgo and Ledger.

C

Staking with chorus one not only gets you the highest yields, but also the most robust security practices in infrastructure that are usually exclusive for institutions. You can stake directly to Chorusone's public node from your wallet, set up a white label node, 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 one welcome.

Sebastian Couture

To Epicenter, the show, which talks about the technologies, projects and people driving decentralization in the blockchain revolution. I'm Sebastian couture 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, multisig 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 interrupt ventures, and I'm sure lots of you out there are also using safe. They were spun out of gnosis 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 does 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 Gnosis, or. Yeah, because I think you're, like one of the co founders of Safe. What's the story there? Yeah, that's right.

Lucas Schor

So safe is a spin off from Gnosis. I joined back in 2019 as a product manager responsible for the, at that point, gnosis safe project within Gnosis. Actually, I was applying half a year before that to gnosis 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 at 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.

No sis, as in the team size grew and the focus expanded beyond what it's originally meant to be, and it became its own ecosystem. And that's when we decided, together with the Gnosis 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 gnosis, 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 gnosis went ahead and did an ICO in order to fund that project. And it happened that the ICO was quite successful. Gnosis 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 Bjorge, who's the co founder of Gnosis, wrote himself a multi signature contract, which is a way to share responsibility of a self custody setup 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 multi signature wallet as well. And that's how the team was formed, as sunny 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 gnosis.

And that's roughly when I joined. Yeah, cool. I think it bears reminding also that 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 in bitcoin, you can create an on chain multisig.

Sebastian Couture

And this is something that a lot of people like, including myself, have used. With Epicenter, we've used this also quite a bit in the early days when we were a bitcoin only company. But yeah, 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?

Lucas Schor

Yeah, I mean, it's always the question, what should be really enshrined as part of the protocol, and what should we then solve the layer above on the smart contract level, it actually happened that Ethereum originally wanted to have smart accounts, so accounts that base 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 the descoped it 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 seat phrase, 1224 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 multisig 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 a completely new bitcoin multisig, and you cannot just rotate one key and continue with the 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 trained again in the Ethereum protocol. Once we see that these are actually must haves and have, the standardization value is higher than the flexibility of having different implementations.

Sebastian Couture

Yeah, I think the enshrine question is one that needs a lot, 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. Yep, there's actually quite some misconceptions still on what ERC 4337 is.

Lucas Schor

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 457 standard. While most of the features such as recovery or session keys and so on, are actually the responsibilities of the smart accounts. So smart accounts have existed since years, safe has been around since five, six years. And a lot of what we 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 4357. So as I mentioned, the Ethereum protocol, it has two types of accounts, this EOA external 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 certain use cases of smart accounts, you actually might not even want to have an EOA involved if you use certain new signature schemes, passkeys or so on, where there's no EOA part of the transaction life cycle. Yeah, but so far, how it worked is that you had to fulfill the transaction verification requirements, be it in a multisig 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 Ethereum 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 UA account. And yeah, that's now coming to ERC 457. So just to kind of put a pin in that, essentially what you're saying here is that a smart account like safe 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.

Sebastian Couture

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.

Lucas Schor

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 biconomy 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 fully verified and fully signed, that then this v layer system would take with the eoa 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 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 UA 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 UA. And they can then get repaid for this gas fee expenses by Paymaster, which is another 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 the transaction and it gets executed in a trustless way.

Sebastian Couture

Okay, so just 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 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.

Lucas Schor

The ERC 457 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, there should be ways to even have better gas efficiency than just using a smart account natively itself. Right. And just to come back to this signing and execution process. So when you, I've encountered this a bunch of times where like, we start a transaction and then we realized maybe the amount was wrong, or there's like some issue with the transaction as we're signing it.

Sebastian Couture

This happened recently where I had a zero too few 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 bundler 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 others that are participating, for example, in a multi signature use case, have access to this partially signed transaction. So they could complete this transaction and send it to the bundle network at the later point.

Lucas Schor

But once it is sent to a bundler, then you need to assume that it's out there and it 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 the mempool, 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 until that point, when the nonce is still available and the transaction is out there, it needs to be assumed that it can be executed. I guess we've clarified here that ERC 4337 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 smart account? Or is that up to smart account companies and service providers to decide?

Sebastian Couture

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 smart accounts, for example, that it requires that 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 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 there's some details there that just define how the account works.

Lucas Schor

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 add a new feature to it, be it 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 validation plugins. These can be certain safeguards that are added to an account and that then extends the logic of the con. And there, there's now initiatives that say we want to have 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 module that they create for smart account a works the same way also with Smartaccount B.

These are. Yeah, there's actually two standards out there. As always, it's not enough to have one standard, you need to 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 7579, which is a collaboration between Rhinestone, biconomy, Okex and others that define different ways how these modular smart accounts could look like with some different technical assumptions. Concretely, ERC 16900 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 75 79 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 these standards are in a way competing at this point. From the safes 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 ways you can extend the smart account, and then you can just add an adapter in order to be compatible with ERC 1600 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, got little adoption so far, and they might still change over time. So our philosophy there is that we want safe smart account really to be as low level as possible, so that no matter how these standards evolve, you can just add another adapter to support them, and you have an account that lasts forever. Incredible. What is safe's design philosophy here?

Sebastian Couture

Because you guys have safe core, 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 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 modules? Yeah, I mean, there's probably two key philosophies for safe.

Lucas Schor

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 how we approach upgrades to the smart account, how we balance, for example, lots of 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 agnostic as possible. Meaning that the account itself, the Corsafe smart account, should be base primitive, but then it can expand it depending on the use cases and optimize then through its modular architecture to different ways to use the smart account 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 web three towards smart account adoption, if we want every account to be a smart account, which is our mission, we cannot aim to do this ourselves. We really rely on ecosystem and a community of builders to, to help us with that. So the idea is that the safesmart account becomes this very core of this smart account transition. And then we have others that are building the different use cases, be it 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 automations?

Is it session keys, maybe for a gaming use case? Is it more passkeys if you want to build a retail wallet? And 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 safe core, there's multiple components. We have the smart account, which we've talked about.

Sebastian Couture

There's also the SDK that sits on top of it, which allows, like you said, 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 it, one of the roles of the API of course, is to coordinate around these signatures. So when you're signing a safe transaction and that transaction then pops up on the wallet of some, 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 gnosis or sorry safes, the company's involvement in running infrastructure, 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 build a wallet, then things like an SDK or API just make this more accessible, make the transition from UA's easier. And yeah, we just always evaluate what's the things that we can provide this ecosystem in order to make it easier to build on smart accounts.

Lucas Schor

And right now it's an SDK that just allows to have to interact with the smart account to craft signatures and so on, and to also work with the ERC 4337 relaying network and the API, as you say that 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 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 seq, 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 you 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 yeah, 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 indexers that participate in retrieving and sharing these partially signed 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 step in if our index would be down. So graph the pathway towards this decentralized index network is something that we are looking into. Yeah. Okay, interesting.

Sebastian Couture

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 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 networks. On networks where the index is not running, you can still sign on chain, and it also is an additional redundancy. If the service is not available, then you could just, with some little extra gas cost, you could sign on chain and not be dependent on it. Okay, great.

This is cool. Thanks for clearing that up. 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 safecor? 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 trying to sign a transaction. It's not working and I'm getting some weird error message.

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 multisig transaction, because there's just all these moving parts that need to work and it always feels like a bit of a lift to get that transaction signed.

So yeah. What are your thoughts on user experience generally and how can we improve all this? That's actually interesting because there's two camps here. Some people say 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 all it is today compared to where it is two, three years ago, I would say there's a massive improvement in user experience since then.

Lucas Schor

But obviously it's still a long way to go. Also challenge there is that we want to have say follow up, be as 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 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 that they're the interface that allows you to have sign transactions the fastest, and they have 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 save wallet 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 user groups. That's cool. I made a note of these, I think I'll probably try them out as well. You said on chain Den and nest wallet.

Sebastian Couture

Yeah, some of the issues I've faced were, yeah, I think ordering of signing and then 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 desktop works or the kind of web version. And one thing I've never really understood is 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 you assign things. But there's one thing I don't really understand is why you need to have a, it seems like you need to have an on device account. So like when you create the save for the first time, you need to have like a 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 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, hot wallet on the device. I don't know, maybe I'm doing something wrong here, but that's always been a little confusing to me.

Lucas Schor

Are you using Android? No, iOS. IOS. 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 cosign transactions. And you can add any kind of wallets to do so like Ledger via Bluetooth or like mobile wallets by wallet connect. And. Yeah, I can look into this, I think. Yeah, we'll have to talk after.

Sebastian Couture

But yeah, so there's like these kind of minorities ux things that I find, you know, can be, can be improved. But overall, uh, you're like, I agree with you that the experience generally is, is, is pretty good. Um, you know, compared to look like ten 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 for people who have been in the 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 three space, we're saying 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 Dapps, and it's still not that accessible to a wide range of people in the world. Even just having pretty much everything default to English, 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.

Lucas Schor

There needs to be so much more that we should do in next years. And that's also why I'm so excited about smart accounts, because I think in the long run, these smart accounts will be the solution, and there's no way around smart accounts in order to get to the user experience while it's still retaining security that is needed to onboard a billion people to web three. Yeah, I think smart accounts are a huge unlock there, and I'm really looking forward to more broad adoption of passkey and other ways of signing. 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 Dex there, are doing an on chain smart account.

Sebastian Couture

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. The idea here is to do a smart account on chain that you can set up using 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 passkey or a secondary account sign. And they're building all of this infrastructure on the chain, which is great when you're doing your own chain. And brings me to another question I wanted to ask you, is, what's safe's 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, uh, the, you know, Aptos and Sui, you know, are you guys looking at those ecosystems at all and thinking of ways that safe can support those? Or is your focus really just the EVM and you'll stick to 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 the long run, will actually solve cross chain in a way that it can make it irrelevant in what networks you interact with, what dapps. But this can be abstracted away through smarter cons. But yeah, in the short term there are challenges.

Lucas Schor

One of them is that smarter construct unique per chain. So 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 two counterfactual deployment, they're still very much independent accounts, which is a difference towards your aspect, which are by design, because it's kind of standardized. Especially in the EVM ecosystem, you have a seed phrase, and it's immediately an account on all EVM networks. So that's going to change. That has to change.

And there are solutions that are being worked on in terms of key stores that are accessible cross chain and ways to sync the state across the chain. Eventually solve that. There was just recently, like a spec on that from Michael from base that goes into that. That's one thing. And then the other challenge will be that smart accounts, they are very much dependent on the virtual machine.

So you can have a smart contract 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 a 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 safe on, say, Solana.

That's like a squad that have been around quite a while and that do similar things. And for safe, the near to midterm focus will still be EVM. I think there's enough that can be built there in terms of smart account adoption on DVM itself, it's a huge ecosystem and 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 that and safe in some way or another.

Should be also available outside of the VM itself. And whether that means integrating with some of the other implementations, such as the 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, like, 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 emerging, those ecosystems which will half mover first mover advantage and likely make it difficult for safe to really gain a foothold in those ecosystems, maybe with the exception of existing customers on the safe on the EVM side that have assets there that want to move those assets into other ecosystems.

Sebastian Couture

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 a single account? So, for example, if you had assets or you had a safe account on Polygon, and wanted to control assets on another account by signing something on Polygon, is there any progress 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.

Lucas Schor

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 keystore 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 the keystore, and then it allows you to see what's actually the account logic and proof that against the transaction.

And that can then be taken cross chain as well, actually via designated roll up. So that could be like a Keystone roll up that then contains the logic of your account. And you have your sub accounts, 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 keystore 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 smart accounts 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 cost chain smart accounts. I would still say it's like maybe six to twelve months out until we have first production ready implementations of such keystore roll ups.

But there's major teams working on that, and I'm 100% sure that we are going to that direction and it's going 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 beyond the EVM, where you can have your 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 verification 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. Again, like in cosmos, we have standards for this and it exists, and we're able to do this pretty easily.

Sebastian Couture

But in the EVM world, I think it 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 of safe have to make in order to be using this recovery feature? The idea behind recovery is that you may have more user friendly ways to get keys into head to hand of users, be it passkey signers, or be it social login signers, such as login with Google or something like that. But still you want to have worst case scenario way to recover access to your account.

Lucas Schor

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 seat 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 the 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 there's, even for others, there may trust some decentralized network of humanity Dao 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 agnostic system to add different recovery systems. And we're working together with partners in order to showcase some of these capabilities. So the way 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 somewhere 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 kind of needs to pre sign 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 the certainty that they cannot go rogue and just run away with the account. There's other ways to add security, such as Cygnum, 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 sign a, but not sign a, B, C 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 logs. 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? If someone wanted to set up a multisig 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? Who has keys?

Sebastian Couture

Where are the seats stored? 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, we usually recommend to. Use a threshold of more than one.

Lucas Schor

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 to any five out of five schemes, because that will mean that only one key needs to be lost and the account is not usable anymore in case you don't have a recovery.

So that's always dependent on also what recovery setup you use. Obviously, if you have a 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 three out of five, that's enough for having multiple people cosign, 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.

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, 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?

Sebastian Couture

And so we had to think about safeguards there as well. But, yeah, 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 thinking about the best scenario. Yeah, 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.

You guys recently passed $100 billion in assets secured by the protocol. I guess that's cross ecosystem or cross EVM 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 the 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 Lindy 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 risks associated with that. So we are not adding new features just to the base contract, but we allow this with modules, and then there's different security assumptions that's behind there.

Lucas Schor

But yeah, generally also because it's not just $100 billion worth of assets that are secured, but also critical infrastructure, be it cross chain bridges, be it restaking protocols, be it stablecoins that use safe smart accounts under the hood in order to control certain upgrade parameters and so on, 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 bug bounty challenge that is associated with that. And a big part of the security is also just on like internal processes and how the culture is around security in the team and so on. But 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 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 accounts really part of the theorem protocol. So really enshrine that and make it very explicit and say 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 lead automatically to have fixed that or a bug in a client or something, rather than a bug 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 safe smart contract 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, on Ethereum mainnet, using safe can be quite expensive, and having that enshrine the protocol 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 a huge benefit of saying this infrastructure should be enshrined so that most new accounts would be smart accounts.

Sebastian Couture

Let's take a step back here and talk a little bit about the gnosis ecosystem generally. Obviously, safe is a huge part of that. There's also gnosis chain, there's gnosis pay. You guys have lots of other products and teams working on all sorts of infrastructure. How does safe fit in with all of this, and what's the long term vision for?

I don't know if you can talk about gnosis generally, but yeah, the gnosis ecosystem, I mentioned it at the beginning. Gnosis originally wanted to do prediction markets. It was quite early, it was pre defi summer, and there was a lot of infrastructure missing in order to even make prediction markets work. So there was no secure way to self custody assets which prediction markets would create. A lot of assets which need to be self custody.

Lucas Schor

There was not a good way to exchange assets because the 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 gnosis was basically forced to build these things out themselves. And that's how in the end, safe was created. That's also how cowswap was created over the years and other things also, gnosis became a Dao as Gnosis Dao.

So suddenly there was infrastructure needed to really enable, have community governance over gnosis 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 Gnosis Guild team was born. As a way, as a team that's optimizing on building Dao infrastructure.

Then Gnosis Dao had the treasury, which had to be managed, and that's where the Kapadki team was born, which is now, I think the biggest asset manager for Dao treasuries. And they manage dao treasuries like the one from Avidao or Ens. 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 gnosis is very much centered around gnosis chain, which is another project that was actually picked up as Xdai in the past, which then was rebranded to gnosis chain.

It's a sidechain to Ethereum and allows for horizontal scaling of Ethereum block space. And on gnosis chain, there's the payments network, gnosis pay being built out, which is really the second focus next to into gnosis chain itself, which is a way to connect DeFi with the traditional financial system, meaning that the idea is that you are able to really happy 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 gnosis pay, as it's the underlying account standard for notice pay, because something like gnosis pay 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 your assets to some.

To the nosis pay network there. But they actually want to limit that. And that requires smart accounts so that every NoSIs card actually is associated with Safesmart account, which has a daily limit associated with that, where any transactions that are below this daily limit can be put into the gnosis pay network and be used to pay at the merchant store. But it's in a way that still the vast majority of your assets are self custodial. And it's just the stain limit that you can then give the long term vision is really that gnosis is focusing on building out this decentralized payment network that then leverages things like safe leverages things like cowswap for exchange of assets and other parts of the NoSIs ecosystem 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 today's payment volume on chain.

Sebastian Couture

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 gnosis ecosystem. So thanks so much for coming on and look forward to having you back on in 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 happy to read them. So thanks so much and we look forward to being back next week.