DAPPCON 2024: Fourth Time's A Charm - Nextgen Liquidity Protocols With Aave v4 - Emilio Frangella

Transcript

hi guys my name is Emilio I am from avara I am VP of Defi avara and I currently leading the efforts for building new Innovative products for for avara for a labs and for uh dial so today we are talking about uh the next iteration of the a protocol which is uh the version four uh lot of thought went into the design of Av V4 uh we are talking a lot about this protocol uh these days um I have I have been saying that when we designed V3 and

we released V3 at this point more we started designing it more than three years ago I was thinking think that actually there would not be a new version of a I was thinking that like the V3 version would have been uh the last version of the protocol eventually iteratively building on top of that and I I was wrong because then uh over the years while we were analyzing how users were using the protocol uh how the Dow was interacting with the protocol the amount of work that the Dow required to uh um interact act with the protocol we realized that there were a lot of margin for improvement uh so the main goal of

before before is going to be uh increase Capital efficiency compared to V3 uh the risk management so when I'm talking when I'm saying improved risk management I mean um improving the way the governance actually uh manages the risk and the way the users perceive the risk within the protocol uh reduce again the the workload for the governance so that there is and with the goal of uh minimizing uh governance uh the need for governance within the protocol and also definitely to increase uh the modularity and extensibility of the protocol the I3

the V3 version of the protocol is already uh quite modular and extensive um extensible I would say um uh but we will take things uh one notch further with before so I'm going we I don't we don't have that much time so I'm going without further Ado I'm going straight to the new features and the new the the main thing I want to talk about the first thing I want to talk about is the new architecture of V4 uh so the main difference that is going to be between V3 and and V4 the highest liar of obstruction in terms of Architecture is uh the way uh that

liquidity is managed and how um uh it it's going to be possible to build on top of A4 so in the previous version uh here uh we had like separate kind of monolitic protocols where uh the liquidity provisioning part and the borrowing part were merged together one another uh what we noticed uh so this basically created the need for different iterations of the protocol where it was required every time to migrate the liquidity from one place to another and eventually if you would create separate

markets for example a at some point uh aabbs released like the a Arc that was a kind of a proof of concept for uh institutional adoption of defi uh that would ALS be separated from the other markets uh so what we kind of uh realized when we start thinking about how the new architecture of uh V4 should look is that actually the liquidity provisioning part pretty much never changed across like different iterations of the protocol between V2 V1 V2 V3 and also in V3 we had added a new uh feature back in the days that we call portals uh portal initially was designed for um uh

facilitate uh cross-chain deployments of liquidity so to be able to move liquidity across different chains uh it was a bit ahead of time I would say because back in the days when we introduced it probably uh the uh multi-chain world was not as developed as it is uh today but actually that feature uh and when we started thinking about how to use that feature of the V3 the portals feature made it pretty clear that actually that feature could be extended uh further to make it like integral part of the architecture of the new protocol iteration so uh from that feature of av3 portals we basically um inherited like the creation

of one single liquidity layer uh which is completely abstracted by everything else that is buildt on top of the protocol so compared to here where you have uh liquidity provisioning and borrowing part all merg together in one single uh protocol instance here you will have a set of smart contracts that are completely independent from uh borrowing or uh or cross-chain uh designs for example and where the liquidity is going to be uh managed and this the liquidity lier is going to manage uh Supply and withdrawal so liquidity is going to manage limits uh so uh draw cups uh uh Supply CS is going to manage interest rates it's going to

manage liquidity premiums uh that is a feature that we will talk uh about uh uh immediately after so uh the interesting thing is that this is going to be completely segregated and the borrowing part is going to hook into the liquidity layer and is going to work in a completely separate independent way so the the cool part the cool thing of this is that in the future if there there is going to be the need to build new features on the borrowing side of things you can just swap out the borrow module for a new borrow module or even having them working in parallel and plugging into the same liquidity layer uh drawing liquidity and um reducing or

eliminating the need of migrating for example liquidity from one version of of the protocol to another so this is going to be the major architectural change there are going to be uh other um uh implications of this particular architecture uh some of which will be unveiled when the protocol will be released and I think it's going to be pretty interesting because the extensibility of this will basically uh help building on top of it a lot of uh unique features some of of those S will talk after me regarding the visual proposal so uh one thing I can anticipate is for example this unified

liquidity layer is going to be also the base liquidity layer for an eventual Aven Network that might come in the future uh where this liquidity liar is integrated at a lower level of obstruction in the network and where users can tap into it directly and seamlessly and other protocols can build on top of that as well uh so uh from the uh new architectural design and from the um unified liquidity layer the major change the first major change I want to mention is the introduction of uh what we call uh liquidity premiums so one of the problems that we noticed uh with V3 was

the inability to price liquidity accordingly and properly uh what this means is that on a in general which has a unified approach to liquidity we don't segregate liquidity into the a design but it's actually uh there is for example one uh single big us DC pool or one big Big E uh liquidity pool what happens is that whenever an asset uh for example w s or W BTC uh gets uh collateral status so you can borrow against it it immediately access accesses the whole liquidity available in the protocol without any pricing

difference compared to assets that might already be in the protocol so for example on the ethereum market I would say that the safest uh collateral that you can use in the market is e right because it's uh we all know the property of is is trustless is permissionless it's the base uh asset of the network where gas is used uh it's very strong and very uh safe asset is super liquid on the market so I would say that for for example when ethereum uh we can consider e as the less uh risky asset within uh within the protocol and other assets built on top of that risk because for example if you can consider r s e

which in which in terms of pricing is basically e with an additional risk that we need to consider due to Smart contract uh to the smart contract implementation of Lio uh there is a slashing risk uh there is a secondary Market liquidity risk although like the way a uses it is that is quite mitigated U but it sounds pretty natural to me that probably users using rra S R SAS collateral they should not pay uh the same rate uh that eth borrowers are paying so if I'm supplying eth and borrowing usdc I'm paying one rate if I'm use WRA s this brings a different a different risk profile and this risk

profile file is not completely mapped into the protocol because I have no way in V3 to differentiate between the interest rate that I'm paying here with this asset as collateral and the interest rate that I'm paying here so uh this is one major Improvement that we were looking for uh to implement in a V4 and the way it's going to work is that compared to the V3 version where there is one single interest rate curve uh assets will still have one interest rate cve but that interest rate could we refer to the base uh risk let's say risk-free asset that in the case of the av4 it Market could be it for example so the interest rate cve will refer to the

interest that borrowers are going to use if they use e as collateral and all the other assets will will have a a premium on top of the interest rates and the premium will be decided depending on market conditions on centralization dependencies or on Smart cont risk and so on and so forth so we can imagine for example that if uh if uh borrowers sorry if borrowers using eth as collateral are paying usdc at 3% probably rst eth is going to be paying a 0.5% premium on top of that so borrowers using rap as collateral they are going to pay 3.5 and maybe rra BTC can be considered a bit uh

higher in terms of risk because there is some additional centralization risk in the wrapping process of BTC so maybe we can consider 1% premium so users borrowing using rbtc as collateral they will they will pay a f further 1% uh rate on top of the base rate this uh the one of e and maybe isolated assets isolation um mode is a property of V3 that will be retained in V4 isolated assets that usually longer tail risk will probably have further higher premium uh to compensate uh suppliers for the additional risk added to the protocol so um I personally think that

this this was one of the missing missing links in uh in V3 and this will basically help uh suppliers getting adjusted more risk adjusted returns and borrower paying a fairer uh rate for the risk that they for the overall risk that they are bringing to the protocol so this was the first feature this is going to be integral part of the uh liquidity layer and going to be implemented at the at the level of the liquidity layer uh so next feature um again this is also going to be integrated at the liquidity layer and

it's going to involve the adoption of automated interest rates uh why automated interest rates um I have to say that currently interest mod interest rate models on a work fairly well um the only problem with with those like in in for those who are not familiar on with how interest rates on a protocol like a work uh this is like this could be the curve of typical interest rate curve of a um asset on top of the other protocol where uh um the interest rate increases depending on the utilization rate of the asset so the more demand there is the

more the interest rate increases and this aims at leaving a certain percentage of the total uh values applied to the pool available for user to uh to basically be uh fairly fairly uh certain to be able to withdraw pretty much at any time uh so the idea here is that the interest rate start from zero uh reaches a point increases fairly slowly with a certain slope until a certain utilization and then spikes up to basically either incentivize more users to bring liquidity or borrowers to repay to bring uh back the liquidity to safe levels so the problem with V3 is

that like a is currently deployed on 13 different networks and there are like 100 assets available uh some of those are the same instance of the instance of the same asset across multiple networks and whenever you need to adjust interest rate CES probably you need to adjust across all the markets and there a lot of governance work and uh uh risk management work as well so the goal here is to automate these strategies we are going to use an approach that is kind of novel in in the blockchain world uh usually until now protocols like a they use like uh PID or variation of P controllers uh which can be quite uh

which they can sometimes be quite reactive to changing market conditions these interest rates here can change either because there is uh for example variability in how users Supply liquidity to the protocol or because there are market-wide movements so for example we have seen lately in there are there has been quite strong uptrend interest rates have gone up across defi that's kind of Market driven is not necessarily related to how users are behaving on uh on on the protocol thanks to fzy interest rates we'll be using FY logic which which is a a mechanism used very um frequently in control theory to control environments and variables that

are hard to model or very computational intensive to model uh through formal mathematics we rather use uh rules that we call fzy rules tools to kind of model um uh humanik reasoning here where you decide basically on certain rules that might move this interest rate curve accordingly depending on market conditions depending on how users are using the reserves so that they optimize Capital efficiency for the protocol and they reduce or eliminate the need for governance to intervene and basically change manually this curve to adjust uh too much Market conditions basically uh next feature uh smart

accounts so here we are starting to talk about features built on top of the protocol on top of the liquidity lier a smart account is going to be uh needed to solve some ux issues of the V3 version of the protocol so in a V3 we have uh for example some certain modes like calling e mode uh isolation mode I mentioned before uh this mode allow a users to activate certain features of the of the protocol but they have the drawback that whenever you activate such feature you can only use the wallet that you are using for that position so if you need another position like standard position for

example uh you cannot do it with one single wallet you need multiple wallets so you need to move your collateral to another wallet you need to fund uh with gas uh the other wallet and so on so forth so smart accounts first goal is to solve this particular ux issue so uh it will be built on top uh with some uh smart wallet um capabilities as well and will give the possibility to users to interact with the protocol using a single eoa and instantiating multiple smart smart accounts that can actually manage uh different position with different modes and uh or even playing position without uh any particular mode

activated so another feature of smart accounts is going to be the use and the implementation of vaults uh this is going to satisfy one need uh that was expressed many times on the a governance forum for example and even um by U uh institutional uh customers uh so it happens pretty often that users might want to to be able to borrow from a without supplying uh the collateral to a liquidity pool because they don't want for example to they don't care about earning interest and getting uh uh liquidity risk they care more about uh just being able to borrow so with av3 this is not possible so if you want to

borrow you are forced to supply your collateral to a liquidity pool you will earn interest but on some collaterals this interest can be negligible so you might want to Forfeit that interest just to be able to borrow and have the additional security that you you are not exposed to liquidity risk uh so Vol is going to enable that and uh what is uh the way it's going to be implemented is that uh users using smart accounts will be able to keep their collateral into the smart account locked into the smart account and borrow from the protocol without supplying to the uh to the liquidity layer uh basically this will enable to segregate uh assets will enable to segregate liquidity risk and

the protocol will only be able to access will the protocol will automatically lock uh the assets into the the smart account so it will not be possible to move the assets outside of of the smart account and eventually the protocol will only be able to access uh the the Assets in case of a liquidation event so if you need to be liquidated um the product will access the assets and move the collateral to the Liquidator which will uh repay the debt for you uh another feature this are um moving to features that are implemented in the borrow module of a before another major problem where that we have always

had with all the versions of a is the um it's basically at the moment impossible to change some risk configurations especially referring to the uh liquidation threshold which you can also refer to as borrowing power so whenever an asset gets a certain borrowing power on av3 is really really hard to lower that borrowing power because if you try to lower it you are affecting all the users so potentially if you lower it to zero uh you could liquidate everyone so it's a process it's a fairly um uh intensive process you need to change whenever you want to lower the borrowing power uh you need to change the borrowing power uh very slowly by a few

percentage points to avoid affecting users and it's very governance intensive intensive because it needs to go through governance to not change the trust assumptions so this is going to solve uh this problem because with Dynamic risk configurations we don't we will not have one single configuration uh for every asset but we will have multiple configurations uh every time uh a new configuration is created a users that new users that will borrow the asset from that point onward will be uh hooked to the new configuration and old users will be will remain on the o on the old configur ation so you will have a situation where multiple users will have different

configuration and this will allow to segregate and reduce the risk further because you can change much more frequently without changing the trust assumptions this also means uh that uh Risk Managers can be offloaded risk risk management uh completely without changing the trust assumption so risk manager will be able to change risk configurations or even automate that using AI or using other for example FY Logic the same approach as the interest rates uh without changing the trust assumptions because you are not affecting uh existing users uh so this is going to be very very useful to further segregate risk and reduce governance uh

workload uh Stronger go integration uh for those who don't know it go is the uh Native stable coin of the a network is uh fundamentally uh integrated with a the moment by uh allowing under the hood disallowing under the hood like supply of go but rather meaning on behalf so with before before and the liquidity liar and go generation will be natively supported so no need to go through basically what is a trick to allow go to be Meed uh users we will be able eventually to decide whether or not they want to receive the interest from other

stable coins in go so if I'm supplying usdc liquidity I might be uh willing to receive interest rting go and the governance can use this for example to optimize interest rates uh interest return return to the users by for example reducing Reserve factor in case uh users decide to receive go interest there will be soft liquidation which is a mechanism already pioneered by uh cve uh with their CRV USD with some crucial differences because of the difference and the different way the architecture of uh a works and there will also be an emergency emergency Redemption mechanism similar to what liquid does today but uh it's going to just be an emergency um

mechanism it's not going to be um like part of the core functioning of go it's only if go sustains like uh prolonged the pegging event then the emergency redemp Redemption mechanism will will be triggered um there is going to be an improved liquidation engine here like uh the abv3 liquidation engine has been working fairly well over the years with minimal upgrades uh compared to the V1 version I think it's time to re renew it a little bit and this will be done by implementing variable close factor and liquidation bonus so users will be liquidated up uh to one Health Factor so

basically enough to bring the the position back to safety rather than 50% up to 50% like it happens today uh it's going to be to liquidate multiple position at the same time and it's going to be modular because multiple assets can have different uh liquidation strategies other goodies uh there is a lot more so there is um a post on the a governance Forum which highlights all the features we will be releasing uh when the time is um ready uh attch people paper as well which highlights more in detail how these features will be implemented but there are a lot of other features uh here that can be uh that that will be implemented I'm

thinking of automated asset of boarding where the mechanism to offboard an asset will be automated at the governance level um treasury management which is brings a lot of governance work at UH today uh where the governance might want to consolidate assets that come through uh their Reserve factor in one or or or a couple of different assets for example e uscc Uh liquidate custom customizable liquidation strategies governance action gas efficiency lot of stuff I really really recommend to uh give a read to the a governance uh forum and there is a post detailing all these uh features and how they will work so in conclusion uh

V4 Builds on the strong I still believe that I3 is quite strong protocol it is the biggest largest protocol by by tvl um in in the space if we exclude reaking and it's growing very nicely so I do believe that it's going to be uh V4 is going to bring quite a lot of improvements on top of that and is going to be um key for the AOW to maintain like the leadership in the space uh so it's the same designed for def for retail defi users as well for institutions so we are almost ready to go to uh a arfc which is the step uh for official governance approval uh for

the development of V before and I really recommend join the discussion on the other governance Forum if you want to follow and learn more about it that's pretty much it thank you so much ailia please give it up for you enjoyed it thanks