Defending Multisigs from Offensive AI: Introducing onchain security markets

Transcript

[music] [music] >> Good morning. I hope everyone's well caffeinated through your usual chai or coffee. I wanted to talk about defending multisigs from offensive AI. And there's a lot of lot that has developed especially in the last few weeks as well. So I want to put into perspective. [cough] [clears throat] And also in this talk I wanted to throw in some elements that make India India. So hopefully you learn one or two things if you are unfamiliar with any of that.

So so firstly I wanted to share the you know India is a land of Bollywood and cricket, right? So in cricket for those of you that are unfamiliar the point of that game is also one of the big points of that game is to protect your stumps from being bowled out. And [snorts] one of the fundamental defensive tricks in cricket is to take your bat and go forward. The reason for that is you know this is a cricket ball. It has a little seam on it, right? When it bounces it it becomes unpredictable. It can cut through, it can swing, and it can move in a way that's maybe

you didn't anticipate. So the best defense is actually to go on the offense. So right now we're living in a world like the offensive AI is compounding at a really high and fast rate. So defensive AI security also needs to compound at the [clears throat] same rate or even faster. And it hasn't just reached that point yet. So I want to talk about how we think about all of this at Safe. And in the last few years so Safe's been around like seven, eight years now. One of the things I feel confident about establishing is like multisig secured

the key problem, right? And and getting getting your authorization and authentication through your signature to perform a transaction. However, it seems like right now, it seems like but nothing is checking what the signature actually does. So to kind of put that into perspective, I call this the three big B's now, Bybit, Bitget, and Binance. I'm sure all of you have been listening or hearing these reference points all throughout the week and we're only halfway there, right?

Like we have one more day at Devcon. One of the the the common denominators for all these incidents is no key leak was found and signatures were all valid. So what does that really tell us? So nothing really broke, but everything was signed. So there is still a gap and I call this gap the intent gap. So in order for us to really respond to it, we need some some sort of a circuit breaker. And this circuit breaker actually exists today, right? Like if you see the transaction lifecycle from like, you know, from being proposal to actually settled, the

circuit breaker in the case of Binance, for example, it existed when we were able to freeze those assets from getting into the wrong hands further. But that's really late in the game, right? Our entire [snorts] industry is built on the premise that irreversibility is is not possible, right? Or irreversibility is not possible. So we need to get the circuit breaker as early as possible into pre-execution state.

And that's that's the point of going forward in the defense. So my mental model when it comes to how we build things at safe. It's five layers. It starts with the account. And then you add a layer called policies where you can express what your account can do, cannot do, should do, and must do right? And then you have this shield. We call it safe shield internally is that this pre-transaction state where you can see what you sign. It's static checks. It's when your account is performing a transaction with the outside world and you don't know what it does, so you need to simulate it, see

the state changes, etc. And then four and five is what I want to put the emphasis on in this talk because these are the new components that safe is building after as two new on-chain products after seven years since our first on-chain product which is the multi-sig. So the number four is safe net protocol which I will cover and then the guard. [snorts] So first thing everyone knows or at least I hope everyone knows, everyone should have at least one safe in in my opinion bias aside. The layer one is the account. So you have a multi-sig account. We build products over it called safe wallet, safe mobile, safe API, and given that self-custody is at scale right now, safe

has moved over a trillion in volume and currently holds just safe wallet alone holds over 60 billion in assets. So when self-custody is at scale, it just needs a more opinionated product especially with enterprises, institutions, they are not just caring about public verifiability but also confidentiality of their coordination data. So that's why we built safe pro. So that's the layer one, the account. And then the new on-chain product that we released maybe three weeks ago is an on-chain policy engine, a very creative name.

With safe we just we're not that creative maybe when it comes to branding our products but let's call it simple. Let's keep it simple. It's the policy Uh, the policy engine is here to natively protect your account in expressing, by expressing what you can and cannot do. Something as simple as if I'm doing a $100,000 transaction, I need one extra signature from my CEO, right? That's one of the most common needs that someone would have. Or hey, I'm just spending 500 USDC to make a vendor payment. I don't need to collect four out of seven signatures. I just need one signature.

So these thresholds, dynamic thresholds, or if you have a cold safe, right? Like you just needed to do one thing, which is move from one safe to the other. It should only talk to that safe and deny everything by default because ultimately the way we look at safe is a operating system of safes, right? If you have your entire life savings in one account, it should move slow. It should be having friction. Things are not supposed to move really fast. Access to that account should be should not be that easy. So the way to achieve that is to kind of compose your policies over your safe, over native on-chain

parameters, right? With the policy engine. The best thing about this is that it actually forces it it creates on-chain enforcements. It's not just static checks. So the third layer [snorts] is what we call safe shield, right? And if you have used safe UI in the last few months, you will see a little co-pilot next to your transaction. It's always scanning your transaction state, telling you if if you have this address in your address book, what contract you're talking to, is there a threat, or even telling you that nobody ever has interacted with this contract. You're the first one because that should allow

ring some alarm bells for you, right? Maybe the whole point of that is we're able to give threat analysis. However, that's not enough. This is, this is really useful, but it's not enough because these don't enforce the checks on chain. And and that's why we built Safe Net. So Safe Net is a protocol that accesses independent security providers that we call sentinels to perform these checks when your transaction is actually going live and [snorts] it is able to react to a charter that we crafted and this basically tell you if this is secure, insecure or inconclusive. And we

built a protocol that brings consensus or a way even to kind of resolve inconclusive results through arbitration and our security council for example. But the point is even when you have a multi-sig account and also a policy engine and also your safe shield pre-transaction checks, Safe Net will catch according to the sentinels parameters and is able to enforce based on that. So how this works in principle?

Very simply put, if you have to kind of just have a very quick takeaway is you propose a transaction, sentinels will check. There are validators who are running nodes who would attest to that and the guard enforces that. So right now the design is that all sentinels must unanimously agree and say this is secure. The and that attestation is posted on chain so you can actually have public verifiability and if that happens you execute. And [snorts] when there is a split result, right? Which happens all the time also it happens more often than not and then there is no attestation, nothing executes and you can proceed at your own

risk for example. So the economics of this, the way we started doing this is we're building this protocol. How we're introducing this is that it's 40 cents per check, goes to the safe Dow, which has been around for over four years. And right now, 100% of that fees go to the Sentinels. We want to be able to control change this to even split the fee share towards the Dow and towards the safe holder community in the future. So right now the their every check has a bond. It's a bonded fee. So if for every verdict that you give for a safe transaction,

it's 2,000 times the fee, which is for example, $800. And in order to run a validator, you stake 3.5 million safe and the delegators are staking behind it. So there is a lot of entry points for for people to participate in this network to actually be become part of this security network to defend against this offensive AI threat that we've been having, especially towards crypto. So I call this or we are calling this it's short-lived on-chain security markets. So why is it a market, not a vendor? Because it's a market because it's the Sentinels are actually competing to protect you best.

And the wrong verdict on the transaction actually costs, which is the the bond. And the verdict is enforced. It's just not displayed. So it's not just UI sugar, not just UI magic. It is actually enforced. And the rules adapt as the attacks do as well. That's the charter that we have in place and it can evolve over time as well. So so where does we are in the early stages of safe net, but where what is the end game? Where do we want to like move towards, right? Like I said, like end game number one is open short-lived security markets to get a lot of participation in. The second is maybe transaction insurance. This is what we are thinking about. And the last thing is multi-account support, not just the same checks for any account in any

wallet that integrates them. Our vision is also to go beyond safe smart accounts, hopefully, and that's something we will be looking into at the in the future. [snorts] So to kind of recap some of the layers because we spoke about a lot of layers, right? If there's one big takeaway in the in how Safe's mental model works is this is this five-layer piece. So not every layer has to be perfect, right? That's part of the design that we have to take in because what if one layer compromises? Not every layer has to be perfect, but the most important thing in this design is that last layer, the very last layer, the guard is blocking, [snorts] is enforcing, and it's enforcing on chain. That is one of

the most important principles of this five-layer design. So [clears throat] how how how can you help in holding up this formation that we have against this ever-increasing threat? One, if you hold Safe, for example, stake it, vote it, [snorts] participate, or if you if you are a security provider and you are like really good at something like detecting address poisoning or shadow signers or anything else, run a sentinel or or participate by attesting through the validator.

And lastly, if you're a builder, you can integrate Safe Net checks into your apps, into your Safe smart accounts. There are 60 million, 65 million Safe accounts in the wild right now. So we're ending this presentation. So at the end, I wanted to talk about another Indian element, the Vedic, the ancient Indian philosophy speaks a lot about like we grew up with this is like the concept of cycles. You know, in in crypto, we actually don't work in calendar years, right? We work in cycles. We work in the bear bull market kind of cycles. It's kind of similar to how the Vedic philosophy also teaches.

Ultimately, every cycle brings in new customers, new pain points, new needs, and with it also new threats. So every every cycle brings its own attack vectors and with every cycle we must also reinvent ourselves to defend against these ever growing threats. So every age has to build its defense again and it's natural part of the evolution that we call that Yugas or cycles. So if every if in this entire 15 minute presentation there's one thing you want to take away is this, right? With the cricket analogy which you must see

everywhere around Mumbai, especially where right next to the Mumbai Cricket Association even is in order to sometimes in order to build the best defense you have to go in the offense and in cricket you just go to the ball. And with that I conclude this. Thank you for [snorts] listening. >> Thank you very much. So we are we are moving from just identifying the threat actions to really enforcing and stopping them, right? >> Yeah, correct correct.

>> So we have a plenty of questions from the audience. I will just select here the first one. We also read it for the online viewers. So I'm selecting for answering the first question and the question is isn't 2000 X penalty of the $0.40 a little low when it comes to downside a user might experience from malicious transaction? >> Yeah yeah, it's it's a really good question. It's something we debate quite often, but you have to understand the this is a new paradigm, right? We live in a world like every protocol is a DeFi protocol.

We're really the first one to build a security protocol. So adoption is key. We need sentinel diversity, we need checks diversity, that need security market diversity. So, penalizing things very heavily upfront is just it's it's not the best form factor for us to really have broad adoption. So, one of the important things is that safe Dow is where these configurations and things get dynamic. So, you can participate where we will evolve our learnings reflected reflect those into the protocol parameters as we learn new things. But but yes, it's it's a it's a really important question and I would

say this is a question that I tend to ask myself and in our team every month. So, you know, but I think it's a very valid question until we have a a more mature answer there for sure. >> Okay, thank you very much. The next question will be if AI can identify malicious activity, how do we ensure its findings are accurate before they are recorded or acted upon on chain? >> AI can identify malicious activity. How do we ensure its findings are accurate before they are recorded and acted upon on chain?

Okay, I I get it. So, right now it's the job of the sentinels to apply their rules to essentially act on the charter to create a security verdict, you know, malicious, benign, inconclusive, etc. So, they may be using AI and we should probably use. But the point is that not everyone's using the same AI. We need like diversity. The point is you can challenge this, which is actually related to question number two. So, I'll address this both.

Ultimately, when sentinels disagree, it goes into an arbitration [snorts] and and our security council right now like views it if they can actually take a position, they'll take a position. If it's not, it's inconclusive. It's still a better model than what we have today. But ultimately, we are I I'll tell you this like almost everyone is using AI right now for their defensive security and almost no one has figured out a silver bullet on how to actually patch things reliably but we are getting there but the point is that we have we have a network we have a protocol that actually can respond plugin to the

advancing AI parameters and tech that is also helping us defend so when that happens the sentinels can actually ensure their findings are actually accurate but they are taking a risk as well by putting their essentially exposing their bonded fee for a wrong verdict that's baked into the protocol dynamics. >> [snorts] >> So so they are being somehow slashed when they are giving wrong answers. >> Exactly slashing has not been implemented yet again we want to get adoption get our foundations fundamentals right before we scale this out into more slashing dynamics as well.

[snorts] What are validators attesting to ultimately they are attesting the sentinels record there are like safe labs runs a validator and we have about like three other validators where we are running these ultimately you have a public on-chain attestation of when a security like security scan or a transaction a safe transaction is posted and the sentinels checks and the parameters they're all recorded publicly verifiable and that is essentially also propagated to all the validators

similarly the sentinels themselves are diverse in how they perform a check the validators form the consensus and how actually they they record this so it's a very similar design to how general Ethereum also. >> Okay thank you very >> much for the explanation. Thank you very much for your time. And please, everyone, >> [music]