Legitimate Overrides in Decentralized Protocols

Transcript

Hello everybody. Look at this as a key card. Just imagine this key card. It's an ATM card, but imagine this is a key card anyway. So, this is an admin key. Many protocols have something like this. Somebody is in charge who can control maybe like a god mode on of the protocol, getting into safety state, whatever. Most protocols have this, and some people think that protocol should not have it. This talk is about things that are already in protocols that we know today.

Chain level freezes, protocol pauses, model parameter changes, and today we are going to discuss that as legitimate overrides. I'm going to keep this here just in case we come back to it. Oh, how do I go back? With the With the green button. Great. Okay, so in crisis mode, most The paradox is that in crisis mode, most protocols or communities actually want the protocol the protocol team to intervene. Say there's a hack for instance, we see the community, you know, trying to get um some kind of intervention. Let's stop this from

happening. Let's interrupt the hack, you know. Let's stop Let's kind of blacklist this bad actor. But when there's no crisis, that becomes a problem. Why is there any capability to blacklist somebody from using this protocol? Or why is there any capability to your USDC or your USDT to blacklist your wallet from actually transferring tokens that are legitimately owned? So, we decided to go back in time and assess over 705 cases of hacks from 2016 to 2026

January. And we assess them and we found some very interesting, you know, very interesting results from the data. 1.33 parallel exponent. What does that mean? That means that when there's a hack, for instance, in the protocol, only or mostly heavy-tailed events have the capability to completely change whatever security measure any protocol has been, you know, been able to protect themselves over the years. Everything is heavy-tailed.

So, I want us I want every one of you here to leave here after this talk with three things. First of all, I want you to be able to leave here with the knowledge that intervention mechanism is is is a design state is a design space. So, it is basically an engineering problem you can actually solve for, not just ideology. The second problem is I want you to be able to solve I want you to be able to differentiate between bounded responses and just blunt responses.

And then the third thing I want you to leave here with is understanding or being able to define what is the right intervention for the specific kind of crisis. So, before we go further, we should try and understand what is the history of intervention, how the space for intervention in blockchain regime evolved. We decided to make this into four main eras. The first era is mostly governance. Well, let me just mention that the first intervention was actually on Bitcoin, not on Ethereum.

We had Satoshi actually, you know, fixed a bug on Bitcoin back in 2010, but we not go back there because that was long ago. So, we just going to start from the first hard fork that happened on Ethereum 2016. Then, there was also a case of V chain where there was a hack. The community decided to implement some kind of blacklist for the hacker. So, that means the first era had any interventions where they were just, you know, ad-hoc responses. Slowly, the system, you know, metamorphosed or kind of evolved into more admin keys.

Just like this guy right here. So, every system have some kind of built-in admin key. And then the system decided to evolve further and have more systematic contagious or whatever reactive kind of governance. We're talking about the Terra FTX situations, so, you know, Terra blows up. Uncle is already trying to do some kind of governance decision. Let's fix this. Let's fix that. That was the first time we had, you know, a major ecosystem-wide level kind of intervention discussion because everybody was, in fact, everybody was affected.

But, by the time we get to 2014, 2024, 2026, we now have more defined engineering system institutionalized emergency kind of interventions. So, that is This is just example of hack situations. Not just hacks, but every form of intervention between era one and two. You see, they are actually quite They are They are quite a few over there. Just a few samples from about about 40 cases.

So, we see era one ad-hoc forks starting from Ethereum. Then, V chain, obviously. But, by the time we get to era two, God mode, admin keys. By the time we get to admin era three, reactive governance. So, we see adult governance decisions all the way to core finance where there are now sub-DAOs and security council. And then, the IDEX also have their, you know, of sub-DAO. By the time we get to era four, things are very much institutionalized, properly defined.

And from Radiant Capital Exploit DAO, a more defined intervention system all the way to, you know, more recently USDT freeze by its team. And the most recent one, which is Linea blockchain adopting the credibility layer. Integrating Fileless Credibility Layer. Now, remember the word credibility layer. I'll come back to that. So, this is how it looks. The 40 cases that we just sampled from the 705.

So, between era one to era four, we see that there is a lot of controlled intervention from signers at signer set, mostly protocol teams, mostly admin keys. By the time we get to, you know, we look at how much intervention from delegated body that is security councils, emergency sub-DAOs. And then, governance level interventions. We see that over a billion, about two billion have already been intervened and controlled by, you know, the smaller signers at. And then, delegated body, about 800 million.

And then, governance just about 300. So, what is the problem? The problem from all of this is that the super hacks can completely destabilize every security measures you've, you know, you've been able to properly implement over years of success. One, just one day all of a sudden, we see that Step Finance is no longer, you know, no more. They've been around for years. They've been successful for a very long time.

Just one day, we see that Reserve lose a lot of money and all of a sudden, no more trust in the system. Just one day, somebody lose, you know, made a swap of about 50 million and got solely about 20 killed or about on Ave and the system is already, you know, being questioned. Even though who cares about who is to be faulted. We need to solve for this. And how do we solve for it? We ask the question, what is the scope we want to solve for?

Who has the power or the authority to be able to intervene? And what are the safeguards to bound that power so that it is not abused? This is the scope we can think about. We can think about it on the network level, on the asset level, on the protocol level, the module level, or the account level scope. If you're talking about network, just an example, we have BNB Chain. Complete shutdown of the network in 2022 to to save 570 million because a hacker was already trying to drain that.

We see an asset level, we've seen this a lot of time, USDT. Yeah, blacklisted accounts cannot make transactions. Or USDC. Or oh, we also see that as well on all financial. Justice on kind actually make transactions anyway. About 0.7 million was locked off his account. We see that as well with um protocol level as well. Balancer being stalked, liquid kill switch. Another example, compound.

And then account level, obviously, running at a car. So, this is how it looks when you assess it over our framework. You see that the network level still have the most significant intervention cases followed by the asset, followed by the protocol, then account, and then model. Model scope interventions are usually protocol level because it's just like a model. Maybe let's stop the liquidation system from, you know, making some liquidations and whatnot.

But still, we see a lot lot of intervention from sign asset controlled. And more increasing delegates, you know, delegated body action. And then less intervention from governance process. So, what are we really solving for? We're solving for containment speed. When there's a hack or there's a failure in the system, how fast are we able to intervene? How fast are we able to stop this thing from destroying the system of trust we built?

What is the blast radius we should assess this intervention system on? Do we want it to be all of this network? Or do we want it to be all of just the protocol? Or just on the account that is, you know, that is the culprit? What is the legitimacy cost if we do this? How much of the trust do we still retain in the system? And overall, what are we really worrying about? Is it a risk versus safety problem or a risk versus risk problem?

We want to always reduce the number of cost. If there's a system like an admin key in the system, if there's a if there's an admin key in the system or there's none, we want to be able to go from high expected cost to low expected cost. And we can only do that by actually architecting the right intervention mechanism in the system. Defining the um the right if the right response to the events and also modeling the trade-off.

What did we find? We found that after assessing 705 cases, we found that governance actually excels when it comes to deliberation and network level recoveries. But it is not alone because governance is also combined with some other um system of interventions. It could be negotiation like the case of Euler Finance. It could also be um it could be it is usually often negotiation because they are often always social recoveries.

Delegation is a sweet spot. When there's a delegated when there's a delegated body that is a kind of Security Council, then we know that there's up to success level of about 48% with with 60 to 90% 60 to 90 minutes in speed of containment. Then the signers had have the lowest volume but highest success the signers had have the highest volume but um lowest lowest success rate.

So, what is the sentiment for all of this? We are saying that the sentiment could have could always be defined as either positive or negative. Just depending on the procedure. One the same mechanism could be interpreted as positive by the community or interpreted as negative by the community, just depending on how much they are involved in it. So we define the tooling.

And we define the principles. Make sure that the system is precise. And also define the stack. Prevention, bounded response, and tooling. So, when we have this, we When we have this, we have clarity that there's a prevention There's a prevention in built in the system. There's a bounded response. And there's a right tool to assess for or measuring the system. Then, enhancing the credibility with more um in-depth defense.

So, what does this mean? This means that we have to define the defense system at every level so that the so that the responses are not discretionary. Instead, we are defining them even beforehand. It could be some pre-execution assertions or defense in depth. In order to make sure that when there's an incident, the decisions that are being carried out already predefined. There are actually three main schools of this in the market right now.

We see some of the intervention system on the API level, RPC. They are very easy to integrate. An example is Hypernative. Everybody know them. Um in block level enforcement, an example is back to the credible layer, just like the file act system. What they do is they integrate their own system by defining invariants in the protocol at the network level. So, basically, the protocol cannot do X or if X is being executed in the protocol, sequence has stopped it.

Now, the more block the more in-depth this integration requires, the more difficult it is the more difficult it is to integrate. So, why should anybody even do this? Why should anybody even define um this system in their stock? It's actually safer to do nothing. Why? Because when you do nothing, you don't leave any signature. You don't have any risks that your career will be in jeopardy. You don't have any worry that, you know, you could get sued by anybody.

But, on the other hand, doing nothing actually destroys the system. Because when something happens, you still lose or the system loses trust. Yes, you protect yourself, but your protocol or your network loses credibility. This is what the scope and authority of the framework looks like. Is there anybody here who can just mention one memorable hack? Just one hack or anything at all that you remember.

Balancer hack, perfect. Thank you very much. Where do you think Balancer of Balancer hack falls in here? Okay, yeah, but like we do know that Balancer is a protocol, so he's here, right? So, it's somewhere around here. So, we also know that when Balancer was happening um we also know that Hypernative actually helped them save one of their pools. So, quality delegated body because Hypernative is not, you know, was delegated to do that.

So, that means this is where we put Hypernative action. So, when you have a protocol or you have a network, whatever, this is this is just a simple way to think about what happens should something go wrong. Do we want to intervene on the network level and give it to an admin key? Then let's think about things here. Let think about this cell. Do we want to intervene on the account level, say a hacker's account, and we want to use a governance process?

Then let's think about things happening here. Well, so how do we make that action we take legitimate? The only way for us to do that is first, we predefine the actions we will take when it happens or if it happens. We don't wait for it to happen before we begin to deliberate on what to do. So, we can choose optimistic freeze. Something is going wrong. We know that this is not this is dissuading from, you know, the business logic of our protocol.

We are going to freeze that and figure out what it is quickly. And in order for us to do that, we are going to also make sure that the actions we can take are predefined, there's a registry and also we're going to make sure that it is not retroactive. Gnosis is already doing that. More just after the balance sign incident like you mentioned Gnosis is already discussing a framework right now where they're trying to move from an adult response to a more clear emergency framework.

It's going to create a system of record. Discuss all of the trade-off and also have clarity on what to do or what they what the Gnosis DAO could do when there's a you know there's a kind of hack that impact Gnosis. This is very good because it sets the path or an example for other networks to you know consider. So, what is the next step you're going to take from all of this? We have been able to do this research and we have also make all of this data open source so that you could you know go check it out read the paper but you should value the contribution

from all of this because now you have a framework to think about incidents before they happen. You have a way to plan for them because we've provided a taxonomy for it. We have a clear framework for you to actually plan, prepare and execute and respond non-retroactively. Choose the right so choose the make a choice for the right cell that works for you. Publish your constraints so the community knows and see everything that's going on.

Build credibility and legitimacy. Measure the sentiment. Decide prevention versus intervention. If there's going to be intervention, what are the things you have to do? Define the instrument and the audit of all of those actions should you take any of them. And very welcome to explore the framework at live research.org. Any questions?

Hello. Thanks for the presentation. It was very lovely. And thanks for sharing the data. Um you mentioned Gnosis. I'm still waiting for my money back after they forked. They still have it on uh Genesis contract and they still haven't given me my money back. So, they are the guys that owe me money now, right? They forked, so I can go to Gnosis company and tell them, "Hey guys, you have my money. I want it back." That's the issue if you fork, right? Uh you are now responsible for handling the money. And why didn't you do it earlier, right? So, philosophically speaking, if I never add a pause, I cannot do anything wrong. If I add a pause, suddenly I'm responsible for any hack.

Right? So, you can never be the best way for me game theoretic is not to do anything, right? Maybe that's more of a philosophical question. Yes. Um that's very good. I think that would take us back to this. When you do nothing, you're obviously safer, right? You know, you can't blame anybody. And nobody is get Nobody is getting sued. But, the system is not safe. My reputation is safe as a carrier, you know, just a individual in the system. I don't I don't get to lose anything. I don't get into trouble. But, the system itself, you're asking other people to put their money in the system.

Is it safe? Is it trust? That is the problem. So, we are trying to do this or we'll build this framework in order for every decision before it happens to be properly defined and have the community impute into it and build that legitimacy that is needed. So, even if there's going to be a fork like you said, then the community knows the system or the process is involved after the fork happens. Should that even be a consideration? Now, entire plan for all of these intervention systems is to make sure that we are as precise as possible.

And when I mean precise, prevention is the first is is no is the first step of that precision. Then, a bounded response means that it is not just a blunt fork, right? It's actually bounded in the sense that it is clear what level of response it can be. And then, tooling is part of the stack as well. I Yeah, thanks as well. I have a question to the slide previously where you said, "Okay, this the multi-sig signers, they have the highest volume but lowest success rate." Okay. And the governance actually the highest success rate.

Uh from from the data that you saw, I would immediately guess Could Could it be related that governance decisions are typically we hold the network we we throw the bomb, right? We we we we roll back. This is multi-sig signers. I mean, they they can only do so much. Is Is there something to that in in the data or is that really uh independent? >> Yeah, that's a very good observation. Um so, the initial paper um we had a very incredible um reviewer who gave very, you know, valuable feedback on that aspect of things. So, yes, one of the reason why governance have the lowest volume, as you can see there, only just 11% is because it's usually like the last recourse, right? It's a nuclear option like you said. You know, like just like

a fork situation, you know, rose box, you know, whatever it is that's happened. But, we also found that, um, it doesn't just work on its own, basically, and it's not really ideal. Because, um, for every time you have to make that kind of decision, it is like throwing a nuclear bomb into a, you know, a problem that you could probably solve with a machine gun. So, so, you want to define, um, you want to make it as precise as possible. So, if it is an attack if it's an account that you can actually, you know, you know, pause or whatever, you you, um, intervene in a more precise way.

And, um, also, one of the just like you mentioned, one of the reasons for the success rate as well for signers is because that's where everybody starts out. Every team actually starts there. And then, as it matures, just like the system or the ecosystem itself, it moves to delegation. So, delegation is a sweet spot. Any other questions? Okay, then. Thank you so much, Carol.

Thanks for your talk. And we have, uh, the last talk for today from Mark Balandies to incentivize or not, uh, where we'd like to just share our observation, um, on this day and the situation collaboration between practitioners and research.