Approaching security with Aave V4

Transcript

is on cool great nice to see you guys everyone we I was already here yesterday I see some familiar faces so that's pretty cool uh quick introduction I am my name is ailio I work uh for aabs as a contributor to the a DA and we are currently involved as um contributors to the Dao uh to that velop like the new version of the protocol uh long story short is that a few months ago aabs came out with a proposal to implement a new version of the protocol uh this new

version of the protocol steams from observing how the protocol has been behaving and evolving over the last couple of years we just saw the great presentation from Ernesto from bgd labs they are the main uh contributors and Main maintainers of the other protocol and they have being responsible for some very interesting up upgrades of the protocol they introduced liquid emotes they will be introducing the umbrella uh upgrade for reamped tokenomics and like developed around go and we have also seen the procedures that are in place uh in the within the Dow to make sure that any uh new feature any advancement any upgrade to the

protocol goes as smoth as possible and uh without any risk for the users and this was also when we started um brainstorming about what we could improve with AV before this was also one of the I would say one of the topics that we discussed so what was the process the thought process behind like the idea of a before so what we have seen with uh V3 is that there are quite a few great um I would say features and great um powerful points for I3 that

make make basically make a protocol the largest uh defi protocol in terms of dvl so there are many actually I just pointed out like what I believe is uh relevant uh to me for this particular presentation so I can think like the great Capital efficiency of the protocol because the pull pulled approach of the assets because some of some features that the protocol implements like emote and most recently liquid emotes introduced by bgd Labs uh which allow basically higher Capital efficiency whenever you are using um whenever you are using assets that are kind of correlated with with each other uh because of the pool model we

also have uh great ux for for borrowers because uh rather than having multiple positions to manage and rebalance uh as it could happen for example with protocols that have that higher uh Capital segregation uh in a in general you can manage everything in one big position and like collaterals areat treated homogeneously and depth positions as well so in instead of having to uh move your Capital across different positions that are maybe single collateral single borrowed assets it's much easier to manage from a user perspective um and what are some of the minus of the current implementation that

we believe can be improved uh over the current version of the protocol so one pretty clear feature that we are missing at the moment is that we are basically unable to price risk efficiently so one of the main problems with wb3 is that we do have quite strict risk management but the only thing that you can manage there is actually risk exposure so you can say how much you want to be exposed to a certain asset but that's actually not enough because you should be able also to say how much a certain asset should pay for that risk that the the protocol is being exposed to right so H for a collateral is not enough to be activated

as collateral and to have certain cups that limit exposure but it should also be possible to say say that a certain collateral that bring a different risk profile should be paying a different um different amount for the liquidity that is provid provided against that collateral right one example is like the CRV situation that we had a few months ago where there was this large position that like at some point went under the threat of uh liquidation and because it was so large it could have basically posed a risk uh for of insolvency for the protocol and what the ideal course of action uh for the now in that situation would have been uh to actually

rebalance the risk by increasing the capital requirements to borrow against CRV so that the the the position is either paying uh an amount that is equivalent to the borrow Capital that is uh that the amount of the capital that is borrowing or that borrower is incentivized to leave the system and to reduce the exposure and there therefore the risk um one it's harder with the current implementation to allow permission permissionless Innovation uh one example is that like the current approach that we are having with uh um custom hok markets where you can basically uh have

markets that are deployed and uh configured for certain specific use cases so are thinking of the heater f Market of the Lio Market shortly after will be the atina market and so on and so forth all of those require quite long lengthy uh uh processes in terms of deployment and in terms of uh governance uh requirements like variety of proposals the full governance process and so on so forth it would be better in my opinion if there were there were a way for users to actually and for entities that actually want to use and want to configure the markets for their own needs it would be better if they could do them by themselves and then eventually being

endorsed by the Ava and being supported with the risk management and everything else that comes uh by being endorsed with the Dow there is a lot of governance work with the carent implementation so besides Le deployment of the new markets we have seen uh there are a lot of risk parameters change uh there are a lot of um configurations that are applied all the time H the mark the deployment of the market requires a lot of governance work and from a strictly security perspective the I3 code base is really big so we are talking like 7,000 lines of code uh and can we do actually better can we optimize it further so to reduce the

surface of attack so all of these are the thoughts that basically uh brought us proposing the new version of the protocol I already did some present on the topic so I'm not going to focus on the features because I would be talking for 5 hours so like I will be very quick on this features because I want to focus more on the architecture that we are thinking um in terms of features I already mentioned uh in the past like Risk premiums Dynamic risk configuration of f interest rates uh these three are aimed at solving mostly or reducing mostly the impact of these two uh shortcomings that I mentioned before inability to price risk appropriately

and reduce the governance overhead so for example Dynamic risk configuration will allow Risk Managers to create uh new risk configurations for only for the new users without affecting past users uh which will basically allow to the Dow to offset completely risk management or almost completely risk management without changing the security guarantees of the system um fuds interest rates which is uh which is like um uh control mechanism that we are implementing right now and it's uh with the idea of being able to adapt the base rate and the slope Point dynamically of the interest rate curves

so that the interest rates can change accordingly to uh market demand more quickly without requiring requiring governance work and then the risk premium that I already mentioned before is like the giving the ability uh to basically price the risk of a collateral independently from from the others uh so these are subset of the features that kind of cover some of of the aspects that I mentioned before but I what I want to uh Focus today is a bit more going a bit more in in detail on the architecture that we are thinking about and how it will look hopefully when the implementation is going to be

finished so uh part of the work that the Dow does today I think is due to the architecture of the a protocol because of the design of the a protocol the pool design and like the monolitic approach that we took when we designed a V1 V2 V3 it is a bit harder to to do um to allow permissionless changes so for example listing an asset requires again a governance process with accordingly a risk evaluation that is done accordingly um uh Oracle creation and so on and so forth uh deploying new markets as I mentioned before requires a full governance process plus the complexity of trying to bootstrap the market

because the market will start from zero liquidity and to attract users to the market you will need to some find some way to bootstop liquidity and risk configuration like there is no way of changing risk configuration without affect affecting P users so every time you try to reduce the liquidation threshold if you if you want to have board an asset for example you need to slowly reduce it by one two percentage point to prevent a users from getting Mass liquidated and so on so forth there are a lot of aspects so a very general I already mentioned in in all in previous presentation it's a very general uh um abstraction level uh we are thinking of separating part of the

protocol in a way that we can create a more modular approach so what I mean by that if we look at the current I have a protocol implementation but even the past that's the in the part that kind of sparked this idea or modularizing a bit more the architecture uh in the protocol with that is a monolithic piece of software where there we have this PO contract that basically handles all the user interactions of course internally there is modularization so we have split the code in libraries subcontracts and so on and so forth but this modularization is I would say uh um top down because top level of abstraction you don't see it you see one piece of software is the pool and then

going deeper in the architecture we'll see the different aspects and different modelization and the within the code and we can basically Identify two main liers within uh the the other protocol uh code one is the liquidity management part and the other part is the borrowing management so if we think specifically about the liquidity management management and we observe how that part evolved over the three iterations of the other protocol we can basically notice that there was essentially no change so everything that was related to liquidity management interest rate management indexes accounting and uh positions management and so on and so forth is

basically unchanged compared between V1 V2 V3 most of the changes that we can see were happened at the uh borrowing part where we kept adding features so we added a stable rate uh we added the credit delegation uh we added e mode isolation mode liquidy modes recently uh different liquidations mechanism and so on and so forth so uh from this idea and this and by noticing this particular aspect of the protocol we started thinking okay why we don't take the liquidity management part out since it's basically un changes since from the beginning and then think of it as a component that can live by itself

and then the borrowing part we generalize it in a way where the liquidity management part doesn't actually know about the borrowing part this makes would make things much easier right this is also uh kind of an evolution of one feature that we added in I3 that is called portals so uh we portals the idea initially was to um essentially uh allow other entities of other markets POS possibly cross chain uh to draw liquidity from the largest other markets to bootstrap them on to or to optimize the capital efficiency right uh this Vision actually never uh took traction for a variety of reasons because we when

we developed V3 we were thinking that probably l2s would gain much more traction earlier much earlier than we actually are witnessing so uh that reality has not really fully uh realized yet and also like there were a serious complexity relates to bridge security and so on and so forth which I'm not going in in detail right now so whenever when we pair like this idea of portal which it was basically first attempt to uh move liquidity out of the markets to optimize the capital efficiency and their realization that we have a part of the protocol that never changed essentially since the

beginning this brought like the realization that actually we can take this part out and start developing it independently so that then we can build on top of it other modules that actually also work independently and this will hopefully bring much more uh simple code better Capital efficiency and uh also reduced governance overhead as we will see later so uh we are currently developing for before this component that we call liquidity Hub uh the liquidity Hub basically handles everything that is basic user function so Supply and withdraw handles the accounting so interest rates accounting the interest rate strategies and the uh

liquidity premium um and is actually completely agnostic to uh the modules that will draw the liquidity uh and will extract the liquidity out of the liquidity layer the liquidity layer doesn't need to know what's going to happen with that liquidity the only thing that needs to know is that like modules that will build on top will pay the interest that liquidity Hub is actually asking for so the liquidity Hub will have like a generalized accounting for all the modules that we buil on top of it and it will not know what's going to happen with that liquidity you know so it can be a borrow module that actually works exactly the same as V3 it can be a module that I don't know borrows against RW that are um that are

um held in isolated vaults can be a lot of things as we will see uh later so what about the borrowing it can be completely if we follow this design it can be completely abstract away so we can take all the features of ib3 and Implement in a module that works by itself that doesn't need uh any knowledge about the inner dynamics of the liquidity Hub except the ABI so the the the interface that allows communication with the liquidity Hub and can be tested separately which is great uh liquidity Hub can be mocked so we can build the liquidity Hub and the borrow module in parallel which is something that we could not do with previous

version and most importantly we can have a variety of borrow modules not just one you know so um that's part of the thought process that is shaping like the form that a before is taking so we call this we call this a hub spoken design so Hub spok is in general is a very common architecture and um modularized design uh philosophy that is very common in a variety of Industries in common in uh transportation is common in uh data science a lot of different um fields and so the idea is that we have this liquidity Hub at the center that handles

the assets and handles all the accounting and then we have a variety of spokes we have spoke number one number two number n potentially this box they draw liquidity from from the liquidity Hub they use them in a certain way they will return it at some point by paying a certain interest plus a premium that's the idea okay and so this generalize the the sign that we saw before and opens up to the possibility of having multiple spars within one liquidity layer so uh this is the general flow operation of how it would work uh users apply liquidity to the liquidity Hub liquidity Hub tracks the total liquidity the US

usage ratio the interest rates and the average premium the spokes whenever a user requires borrowing draw liquidity from the liquidity Hub uh and liquidity Hub keeps track of the total liquidity drone and eventually the liquidity drone per spoke so that you can set caps for every spoke eventually to limit the exposure that the liquidity Hub gets to a certain spoke and and spokes whenever they return the liquidity back they pay the liquidity rate that was accumulated plus a premium and the premium is decided by the spoke through the risk configuration of the specific spoke and spokes can fetch the balance spokes have one major requirement when when users borrow liquidity the major requirement is that

there is a proper collateralization ratio that is not violated otherwise there is risk of insolvency so the idea is that the spok can fetch the balances from the liquidity Hub to understand uh the capital allocation of a user for example and how much collateral they have right so this poses a few challenges so what we are thinking is okay how do we manage uh multiple spokes fetching balances from one liquidity Hub that gets can get very very complicated very quickly and the reason is that it's really hard to understand uh when a user supplies liquidity uh if for example a user is borrowing from a variety of different spokes to which spoke book that collateral is being allocated to

right so uh we are thinking of a variety of designs one uh one design that we are thinking about is the potential of using for example a master book so we will have a master spoke and that Master spoke is the only one that is allowed to um draw liquidity from the liquidity Hub and also use the accounting within the liquidity Hub to calculate collateralization factors and then we have secondary spokes that can be n an unspecified number which the only capability they have is basically to uh draw liquidity and return it but the collateral needs and the collateralization ratio needs to be accounted in and uh stored in an

different uh U venue than the liquidity Hub uh so basically this would be a fully generalized portal Design This is currently the design that we are evaluating for the uh for the liquidity hub and the the spoke design but it's not the only one the cool part is that the thanks to mod modularization we already started liquidity Hub and we have the luxury eventually to decide which design we want to use much further down the line because because we can afford to develop liquidity Hub basically independently from the rest of the protocol so um the secondary spokes if we go with this design which is still not 100%

guarantee but it's is currently the design we are leaning into the secondary spokes can be anything they can be isolated collaterals they can be rwa based or they can even be other liquidity hubs which is the cool part that enables a lot of interesting aspects that I will uh talk about shortly uh so if we look at this diagram here I put like an example uh that how it could potentially look uh going forward so before I explain uh in detail this diagram like I want to uh like um clarify that one of the features that we

are going to implement in V4 is called smart accounts so one we want to give the users the ability to borrow from a without actually supplying the collateral into a this was a feature that was requested for a long time H the collateral would be in a separated uh smart contract that it could be a vault it could be a safe we are actually evaluating to build on top of the safe so you would be able to borrow directly from your safe within the a without supplying the collateral first into into the liquidity Hub and this was requested uh for a long time and the reason why users are requesting it is that either they don't want to take the risk the liquidity risk uh by earning I don't

know like just a few percentage point of Interest or they cannot for legal reason mix their collateral with other assets of Unown origin within the a pool so this would basically help them allow uh to to solve and then we have H isolation mode that we already have in V3 but it will get we with this design we'll have a completely different uh approach uh within iv4 so in iv3 is implemented as a standalone feature in within uh the monolitic design so it's a feature with with a variety of edge cases uh with this approach actually isolated asset they become a separate market so it's going to be a separate Market with a

separate liquidity Hub with only assets that match the match the same risk profile and what we can do is that we basically uh connect this liquidity Hub through a secondary draw module to the main liquidity Hub so that the dowo can for example give to the isolate isolated assets pool the ability to draw liquidity up to a certain cup to uh to the from the main liquidity Hub so uh you have basically the same design that we have today in terms of um uh depth ceiling but with within a separate model a separate liquidity lier and a liquidity Hub which also gives the

ability to eventually users that want to get exposure uh to Higher yelds by supplying direct directly against isolated asset they can do so we can we cannot have this feature as it is implemented today in av3 so with this design we can have users going straight to the secondary liquidity hub for example and earn a higher interest because like assets that are isolated usually should pay thanks to premium a higher interest rate and also the smart account spoke could for example just draw liquidity from the liquidity Hub and then keep the collateralization in safe wallets for example where uh a custom hooks can be installed to prevent

users from moving asset if they are borrowing and so on and so forth so uh this particular uh diagram is interesting because it shows how uh rather than having a very big and complex monolithic borrow module with this design we can split them in separate parts and have smaller easier to test easier to implement modules that actually interact with one send coordinate main coordination Hub which is the liquidity Hub um so to to finish because I think I don't have any more time yes ER the from a security perspective and uh like ease of implementation perspective there are

a variety of advantages like spoke and liquidity Hub can be implemented separately which is exactly what what's happening at the moment because we are mocking the the the features that we expect to have into the borrow module and and we can actually implement the liquidity Hub uh by itself uh thanks to the uh completely obstruction that we are uh building into it everything can be mocked which is something that we could not do before so we don't really need a fully functional liquidity Hub to test the borrow module we don't really need a fully functional borrow module to test the liquidity Hub that's very cool and that makes implement the development much easier because then we can

implement for example the modules that we saw here all of three in parallel we don't need to implement like them as a unique uh like um monolithic piece but we can Implement them separately and uh in the future it will be also easier to replace spokes or Implement new spokes so there would be a lot more to talk I don't know why this is pixelated but it's it's good enough and and yeah there will be a lot more to talk about on this particular topic it's been very exciting uh for until now and we hope to have something to show uh to

the DA and to the rest of the community very soon uh that's it thank you guys for listening and if you have questions I'm well happy to answer yes [Applause]