Aave 🛠 Aave Protocol V3

So, welcome everybody for coming to this talk. We are talking about Aave 3. My name is David. This is my pair, Miguel. Um yeah, we are going to learn more about the Aave protocol, new features of Aave 3.

Um uh yeah, first of all, what is Aave? Basically, Aave is a decentralized protocol, liquidity market that allows users to supply cryptocurrency. Um provide liquidity to the protocol and get some yield of it. Uh there's also other actors that is the borrowers that can can draw liquidity from the protocol by putting collateral. Uh first, they can use any listed collateral in any supported market like Ether, Dai.

Um also there is another actor that is the liquidators that take care of the healthy making the protocol healthy. They basically liquidate positions basically paying back the debt of borrowers that have risky positions or they are near under collateralized. Under collateralized. Um well, they we launched the Aave 3 like 1 month ago. Um it has received a lot of uh Well, it it was well received by the Aave community and basically we got uh the Avalanche market that is now with around 4 billions of liquidity located at the protocol.

And by the using liquidity incentives by the Avalanche project. And also we have the other markets uh that are with with a limit that I'm between 5 million and 40 million with organic growth. With the projects in six networks, six different networks. And yeah, we also have more markets like the AMM market. Um Um now Miguel will talk about the the new features about of Ave V3.

Um yeah. Yeah, you can. Thanks, David. So, uh yeah, the third iteration of the Ave protocol builds upon the foundational elements of the Ave protocol, which are instant liquidity, the A tokens, different interest rate strategies, and so on and so forth with with new groundbreaking features that expands from the increased capital efficiency to an enhanced decentralization. So, yeah, let's dig into the some of the new features of this third iteration of the protocol.

First, in terms of capital efficiency, we have portals. So, yeah, given the fact that we live in a multi-chain and multi-block world, having a way to migrate tokens from one chain to another in a seamless way is more and more important these days. While the previous iteration of the protocol the version two was deployed on multiple networks with meaningful TVL, it's true that there was no way to have all the supply assets flowing seamlessly from between chains. So, this is the point of portals. Portals is a new feature of the core contracts of the version three of the protocol that allows to allows the supply assets to flow seamlessly between chains.

So, in high level, it leverages the unique design of the A tokens. So, when these that bridges are able to take A tokens from the users in one chain and being a mint those A tokens into another chain. So, first, we'll need bridges that plug into the portals. This kind of bridges will be named as ports. Once they are kind of registered in the system, they will need to to call a couple of functions, new functions that are in the in the in the pool contract.

These functions are mint and backed and backed and backed. The first one allows the bridge to mint unbacked A tokens, which means that these A tokens don't have the underlying assets with them. And then, they will need to use the the the other function, which is called back and backed, which allows to back those A tokens that were already already minted. So, portals essentially allows these bridges to supply assets in a fair manner. So, when a user wants to move their A A tokens from the source network to the destination network, first, the bridges will take the A tokens from the user in the in the source network, then instantly mint brand new A tokens in the destination network and redirect it to the user.

And once the underlying assets, the real liquidity, has been moved through the bridge, could be the canonical bridge of the chain or whatever bridge in the in the ecosystem, uh, uh, then they will be able to back those already, uh, fresh new minted a tokens with the underlying. So, at the end, the destination network will have all the a tokens with the corresponding, uh, underlying assets. So, as you can imagine, this feature is really interesting because it allows the users to move their a tokens from one chain to another without losing a penny of a dollar and with the benefit of unwinding the position, which is, uh, really, really cool. Also, the efficiency mode. This tries to increase the the utilization of the capital that is sitting in the in the protocol because, as you already know, there is a lot of uh, assets and capitals that are are currently sitting idle in the protocol.

So, this is mainly caused because the the the risk parameters. The risk parameters in the system, there is one of the risk parameters in the system which is called the collateral factor. The collateral factor determines how much of an asset a user can borrow using an asset as collateral. So, having a 75% collateral factor on DAI means that a user can borrow up to 75 DAI with 100 DAI as collateral. So, if the protocol is able to increase this collateral factor, they will be able to increase the borrowing power of the users and thus increase the capital efficiency of the protocol, which is really good.

So, as you can imagine, it's not So, the con the the con the the collateral factor of, uh, the assets in the previous iterations of the protocol were a bit, uh, conservative because all the assets has its own characteristics, its nature, and even price different price volatility. So, as you can imagine, it's not the same having a user borrowing USDC against ETH than having the user borrowing USDC against DAI. The latter position is less risky for the user and also for the protocol. So, uh, this is because mainly because both assets are stable coins and also because those prices are the those assets are correlated in price. So, that's that's the main point of the efficiency mode.

What if we are able to group the assets in categories with the same characteristics, same nature, or the same uh, price volatility? So, is we can increase the borrowing power of the users in that cases. So, in the protocol V3, there are uh, high efficiency modes categories. We have the stable coins category with USDC, DAI, USDT, or even the the euro pairs. Also, we could have um, BTC variants or ETH ETH variants.

And let's see what's what's coming from the community in the future. It's going to be interesting. So, when a user enters uh, e-mode in one of these categories, let's say for example, the stable coins, the user will be able to enjoy a high borrowing power using a stable coins as collateral, but they will only be able to borrow a stable coins. So, they still can supply other assets and even use them as collateral, but only with a stable coins, they will only be able to maximize their borrowing power. So, right now, users in a stablecoin's e-mode, they enjoy a 97% of collateral factor, which is really good because they can borrow up to 97 die with 100 die as collateral.

So, this features will bring a wave of new use cases and new tools in the ecosystem like for example high yield high yield farming strategy, high leverage tokenized positions, also diversify risk market risk because you now can split your assets in in categories. So, yeah, it's going to be nice. Now, more on the risk and security side. First, we have the supply and borrow caps. This security measure is pretty intuitive because this security measure allows the community to set hard caps on the supply on the amount of the supply assets and the borrowing assets.

So, in this way, the protocol can control and modulate the exposure to certain assets in some way. Supply and borrow caps together with isolation mode is a good combination and interesting combination to modulate the exposure as I said, but also to list assets in a more secure way. So, until now, users assets were not listed in the protocol allows the users to use that assets as collateral and borrow any kind of assets in the protocol. So, theoretically, we could have we could have a user borrowing the whole capital of the of the market using one single asset as collateral, which is far from ideal because that would mean that the protocol is completely exposed to that certain asset. So, uh isolation mode, which is uh inspired by the MakerDAO, I don't know if you know it, but in MakerDAO, you have different vaults and you can and these vaults has a some a particular asset for each and they also have the asset ceiling.

So, you cannot mint more than the asset ceiling using that specific vault and that specific collateral. So, isolation mode works in a pretty similar way. Users in in so, the community can list assets in isolation mode and users using this asset as collateral, which is isolated, they only will be able to borrow up to a certain limit uh of assets. So, for example, in this case, we have the token two, which is uh listed in isolation mode with a debt ceiling of 10 million and that will mean that users can use that that token two as collateral, but only they will only be able to borrow up to 10 million uh dollars worth of assets in stable coins. So, as I said, this is an interesting way to model exposure and also list assets in a in a more secure way.

And yeah, all of you can imagine having a new asset into the protocol, first listed as in isolation mode, then uh keep on going with supply and borrow caps and finally, maybe without any other security measures at all, which is good. Also, the price Oracle Sentinel, yeah, this Oracle is uh is really specific for layer twos. Because and gives increases the experience of the users in those in those in those networks. Um this price Oracle Sentinel allows to handle eventual downtime of of the sequencer. As you may already know, the sequencer are the entities that are in charge of submitting and settling transactions in the network.

So, if the sequencer goes down, then the network essentially stops working. So, during this downtime, we could have price variations, and these price variations could affect the users' positions in some way. So, if when the sequencer goes up and the network starts working again, these users could have these positions affected since all the price variations come into play at once. So, in order to mitigate this scenario, the protocol introduces a grace period, which is a duration of time that the users are able to fix their positions in in order to don't get liquidated in some way. Yeah.

Decentralization. In the third version of the protocol, there were also some improvements in terms of decentralization. And in the previous iteration, we already have some a permissioning system where all the roles were specified with their responsibilities, but in this version, this uh permissioning system is more fine-grained and more sophisticated. And also, there are some new roles in the system that brings new ways of doing things, let's say. So, we have the risk admins and also the listing asset admins.

The The risk admins is a specific role of the system that has the ability to change the risk parameters of the reserves without the need of a governance vote. These risk admins could be DAOs or any other entity or even automated agents that react to a specific events or metrics and change the risk parameters accordingly. They can change the risk parameters or also the the interest rate strategies of the reserves as well. And also, we could have the We have the which are which has the ability to list assets without the need of of going to a governance proposal, which is also interesting because we could have uh some new strategies of listing assets, and this is a kind of a of a way of delegating the governance of the community of the protocol to some other entity out there. So, one of the discussions that have been in the in the community forum is the the permissionless listing.

So, what if the a community of users are able to decide which asset they which asset they want to list? So, they can stake some a part of this of this assets in the protocol and use this this assets as a backstop in case there is uh that that something happens. So, yeah, really cool. Also, there is as you can imagine there is a bunch of new features in this third iteration of the of the protocol. Some of them are more user-facing features, some of them are more in the technical side, but yeah.

For example, it's good to mention the repayment with A tokens. So, now this increases also the experience of the users as you can imagine. Users now are able to repay the their debt with A tokens. So, they didn't So, if a user has a debt of 100 USDC, they can provide 100 A USDC to repay the debt. This as I said increases the user experience, but also helps the protocol just in case the underlying assets gets locked in the Aave pool contracts for for some for some reason.

Also, there there are the there is the introduction of the permit function and the EIP 712 to the credit delegation function. And also the introduction of a simplified version of the flash loan function with a reduction of 20% of gas costs. This is only in the case that the user wants to to flash loan one asset instead of an of a set of of assets. And yeah, there is many many more. But in general, the code was reorganized and also optimized.

So, there has been a reduction of 10% or 15% of gas consumption across the board across the board. So, which is really nice. Yeah, that's pretty much all. Yeah, we created some tools to help you to build on top of Ave. This is one of the Ave Sandbox.

That is tools allows you to to integrate or to fork a network that has Ave V3 project. With a simple command and it spins a hard hat node to the Ave market. It also It also allows you to faucet the the assets that that are listed in that market with in an easy way. And also it allows you to connect the Ave open source front end to this local sandbox or to this local hard hat node. Yeah, this way integrators can build safely at the top of Ave markets in production.

But in in in in also in the same time at local local host that is much faster to develop and The only dependency that you need is a node js. Oh, yeah. You can find the the repo at the QR code and also at github.com Ave / Ave Sandbox. Sandbox.

Yeah, we also have some NPM packages with the smart contracts and also some utilities, some helper helper functions that helps you to to develop new front ends front ends for Ave or different dashboards that you need. The utilities contains all the helpers to to interact with the protocol and also contains all the math related with the with the with the protocol. So so it's quite nice so you don't you need to rebuild the wheel. Well, you as always you can check the code at the different repositories. Yeah, right now here at the hackathon we have the the prizes.

Yeah, we are rewarding for the most innovative Ave integration. Um yeah, you can see the list of the the prizes. Um yeah, there's some some resources like the developer docs that are quite complete and it contains all the definitions, all the contract that runs Ave. Ave protocol. Um yeah, there is also the the Avegant's DAO.

Uh there you have in that link you can request for for proposals. Maybe you have an interesting idea to build on top of Ave uh as a community member. And here you can request a grant to develop that idea and execute that idea. Um yeah, here next Sunday we have a Ave. So, yeah, here is a money score that you can use.

Yeah, it's hosted by the Avegant's DAO. Well, and that's it. If you have more questions, feel free to ask to us. Um yeah. Okay.

So, that's it. Thanks everyone for coming. Ah, you have one question. Okay. I missed the code.

Ah, yeah, of course. Here is the code. I have something. Mhm. So, in Ave V3, did any of the core components change that they have funds in the sense that when you deploy a version of you know, central land of that, there is might be introduced like security risks.

So, is that the case with this deployment or was more like an overall uh refactoring kind of What do you mean exactly? Could you repeat? Yeah, so I'm wondering if deploying a new version of the protocol introduces security risks that you know, you might not have a good upgrade. Yeah, I mean like any other protocol. If you deploy any version, you need to take into account how the upgrade is going to be.

Of course, if you are using some kind of proxy pattern like Aave does, uh you need to take into account the storage layout and you know, keeping things retrocompatible maybe whatever. So, you need to take also things into account in in that in that way. Yeah, sure. So, version two and version three are running at the same time like are Yeah, now they are running at the same time. There is also some discussions in the forum to upgrade the contracts of the V2 market to V3 and that's going to be a challenge.

That's going to be a real challenge because Are there Yeah. users too? Yeah, exactly. So, it needs to be backwards compatible, also taking into account all the functions, all the storage layout and this kind of of things. So, yeah, yeah.

Any more questions? Okay. Nice guys. Thank you so much for coming. Reach us out if you want to talk about Aave or any hackathon idea or just about Aave V3 or what's going on on on Aave companies.

Thanks for coming. Thank you everyone.