 Hi, everyone, and thanks a lot for coming to our talk. So I'm Daniel, and with me here is Ari, and this is a project that has been done by a few people. So there's Sam and Luis who are in the audience, but won't be presenting here today. And so today, we're going to talk about security risks in DeFi. And in particular, we're going to try to sort of give some definitions and explain how technical security and economic security are different, or how they differ. So a quick outline of what we'll be presenting today. So this talk is meant to be fairly accessible. So we'll start by presenting a bit of different primitives using DeFi. And then we'll present a couple of protocols that can be built. And once we've done this, we'll enter a bit more into the main part of the talk, which we'll be explaining what technical security and economic security is. And we will finally present a few open challenges for research with a focus on these different types of security. So we'll start on a very high level. But what is DeFi? So we have a couple of definitions and properties for DeFi, so the definition of a give is a peer-to-peer powered financial system. And for it to be called DeFi, we're saying that it should have a few idealized properties. First one being non-custodial, which means that participants should have control over their funds at any point in time. And next one is that it should be permissionless. Anyone should be able to participate in these financial activities without restrictions or without being able to be censored by a third party. Should be openly auditable, which means that anyone can look at the state of the blockchain or what is powering the DeFi and be able to see the transactions and what is going on. And finally, it should be composable, which means that different protocols should be able to communicate with each other and to interact to form new financial systems on top of this. So well, with this DeFi coming, there has been a lot of controversy and all. And we can see this a bit as two very pop point of views, an optimistic and pessimistic point of view. For the DeFi optimist, DeFi is a huge technological advance. It's a new financial system that's openly auditable and that has all the properties listed before. And that's obviously very promising for the future. And there has been already a lot of good things with DeFi, for example, stablecoins like DAI has been used in countries like Argentina to fight inflation and sort of things. And also, we have seen that more custodial system has tend to fail in some places where decentralized finance could have allowed people to have more visibility on what was going on. On the other hand, there's also this pessimistic view that is that, well, DeFi is unregulated, it's hack-prone. It can allow people through its sedentary nature to commit many sorts of crime like scamming, money laundering, and so on. And well, there has also been many hacks, as probably you have all seen, and this North Korean hackers hacking protocols and also, a bit more recently, as a crypto-mixer being sanctioned and so on. So well, in this talk, we'll focus mostly so on security, which is something that we think is absolutely, it's a complete must for the vision of the DeFi optimist to be fulfilled. And really, what we'll be trying to do is to differentiate between what is technical security problem and what is an economical security problem. Before this, we'll give a bit of background around different primitives that are needed for all this. And we'll start with some very basic assumptions here, as well, all DeFi protocols rely on an underlying blockchain, and it assumes some security properties, which are consistency, integrity, and availability. And there are going to be any DeFi without these to begin with. Then it uses a few other properties of the blockchain. And here, one that I want to highlight, there's a lot of security issues, because this are many potential, let's say. It's atomicity, which means that if a transaction starts, it will either succeed completely or it will revert. But there cannot be a half transaction that just cannot be. And obviously, DeFi relies on smart contracts, which are programs that run on the blockchain. And using these primitives, there are a few really essential piece of software and of other primitives that are required for DeFi, first one being Oracle. So because blockchain cannot have access to off-chain information, somebody needs to take this off-chain information and put it on chain. And these are called Oracle's and are used, for example, to get price of, say, USD, because this is not an information you could possibly have. Then there is governance, which is used typically to upgrade DeFi protocols with time, change parameters, and these sort of things. Then we have keepers, which are off-chain sort of bots and that will submit transactions to update states. This is because in most blockchain systems, you need a transaction to be able to perform any sort of state transition. And therefore, somebody has to take care of this. And finally, there are many market mechanisms that are used in DeFi. There are collateralization, where people will put some money at stake to make sure that they get a default in the position, for example. Then there's arbitrageers. There are also liquidations, liquidation which are used if somebody does not have enough collateral for whatever position. So that covers roughly the main primitive that we'll need in DeFi protocols. And now I'll present just a couple of DeFi protocols, probably some most of you are already familiar with these, but just to highlight a few properties so that we can kind of all be on the same page to start talking a bit more about security aspects. So there are many types of protocols, but we don't really have time to go through all of them. So we'll first start with automated micro makers, which are decentralized, on-chain centralized changes. Because on-chain, it's way too expensive to have some order-book-based DEXs. AMMs are somehow has become extremely popular and they have a lot of good properties, a few properties that are less good. But the main idea is that people will come and provide liquidity to a pool that consists of typically two or more assets. And by providing this liquidity, they in some way commit to a portfolio of these underlying assets and a portfolio that will be rebalanced by arbitrageers that will try to keep the prices consistent with some other off-chain, for example, prices or prices on some other exchanges. Once that is done, people can trade for this pool and that generates fees for the pool. And typically, this is profitable in the case where they are volatility harvesting. So talk just before was a lot more advanced than this. But basically, if the price is around some line and going up and down, it's typically profitable, as opposed to if the price is consistently diverging, then maybe not so. And there are still some risks, and especially strategy risk and adverse selection risk involved with these AMMs. And another very important type of protocol for DeFi are protocol for low-level funds, also called lending protocols, which are on-chain markets where people can borrow and lend assets. So typically, people will come and deposit some assets that are pulled in smart contracts. Other people can come and borrow these assets. And to do so, they will need to be over collateralized so they cannot default on their position. And an interesting thing is that there are algorithmic interest rates, which means that typically with this market, there is no duration risk. And if a borrower would default on his position, which means his collateral ratio is not high enough anymore, he can get liquidated based on a rule that are imposed by the protocol. And a final point that's also very typical to DeFi are flash loans. That's quite an interesting primitive because it allows people to borrow money without having any collateral. And the condition for this is that they repay this loan in a single transaction. And this works mostly because of the primitive I described before, which is atomicity. So with all this, then these protocols can communicate together, as I mentioned earlier. And for example, one person could deposit some money in an AMM and get some LP shares and use these MP shares, for example, in lending protocol as collateral to be able to borrow some other type of asset. And that's a very interesting thing with DeFi that all the protocol can really very easily communicate. So now that I'm done with this sort of intro background about DeFi itself, we'll dive a bit more into the security. And we'll really try now to delineate technical and economical security. And first, we'll start with some informal definition. So we say here that for protocol or smart contract to be technically secure, it needs to be secure from an attacker who is limited to atomic actions. And where like here being secure is going to get exploited, we have a more formal definition if I exploit in a paper that I will show at the end. But for example, it could be not to be able to steal assets. And so here atomic actions means that the action would be either a single transaction or either a bundle of transactions. But the property needs to be that all these actions will be executed atomically. And because of this, so technical attacks on technical security are risk-free, because basically the attacker can just perform the attack. And at the end of this transaction or of this atomic operation, he can see if yes or no, he made money. And if he did not make any money, if he made money, he profits. If he didn't, he'll only pay the gas fees and can reverse the transactions. So by definition or by kind of extending the definition, technical attack will always be risk-free. Otherwise, it will fit our other type of attack. And there are some examples of technical attacks are atomic MEV, sandwich attacks, and for example, like re-enterancy, or also attacks that exploit logical bugs. And that's all now fairly well studied. We know more or less how to protect against these. So of course, like testing smart contracts very well and program analysis or formal methods. And these are, in general, the better-studied ones. So part of smart time vulnerabilities, you have re-enterancy, internal manipulation, logical bugs, all of which are by now quite well studied. There are single transaction sandwich attacks, which is where, if a protocol, say, would use the spot price of an AMM to use as a price in their protocol, an attacker could come and imbalance this AMM so that when the protocol would try to look up the price, it would get the wrong price, and an attacker could fairly easily exploit this to make money. Our governance attack, if it's possible in one transaction to do some governance action, an attacker could probably borrow enough governance token to do so and execute some malicious proposal. Lastly, there are transaction ordering attacks, so for AML displayments attacks, where an attacker could front-run some particular transaction to make profit instead of the person who initially initiated this transaction. And also multi-transaction sandwich attacks, which are an attack where an attacker could come and see that somebody's trying to swap, but have, for example, a very high slippage tolerance, and he could imbalance the pool before to give the victim a bad price and then rebalance the pool after and would get the profit that the victim lost because of the price he got. So now I'll give it to Ari so that he can talk about economic security. So the other type of security we define a protocol is economically secure. If it's not profitable for an attacker who can perform non-atomic actions to manipulate the protocol into unintended states where they can essentially extract assets from the protocol or cause other sort of mayhem in the protocol. And so economic security is about where you have an exploiting agent who's trying to manipulate some sort of incentive structure of the protocol to profit, like by stealing assets. And since these are non-atomic, they have upfront tangible costs and are not risk-free. Basically, you have to set up the attack and then actually perform the attack later on. And something could happen in between those two times. And basically, the attack could fail if something happens in between those two actions and such as the market responding or other agents responding. And to address this, we really need to have economic models of what's happening in between these transactions and the attacker would need to understand this and basically manipulate what's happening in between these transactions. So let's hammer down a little bit further what the difference is between technical and economic security. So in a technical exploit, we have an attacker who's effectively finding a sequence of contract calls that leads to a profit. And these are either in a single transaction or a bundle of transactions, but it's being done all at once or not at all. And for these, formal models of contracts are basically enough, so to say, although it can still be quite a hard computer science problem to work out the optimal ways for attacks to be performed. In comparison, in an economic exploit, an attacker is performing multiple actions kind of at different times or really different points in the sequence. And they don't necessarily control what happens between those actions. And so there's no guarantee that the final action is profitable. So there's kind of a setup. There's actually performing the attack later, but in between, some sort of market can respond or other agents can respond. And so the attacker doesn't really know if it's profitable at the end. And for this, we need models of what's going on in between, which is a bit different than just formally verifying contracts. And so this is kind of an open area of research, especially around kind of understanding liquidity of markets. So let's hammer down even a little bit further with like a very simple example of something that'll be a technical exploit and then something we can change a little bit about it that turns it into instead an economic exploit. So in the example of a technical exploit, let's say a protocol uses an instantaneous AMM price as an oracle and that then an attacker performs an atomic sandwich attack to steal assets from that protocol. Because this can be done atomically, this is a technical exploit, but we could change it. We could use a smarter choice of oracle so that this isn't possible. And that leads to instead it being an economic exploit. So here, consider that the protocol instead uses a little bit smarter choice of oracle, a time-weighted average AMM price. But these can still be manipulated over time, but it involves risk for the attacker, but they still may be able to steal assets. And actually, something like that just happened very recently in Mango, I believe. So we can see this also like in data about what's been happening in different protocols. So one example here to kind of illustrate this a little further is something that happened in Compound in November 2020. Now this wasn't really clearly an exploit, but it kind of illustrates what could have been an exploit and what can be exploits in other protocols. So basically, the price of dye was trading on Coinbase. And for a very short period of time, the price pumped to $1.30. And because Compound was using Coinbase as an oracle, this allowed a lot of liquidations to be possible on Compound. And that cost a lot of LP's money in Compound and opened up a lot of opportunity for profit from liquidating those positions. Now this wasn't clearly an exploit, but you could imagine that somebody might set this up intentionally, manipulate this market that manipulates the oracle price and then profiting from the resulting liquidations. And that's essentially what we've seen later as well. So in a clear exploit, something similar happened in Venus in May 2021 where the Venus market was manipulated and essentially the attacker was able to leave the protocol with a lot of bad debt. And again, just recently, something similar happened also in Mango. So what are the tools available to help to fix economic security and make protocols more secure? One of the first ones, the biggest is really over-collateralization. And here, it just doesn't come without risks though. And so it's very important to include an analysis of the actual economics in designing and calibrating your protocol. So for instance, you could have persistent negative shocks that affect collateral prices and you could also have kind of illiquid markets around those assets. And this can lead to loans being under-collateralized and the system being left with bad debt. It can also lead to situations where it's unprofitable for liquidators to actually initiate the liquidations, which then also can lead to the protocol having bad debt because the liquidations don't happen in time. And there's also sort of issues that can happen with stablecoins and deleveraging of these stablecoins like we saw in Die on Black Thursday where you had this like short squeeze effect and you also had this sort of like collapse of the liquidation engine. Some other things that you need to be aware of when you're designing protocols with respect to economic security is the minor extractable value that you can be setting up. I won't go too in-depth here because there have been a lot of great talks already about minor extractable value. I'll just point out that DeFi applications tend to give many new sources of MEV and you need to be considering these. And this is essentially coming from arbitrage opportunities. So for instance, in DEXs, you can have sort of like stale order quotes and whoever fulfilled those is able to do an arbitrage loop and profit. And in lending protocols, there's usually a liquidation incentive and if you're the person who can come in and perform the liquidation when it's allowed, then you can profit from being the person who does that. And this can lead to consensus layer risks if this MEV is greater than the block reward. Another important area is in the design of governance and the risks that can come up from your governance layer. So the governance is basically introducing a way to upgrade protocols and these need sort of careful guardrails and careful design so that your governors aren't going to have mis-incentives to do things that are actually bad for protocol users. And so commonly, governance may not really be incentive-compatible with the actual users of the protocol and this can be an issue. They may not act in the interest of these protocol users. And to illustrate a little bit, in some sense, governors have some honest cash flows, but these cash flows may not always be very high. Sometimes they can crash and then if they do crash, the region of incentive compatibility might shrink and it may be more profitable for these governors to instead of doing sort of honest actions and upgrading the protocol in good ways, to instead decide to attack the protocol and basically steal assets from the protocol or do other things that put protocol assets at risk. And the costs to do this can sometimes be very low in DeFi and should be part of the design of governance systems. So for instance, tokens can be borrowed and agents can be sort of anonymous and this can lead to low costs to actually do these governance attacks. The last one I want to hammer down a little bit on is what we were talking about in the examples of where you have markets or oracle manipulations that can directly affect your protocol. So here we need to distinguish between, one, a market price that is being manipulated but correctly supplied by an oracle and two, an oracle that is itself being manipulated. So in market manipulation, you have an adversary who is manipulating the market price either on or off chain depending where that market is occurring. Over some period of time and they can profit if the manipulation, they can exploit it in a protocol that uses that market as an oracle. And these problems persist even if the oracle is not an instantaneous AMM because there is some liquidity in the market. Depending on that liquidity, there's some cost to affect the market price and you can instigate changes to market price that are then reported through the oracle system. And importantly though, this is risky because you have to do it over time, it can't be atomic which is again the main point about economic security. And this compares to oracle manipulation where it depends on the design of your oracle but even if the market price is not being affected, the oracle might be reporting incorrect prices. So centralized oracles have potentially a single point of failure and you might want to control for that in designing your protocol. And on chain AMM based oracles, as we've seen, can be manipulated and so the costs of manipulating that depending on the liquidity in those markets is something you should be carefully considering. And other decentralized oracle solutions are really imperfect for the issue that you can't really verify the correctness of prices on chain. And so it's quite an open problem how to do this very well. So that sort of concludes our discussion of technical and economic security but it leads to a host of new research challenges that are really going to be important for securing D5 protocols into the future. So I'll give you just like a quick flavor of these. One is around composability risks. Mostly these are not very well quantified but a lot of program analysis can be done to understand these risks a bit better and then to design your protocols in ways where how you're composing with other protocols is as safe as possible. Another is what we were just talking about this governance sort of risk and modeling the incentive compatibility of governors and sort of modeling out what we call governance extractable value and trying to understand when our governors in your system incentivize to do things that are good for the protocol and how do you stop them from doing bad things. And these need economic models about how these governance systems work over time and how the agents make decisions. Another is around oracles. So basically a similar sort of role as governance incentive compatibility to report correct prices. And then in a fair amount of work to be done in MEV. And there's just one illustration of sort of like what makes MEV very hard is that if you're looking at just intra block MEV, atomic MEV, this becomes an optimization problem that resembles NAPSAC but where the items in the NAPSAC can change depending on the current selection. So it should be even harder than NAPSAC and so it should be an NP hard problem. And this becomes even harder than if you're looking at inter block MEV and this includes cross chain MEV because now you have to look at an inter temporal version of that same optimization problem. And there's also a lot of work to be done in sort of making anonymous DeFi protocols and preserving privacy. So that brings us to the end of the talk just as a quick recap. We've covered how DeFi has several innovations but it also has several risks. And to fulfill the vision of the DeFi optimist we really need to make sure that DeFi is secure. And to do that we've delineated two types of security risk between technical and economic security and the key distinctions that allow this to be useful are that it's based on atomicity and it really tells you a lot about the models you need to understand security in your DeFi protocol and the types of models that we as researchers need to build out. So thank you and let's open it up for questions if we have time. Just while we're working for the mic. So this is based on the papers that we wrote and this is a QR code in the link if you wanna have a look and there are more formal definitions in there so please feel free to take a look. So how does this overlap with a lot of what gyroscope is doing and sort of your mission and vision, I'm super, super curious about that, yeah. That's a great question. So how we've designed, so it's a gyroscope. We're working on a new stablecoin project where we're building a bunch of different primitives that allow what we think is a more resilient stablecoin design and it's really coming out of all the research we've been doing. We've set up some of the initial models that like help to understand for instance, economic security and the mechanism design that went into gyroscope takes all of that knowledge into consideration and tries to do the best mechanism design that we can considering how we understand economic security today. Thank you so much. Remember, the venue will be open this weekend so come and talk with the people with every wild close deals, et cetera.