Lending was one of the earliest major applications in DeFi. A lending protocol is a smart-contract system that allows users to deposit and borrow tokens. In that sense it resembles a bank: depositors place assets into a lending application, the application lends those assets to borrowers, and depositors earn interest over time. When a borrower’s position becomes undercollateralized, liquidation is triggered. Anyone can participate in the liquidation process, and successful liquidators receive a reward. The liquidation system protects the solvency of the lending market and, in turn, the interests of depositors.

DeFi lending differs from banks in several important ways:

1. Interest calculation a. In DeFi lending, interest starts accruing from the block in which you deposit and stops at the block in which you withdraw. b. DeFi lending rates can fluctuate widely and are tightly linked to utilization, which can be roughly understood as borrowed funds divided by total available funds. Most protocols define thresholds where rates rise sharply once utilization becomes too high, which can be painful for borrowers. c. All borrowing is overcollateralized. There is no concept of unsecured credit lending.

2. Liquidation a. All deposits and loans in DeFi are transparent on-chain. b. The liquidation rules are fixed and explicit. c. Anyone can liquidate, and liquidators can earn substantial rewards, often around 10% of the liquidated amount. d. Because the data is public and the incentives are strong, the liquidation system can operate reliably.

3. Flash loans Flash loans are one of AAVE’s most important innovations. A flash loan is not a bank-style instant loan. It means borrowing and repaying within the same blockchain transaction. For example, if an arbitrage opportunity appears but you do not have the capital, you can use a flash loan to borrow, execute the arbitrage, repay principal plus interest, and keep the profit.

   Flash loans are also widely used in contract exploits, because they allow attackers to access much larger amounts of capital. Many recent attacks have used flash loans as the funding source.

4. Collateral types Banks can accept many kinds of collateral because they can evaluate assets off-chain. DeFi lending can only support a subset of tokens, because those assets need transparent pricing. Traditional asset appraisal is difficult to bring fully on-chain.

DeFi lending has gone through three major stages. The first stage was represented by MakerDAO, the second by Compound, and the third by AAVE.

There is no doubt that MakerDAO was the pioneer. Compound redesigned the interest-rate model, and nearly every later lending design built on top of Compound in one way or another. AAVE then became the most complete system. Its core lending model is similar to Compound’s, but compared with Compound and MakerDAO, AAVE stands out in several ways:

1. AAVE’s biggest innovation was introducing flash loans. From that point on, anyone pursuing on-chain arbitrage or certain attack strategies no longer needed to worry about capital. Flash loans are a uniquely on-chain advantage; there is no equivalent in traditional finance.
2. AAVE also introduced stable-rate borrowing. Compound’s rates fluctuate continuously with utilization. When utilization spikes, borrowing costs can rise sharply, which is painful for long-term borrowers. AAVE added a stable-rate option to address that need.
3. AAVE’s codebase is better written than Compound’s. It is cleaner, more structured, more readable, and easier to maintain.
4. AAVE is also safer. Its modular design, code quality, and testing are stronger. For example, when Cream Protocol suffered a major exploit and lost tens of millions of dollars, I could not help thinking that if it had forked AAVE instead, that specific attack likely would not have been possible. I discuss that in more detail later.

Unlike the swap market, where Uniswap clearly dominates, lending is still closer to a three-way contest between MakerDAO, Compound, and AAVE. AAVE has an advantage in total deposits, Compound has the broadest user base, and MakerDAO has very strong locked value. All three have their strengths, and the gaps between them are not overwhelming. The real distance is between these three leaders and the many imitators. Without major innovation, it is hard for newcomers to challenge them.

Because AAVE is more complex than Compound, most lending protocols on chains like BSC and HECO historically forked Compound instead. Many of those teams optimized for fast launches and never deeply studied Compound itself, so once the products went live they hardly dared to change anything. In many cases the only visible change was renaming cTokens into various xTokens, because the main objective was token issuance and short-term fundraising rather than protocol design.

From a learning perspective, AAVE is an outstanding codebase, several levels above Compound in overall engineering quality. Even AAVE v1 was already well structured, and v2 improved on it further. In many respects it is exemplary:

0. The project structure is very clear. Interfaces, libraries, implementations, core modules, and adapters are all well separated.
1. It has complete tests.
2. It has complete deployment scripts.
3. It has solid official documentation and whitepapers.
4. It has mature surrounding SDKs and code examples.
5. It follows a consistent coding style and comment style, and functions are well documented.
6. It includes proper linting and code-quality checks.
7. Its use of library patterns is exceptionally polished.
8. The WETHGateway unifies ETH and token flows cleanly. In my view this is clearer than Uniswap’s router, which exposes many ETH-specific entrypoints.
9. Its proxy usage is textbook quality, even though OpenZeppelin later provided a more general-purpose proxy solution.

The only project I would put in the same class is Uniswap. Uniswap also open-sourced its frontend, while AAVE did not, and that is one area where AAVE falls short.

This post is the introduction to a broader AAVE code-analysis series: 0. Introduction to the AAVE lending protocol

1. Overall architecture of the AAVE codebase
2. The AAVE interest-rate model
3. AAVE interest-rate code walkthrough
4. AAVE risk control
5. AAVE flash loans
6. How AAVE decouples its modules
7. The AAVE proxy pattern
8. AAVE deployment