So, we'll talk about proactive security infrastructure for DeFi. In other words, how do we get people with big money to trust their capital with our systems? So very quickly, we'll talk about the regressions of centralization of the D5 security space that we see that we're creating, and then a little bit more about how we can create a framework around that for better risk disclosure. So the first thing to understand is that traditional finance, security is not an issue, right? Uh, you have a few meetings, at the end of the day you can always go back to the Excel spreadsheet and change it, right?
But in cryptocurrency, we have instant settlements, so in this environment, uh, security here is more like a space, because a mistake would be really devastating, right? The same thing that excites investors, namely instant calculations for capital efficiency, also scares them, because now mistakes are unfixable. But what is evil, right? How do we define evil? Hacking is very simple - it's when business logic and protocol logic diverge, right?
When the expected effect and what actually happens are not the same , because after all, what is USDC? Right? We're talking billions of dollars in USDC, trillions of dollars in the future in real W assets. That's all it is. It's just one line of code that tells who owns billions of dollars.
If I can somehow change that one line of code to make me the owner of a billion dollars, I own it. Right? So, we are in an industry where software is an asset, and the asset is software. And because calculations happen so quickly, the industry is responding with several security measures. We do monitoring, which as we have seen, is reactive, right?
He does something after the fact. We use co-signers, where we essentially say, “ we essentially say, “ Okay, I don’t trust people to send transactions. I will send them to an intermediary to verify these transactions before they hit the network.” But this introduces centralization. And, of course, the problems are now being exacerbated by the spread of the virus.
An isolated system failure on one side can turn into a market event. So, right now the development process looks something like this. Developers write and test their smart test their smart contracts. Then they conduct an audit. After the audit, they are ready for deployment.
They monitor or co-sign, and or co-sign, and , you know, when things go wrong, they publish a report. There are two new things emerging in the industry that I think are worth looking at. One of them is a formal inspection. This is an old idea that has become new with the advent of artificial intelligence. Formal verification is now practical, and I think that will be something that , um, all industry players should consider.
And the other is ensuring compliance with the rules during implementation, and that's what we do. We ensure that properties are respected during transaction execution transaction execution . The problem with audits and formal verification is that they answer the question: is my smart my smart contract correct? Right? This is the fundamental question they are answering.
But ensuring compliance with the rules during implementation raises another issue. Is the world my contract depends on still true? Is it still correct? Formal verification and audit cannot consider dissemination. And the spread is important because that's partly why the Kelp Dow incident became a systemic risk.
Kelp bridge means in bridge bridge means in bridge . Hmm, it works by locking the token on one chain and then minting IUS on other chains. Right? So there was a smart contract, a bridge with a lot of its tokens, and then the hiker was able to get those tokens from the bridge contract, and then he went and borrowed them, right? And not only did they do that, they repeated the same attack on Arbitrum, right?
They took other tokens, linked them to Arbitum, and then repeated. That's right, they didn't participate in this hack. But in the end, the hacker laundered about $230 million through Thchain. We had some of their, uh, hacked funds stuck on Arbitum, and Arbitum then performed a, uh, bailout, and ultimately you had a hacker with $300 million in bad debt. And the question now is who pays, because someone pays.
So the spread of infection is important. And in the midst of this security carnage, what do the protocols do? They have very strict restrictions. They reduce their ability to earn money because they are very afraid of how much money is coming in and going out. And then they set alerts and hope that these " hope that these " kill sets" work.
They can renew contracts as failed. They're going back to centralization, aren't they? Because it's scary for a developer in this field. It's scary what the regulator will see at the end of the day the regulator will see at the end of the day , isn't it? What do regulators see?
Because they see it and take it into account. They see small groups making urgent discretionary decisions with arbitration, as in the case of Arbitum, but it will be very difficult for Arbitum to claim decentralization in the future. They see a slow response under certain conditions with Kelp. Even in a good case where we have rapid incident response, as in the case of Balancer, even then it is not enough; 100 million dropped out. And then we have accountability issues about who should stop who, like in the case of Circle and Drift, and I want to double-click on that because freezing is a very primitive solution, right?
On the one hand, Circle freezes the network after a court ruling, and then they freeze the assets of users who had nothing to do with the court ruling, or they do n't, and then they get sued for failure to intervene. Right? Circle loses on both sides loses on both sides . Obviously, freezing or relying on freezing is not the best solution. So best solution.
So , obviously, we are not advocating for easing restrictions or easing controls. But what we're saying here, our thesis is that we need to have visible, automatic, and preventive controls. We need to eliminate the human factor. So how do we do it? So, we are creating a system that allows the network to update itself.
This is an integrated switch and evidence layer that works at the network level. And when we say network layer, we mean a block constructor, validator, or sequencer. And very quickly, this allows applications to go to our smart to our smart contracts in the on-chain registry and configure policies, right? Additional verification rules. And then to the validator, the blog builder, the sequencer, it adds to these rules and says, "Okay, every time a transaction is added to a blog that I create, if that transaction violates any of these policies, I'm going to delete it."
This provides on- chain functionality, i.e., you know, table stakes for exchanges like Arbitum, but in a way that is compatible with conventional systems and doesn't introduce new vectors of centralization. The system attributes are very simple. Firstly, we have a transparent system we have a transparent system because the rules are known in advance.
It is auditable, and every decision immediately creates records. When you add a policy, you change the policy, you change the risk parameters. There is a record that you can use and will likely need in the future for compliance purposes. And finally, it is based on rules. The system responds based on predefined rules that you set, and users know how your system will respond .
There is no one on the island. What are some unacceptable economic outcomes you can identify in such a system? Because while the attack vectors are infinite, the undesirable state of your system is not. This is very well known. Maybe well known.
Maybe one withdrawal, uh , limits. You want to make sure the borrowing is correct. You are granting the correct permissions for accounting, right? You don't want your contract to renew or perform some strange and very destructive actions while you're sleeping or even minting, right? Imagine a future where you have tokenized assets, tokenized stocks, billions of Apple shares trading on the unis swap, and suddenly someone, that is, trillions of them that is, trillions of them , goes to the exchange and exchanges them, right?
And then you have hundreds of investors holding these tokenized shares that have no value whatsoever, right? As a regulator, how can you have orderly markets in such a case? What are you doing? Who pays again? So, policies, uh, we allow protocols to define very deterministic and specific rules, like invariance to other risk signals, circuit breakers, anomaly detection, right?
This allows protocols to compose both deterministic and more probabilistic signals into whatever policies make sense to them. They simply define new limitations. Again , this is an extremely boring technology, known on traditional exchanges for decades, that we are bringing to the blockchain. And this is not a theoretical system. She is actually in production.
We have integrated with Lineia. Hmm, we'll talk later. You should go. Hmm, and we actually stopped the leakage of almost $50,000 from everyday users, right? Over 4,000 transactions were canceled because they would otherwise have exhausted these users.
It works. Good. So how do we take security rules and turn them into a framework that investors can use to make better allocation decisions? As we have seen, the security landscape is evolving security landscape is evolving and attacks are becoming more professionalized professionalized , right? On the one hand, state actors.
You have invisible counterparty risk; although the industry has evolved and we can model and we have great dashboards to assess the financial risk of your investments, a lending protocol has been developed, this does not address counterparty risk. It's very opaque: who controls what, what are the interdependencies? On the other hand, this situation creates a very inefficient market because we are going back to discretionary control, and we have markets with discretionary control, right? It's called the new New York Stock Exchange, and it's working great. It doesn't matter whether it should be reproduced as such.
We now have a system where we see concentration of power, conflicting records, investor uncertainty; it is very difficult for people to invest money in these systems. And that's exactly what we're seeing: many institutional investors are backing off after the Kelp incident , pulling capital out of the system, returning to treasuries. So with a preventive system, where you define these policies, we have three parts. First, you define the risk in advance. Okay, financial security.
Then you provide the risk, right? So you're saying that when the system goes outside this risk curve, I won't let it go. And finally, you create records when that risk is identified, regardless of whether policies are created, changed, or violated. We believe this is not an exhaustive list, but this is how we see the development of a new type of counterparty structure. First we need to know the scope and coverage of these policies, what functions of the contract assets or transactions are covered, and we can do this very clearly.
Secondly, when, uh, what are the limits of the system, right? Third the system, right? Third , who can change, disable, or delete these policies? Fourth, operational integrity. How does the team manage multiG?
How do they deploy? How do they perform DevOps? How do they renew their contracts? And now there are cross-industry efforts with seal frameworks aimed at harmonizing the different standards that security researchers have to create a kind of sock two for the industry, and it's crucial that we do that because if we don't self-regulate, we're going to be regulated harshly and unilaterally. The fifth is the reaction when the policy works.
What is happening? What is the system's reaction, right? Do you just stop letting the system take on more risk? Are you completely suspending the system suspending the system ? How do you react?
And ? How do you react? And sixth, is the deployed code significantly different from what was there during the audit? What is a delta? Is this something investors should know or not?
So why are we here, and to show that this we here, and to show that this shouldn't be the case. We don't need to go back to centralization just because we can't create secure systems that work instantly without it. Um, it's possible to offer stronger investor protection and decentralization at the same time. Thank you very much for your time.
Automatic transcript — names and jargon may be misspelled.