Securing Institutional DeFi Without Centralizing It

Transcript

[applause] >> So, we're going to talk about preventative safety infrastructure for DeFi. In other words, how do we make people with a lot of money trust our capital with our systems? So, very quickly we're going to talk about the DeFi security space. Centralization regressions we're seeing. What are we building? And then a bit more about how we can create a framework around that for better risk disclosures. So, the first thing to understand is that traditional finance security is not an issue, right? Uh you do a couple of meetings. At the end of the day, you can always go back to the Excel sheet and you can change it,

right? But in crypto, we have instant settlement. So, in that environment, uh security here is more like in aerospace because an error will be really destructive, right? The same thing that excites investors, which is instant settlement for capital efficiency, is also what scares them because now mistakes are irrevocable. But what is a hack, right? What How do we define a hack? A hack very simply is when the business logic and the protocol logic diverge, right? When the intended effect and what actually happens is not the same.

Because at the end of the day, what is a USDC, right? We say billions of dollars in USDC, trillions of dollars in the future, in the real world assets. This is all it is. It's just a single line of code that says who owns billions of dollars. If I somehow am able to change that single line of code to put me as the owner of a billion dollars, I own it, right? So, we are in an industry where the software is the asset and the asset is the software.

And because the settlement is so fast, the industry is responding with a couple of security measures. We're doing monitoring, which we've seen is reactive, right? It does something after the fact. We do co-signers where we basically say, "Okay, I don't trust people to send transactions. I'll send it to an intermediary party to test these transactions before they go to the network." But this introduces uh centralization. And of course, the issues now compound even further with contagion. An isolated system failure on one side can spiral into a market event.

So, right now, the flow of development looks a bit like that. Developers will write and test their smart contracts, then they will go and audit. After the audit, they're ready to deploy. They do monitoring or co-signers, and if and you know, once things go south, they'll pause the protocol. There's two new things that are coming up in the industry, and I think it's worth seeing them. One is formal verification. It's an old idea made new with the advent of AI. Formal verification now is practical, and I think will be um something that all the industry players should should note. And the other is runtime enforcement. And this is what we do.

We enforce properties during the execution of transactions. The issue with audits and formal verification is that they answer the question, "Is my smart contract correct?" Right? That's the fundamental question they answer. But the runtime enforcement asks a different question. Is the world in which my contract depends still true? Still correct? Formal verification and audits can't reason about contagion. And contagion is important because it's partly why the Kiln DAO incident became into a systemic risk.

Killed bridge funds in a bridge. It works by locking the token on one chain and then minting IOU's in other chains right? So, there was a smart contract bridge with a lot of their tokens. And then a hacker was able to get these tokens out of the bridge contract. And then went to Ave and lent them. Right? And not only they did that, but they repeated the same attack on Arbitrum. Right? They took the other tokens, they bridged them to to Arbitrum and then they repeat.

Ave right? Had no part in this hack. But at the end we had a hacker laundering about $230 million through ThorChain. We had some of the the hacked funds being stuck on Arbitrum and Arbitrum then performing the the uh rescue. And at the end, you had Ave with $300 million of bad debt. And the question now is who pays? Because someone has.

So, contagion is important. And in the midst of this slaughter of security, what do the protocols do? They have very aggressive caps. They kneecap their uh their ability to make money because they're very afraid of how many funds are coming in and out. And then they set up alerts and hope the kill switch will work. They they may upgrade the contracts as failures. They regress into centralization, right? Because it's scary. As a developer in this space, it is scary. What do the regulators see at the end of the day, right? What do do the regulators see because they are seeing and they are taking notes.

They are seeing small groups making urgent discretionary decisions with like with Arbitrum DAO. It will be very hard for Arbitrum to make claims of decentralization in the future. This is slow response under uncertainty with help. Even in the good case where we have instant response that is fast, as we did with Balancer, even then it's not enough. A hundred million were out. And then we have accountability issues around who should stop whom. Like with Circle and Drift.

And I want to double-click on that. Because freezing is a very primitive solution. Right? On one side you have Circle freezing after a court order. And then they're freezing assets of users that had nothing to do with the the court order. Or they don't do that, and then they get they get a lawsuit for not interfering. Right? Circle loses in both sides. It's obviously that freezing or depending on freezing is not a good solution. So obviously we're not advocating for weaker constraints or weaker controls, but what we say here, what our thesis is is that we should have controls that are visible,

automatic, and preventative. We need to remove the human element. So how do we do that? So we build a system um that allows a network to upgrade. Uh it's an integrated circuit breaker and evidence layer that is operated at the network level. And when we say network level, we mean the block builder, the validator, or the sequencer. And very quickly it allows an applications to go to our smart contracts through an on-chain registry and set up policies, right? Extra validation rules.

And then a sidecar to the validator, the block builder, the sequencer picks up these rules and says, "Okay, whenever a transaction is added to a block that I'm building, if this transaction violate any of these policies, I will drop it. This gives the chain functionality that is, you know, uh table stakes for up chains just like Arbitrum, but in a way that's backwards compatible and doesn't introduce new centralization vectors. The attributes of the system are very simple. One, we have a transparent system because the rules are known in advance.

It's auditable, right? Every decision create records. When you add the policy, you change the policy, you change the risk parameters, there is a record that you can use. Uh and will probably be required in the future by compliance. And finally, it's rules-based. The system reacts based on predefined rules you set. And the users know how your rule system will react. There is no human in the element. What are a couple of unacceptable economic outcomes you can define in such a system?

Because while the attack vectors are infinite, the undesirable state of your system are is not. It's very well known. Maybe one withdrawals limits. You want to make sure that borrowing is correct. You do your accounting correct. Permissions, right? You don't want your contract to be upgraded or to do some weird and very destructive action while you're asleep. Or even minting, right? Imagine in the future where you have tokenized assets, tokenized stocks, billions of Apple stocks trading in Uniswap, and suddenly someone mints trillions of them. And they go to the exchange and they exchange them, right?

And then you have hundreds of investors now that are holding these tokenized stock that has no has no value, right? As a regulator, how can you have orderly markets in such event? What do you do? Who pays? Again, So, the policies um Um, we enable protocols to define from very deterministic and concrete rules like invariants to other risk signals, circuit breakers, anomaly detection, right? It allows the protocols to compose both deterministic and more probabilistic signals into whatever policies make sense to them. They're just defining new constraints. Again, this is extremely

boring technology known in a traditional exchanges for tens of years that we're bringing to blockchains. And this is not a theoretical system. It's actually in production. We've integrated with Linea. Um, they have a talk later. You should go. Um, and we have actually stopped uh close to now 50,000s of dollars to be drained from everyday users, right? Over 4,000 transactions have been dropped because otherwise they would drain these users.

It works. Okay. So now, how do we take the security rules and make them into a framework? And the framework that investors can use to make better allocation decisions. As we have seen, security landscape is evolving and the attacks are increasingly professionalized. Right? State actors. On one side, you have an unseen counterparty risk. While the industry has evolved and we can model and we have great dashboards for the financial risk of your investment, about a lending protocol, that's not the case for counterparty risk.

It's very opaque. Who controls what? What are the interdependencies? On the other side, this situation creates a very inefficient market because we regress to discretionary controls. And we have markets with its discretionary controls, right? It's called the New York New York Stock Exchange and it works great. Doesn't matter to recreate it. As I said, now we have a system where we have we're seeing concentrating power, inconsistent records, investor uncertainty.

It's very hard for people to put money into the systems. And that what we're seeing a lot of institutional investors after the killed down incident pulling back, removing capital from the system, get going back to treasuries. So, with a preventative system where you define these policies, we have three parts. First, you define the risk in advance. Okay? Financial security. Then, you enforce the risk, right? So, you know you say whenever the system goes outside of the of this risk curve, I will not allow it to go.

And finally, you produce records when this risk is defined, when are the policies created, modified, or broken. Very quickly, we think uh this is not an exhaustive list, but this is how we're seeing a new type of counterparty um framework to evolve. First, we need to know the scope and coverage of these policies. Which contract, assets, functions, or transactions are covered? And we can do that very explicitly. Second of all, when uh what is the boundaries of the system, right?

Third of all, who can modify, disable, or remove these policies? Fourth, operational integrity. How does the team do multi-sig management? How do they do deployment? How do they do the devops? How do they upgrade their contracts? And there is now a a cross-industry effort with sealed frameworks in in in in making an effort to harmonize the different standards security researchers have in creating a sort of SOC 2 for for industry. And it's vital that we do it, because if we don't self-regulate, we will be regulated violently and unilaterally.

Five, incident response. When the policy is triggered, what happens? What is the response of the system? Right? Do you just stop allowing the system to take more risk? Do you pause the system in total? How do you react? And six, is the code that is deployed substantially different from when it was audited. What is the delta? Is it something that investors should know or not? So, while we we are here and is to showcase that it doesn't have to be this phase. We don't need to regress into centralization just because we can't build secure

systems that settle instantly with audit. Uh, it is possible to offer stronger investor protections and decentralization at the same time. Thank you so much for your time. >> [applause]