Safe: Mission, Vision, Achievements and Announcements

Good morning, everyone. Can you all hear me? I'm waiting 10 seconds for people to catch their feet. All right. Welcome everyone to the SafeCon.

This year, we're doing things a bit differently. For those who were at SafeCon in the past years, we've been at the other side of the river. Now we thought we're integrating SafeCon within DapCon to make it easier to go back and forth. Now SafeCon is a one-day event. We're expecting up to 400 people today, and it's all about self-custody.

So we got people from different parts of the industry, different types of people like researchers, builders, users, such as general self-custody advocates. But what combines us, the goal that we share, is that we want to make altogether have self-custody be secure and easy. And yeah, it's never been more important that we are able to make self-custody secure and easy than today, with geopolitical conflicts across the world, with constant data breaches of intermediaries, and with custodians, for some reason, sponsoring military parades. I think it's crucial that people in the world, they have the ability to take control. They have the right to self-custody, and they have the possibility to exit a system that they find themselves in.

And that needs everyone of us. That needs the entire industry in order to make this possible. But also, at the same time, self-custody itself is being attacked. And I had a talk yesterday at DAPTCON about the Bybit hack, and the learnings that we should take from that, and a little bit of the details. So I'm not going too much into the nuances there, but just the high level, what we should learn from Bybit, which happened about three months ago.

Definitely, self-custody and secure self-custody is a constant battle. We haven't solved secure self-custody yet, and it's questionable whether we will ever solve it, because self-custody means that you defend yourself against malicious actors, against adversaries that would like to somehow compromise your account. And they constantly change their tactics, their tools, the environment changes, the tech stack changes, and it's something that never stops. Like, this battle is really something that's ongoing forever, and we need to make sure that we're always raising the bar in terms of this, that we're always giving users better and better tooling in order to defend themselves against attacks. It's also a very unfair battle, because in custodial solutions, you have to case, and what we also challenge, or what we don't like, is that there's one institution responsible for custodying all the assets, but that also means that the cost of security is socialized across all those users, because it's essentially the institution responsible for the security there.

In self-custody, the security is very unique per user, and the investments into security have to be appropriate for each user, but that also means that the types of defense mechanisms and the types of tooling need to be different for different users. It's unfair, because on the other side, there's nation-state actors, like the Lazarus Group, which easily can spend millions of dollars of investment into trying to compromise one single user, because if they succeed, actually, it is a lucrative investment. That's something to keep in mind. Another learning is that self-custody is relying on two main pillars. On the one side, you have the infrastructure, you have the transaction supply chain, basically all the different tools that users essentially use in order to make transactions, and that's the operating system, the device that they start with, the laptop, the front-end that they use, the application that they use, and everything in between, like the RPC, the indexer, all the off-chain infrastructure.

Unfortunately, we are at a point where we've built very cool web-free technology, but then we add a thick layer of web-2 technology on top, which is adding a lot of complexity from a security perspective, and just increases the attack surface for hacks to happen. So, the resilient infrastructure making this really secure is getting harder and harder as the transaction supply chain is growing. On the other side, the second pillar is the transaction verification, which is really the last line of defense of self-custody. We always say, don't trust, verify, but that is easier said than done. We see that many users don't verify transactions in a very appropriate way, and it is because it is complex.

Clear signing is not something that is propagated across the ecosystem. Many people verify maybe what they see on the front-end, but they don't verify if the payload is what they intend to do on the hardware device, and then suddenly, out of these two assumptions, what can happen is that if the transaction verification is not done properly, the infrastructure and the transaction supply chain becomes a single point of failure. That is something where definitely we need to have more investments. We need to have investments into hardening the infrastructure, working on decentralized alternatives, working on client diversity, front-end diversity, increasing the bar in terms of standards, security practices, OPSEC, all of that. But on the other side also, educating users about how they can verify transactions, providing better tooling to verify transactions, educating also about secure setups and processes, all of that.

There is going to be a very interesting panel on this later today about the current status quo of transaction security and transaction verification, so make sure to check that out. I also think this might not be enough. Even though we can invest more into these two pillars, we might need to think about additional layers of security, and one proposal that I have here that I would like to also discuss with you later in talks is execution guarantees. Execution guarantees essentially meaning that there is certain logic that is part of how even if the transaction supply chain and transaction verification fail, the outcome should not be catastrophic. There should be ways that there are certain guarantees given that certain invariants that cannot be broken and that can be implemented in different ways.

I have talked to people here at Dapcon. They work on a way to have assertions being enforced by sequences, for example. There's possibilities to have hooks as part of a modular DeFi protocol that enforces these guarantees, and in the case of Safe, the Safe Smart Account, there is a possibility to do that via guards, which is plug-ins that essentially do checks on transactions, pre- and post-transaction checks, and that's something that's super underutilized. We've talked in the past a lot about modules and modules being able to create new recovery mechanisms and other things, but I think what we should actually focus on more are these guards because they enable to create these execution guarantees, and they can come in the form of a cosigner, so a trusted party or even a network maybe of cosigners that runs logic and enforces certain rules, for example, that your account can only be upgraded to a certain set of singletons, for example, or that your account can only transfer a certain amount to another address. The rules are pretty arbitrary there.

You can implement—or cosigners can implement anything, really, like security checks, compliance checks, whatever. There can also be policies enforced via guards, which can live on-chain, which can live off-chain, which are user-defined, which are provided by the application. The range there is also broad. Or resource locks, which is a fancy way to say escrow and escrow logic, which can be enforced on transactions. I'm glad some teams, some of them are also here today, are working on this.

They work on additional guarantees, execution guarantees, as guards also, like the Hibernative team, Blockade team, working on cosigners, Drosera, as their traps have a framework, and others. I would just advocate for people that are especially building on SAFe to take this seriously, look into guards, look at the possibilities, also talk to these teams and their experiences, because I think that's something we need to do more in. A few short announcements. There will be more across the day. One is that the team is finalizing the smart account version 1.

5, which the big change there is that it introduces also module guards, so guards that actually run on modules. Also execution guarantees running on modules, which opens up more opportunities to create these security mechanisms, and a bunch of smaller changes. Essentially the idea is that 1.5 becomes the long-term support, the last 1.x version, and that any future version would then be most likely a bigger change, like a v2.

So that's the idea there. So we packaged whatever we think makes sense in the long term to be included in the 1.x version, and have this be most likely the final one. It's also interesting that the SAFe smart account is now being pre-deployed by all major L2 stacks. So whenever a new L2 launches with any of these stacks, they actually come with the SAFe smart accounts be pre-deployed there.

That just enables better multi-chain support, rolling out products to many networks more easily, and also reduces central party deploying these contracts there, which helps decentralization. Now, a bittersweet announcement. After Bybit, we temporarily paused the development of SAFeNet. For those that remember, SAFeNet was announced as a vision last December. It was the initiative for SAFe to work on interoperability, to create unified balance across networks.

When the Bybit hack happened, we needed some time to think about what is actually the best focus for us in this situation. Is this really the problem that we want to solve? Is it really us needing to solve this? We realized there is a bunch of teams working on interoperability right now. Chain abstraction at some point was pretty much every team pivoted to chain abstraction.

So there's a lot of development there. There's even initiatives from L1s, from the Ethereum Foundation, from L2s to create native interoperability. Finally, given our realization that now is the time to invest into security rather than convenience, all these three things together make us realize that it's not the right time to bring SAFeNet as envisioned to the market. It's sad for myself because a lot of blood and sweat went into this, and we have made quite some progress. We want to make sure that this progress isn't going to waste.

So next week we are open sourcing SAFeNet, hoping to get feedback and signal there in terms of how to take this forward with the ecosystem together. There are very interesting learnings there from SAFeNet, especially on these execution guarantees that I mentioned, because that was also part of the roadmap. How can execution guarantees be enforced on cross-chain transactions as well? So there's very good learnings there inside, also text that can be built upon in the future as we focus more on the security aspect. Also, we wanted to go forward into the next phase with a better structure within SAFe.

So that's why we announced SAFe Labs, which is really the product side of things. It's a fully owned subsidiary of the foundation, so it's very much ecosystem aligned, but it has a mandate to productize and also commercialize technologies around SAFe, and especially raising the bar in terms of enterprise readiness and really scaling the solutions that we already have to more audiences. This team is being led by Rahul Rumala, who's also here today, focusing particularly on SAFe Wallet and SAFe API technologies and products that we've been working on over the last years. He will be here doing a talk at 1.30, so if you want to hear about what's next for SAFe Labs, what's the newest developments, make sure to check that out.

On the one side, we thought it's important to really take the next level in terms of the product, but we also want to look ahead and really work on the things that make self-custody and that is really what the ecosystem originates on, like the Cypherpunk values, which we want to push forward and really work on the hard problems of self-custody. We're also having the SAFe Research Initiative going forward, which is led by Richard Meissner, and this initiative really focuses on the core values of Ethereum, which is censorship resistance, security, and privacy. So that's always the tension when you build up products. Do you focus on simplifying things, great UX, mass adoption, or do you actually work on the less shiny, less marketable aspects, which are nevertheless the more, or at least equally important aspects to building a product, which is censorship resistance, security, and privacy. There, we want to have a team that's purely focusing on long-term challenges that we can solve.

There, Richard will talk a bit more about already the initiatives that are in progress right now, but also going forward, and also the mentality that we want to apply to this research, because it should be also practical research that supports the ecosystem. Yeah, there are two. Make sure to check this talk. Yeah, so generally, we want to be focusing with different mandates on different aspects, but with one shared mission. So we will have going forward the foundation, which I'm leading with the mandate of fostering the SAFe ecosystem and generally the self-custody ecosystem, SAFe Labs, which is productizing technologies and also commercializing them, taking them to the next scale, and SAFe Research, which is pushing for cypherpunk values and solving the hard problems of self-custody, SAFe Labs by Rahul and SAFe Research by Richard.

And the shared mission and what ties everything together is really to make self-custody secure and easy, and yeah, this needs these different focuses. Yeah, there's going to be a lot of other announcements throughout the day and talks and panels. Make sure to hang around here. Very interesting, also at 5 p.m.

, Xiaowei from the Ethereum Foundation will come here and talk about making DeFi cypherpunk again. So that's an interesting one, but also very interesting panels on security, on on-chain organizations, and many more. So glad to have everyone here today. Looking forward to also chats on the side, one-to-one, and yeah, thanks for being together with us on the battle to make self-custody real. Thank you.

Thank you. Oh, I mean, question. Yeah, I mean. Sure. Sorry?

I mean, you need to always anticipate it. Like, honestly, like, we should always operate with the assumption that someone at this very point tries to compromise your systems. And so, yeah, this is something we need to anticipate. Predicting is hard, at least not in this scale, in this exact format, because if we would have anticipated that attack vector, it would have been possible. More questions?

Would you say the problem mainly was ledger needs a bigger screen? Would you say the problem is mainly that ledger needs a bigger screen? I mean, there's not one single problem, especially in this case. It's probably a few links that got broken. Like, if you imagine a chain, like, sometimes the chain breaks, and then it's easy to point, like, these are the points where the chain breaks.

It's hard to predict it before, where are the weak links. I think clear signing and being able for people to verify transactions is one aspect that needs to be worked on, but also the infrastructure security is another thing, and just missing fail-safes is also another thing. I don't want to weigh them against each other. That would be bad.