What you should consider before putting millions into DeFi - Daniel Que

good I guess I'll get started so my name is Daniel I work at coinbase I'm a software engineer I work primarily on the backend systems there but also work on us DC specifically we have a u.s. DC bootstrap fund which makes investments in two different d5 protocols to help them grow so you can come and ask me about those later on but yeah so this talk is about defy and risk so yeah defy risk considerations and you must have seen this coming this is not investment advice and I have to put this up here for informational purposes only we're all smart here we can do our own homework and yeah not advice our lawyers made me put this in here all right so defy so yeah thanks so defy is this thing that's been on a lot of people's minds lately and it's grown quite a bit in the last two years and a lot of it is due to lending protocols and the metric used here is total value locked which isn't necessarily like the best metric but it does do a decent job at measuring the growth and you might wonder like why why is it growing so much so if you come in to d5 this is kind of the things that you see you see that you can lock up some of your investments that you were planning to hold anyway and you can earn interest on them and here we have like 6% 7% and it was pretty typical to see like 15% just a few months ago and that's kind of crazy especially when you compare it to say savings accounts which give you like 0.1% high-yield savings accounts which are 2 to 3 percent and even stocks like there's a rule of thumb that on average they perform around like 70 percent per year in the long term so 15% kind of blows that out of the water and you kind of start to wonder like what's going on here right it's a very exciting but you can't compare them apples to apples and that's basically what this talk is about is all the the risk that comes with this stuff and the people who are getting into defy lately tend to be younger as in they haven't lived through a financial crisis which would really impact your perception of these things right like if you live through that when you're young then you're gonna be a lot more risk-averse and typically people also come from a computer science background myself included I actually study at the University of Waterloo here in computer science so a lot of this is a reflection of myself too in computer science things are very theoretical discrete often it's like deterministic and there a lot of assumptions and things just like work versus in engineering or in finance you think a lot more about things going wrong and you expect them to go wrong and you have a lot of like fault tolerance and yeah it's like the real world so yeah what could go wrong that's that's a question here but before we get into that I'm gonna do a little overview a little review of how planning protocols work just to have some context I'm sure a lot of you are familiar with it but generally they follow this kind of pattern we have a pool and you have lenders and borrowers so the lenders can deposit assets which the borrowers can borrow and they can withdraw and do whatever they want with it and they have to come back later and pay back with interest so because smart contracts each address is pseudonymous you can't just lend out money and expect them to give it back to you because if you can't track them down then they're just gonna run away and keep your money so to combat that we have collateralization over collateralization so it's quite typical to see something like this where in order to borrow funds in this example USC see you first have to provide 150% collateral in this case eath and the value of the collateral can fluctuate and so can the borrow token as well as well actually like it doesn't have to be a stable coin and if the collateral falls below the value of the borrowed tokens and the borrower is incentivized to just like run away with that and there's no reason for them to come back and pay so before that happens at maybe 120 percent they would get liquidated to recoup the funds and in this liquidation there's a liquidation penalty or reward depending on which side you're on to incentivize Liquidators to keep the system solvent and the rest of it goes back to like the lenders alright so here are the risks that we're gonna cover today and the first one is smart contract risk so a smart contract risk is probably the most well known it's pretty like self explanatory basically it's just the risk that there's an issue in the smart contracts whether it's a bug or a vulnerability that it gets exploited and it could result in locked funds or lost funds which are pretty similar as a as a lender whether you lose them or they're locked forever there's this quote that I like there's a finite amount of time to write code but an infinite amount of time to hack it and this is because smart contracts are immutable you can't just push a hotfix and on top of that not only is it a finite amount of time but it tends to be really compressed because these teams are trying to meet deadlines and push out code quickly so it's a very common for bugs to be introduced in that in a high-pressure environment like that an example like probably the most a Taurus example is the Dow in 2016 where one hundred and fifty million dollars worth of eath was locked up and resulted in the you theorem classic fork it's important to keep in mind that all of this defy stuff it's being built on emerging technology which is bound to fail at some points along the way to being more mature and also worth considering which some people don't always so while the smart contracts are immutable the platform that it's built on top of isn't necessarily immutable seoui theorem has upgrades all the time and they change things about how it works for example there could be changed to an opcode that changes how much gas it uses and this could actually introduce an issue that can like you know mess up your contracts it's like very specific but you know it's a risk nonetheless so how can you mitigate these for one better coding practices for sure you can separate critical components of your contract from secondary things and make sure that the critical stuff which moves money around is working well and when you separate in that way it's also easier to test it and verify it for example I've seen some protocols that have a separate vault contract and then the other contracts just communicate with the vault and the vault will manage like the allowances and move all the funds around so as long as the vault is secure then funds are secured also in terms for coding practice you can add circuit breakers and time delays so for example before an impactful change takes effect there could be like X days before it actually takes effect so that people can kind of audit the diff and decide to pull out or exit if they if they want to and this was actually crucial in the dow example from earlier where there was like a period of time before funds could actually be withdrawn so they were able to basically use that time to work on the hard fork and prevent all the funds from actually being like lost and cashed out another mitigation is monitoring at coinbase we have a lot of monitoring stuff basically you want to learn about these changes in these contracts as soon as possible and you'll like alert engineers with something like Pedro Duty these tools are pretty new for crypto and there aren't like great solutions out there right now but they're being worked on and they'll they'll be here soon the next thing is auditing it's very important for smart contracts the audit should be from a reputable firm ideally there would be multiple audits as well to you know just to have extra assurance because one firm can always miss something and there's also typically two kinds of audits that are being done lately it's like manual and formal verification formal verification is quite new it works really well because it can give you like this mathematical proof that you can sleep a little bit more soundly at night but there are still issues with it for example you have to come up with the rules that you're formally verifying and that will always require some amount of manual work and the other issue is that you can only check the code against the spec but if there's issue if there's an issue with the spec itself then formal verification is not going to catch that and for that you you'll need like a manual audit so it's always best to have a combination of both and finally it's also important to look at where the audits came from so oftentimes or most the time the protocol teams will hire an auditor and the auditor since they're being hired to do this it's in their interest to make the team look good right and you don't really see official audit reports that make the team look bad because there's a bit of a like incentive misalignment there so yeah you have to like read the audit reports with a grain of salt because and keep that in mind yeah yeah but typically like it's good it's a good like extra precaution to do an additional like independent audit that's not tied in any way financially to the to the protocol so this Marc contract risk is kind of like its tail risk and what tail risk is is basically something an event happening that's like three standard deviations away from the mean given like a normal distribution so it's basically something that's quite unlikely but with smart contracts specifically it's somewhat systematic like you can't completely eliminate the risk you can only mitigate it so you should always like be prepared for an event such as this and be prepared to like you know move forward with things and not have this be like a something ending event all right so the next type of risk credit risk so credit risk is the risk that a borrower doesn't repay alone but with these smart contract protocols we kind of solved that right because we have over collateralization so you don't have to worry about that as much because you can just liquidate the the person if they're not going to pay back but then you would just replace credit risk with liquidity risk because now you have to exit these positions which may not always be possible so one example is if you have an illiquid asset for example let's say you deposited USD C and someone else is borrowing that and they're using a random token to collateralize it it may be very hard to to liquidate that also also worth noting is the slippage if the books aren't very healthy then liquid in that much of an asset might move the price and the 5% liquidation discount might not be enough to and why's the creditors to liquidate issues can also arise during network condition or network congestion basically when there's a lot of price action people use the network more and it takes longer to get transactions through so this delay could be like those extra 30 SEC's and can 30 seconds can be crucial sometimes and crypto isn't hers for being pretty volatile during a price crash the price might be moving too quickly to to liquidate because when you're liquidating you're still constrained by the block time and in an addition to the price crash specifically with these lending protocols when you liquidate someone it's basically like a market sell order which can put more sell pressure and cause more people to get liquidate because the price is going even further and it can cause this kind of downward spiral and the more funds are at risk of being liquidated the more of a risk like this downward spiral is so in these lending protocols the losses are socialized so all of the lenders would just take a cut so everyone gets a haircut another type of risk that kind of falls under this liquidity category is bank run risk basically when you put money into the pool and someone borrows from there they're withdrawing the front's from the smart contract so they're not in there and they're not available for you to go and withdraw them similar to like in a bank run situation if everyone's trying to pull out their cash at the same time and the bank doesn't have enough cash on hand and they're not gonna be able to pull it out so that's something else to be aware of in lending protocols specifically so mitigations if you focus on liquid pairs and don't deal with illiquid assets you can mitigate a lot of those risks you have to make sure that both sides of those of that pair has to be like liquid because even though you SCC has a lot of like good liquid pairs or eath has a lot of really good pairs if you pair eath with some you know very low market cap coin the you know there's not much liquidy there another thing is the collateralization ratio and the liquid the liquidation discount ideally they should be tuned per pair because every pair of assets has a different risk profile and therefore they should you know one size fits all it doesn't work here a good history of liquidations and a good healthy network of Liquidators is also good to have just like some redundancy and finally monitoring once again you want to be aware of market conditions and be ready to take action if necessary all right admin risk so a lot of protocols have admin access they're kind of like backdoors they allow things such as pausing so pausing functionality and the network tuning parameters like collateralization ratio or liquidation discounts and upgrading and these are very sensitive things because like upgrading specifically because of the way that they're implemented you can upgrade the implementation to something arbitrary and this new arbitrary implementation could you know allow an attacker to withdraw everything for themselves admin risk is the risk that these capabilities are exploited and this could happen through a hack let's say the private key is leaked and someone gains access to it or it could be like a rogue employee you know gone wild and trying to mess with the system and even if it's not like upgrading and you can't withdraw the funds just pausing the system can have an effect for example someone can lock the contract and demand a ransom and if there's a lot of money in there then it might be worth it for people to like pay that ransom so to mitigate this one thing you can do is separate the roles you don't want to have one private key responsible for everything ideally each role is separate and with this increasing severity of the roles you should have like increasing severity of security or in security so better coding once again if you have time delays to give people time to react to changes then they can exit secure key management is very important you want to and this is for both external and internal so externally you don't want someone to be able to take your keys obviously and do stuff but internally as well it's important to have processes in place to prevent employees from accessing these things and doing something accidentally maybe finally multi-sig is definitely worth considering it helps to spread out the risk of the of the keys and you don't want to have like a very high value key in one place all right Oracle risk so Oracle's provide real-world data on the blockchain and they're very essential for defy Oracle risky is the risk that an Oracle malfunctions or is exploited and an example of this had happened somewhat recently is actually a synthetics which shout out to synthetics over here there is an Oracle that reported the price of the Korean Won as being a thousand times higher than it actually was and there were some trading bots that would do like some Oracle front-running so that whenever they see a large Delta in the Oracle they would buy or sell right before and then sell or buy right after so a bot took advantage of this and made a billion dollars in profit in under an hour yeah yes it's important to note that they couldn't actually cash out that billion because there was only like maybe tens of millions of funds in the system at the time but it still would have been a you know disaster if they had tried to you know maliciously exploit this and luckily the owner of the bots agreed to reverse the trade the trades and in exchange for a bounty so good guy so you can mitigate Oracle risk by having multiple sources and perhaps taking an average you want to discard outliers you can do that by discarding the max and min but it's also good to be more sophisticated and do maybe discarding the top and bottom like standard deviations like because just max Inman can still have issues let's say if there were two that two Oracle's that we're providing like a an erroneous value you can also limit the price deltas per like time so for example you only let the price move by 10% per block and anything above that will either fail or just be capped so this is another great way to mitigate it's you have to be careful with the tuning of that because sometimes the prices actually are very volatile so you have to make sure that you're not like misrepresenting the prices because that could lead to other issues there's also this question of centralized versus decentralized Oracle's centralized Oracle's tend to be a lot simpler and more efficient like faster decentralized Oracle's have a lot of stuff in them and a lot of things need to be gone just right and you know the more moving parts there are the more chances there are to for things to go wrong so there's a bit of a trade-off there and as you know more research is gone goes into decentralized oracle they'll be like more viable over time and finally you want to monitor them just like everything else so now we have dependency risk so this is the risk that dependent contracts fail so in defy there's this meme like money Legos everything is very composable and they're built on top of each other they're very intertwined but the and this is very powerful because you can build applications very quickly and like stand on the shoulders of giants but the issue is that if a cornerstone like primitive contract fails then it can affect everything on the stack and it's kind of like it kind of mines me of p.m.

dependency management but now you have to do that with your money and it's just a bit of a mess so to mitigate this you want to audit your dependencies and when you're coding these smart contracts you want to treat them not as a black box but as a white box you want to be aware of all of the edge cases the corner cases instances in which they can fail one example is a lot of ERC 20 tokens can be paused and it's like a surprising number like almost half of the top 20 or something like that and basically pausing there's a flag in the contract where if it's set to true then transfers will just fail and the issue with this is it not only affects the bat token itself but it can affect other tokens in the same system like if you try to withdraw a bunch of Year C 20 tokens at the same time and one of them fails the entire transaction will revert so you know it could result in lost funds so you have to consider like how the underlying things work in all their many and many different ways so the last risk that we're talking about here is centralization risk which is somewhat similar to admin risk it's the risk that the team developing the protocol is centralized and makes bad governance decisions such as you know maybe they go too risky with the collateralization ratio and it just results in like losses from liquidations so this can kind of be mitigated with decentralization but then you have decentralization risk like so the answer to centralization is often like oh we'll make a Dao and everything will be fine but those are very hard and they're not a silver bullet technical solutions can't always solve social problems and yeah that was tend to be like slow they have low participation not everyone is an expert so you don't get like the best signal necessarily and there's a lot of work being done here and hopefully it'll we'll get to a point where this is truly viable but for now I think it makes sense to decentralized overtime like you don't have to be a hundred percent decentralized from day one you can be somewhat centralized make compromises get like something working and then over time decentralize it so in conclusion you should be aware of the risks and this is not a comprehensive list there are many other risks as well remember that you you can mitigate but you can't fully eliminate these risks so they'll always be there there's somewhat systemic not all risks are equal for example with smart contract risk if something does go wrong it's it might be rare but you might lose everything compared to liquidity risk it might happen more often but you'll only lose like some percentage of your of your funds and finally things are still maturing so expect the unexpected things are like gonna go wrong and you should be prepared for that so the real conclusion is that you should make your own conclusions and this is not investment advice thank you and we have two minutes for questions it does yes yeah decreasing interest rates I'd say it's a risk in that it's like less exciting and it's not gonna bring in new users as much yeah but on the other hand mm-hmm I'd have to think about that a bit more I'm sure there are some like downstream effects from that yeah so we have a couple of things coin based wallet is a one example we have like the mobile dab browser the u.s. you see boots trap fund is another one where we're investing in these protocols to you know help them grow more yeah we have a bunch of different projects like in like related to define yeah yeah regulation risk is another is another issue that we didn't cover here but that's definitely worth considering as well because if the and it's kind of related to the centralization risk like if the company developing the protocol is centralized and they're in a certain jurisdiction where they can get shut down then it can impact the protocol so yeah all right we're out of time but thank you very much for coming and have a good hack