The Aave protocol contains a large number of smart contracts and governance roles that work together to provide the protocol's services.

In this second part of my series, I will focus on the major contracts and how they interact with one another to keep things simple.

Smart contracts

Here is a diagram that shows the different contracts and how they interact with one other in the protocol.

a diagram that shows the different contracts and how they interact with one other in the protocol.
The different contracts and how they interact with one other in the protocol.

Lending Pool Addresses Provider Registry

As you can see from the diagram above, LendingPoolAddressesProviderRegistry contains many LendingPoolAddressProvider.

LendingPoolAddressesProviderRegistry is a register of the active LendingPoolAddressProvider contracts, covering all markets.

Each LendingPoolAddressesProvider has an id.  The id assigned to a LendingPoolAddressesProvider refers to the market it is connected with.

For example, with id  0 for the Aave main market and 1 for the next created.

The contract has the following functionality:

  • Returns the list of registered addresses provider
  • Registers an addresses provider
  • Removes a LendingPoolAddressesProvider from the list of registered addresses provider
  • Returns the id on a registered LendingPoolAddressesProvider

Lending Pool Addresses Provider

This contract acts as a factory of proxies and admin of LendingPool, LendingPoolConfigurator, so with the right to change its implementations.

The general idea behind a proxy is that a caller (external or contract address) makes a function call to the proxy, which then forwards the call to the delegate, which contains the function code. The proxy receives the result and passes it on to the caller.

You can read more about it here: https://fravoll.github.io/solidity-patterns/proxy_delegate.html

It also contains the address of PricceOracle, LendingRateOracle, LendingPoolCollateralManager.

The contract has the following functionality:

  • Get/Set the id of the Aave market to which this contract points to
  • Get the proxy address of LendingPool and update the implementation.Get the proxy address of LendingPoolConfigurator and update the implementation.
  • Get/Set the address of the LendingPoolCollateralManager

Lending Pool

The LendingPool contract is the main contract of the protocol. All actions happen through LendingPool.

Users can interact with the reserves through the actions:

  • Deposit
  • Withdraw
  • Borrow
  • Repay
  • Swap their loans between the variable and stable rate
  • Enable/disable their deposits as collateral rebalance stable rate borrow positions
  • Liquidate positions
  • Execute Flash Loans

Lending Pool Configurator

Every LendingPool contract has a LendingPoolConfigurator go with it, with the purpose of managing and config the assets in the lending pool.

The contract has the following functionality:

  • Initializes new reserves into the pool
  • Updates the aToken implementation for the reserve
  • Updates the stable debt token implementation for the reserve
  • Updates the variable debt token implementation for the asset
  • Enables/Disables  borrowing on a reserve
  • Configures the reserve collateralization parameters (LTV, LT, Liquidation bonus)
  • Enable/Disables stable rate borrowing on a reserve
  • Activates/Deactivates  a reserve
  • Freezes/Unfreeze a reserve. A frozen reserve doesn't allow any new deposit, borrow, or rate swap but allows repayments, liquidations, rate rebalances, and withdrawals
  • Updates the reserve factor of a reserve
  • Sets the interest rate strategy of a reserve
  • Pauses/Unpauses the pool, all the actions of the protocol, including aToken transfers

Lending Pool Collateral Manager

This is the logic contract that implements actions involving collateral management in the protocol.

This contract will always run via DELEGATECALL, through the LendingPool, so the chain of inheritance is the same as the LendingPool, to have compatible storage layouts (Both of them inheritance contract LendingPoolStorage

aToken

This contract is implemented EIP20, so it will have all the functions such as balanceOf(), transfer(), transferFrom(), approve(), totalSupply(), etc.

It also implemented EIP2612 methods, providing function permit(address owner, address spender, uint256 value, uint256 deadline, uint8 v, bytes32 r, bytes32 s)

Allows a user to authorize the usage of their funds by another account (or contract) via a signed message. Gas-less transactions and single approval/transfer operations are now possible.

Since each pool has a different aToken, so each aToken has a function to the address of the associated lending pool for the aToken: POOL()

aToken has a different way of storing balance, such as the normal ERC20 token. Instead of saving the user's balance, it stores information about the user's scaled balance. And each asset has its index too, and it keeps increasing over time. The scaled balance is the balance of the underlying asset of the user (amount deposited), divided by the current liquidity index at the moment of the update aTokenBlance=scaleBalance*currentLiquidityIndex

For example, user A deposits 1000 DAI at the DAI index of 2. So the scaled balance of user A is 1000/2 = 500. After a time, now the DAI index increased to 3. So user A now has 500*3= 1500 DAI. Users can get scaledBalance by using function: scaledBalanceOf(address user).

Debt Token

Both stable debt tokens and variable debt tokens are modeled on the ERC20/EIP20 standard. However, they are non-transferrable. Therefore they do not implement any of the standard ERC20/EIP20 functions relating to transfer() and allowance().

These debt Tokens have an exciting feature, which is credit delegation. This feature allows you to give others access to your credit line, letting them draw up to that credit amount in their own time.

By using: approveDelegation(address delegatee, uint256 amount), the debtToken that the delegatee borrows will transfer to your account when using this function.

This function is used in WETH Gateway. If you need to use native ETH in the protocol, it must first be wrapped into WETH. The WETH Gateway contract is a helper contract to easily wrap and unwrap ETH as necessary when interacting with the protocol since only ERC20 is used within protocol interactions. You need to approve delegation to the WETH Gateway in order to borrow ETH from the pool.

Read Introduction to Aave Lending V2 Part 1: https://techfi.tech/aave-lending-v2/

Read more about Aave Lending V2 (Part 1) HERE

Reference:

[1] Introduction to Aave, Aave document, accessed March 19th, 2022.

[2] Aave whitepaper, Aave document, accessed March 19th, 2022.