So let's start off with the most obvious risk and that is smart contract risk. And I'll spend some time on smart contract risk and I've divided it into a number of different sub modules. So the first is the type of exploit. So what are we talking here? We're talking about a hack and I'm going to be careful in the way that I actually used the hack because sometimes hacks are very nefarious where people actually go in and steal a coin. There's another type of hack that's more like an arbitrage. You see an opportunity to take advantage of something and you do. So that's not in the same category, in my opinion as the sort of hack that comes from an adversary that actually wants to steal something. So the sort of hacks that we are familiar with and I'll talk about this to some degree, but not a lot are the hacks of these centralized exchanges. So there's been a long list of them and people make the mistake of thinking, well these are Blockchain hacks. And it really has nothing to do with Blockchain and nothing to do with smart contracts. These are just centralized exchange. They're like brokers and the security practices are poor and somebody comes in and exploits them. And I'll go through some details, but that's not really what we're talking about here. So we're talking in the DeFi space in terms of a smart contract. And the risks that are associated with having a contract that is not very well thought out or not very secure. So this is a new type of risk. Okay, so just to be clear and I said already that DeFi solve some problems are risk situations that we have in centralized finance, like counter party risk. But you introduce a new class of risks. And the key component in DeFi is a smart contract. So if there are issues with that smart contract, then that opens the door to an exploit. So let's think about this risk. I think fascinating in that it's just so different. So think about a hacker wanting to do some damage to, let's say a centralized let's say commercial bank. Well, the first thing that they need to do is to get into the bank systems and that might not be easy to do. But let's they get in, then the second thing they need to do is to look at all the code, which could be hundreds of thousands of lines of code and to figure out where to attack and then they attack. Okay, so that is in the usual kind of centralized finance world and it's not just centralized finance, its is basically the business world as we know it. Now contrast that with decentralized finance, so with decentralized finance, the code is public. You don't need to hack in to see the code, it's for anybody to look at and download. Okay, so it's very interesting, as I said, that this is a new attack vector with the code is available to anyone. Okay, so that means you need to be like really, really careful. So for example, and in centralized finance, if you've got really good security and nobody can get in to your website. Even if your code has got some flaws, given that nobody can get in, you're pretty well protected. So in decentralized finance, it is wide open for anybody to take a look and if there's any flaw in that code, it's going to be exploited. Okay so this is definitely what I call a new attack vector and it's something that is basically unknown in traditional finance. And it points to the importance of having very high quality smart contracts. These smart contracts are not hundreds of thousands of lines, they're actually pretty short and concise and you need to get it right. And part of what we'll do in this course is highlight a number of situations where you don't get it right. So what do you do to mitigate that risk? And it's interesting in the DeFi ecosystem that there are a number of companies that have been founded that are doing quite well. And their single job is to do an audit of the smart contract code. Okay, so this is standard practice now where you develop, you're smart contract and before for example, people transfer liquidity to that contract. You want to make sure that there are no mistakes. So we've got a history of smart contract compromises and again, I'll go through some them like de force. We'll talk about the history of these and to reduce the chance that there's an exploit companies will employ a third party auditor to go through and to basically stress test the smart contract. Indeed, the stakes might be very high. So this could be a contract that effectively billions of dollars go to, it's got to be really secure. So it's sometimes the case that you employ not one auditor but two auditors just to make sure that everything is exactly right. So again, this is different from centralized finance because the code is available for anybody to see. So we'll talk also about the sources of risk in terms of an exploit of a smart contract. So one obvious source of risk is. Like a logic error and in the code, okay? So, that is one category. There's many categories, but there could be an economic exploit also, that will go through considerable detail that might involve an oracle, that could be manipulated. So, but the logic error is kind of the easiest to deal with, because that's within the actual code. So it's something that you definitely want to make sure there's nothing, that is like that in the contract. So let me give you an example of a logic error. So, you might have a contract that basically, you hold tokens in that contract and it basically serves as an escrow. And let's say we set this contract up so that it is a lottery and we've talked about lotteries before, that you can have a fair lottery. So people put their token into the contract, there's going to be one winner that's drawn. So let's say that happens, and the contract is keeping track of how many tokens and fractions of tokens that it actually has. And then let's say there's some rounding somewhere, okay, so if that happens, then this could be devastating for the contract, because it might be that you round up a little bit. So let's say the contract has got the equivalent of 999.99 of of the token. And let's say the payout Is rounded up to one million for the lottery winner. So within the contract, it goes to transfer the one million to the winner. But, there's insufficient funds because we're short by one cent. It doesn't sound like a big deal, but given that this is algorithmic and it might not be one cent, it might be a fraction of a cent. That that means that every time the contract tries to transfer the one million, the transfer fails. Okay, so again this is a devastating logic error because it means that $1 million minus one cent is going to be locked in that contract forever, okay? So things that don't really seem like a big deal, could become devastating and and rounding is just an example, is actually a common example of something that you definitely want to avoid. And the worst possible scenario is where all of the funds are, we call it bricked in the smart contract they're there, but there's no way to get them out, it's locked. Okay, so that's an example of a logic error. Economic exploits are more subtle. And again, often it's involving something outside of the smart contract that could be manipulated. So there's no logic error in the code. But it could be that the contract is exchanging tokens and that it looks for a price through an oracle. And so in looking for that price, it's possible to go to the oracle and potentially manipulate the oracle and cause an opportunity for an exploit. And this is actually a fairly common thing to do, to take advantage of illiquid decentralized exchange mechanisms and to manipulate the oracle price to get a better deal. This again is something that you might call it a hack, you might call it something else, that you see an opportunity, there's nothing illegal that goes on here. This is basically everything is transparent, so anybody could actually do this. Okay, so this is just an economic exploit. So to be a little more specific here, the way that this would happen is you've got this oracle feed from another exchange, let's say it's a just a single feed and that exchange is not that liquid. And we've talked about this situation as to what happens when you've got illiquidity in the context of our constant function automated market makers. So given that there is not much liquidity, on the oracle exchange you sell heavily and when you do that, it reduces the price of the target token. And if it's a liquid, it could very substantially reduce the price. And then you go to the more liquid contract that is using that illiquid contract as the price, the oracle price. And then you do the reverse you buy and you're buying at a really cheap price. Okay, so you manipulate one feed to reduce the price and then you buy and you're buying at a cheaper price and then eventually that will go up in value. So this is just an example and we'll go through other examples like this, but this is an example of an economic exploit. So again, there's a long list of exploits like this, but some of them are known as flash attacks. So we actually did a number of examples of using flash loans in the previous course. So we talked about a flash loan to refinance a loan. We also talked about a flash loan to take advantage of an arbitrage opportunity. So, So basically the situation here is, and I tried to make this clear in the previous class, that anybody can take a flash loan. Okay, so this is not restricted to the high network individuals. Okay, so these attacks can happen very quickly with very considerable size. So we'll go through a few of them in this course and one of them will go through in great detail where you can see all of the transfers. So, I guess what I'm saying here is that in traditional finance, you might think of there being different markets for the same commodity, for instance. So oil is an example where there's markets for oil, even within the US at different locations. And you might think of a strategy where at one location, maybe you can buy the oil cheap and then you could sell at another location where it's more expensive. And even after the cost of transportation, but it's way more complicated. First, I've already mentioned you have to actually transport all the commodity to the other exchange. And second is the time lag and actually doing that. So by the time you transport, maybe that higher price has decreased. And what seemed to be an arbitrage really isn't. Okay, so in centralized finance, there's a lot of risk and actually doing this. Whereas in decentralized finance, this happens near instantly at very low cost and anybody is welcome in these protocols to take out a flash loan to make this not a small exploit, but a large exploit. Okay, so flash loans play a very important role here. So again, it's very very important to get this right. So it's a bad idea in a smart contract to have an oracle that goes out to a single illiquid, decentralized exchange. You're just asking for problems if that's the case. So often that's mitigated by using a number, not just one, but a number of liquid exchanges. But this is again, really important for this particular technology. There have been many of these flash attacks or exploits. And again, I just want to be careful here because I'm not using the word hack, though some people we'll use the word hack, especially in the media. So, bZx is an example of one that was based on the flash attack. And basically the attacker took a flash loan, diverted funds to purchase a lever short position, and then manipulated the price of the oracle that the short position was based upon. And they closed the shop with the profit $300,000. It's a small amount in the big picture of things, but it's a good exploit to show you what the vulnerability is. So there's a good example of an economic exploit and we've got plenty of examples like that. So this is in a little more detail what this attack actually looked like. And let me actually go through it. So the first thing is a flash loan on dYdX, which we just talked about for 10,000 Ether. Okay, so this is not a small flash loan if you think about the price of Ether at $2,000. And then 5500 Ether sent a compound to collateralize a loan of 112 wrapped Bitcoin which we talked about at the end of the third course. And then 1300 ETH sent to Fulcrum's pToken and five times leverage short position is opened against the ETHBTC ratio. And then we get 5637 ETH borrowed and swapped to 51WBTC through Kyber which we also talked about Uniswap reserve, and that is exactly where the slippage occurred. So that was basically manipulating the price there. And then the attacker swapped 112 wBTC borrowed from compound to 6871 ETH on Uniswap and there you see the profit and the flash loan is paid back in the end. It's all in one transaction, you can actually go through this,see the math and the profit was 1193 ETH. So again, this is like a key thing is that manipulation of the ETH liquid price that was based on like the oracle and this generated a profit for the attacker. So I've also got a screenshot from Etherscan. So Etherscan is a website where you can see everything that's ever happened on the Ethereum Blockchain. So everything is there. So every block, every transaction is there. And I've highlighted the transaction hash of this particular exploit. And you can see the block number, you can see the address where it came from. And that address is an Ethereum address but the zero X on it, and notice that it's labeled the bZx Exploiter number 1. So that is basically the address of the exploiter that went through did all of this, and generated a $300,000 profit. Some of the profits again are going to be much greater. And Etherscan also shows you the basics of the transaction. So it's a little less detailed here, from what I just showed you. But you can see the borrow of Ether on the flash loan from dYdX. And remember when we talked about dYdX, that those flash loans come without a fee. There's no fee associated with that to take a loan of that size, and no collateral. And notice in this transaction that you borrow, the first thing you do is borrow and then we're supplying Ether to compound and that Collateral is used to borrow 112 WBTC. Then there's a swamp on Kyber, and then the last line we repay the flash loan. So again, if anything happened that failed and the intermediate steps, then we return to the original state where there's actually no flash loan. Okay, so this is an important property of this transaction with multiple steps that it is atomic. And that's the reason that the flash loan is basically got no counter party risk, even though the person taking it out has got no collateral whatsoever. So this is a fairly simple exploit. I can represent the exploit in like five lines. We're going to look at later on, much more complex exploits. But they add the same flavor. Where you're borrowing something and then you use that borrowed fund as collateral, and you meant something else and then you use it and then you pay everything back on the final step. So this is the basic idea of an economic exploit, very important risk in the defib space.
