Beyond Multisig: Continuous assurance for onchain teams

Transcript

[applause] >> Hello everyone. Uh hope you guys can hear me all right. Uh my name is Rahul uh and I'm from Safe. Uh today I want to talk about uh what comes beyond multi-sig. Um especially from how we are thinking uh from this lens of Safe as a team, as a project, as our vision as well. And so my next 15 minutes uh I hope one of the things I can impress you is with some insights, with uh with a shared perspective, and uh uh a collective uh information on what comes next.

So I was here like exactly probably one one year ago. Uh so it's always nice to frame uh Devcon is this milestone and retrospect in some way. So uh so last year in 2025, I spoke about this uh philosophy that uh we were leading with. Uh at Safe, we call it Cypherprice, which is uh uh how do you how do you uh build enterprise scale demand, but it but built on the foundations and the principles of Cypherpunk. So for lack of a better term, we call it Cypherprice, right?

Uh what has changed over the last one year is that that thinking shift. Uh that philosophy became habits, habits uh shaped uh our principles, and the principles shaped our product. So uh with that an evolution in our perspective uh also about how uh things are changing uh clearly in the space. So uh I like to kind of like lead with an insight with uh a presentation when I have something uh I try to do a lot of research, and this is this one insight that I have uh for for myself, but also for uh everybody.

Uh in this AI-driven exploit era, right? Uh we all know, we all see uh stuff that's happening. Uh the cost of uh performing an attack by a threat actor, it's it's just getting easier, right? It's getting It's uh it's getting cheaper. Uh it's getting faster. Uh it's getting more efficient. Uh one of the most uh mind-boggling insights that I had uh was this uh uh this insight from Mandiant, a cybersecurity firm by Google, is that uh uh they have this uh metric they follow, which is called mean time to exploit, right? They measure year over year as a trend. How long does it take to actually find an exploit?

It's currently at -7 days. So, kind of like let that boil that let that absorb. So, what does that even mean a -7 days uh is time to uh exploit? So, from my side, the way I kind of like uh interpret this is that >> [snorts] >> it takes attackers -7 days to find uh a vulnerability before you can even patch it. Right? >> [laughter] >> So, they are ahead of you, essentially, and that's that's the reality. So, like one of the things that I constantly actually think about it is uh what does this mean for for me? What does that mean for SAFE? What does that mean for our industry?

Uh our users, our customers. Uh And that that one insight for me is uh uh it sets a lot uh really strong perspective overall. But ultimately, I boil this down to uh uh this one learning. Like weak weak assumptions are easier to find, and uh the account setup, your posture uh on how you set up your assets, uh your control, your governance, that has to keep up. Uh So, and further translation of this is that uh like in it's very common in our day-to-day use of crypto. You know, we we have our wallet, we use our Chrome extension, we use a safe, we use a module, you got you have a guard, you

open a position in DeFi, you monitor it. Uh there are lots of moving parts. You you get on a new chain, a new L2. Uh there's a very exciting yield position. You're moving your assets around, you're touching many things. Uh all of these are audited. Right? Like uh we have this best practice, right? Like there's a minimum bar of keeping things audited before uh letting users touch it so sort of thing. So, what I what I see is this uh by nature, our ecosystem is fragmented. It's by design, but also the security of uh of uh this entire system is fragmented. And uh what this kind of made me realize is that

being audited is just not enough. It's a great starting point, but it's not uh enough. It's it's sort of a proof point that of assurance of point in time. It's a point in time assurance. That's how I kind of translate it because ultimately how are users using crypto or Web3 uh ultimately? It's it's workflows. It's uh you have a day a recurring transaction. Uh you have to do payments, you have to uh monitor your assets, you have uh uh market making, you have treasury workflows, et cetera, et cetera, right? So, these are the workflows, and this workflow kind of mandates you or dictates your behavior in touching many things, and that's the behavior we have today, right? So, at Safe, we often

think about this uh as the entire workflow end to end, right? Where does it start? Where does it end? What is the actual uh job that that that a user or a customer is trying to accomplish? So, for us, the goal is to kind of really raise the raise the bar, raise the posture of the entire workflow because you want to have confidence over the entire workflow not like a checkbox that it follows a compliance or a certification or an audit. It's just not enough. We want the entire workflow secured. one of the more interesting things of how safe has changed actually safe kind of changed with the industry, right?

Like uh 8 years ago I remember uh myself I had one safe. One safe became two, two became four, four became eight. Uh a lot of people have many safes that actually use us. This is something we see uh recurring uh on a recurring basis. Teams actually have multiple safes. Uh and that's pretty natural that I think as teams grow uh safe solve uh safe accounts become like a system of safes. And uh this forces uh >> us when we're really designing a composition of safes that uh how do we what do we want to express with our safe setup?

Uh in my head I I really often think about a safe setup in three controls. Ultimately it's the control that we I want to express with my safes. Uh the first one is positive control, right? Which is what uh what do you want your uh what do you want to approve? What do you want your system or your safe setup to say yes to? And the second one is negative control, what do you want to block? What do you want to restrict? What do you want to constrain at any given point? That's that's how we we do it with guards and rules and permissions in place.

And lastly is the delegated control. It's this concept of uh giving a delegated authority to another uh entities that can act on your behalf, right? We express that through uh system called modules uh in in the safe architecture. So, ultimately we uh in in my opinion every team and also us as builders we ask these three questions. Like what controls uh does it need to express? So, now going back to the fundamentals, right? The way we kind of like think about this evolution on the safe system, a system of safes, is that every every safe should have a a pretty clear bounded job, right? Like you have a you have an operating balance, what it

what it holds, what it can do, who is acting on it, and then what rules apply. Now, those are like the four fundamental dimensions that you can kind of like compose. And then ultimately, what you want to express this is this entire network or a tree of safes or a system of safes. Ultimately, like you can have a very typical structure is you have a a reserve safe, which is for capital preservation, or you have a payment safe, which is a high-velocity transacting account, or something that's a bit more like DeFi operations where you have uh higher thresholds for security and rules and permissions.

So, not all safes are the same, and this is this is this needs to be reflected in this architecture of how you compose your stuff, right? The controls matter. Controls are not the same in every safe that you actually use, you set up, and you interact. And that's the reality of it. Like we shouldn't treat every safe as the same and give it separate responsibilities. So, lastly, I I talked a little bit about delegation, right? The way we also think about delegation is when you delegate authority for something else to kind of act on your behalf, it needs to be really really narrow. It needs to be visible. It also needs to be revocable.

If you're giving that authority to something else, you need to be able to take it away as well. And that design thinking needs to apply when you set up and when you operate it and when you monitor it, ultimately. again, so in a world when we grow further, there'll be more accounts, there will be more signers, there'll be more chains, and that's we we know this is going to happen, right? How many of us have more than one wallet or one account? It's just It's just something we we deal with. Hell, we have more than one bank accounts even, right?

the takeaway that I'm kind of like trying to impress upon here is that you you really cannot protect that you cannot see. So, how do you protect something that you don't know what's happening? How do you protect something that you don't have control over perhaps because you gave that control away? And how do you actually look at this entire system, the entire workflow? How do you see it in one place? And this is this is the thinking that we're applying. And one of the big things that we're doing like as of today is this uh uh workspace, which is a like your operating system for all your safes in one place where you can stitch things together, apply, bring your team together, you have a

shared address book, etc. But ultimately, teams are working together, and you are also perhaps a signer across many safes. You you you are operating safes across companies. That is a completely different workflow than our traditional models in place as well. Uh and this is live today, and that's super exciting for us because it's a pretty big step to kind of have gotten to this stage mainly because how we also grew as an industry. And something else that's been live for a while is what we call like Safe Shield, is a co-pilot. So, in this AI-driven exploit era, what one of the thinking that we have is

we need a a secure security co-pilot that sits right next to your transactions. essentially, that's telling you is this uh is this malicious? Is this is this safe? Is this is some you're interacting with this contract for the very first time. You don't know you we have not seen any proof of historical record. It's to kind of give you the confidence to operate your transactions. And there is there's two parts to this actually. What what we've been doing so far is actually a lot around the off-chain assurance of off-chain confidence with getting a bunch of rule sets from across the industry, working with multiple service providers, including our rule

engine that's evolving as we speak as well. We call it safe shield and that's a lot of the off-chain policies. And one of the other exciting things that we're doing is the on-chain security guarantee or security on-chain enforcement of rules. We call it safe net. This has been a long time coming. For safe net actually the you you should attend the talk tomorrow from Richard who's the creator of it. It's I think it's at 11:00. But one of the things we're doing is a co-pilot safe shield will actually incorporate safe net as part of it. So you have the best of both worlds which is off-chain guarantees and on-chain enforcement to get a complete picture.

And the other very big thing that we've been launching is this security hub that that we launched. So when you have a system of safes in one place security hub will essentially give you a perspective into a score. We made it super easy for people to actually know if your setup is actually secure. You know, if you have an outdated contract, if your signers are has a private key loss that's been reported, that it's been labeled as malicious, you are using a third-party module that we don't recognize and things like that. Especially when you have a system an operating system of safes like like some of our users when they have hundreds of safes, it's very hard to keep up with your entire

security posture. Hell, it's even harder for you to delegate that to a a security professional to come in and actually review it once a quarter or once a year. So, this is going this is live today and I'm super excited to kind of like get this into the hands of user because it's it's one step closer to kind of like bringing more protection and more confidence to uh to sell for secure transacting in crypto overall. based on these as foundations, we where we're going next is to kind of complete this full assurance circle, I would say. Uh one of the things we're working on is a lot about on-chain rules on-chain policies. One of the most requested

things that a lot of people have and I'm sure a lot of people here also probably resonate with is having a a time lock when you transact, right? Like if if I'm doing a 100 million transaction, I can wait, you know. If I'm doing a billion dollar transaction, I can wait. The friction is necessary. It doesn't need to be instantaneous. It just needs to work in the way deterministic way that we we need it to work. And not only that, like we want to employ a lot more verification tools, like bring in cosigners to give you more confidence, have your own tooling system to kind of verify actually what you're signing is that gives you really a high confidence and it's pretty typical into the

best practice security workflow. And lastly, is this cycle doesn't fully complete if you cannot monitor it ultimately. You want to monitor because things are happening on our accounts when we sleep, right? That's the reality of it and you want to have monitoring place, but it doesn't really stop at monitoring as well because once you [snorts] have monitoring in place, you want to be able to employ things that can react to it. Right? You want to be able to react. You want to pull a position if you have a pool that's too toxic. You have a stable coin that's deep pegging. You want to be able to react.

And so so so basically the risk posture is not just with your account but also to your assets. Right? And that entire thing is how really we're thinking about a full workflow. So ultimately when risk changes either on your assets or your account, your system your your operating system your controls should be designed in a way that they can respond ultimately. and I will leave you with this last take. Right? Like I often think about beyond multi-sig is really what I'm thinking about future of self custody.

And it's not just that account set up and set up and forget. It's actually it keeps it needs to go continuous. And to me the future of self custody is continuous assurance. Right? And the way I really think about it is like separating responsibilities. You set up rules, express rules. You verify it, monitor, and then respond to this ever changing landscape. Ultimately, our mission is quite simple and I think that resonates with a lot of people. We want to make self custody easy and secure not as a compromise of one or the other. And that sometimes it's harder than it sounds or easier than it sounds for some people. But

this is the one thing I want to kind of like express is we we're in a era we need to really think about this entire workflow for us. And Safe Labs or Safe is really set up to kind of give that tooling and purpose and mission to kind of give users the confidence ultimately at the end of the day. So with that I leave you for the next agenda as well then. Yeah. Thank you. >> [applause] >> Thank you, Raul. Does anyone have any question? We have a time for one question.

>> Yeah, thank you very much for the presentation. So, I'm also very I use safe very often for and have also a lot of safes. So, I have one question. So, I missed something actually. So, all the data we are using in safe and other wallets, we read from RPCs and so. What are your plans to do all this data to verify this data to have trustless data? Because if I have no trustless data, then all the checks might be critical because I cannot trust that this is really collected.

>> Yeah, yeah, no, that's a great question. maybe the way we think about it is a little fragmented. I have to dissect it a bit. Uh so, how do you know that you have trustless data, right? Ultimately, one one of the design principles uh we have when we design this building our products is not to make the choice for the user, right? Like we want to be employ the user with a choice to kind of like express their needs, especially on the the spectrum of trustlessness in the architecture as well. So, today, like for example, when um very simply put, like the safe shield that I spoke about, there are two parts

to it. Uh the trust assumptions are quite different. When you use the the safe shield, which is the off-chain uh way to kind of like scan and get confidence, you are making a trust assumptions on the our infrastructure for sure. But the safe net part is actually the more trustless part and and I think there are from our lens we are seeing a lot of trade-offs. When you really go with the the the deepest trustless assumptions on the stack, there are certain UX fallbacks or UX compromises that you have to make. And we try to always find this balance by actually giving that choice to the user to express like hey, this is what we can kind of provide and

you can interact with. So for RPC data especially, we have our own indexer for example and you can run that entire stack self-hosted as well. Like you and a lot of teams do this and we maintain this quite quite openly as well. Pretty much all of safe's code, most of safe's code I would say is open and a lot of it is open source already. So yeah, like I hope that answers a bit but like this is how we kind of we kind of dissect and think about trust assumptions in the architecture in general.