Hello everyone. So, I want to start this presentation with an example. A few months ago, um, there was a protocol team that was doing something that could be considered pretty standard. Hmm, it was a routine update to their protocol and no one expected anything to go wrong. It was a classic, classic Tuesday.
The test suites passed successfully, the contract audit went well. The management was successful, the time blocking was also good. So all the systems deployed the systems deployed , deployed, and continued their work. But something happened. As soon as the deployment hit the main network, something strange started happening.
The asset, which was supposed to be valued at $2,200, hmm, immediately showed a dollar. This set off a horrific chain of events. The bots picked up on it immediately. Cascading liquidations took effect, and the protocol within four minutes, ahem, ended up with almost 2 million in bad debt. But the worst part is that the problem was n't caused by the smart contract.
The smart contracts behaved exactly as they were supposed to, exactly as intended. Um, all the tests didn't show anything that could be causing the problem. So what happened here? Let's move away. As Kartik mentioned, my name is Andre.
I'm the co-founder and CEO of Tenderly, and I've spent the last eight years building a modeling layer that some of the best teams in the industry have used to stay secure on the blockchain and build the best versions of their products. I want to talk about one often underestimated aspect of launching a blockchain product that is more important now than ever if we want to, if we want to get to the next level of adoption. So, looking back at our example, why didn't any of the checks raise any red flags and stop the process completely? This seems like a very glaring mistake. Um, that's what had to be decided.
But the reality is that often most of our energy, most of our systems, most of our practices are focused on moving smart smart contract training from just an idea to something concrete, something that gets launched, and something that brings everyone together. Now this is exactly the place where you should pay your attention from the very beginning. Um, this is a serious milestone. Nothing can exist without this, uh, this fundamental step, and we need to make sure that all the audits, all the tests, all the checks are passed, uh the checks are passed, uh , before we, uh, start launching. But we often get too fixated on this.
It's important to do everything right, but that's only half the story. At some point you launch, you click on mainet, and the build phase is complete. But the work of operating it and ensuring that it continues to run smoothly and continues to, uh, receive the updates and attention that it deserves never stops. So how did we end up in this situation where we spent the last 10 years, uh, looking at how we get through this assembly phase? Often losing sight of the important part of this protocol working in production with dependencies in the real state and all that world.
There's a saying I like, uh, that paints a little clearer picture. Uh, a map is not a territory. It's a sociological quote, and it essentially says that if you look at a city and a map of a particular city, it's a clean, concise documented tool. Map on paper. She is very accurate.
It is very proportional, and it becomes very accurate, that is, reflecting the city that it is trying to represent. But that's not the whole story. If your job is to move around this city and live with it every day, and this is an area every day, and this is an area ... So, if you add traffic, congestion, construction, population density to the map, the city is much more than just a map. The area in which it is located is as important and vital as knowledge of the layout of the area.
And I think cryptocurrency and blockchain are much more similar to that than you might initially think. We spend a lot of time defining these smart contracts, making sure they are fully vetted, fully tested, as accurate as possible, so that they can capture the essence of what we are trying to achieve in the blockchain. But that's only half the equation. When we start, uh, when we deploy it on the mainnet, uh, it starts to take on a life of its own. All the dependencies, all the assets, all the user flows, uh, that go through this, uh, contract, it's a life of its own, and it's completely different from what we originally, uh, what we originally expected.
So in a way, in cryptocurrency, you build a map, but then you need to work in an area that is wider than that. We have been able to survive in this space for so long because it is a new innovative revolutionary technology. Uh, we needed to take an early risk, or maybe even needed to take an early risk if we wanted to get to where we are today. But now the situation is different. Institutions are very clearly showing signs that they are viewing cryptocurrency as the future rails of their industries, and, uh, we are no longer considered alternative finance.
We are starting to become finances ourselves. So, we need to start performing at the same level that is expected of us if we want to meet this demand and reach the full potential of cryptocurrency. So how we manage risk will be a critical discipline over the next decade of work, and how we protect, safeguard and advance the interests of institutional assets and relevant audiences will be critical if you want to succeed in the long term. So I want to talk about four types of risks that I consider as a holistic unit when it comes to operating a professional on-chain professional on-chain protocol at scale. It is a process, its dependencies, its market, and its code.
We will consider them in turn. So, the first type of risk is the one from our example. This was not a problem with the code. This wasn't a problem with anything malicious. This is a process or operational failure that has caused serious, major, multi-layered, negative consequences.
And I think about it this way: every, uh, every process, every rule, or every method that your organization uses to interact with blockchain is another opportunity where something can go wrong. So signing regular transactions, uh, performing treasury management operations, uh, deploying contracts, administering them, automating workflows so that your protocol can run smoothly. They are all important, but they all create gaps and places where human error can occur. We kind of assume and rely on the fact that the person, the operator, knows what they need to know what's right in what can often be a very complex series of transactions, and that doesn't really have to be the case. We have to put in place protective barriers to ensure that whatever we send down the chain, uh, we have confidence and proper documentation proper documentation , uh, to make sure that we stay safe.
To prove this point, I don't know, I know from anecdotal sources, but I'll try to find some numbers that confirm that we see six to seven times more exploits of people or types of processes (whether it's an exploit or not is a debatable question), uh, than traditional code errors, uh, or, or traditional code exploits. And I think that says something. I think it shows that we as an industry have gotten much better at securing our code and making sure that the little house that we've built is locked down and secure, but we haven't taken into account the complexity that taken into account the complexity that comes with having many of these protocols interacting together in a chain. Which brings us to the second risk, uh, the risk of addictions. Now this, uh, this is something that can happen and can have very, very have very, very , very serious consequences, and you don't even have to do anything wrong.
So when you build a protocol, in most cases you deploy it along with the dependencies that you rely on, and those dependencies have their own and so on. The internet is getting pretty big. And after all, that's one of the main advantages of blockchain, is n't it? That's how, uh, that's how we got DeFi Lego, right? But the downside of this is that now we need to consider making sure that all of this works properly, within parameters that don't mess up our protocol in unpredictable ways.
Since cryptocurrency is interconnected, we need to make sure we account for second, third, and fourth order dependency failures. Hmm, and we need to make sure we understand what the impact would be if something went wrong at these levels. We need to know what the explosion radius is if the protocol my protocol depends on suffers catastrophic losses catastrophic losses . The flip side of this is DeFi. The other aspect of having this network of protocols connected together on Ethereum is that ultimately, these are all financial products, and the market and how it behaves is a critical part that can, uh, make or break the performance of your protocol.
I'm thinking about it. I think D5 protocols are roughly 50/50 split between the code, mechanics, and algorithms they developed, and the other half is the state, registries, and pools that make it all up and connect it to the rest of DeFi. This is also a fairly normal, fairly standard problem that traditional finance is also trying to solve is also trying to solve . But I think it's a little easier for them, compared to ours. We don't have the luxury of having trading hours, circuit breakers circuit breakers , human checkpoints in the loop that would ensure that someone can step in and say, "Hey, let's take a little break before we continue until the volatility dies down a bit," what took days or weeks can be dispelled in an instant .
And trying to predict and model these types of, uh, these types of outcomes becomes important because ultimately, by the time a person recognizes or notices that this type of volatility is happening. Robots have seen this before, but the avalanche is already underway, and it is often too late to react. So modeling and measuring how comfortable we are with these types of risks is the name of the game in traditional finance. And finally, code risk remains as important as ever. This is the problem that we This is the problem that we , as an industry, have spent the most time trying to solve.
So audits, comprehensive testing, surface management surface management —all of these are very important and remain very important disciplines, and we must maintain them at the same level as before. Why? Because we're not just protecting our own protocols, are we? If I upload something to the chain, I want to protect myself I want to protect myself . But we also, by introducing bugs by introducing bugs , exploits, etc.
and increasing the overall risk level of our protocol, affect others around us, right? This is the whole point of the risk of addiction. So, the main difference is that instead of focusing on comprehensive testing of the protocols themselves separately in our little sandboxes, we need to start thinking more about validating and testing the dynamics of the on-chain. The lack of this was one of the reasons we gave the example above. So being right at launch doesn't necessarily mean being right at scale.
We cannot theoretically model all possible states that our protocols can be in. Therefore, it becomes important to take into account the surrounding world. So, if we take a step back, we will notice that traditional finance has been facing these types of risks for decades: process, dependency, market, and code. They have well-known frameworks that give them, you know, broad guidance on how they should manage and behave when faced with these types of risks. In cryptocurrency, we just call them that.
We haven't quite figured them out yet. There is one missing element that ties all four risks together. And this is my proposal. What we've been doing for the last few years. Hmm, all the examples above, all the types of problems we face in blockchain.
They all arise from the difficulty of understanding how our actions are reflected on the live blockchain. This has been, um, a problem all along . Hmm, how do we simulate accurate live results without actually exposing ourselves to the blockchain? You know, one of the drawbacks of blockchain is the lack of undo buttons. So before we actually take our actions on the blockchain, we need to do everything we can to make sure we do so with full awareness of the theoretical limitations and what will happen.
After all, all serious industries are already approaching this with security in mind, and are already approaching it in their industries accordingly. An airline isn't going to send a pilot into the sky without hundreds of hours in a simulator, right? Financial institutions are required to conduct thorough stress testing for every new product they release to the market. And what's interesting for us is that with blockchain, we can have a unique advantage, uh unique advantage, uh , considering everything, because blockchain is code-driven. It is designed as a kind of world computer.
What others have done, trying to replicate, model or approximate, uh, and call it a simulation, uh call it a simulation, uh , we can go to the real thing and try to get the exact, uh, exact behavior and the exact, uh, type of preview, uh, before going to blockchain. So it's not all, it's not all bad things, uh, that blockchain gives us in the operational realm. So internally we call this blockchain operations as a broader category. This is something that, as you know, people, people at the forefront of the industry, have been doing in one way or another for some time now, and now it remains a quiet advantage that they can take advantage of today. But if we want to be serious, if we want to take on the volume that institutional interest will give us, uh, we need to take this seriously, and we need to consider this, uh, as the stakes at the table.
So, going back to where we started, we've done a great job of building the rails, of innovating, of putting all the building blocks in the right places, but we need to focus over the next decade on making sure we know how to use it at the level that global attention demands. Thank you.
Automatic transcript — names and jargon may be misspelled.