Designing Defi Resilience: Inside Aave V4 Security Blueprint

Transcript

[clears throat] >> Hi everyone. Uh how are you? I'm Tomer Ganor, tech lead at Aave for 4 years. I worked on the biggest DeFi protocols that you know, like Aave, Lido, and many more. Uh I have a lot of experience with smart contract auditing, formal verification, and design review. And I did actually design work for a couple of the biggest protocols in the system in the ecosystem, like for example Aave V4, Lido DAO governance, and Lido 3.1. Uh so, let's start. Um so, why should you listen to me?

So, I've been working on this project protocol and project with Aave Labs for the past year. This is by far my longest engagement with on a single project. Uh and this full year of work with the team just showed me the level of seriousness they have about security. They really care about security. They're willing to go the extra mile to make sure that everything is as good as it could be. Uh and every small mistake, every small concern, they're uh fully willing to fix it just to make sure everything is as good as it could be. And it's really shows the importance of security for them.

Um so, let's start. So, what is Aave? So, Aave is growth in finish, so whoever knows know, and also the biggest lending protocol and the biggest protocol in DeFi. And they have over a 50 billion TVL, and if you don't know them by now, I think maybe this presentation is not for you, but you could stay still if you want. Um and now they deployed V4 in this in DeFi day in ECC. Uh and I it's expected to have much more TVL now after V4 is live, hopefully soon.

Um so, basically V4 is the newest version of Aave protocol. It tries to solve couple couple of different problems. One of them is problem of more like a finance [snorts] problem. Um if uh if all of the liquidity is spread out across the blockchain in different pods of liquidity, different pools, that means that when we borrow from one pool, the interest rate for borrowers increase in that pool, and all of the other pools have lower interest rates for borrowers. It means that there is this this inefficient capital allocation between the different pools. And the same goes for the for the for the depositors or for lenders. They deposit to the not so utilized pool, and now all of their like the yield is very low, unlike the other

pools where the yield is much much better. So, people should always transfer their their money between different pools to to make the allocation more productive for them. So, Aave V4 wants to solve this problem by putting all of the liquidity in one place and connect different spokes, and we're going to go into it in a second, that will make us be able to have different modes of operation, but all of the liquidity is always utilized as as far as that there is demand for it, of course. And the second problem or second opportunity we have here is we could innovate on top of Aave V4 by connecting different spokes and different spoke types to the hub, which either built by Aave Labs team or by different protocols. And by connecting them to the to the hub,

you could bootstrap them very easily, and you could just have access to a bunch of liquidity up to of course the DAO's approval, and they let you have some credit line, which is substantial, but it makes the innovation much more easier. And other versions, for example, Aave V3, it's very very hard to build on top of it without being outside of the protocol completely. Now, you could could be inside of the protocol with your new system, with your with your new innovation. Okay. So, the initial design, we're going to go on over the initial design, and then we're going to compare the old assumptions and the new assumptions to make the the innovation part of the integration part much more easier. So, let's see the the old design or the

initial design was to have users deposit money to the spokes. Spoke put the money inside of the hub. All of the money is in the same one place. And then when you want to borrow, you borrow money from the hub, goes to the user, and that's it. Very simple. All of the money sits in the same place. Uh the the cool part is that we could plug in those spokes whenever we want. We could increase and decrease their credit line, which basically means that we could let them either deposit how much they want or with some limit depending on how much we trust them, how much we want to depend on them. And the same goes for borrowing. If you want to let them borrow up to some amount, then we could limit it or we could just disable it completely. So, depending on the trust

we have on them and the trust that the technical team gives on them gives to them, then it will be basically limiting the risk that we are exposed to. So, the trust assumptions is the big thing in this talk. So, in the initial design, the spoke was completely trusted. Basically, imagine that you write smart contract, you know that the smart contract is not malicious because you are not malicious. And that means that you could do whatever you want from the spoke, and the hub will just accept it. Because if you say I want to get money, you say, "Ah, probably you should be able to get it, so I give it to you." If you want to report some higher yield that you're getting, "Ah, no problem. That's probably trusted, no problem there."

But that has a problem because maybe the work is much more efficient because when you trust, the efficiency is higher because we just do stuff immediately. But the problem is that when we want to connect some other third-party contracts, different new spokes that a lot of talking about a lot of developers here, but a lot of people wants to build new spokes, already built new spokes to connect to the hub or to Aave V4 V4 hub, um we need to trust them. And maybe you don't want to trust them, maybe we can't trust them that fast. We we don't want Aave Labs team to be able to be the bottleneck for innovation. So, the change in the trust assumptions from the fully trusting the spokes to be very suspicious about the spokes. Of course, we need to have some trust that they're

not trying to rob us because then they could steal money money, but we can trust them much less and still have the same functionality. So, let's go over it and see the old design and the new design. So, what can break everything and break as you're going to see, but don't worry, none none of those things I'm going to show you today broke because those things are problems that happened before the code was written. So, it means that we caught them before, and we could prevent them completely. Um so, let's see. Uh so, okay. So, first thing is the the transfer function.

Whenever you want to pay the hub or deposit to the hub or repay, we in the initial design, what we did was go to the hub, just say, "Okay, take money from this address." It's a parameter like the from address is just a parameter that the spoke provides. The hub sees that parameter, just say, "Okay, no problem. I will transfer from this address to myself, to the hub, and then if the transfer succeeds, great. Now, money has been transferred, so I could give credit to the spoke." And that's it. One easy to notice problem is that you also might provide the hub itself as the from address. So, hub will transfer from hub to hub. That in most cases just works without regards to the balance of the hub. So, even if the balance is $100 and

you say transfer 1 million, it usually works because it's a short circuit in the transfer from function or transfer. So, that's of course is wrong because it's going to succeed. There's hub will think the spoke deposited $1 million when he didn't. The the balance is the same, and then you just get credit for $1 million, and that's of course not good because then you could withdraw it. That's not good or you borrow against it. And another problem that might happen is that the spokes are just fully trusted in a way that you transfer from any user that approved the hub already. So, even if the user is not doesn't know the spoke, if we just connect the spoke to the hub and give it permission just to deposit, which would be very safe, you could just steal approve us from random

users that use this asset in different spokes that just approved the hub. And that means that we could make the hub steal money for us and give us the credit for it. And then, if the if the spokes are fully trusted. But if you want to enable third party, then it's less good for us because now it's another thing we need to check. So, instead, what we can do is we can give the permission and the responsibility of the spoke of the of the transfer to the spoke. That means that from now on, the approval will get go to the spoke. Spoke will transfer money from the user to the hub. The hub doesn't need to trust anyone. They don't just need to verify that his balance increased. So, that means that now whenever spoke goes to the to the hub

says, "I want to deposit this amount." Great. You deposit that amount. I will check that my balance increased by that amount. And and I the hub doesn't take money from anyone, gives money to anyone, and now there is no trust that the hub needs to do outside of the spoke, and the user don't need to trust the spokes anymore. Sorry, doesn't need to trust other spokes, only the spoke they want to trust. So, that helps the user or helps the hub to have less trust in the spoke, which this which is the same the same functionality, basically. Here we could transfer to the hub, here we transfer to the hub, but now we have less trust.

Okay. So, now deficit. So, deficit, for who doesn't know, is basically like if you go to the bank and you have credit line, let's say 30k, and you borrow 30k, and then after a month you go back to the bank and say, "I can't pay. I'm bankrupt or I can't pay." They just remove your your your loan. You are not paying anymore. They're not going to collect any interest on it and just write it in the books as a loss. They lost money. Uh same goes for deficit. If the spoke in the in the happy flow, the said happy flow, like this would not happen a lot, but when it happens with a legitimate spoke, the spoke could draw or borrow funds from the hub, then if the collateral is not enough, maybe price crash, maybe interest accrued too

much or something happened. Then it might report deficit which means that I cannot the spoke is telling the hub I cannot collect from the user these funds to return to the I'm sorry. So the hub just records this as a loss, put it in deficit variable and later the umbrella system or some system would resolve it. But for now the debt is gone from the from the spoke. That means that the spoke now is able to just draw again. Because imagine they just go to the bank, have a 30k credit line, you use it, you tell you say to the bank I'm not paying and then you're not paying and then you get use it again. Just borrow again 30k, again not paying, again 30k, you just drain the system. So this works if the spoke is trusted and they won't just print money

and just steal money from the hub. But once we want the the the system to be not trusted or the spoke to be third party that we don't trust or check less, then this would not work. The solution is very easy. What we do is just put the deficit of the spoke as a part of its credit line. That means that if you draw 30k or let's say $1 million, you borrow $1 million and you report deficit on the $1 million because you can't collect it from the user for some reason. Sounds like shady but let's say it can happen technically. That means that this $1 million is still a part of the credit line. It's still being utilized. So you can just say I report deficit, I can't pay but give me more money. You cannot take more money

that you haven't paid yet. So that means that when you try to draw again the second time, you just revert. So now the hub protects itself. That means that the spoke could borrow from the hub at any given point up to the draw cap up to the credit line and and the deficit is a part of that. So that means that we can trust less again, trust less in the spoke. And this credit line will be configured default by the risk managers depending on the collateral the spoke have, depending on who build it, depending on the trust that maybe the developers the Avalanche team will give in the spoke and many more reasons but you could borrow up to that limit and not more.

Another problem with the deficit because deficit is very unique is that also the rounding of deficit. For the system to work, we had to use precise numbers much higher precision than the asset precision. That means that for example, if we draw in dollars, let's say this is the lowest amount that we can draw is is $1 and $1 and the precision of the inputs will be much higher than that. Let's say 1 cent which is the only two decimals more, usually it's six decimals more or more but let's say two decimals more. So we can report deficit on 1 cent which means that basically the spoke can say, oh I can't pay this 1 cent. So we have two options when we do it. Because we record

internally the the deficit in asset terms because that's how much we're not getting paid. So we can choose either to round it down to zero up to one. Either one of them doesn't work. If we round down to zero, then we could just report deficit to smaller than than $1 amounts and then the debt is gone and the deficit is stay zero because we round down to zero, round down to zero. That means that basically if we borrow let's say $1, let's say that is the draw cap, $1 and we report deficit 1 cent 100 times, we just round to zero. So there is no deficit, there is no debt and we just didn't pay anything and we could borrow more which is not good.

Or that was what chosen in the end. It sounds like it should work to round up. Basically means we're going to utilize more of the credit line than what the spoke was meant to. So we're punishing the spoke for rounding for this rounding. Basically imagine that we borrow $1 and we report deficit 1 cent. Round it up which means that now we use full $1 of the credit line just for the deficit and then we owe extra 99 cent for the debt. And and that that is okay because like we only check the credit line when we borrow. So that's okay. But if we do it again and again, let's say 100 times because we have 100 cent in a dollar. That means that we could be in the deficit of $100 and we initially borrowed only $1. That means we basically printed assets to the

system. Total amount of assets in the system increased without us even transferring money to the system. So that means that we printed money. So we donated money to the to the system without without transferring anything to it. If if you transfer assets to the system and by that donating money, that's okay because you lost assets, someone else got them. That's okay. But here we didn't transfer any assets. And and by accounting alone, we created this false inflated asset. And and that is a problem. Because we can just basically print money. And again, that's okay if the spoke is trusted and if everything is okay.

But if the spoke is not so trusted or we want to do it faster, what we will do instead is just to not round. We can just take the precise value that the spoke is reporting and then the invariant of the property that we preserve here is that the sum of debt and deficit together is always the same across I was able to report deficit function if we borrow it, increase of course but across the report deficit function, it was dollar and zero and then it's 99 cent and 1 cent, 98 cent and 2 cent. The sum is always one. And that means that we cannot donate money from thin air without transferring actual assets.

Okay. So now we have the risk threshold. This this this mechanism is very cool. Like I I really like it. Basically what it does is so risk premium shares are the way of the system to compensate users for risk that for excess risk that they bear because of risky lenders. That means that if you have sheet collateral that you borrow assets against, that means that you pay higher interest. For example, maybe if you the base interest is is 5% and you use a not so good collateral, you might pay 7% or 8% or maybe or maybe 10%. That means that this needs to be accounted somehow.

And the way that we do it is we let the the spoke fully we fully trust the spoke to just take this take this number and report it to the hub. We just trust them. And if we trust the the spoke to do it, as you see the red bar which is red is not good, it means that maybe what if the spoke just says my shares is max uint. So all of the calculations we do based on this number are going to revert. So this asset is completely stuck, completely lost because we trusted this input from the spoke. And that means that the sum of all of these premium shares is let's say max uint and that means that anyone trying to do any operation in any other spoke and also in this spoke would revert because it's the numbers just revert.

And that's of course is not good. So the way to resolve it is to just trust less in the spoke and limit it because we know that there is this max amount of risk attached to the debt. So we could just limit and not trust the spoke and we just limit it up to the upper bound, the max upper bound that it could be to basically prevent the spoke from over reporting. This will cause a malicious spoke or a wrong spoke to just revert whenever you try to report too much. It it works. Like it you could try to do it and then it reverts and then the system works. You just revert, you cannot do the operations you want to do but the system would continue working because we don't let you report the higher number. We don't trust you to to do it. You could

do up to the max. And this is a very very simple idea which is preventing inflation, crazy inflation of assets or loss of the system because you could also print money in that way by increasing the rates even if the numbers are not reverting completely. So the main conclusion here for this talk that anyone can write a spoke. There are a lot of teams already written some spoke or or it's a work in progress. So please feel free and encouraged to write new spokes, have new innovation on writing cool new technical financial instruments based on Avalanche before. It could help you bootstrap your protocol or your spoke. And and it will be very much more easy for the Avalanche team to make sure

that the code is safe because of this new design and if it's cool enough, hopefully I could look at it too and see your cool code. And and thank you very much. >> [applause] >> Thank you for presentation. Anyone have a question? No? Anyone? Yes. You said that you got these before the code was written. Is that like actually before the code was written? Okay. How did you think about the process? So basically what happened is that Ava had an onsite last year and we participated in the onsite and there was some stuff

like they were talking about what could what could or could not happen in the and what they want to be able to build on top of it. And during this process or before the like during the design phase, was talking with them and trying to help to break the system just before like they have the code already. So we said, this transfer from like it's easy to see it might be a problem but that has also the other risk of the transfer from anyone and trust [clears throat] that you give and basically every every part of the system that you want to build this feature on top of, then you think what can break and then even before like you don't need the code to think about these things.

And and and it's very annoying when you already written the code and then you need to change everything because you change the design. So do it it's much more easier to do it before. So it's basically a combination of invariants and then like two security researchers sitting down talking about a system and you know, what can you break in the system? You you want someone to explain the system and then like what I like just to tell them explain to them the system and then I try to break it as fast as possible. Like with all of all of like some ideas work, some ideas don't work, but it's it's fun to try to like because it's very productive. Like what do you want to do? Oh, but this won't work. What do you want to do? This would not work. We need to change this.

It's very fun. Thank you. Yeah. Another question? Okay. Thank you. >> [applause] [music]