Aave V1

Resources

• Whitepaper
• Source Code
• Contract Addresses

Key Differences

The following are key architectural differences between Aave V1 and subsequent protocol versions:

• Debt Tokenization: V1 did not tokenize borrow positions, so borrow balances had to be read from the protocol contracts. V2 introduced variable and stable debt tokens.
• LendingPoolCore: V1 used a separate contract, LendingPoolCore, to hold protocol assets, which added complexity for users and developers. In V2, this was replaced, and assets are held directly by aTokens.
• ETH -> WETH: In V1, the protocol used ETH directly, but Aave V2 switched to WETH for consistency.
• Interest Redirection: V1 allowed users to redirect earned interest to another address, a feature removed in V2.
• Batch Flash Loans: V1 introduced flash loans, limited to one asset per call. V2 added multi-asset flash loans and the option to keep the borrowed amount open as debt instead of repaying it in the same transaction.
• Withdraw aTokens: In V1, users had to redeem or withdraw their aTokens through the aToken contract. V2 migrated this action to the LendingPool contract.

Architecture

LendingPoolCore

The LendingPoolCore contract holds the state of every reserve and all assets supplied, as well as the basic logic (e.g. calculations using the stored data).

LendingPoolAddressesProvider

The LendingPoolAddressesProvider is a global addresses register of the protocol. This contract is immutable and the address will never change.

LendingPoolDataProvider

The LendingPoolDataProvider contract performs calculations and provides data for the LendingPool contract, specifically:

• Calculates the ETH equivalent of a user’s balance to assess the borrow limit of a user and the health factor of their positions.
• Aggregates data from LendingPoolCore to provide high level information to the LendingPool.
• Calculates the Average Loan to Value and Average Liquidation Ratio.

LendingPool

The LendingPool contract uses both the LendingPoolCore and LendingPoolDataProvider to interact with the reserves. This is the main contract developers should interface with.

The LendingPool also manages the tokenization of users' supply position via aTokens.

LendingPoolConfigurator

The LendingPoolConfigurator contract provides configuration functions for the LendingPool and LendingPoolCore contracts. It also has a number of important functions:

• Activates / Deactivates reserves,
• Enables / Disables borrowing for a reserve,
• Enables / Disables using a reserve as collateral,
• Enables / Disables stable rate borrowing for a reserve,
• Freezes / Unfreezes reserves,
• Updates a reserve’s Loan to Value,
• Updates a reserve’s liquidation threshold,
• Updates a reserve’s liquidation bonus,
• Updates a reserve’s decimals,
• Updates a reserve’s interest rate strategy address.

For all of the above functions, relevant events are emitted to the blockchain. Anyone can monitor these changes to know when values have been modified or added/removed.

The contract is owned by the LendingPoolManager, as defined in the LendingPoolAddressesProvider.

Interest Rate Strategy

The InterestRateStrategy contract holds the information needed to calculate and update the interest rates of specific reserves.

Each contract stores the optimized base curves using the corresponding parameters of each currency. This means that there is a mathematical function which determines the interest rate of each asset pool, with the interest rate changing based on the amount of borrowed funds and the total liquidity (i.e. utilization) of the asset pool.

The parameters for the optimized base curves are:

• baseVariableBorrowRate
• variableRateSlope1
• variableRateSlope2
• stableRateSlope1
• stableRateSlope2

The interest rates are calculated depending on the available liquidity and the total borrowed amount.

Every reserve has a corresponding InterestRateStrategy contract.