Evolution of lending application architecture on Ethereum Comparing MakerDAO, Yield, Aave, Compound, and Euler.

Exploring the Evolution of Lending Application Architecture on Ethereum A Comparison of MakerDAO, Yield, Aave, Compound, and Euler

Author: @albertocuestacanada, Source: D-Link Translation Project

Lending is the cornerstone of blockchain applications based on Ethereum. Billions of assets have already been borrowed, so understanding how lending works is crucial for developers, architects, or researchers.

Just like the evolution of programming paradigms, these DeFi applications have different architectural designs that reflect changing priorities such as security, efficiency, and user experience.

• Scaling Bitcoin: BitVM to the Rescue?
• The Uniswap Saga Continues: Android Users Rejoice!
• Mysterious Riddles and Russian Rabble-Rousers: The FTX Heist Unveiled!

This article focuses on analyzing the architecture of lending applications such as MakerDAO, Compound, Aave, Euler, and Yield. We will highlight key innovations and design patterns that serve as valuable lessons for future lending application development.

If you are a developer, architect, or security researcher, then this article is for you. By the end, you will easily understand the new lending applications on Ethereum and have a comprehensive grasp of their architecture. Dive deep into how these DeFi giants were built from scratch.

Lending in DeFi

Most DeFi lending is overcollateralized. If the value of the collateral provided by the user is higher than the value of the loan, the user can borrow specific assets. Unlike traditional lending, many of these loans do not have periodic or fixed repayment dates. Essentially, you can borrow and never repay.

However, there is one catch: the value of the collateral must always exceed the predefined boundary of the loan value.

If the value of the collateral falls below this boundary, the loan will be liquidated. During liquidation, others will repay a portion or the entirety of your loan, and they will receive a portion or all of your collateral as compensation.

All loan applications following this financial structure require the same construction, which can be organized in various ways:

• A treasury to store user collateral and borrowed assets

• An accounting system to track each user’s collateral and debt

• A function to determine borrowers’ interest rates

• A mechanism to verify the availability of sufficient collateral for lending, often involving an external price oracle

• A liquidation path for lending in the event of insufficient collateral

• A risk management system that records the total loan amount and other security indicators, such as global and per-user loan limits, minimum collateral requirements, and specific overcollateralization rates

• Interfaces for users to add and remove collateral, borrow, and repay

> The loan process in MakerDAO follows the same steps and functionalities for all supported assets

Loans and lending can be seen as separate functionalities. In DeFi, we have found these two functionalities in most lending applications, but they are not always well-integrated. In Compound, Aave, and Euler, the interest rates for borrowers and lenders are internally correlated; in fact, this is what allows these applications to run with minimal intervention.

On the other hand, MakerDAO and Yield lend assets to borrowers from their own protocol.

They do not require users to provide assets for others to borrow.

This article will focus on on-chain borrowing and largely ignore lending. Borrowing is much more complex due to collateral requirements, and understanding borrowing patterns can often help better understand the entire protocol.

The Architecture Evolution of MakerDAO

MakerDAO, launched in November 2019, holds $4.95 billion in collateral. Despite having different contracts and unique terms for each functionality in its modular architecture, it is still easy to understand and verify.

The Treasury function in MakerDAO is managed by the Join contract.

Each token approved as collateral has a separate contract.

MakerDAO does not own any lending assets DAI. It only mints and burns DAI as needed.

The accounting is handled within the vat.sol contract. Join updates this contract when collateral enters or leaves the system. If a user borrows, they interact directly with the vat.sol contract.

This action updates the user’s debt balance and allows them to mint DAI against their debt.

To repay, users burn DAI in the DAI Join contract. Then, this process updates Vat, allowing the user to settle the debt.

In addition, the vat.sol contract acts as a risk management engine. It maintains all lending limits, sets minimum thresholds for each user, and monitors collateral ratios. When a user’s debt or collateral balance changes, the vat.sol contract evaluates rates and spots.

These refer to the interest rates based on the collateral used and the ratio of current DAI to collateral prices. Interestingly, these values are input into the vat.sol contract by other MakerDAO contracts, which sets it apart from most other applications.

MakerDAO prioritized security during the design phase – gas cost and user experience were secondary concerns, and competition could be overlooked.

As a result, it can appear peculiar, costly to use, and difficult to manage.

However, its management of large assets and its operational record without major incidents highlight its robust design and execution.

Highlights of MakerDAO:

• Each asset has its own contract.
• Accounting functionality is centralized in a single contract that also records and enforces risk parameters, including collateral checks.
• Unlike other applications, oracles update contracts and monitor collateral.
• Price and interest rate oracles use different interfaces.
• Interest rates come from external sources.
• To borrow, users must interact with multiple contracts.

The Evolution of the Yield Protocol

Yield v1 served as a proof of concept for fixed-rate lending using YieldSLianGuaice. This version built its collateral debt engine on top of MakerDAO. However, Yield v1 was expensive to use and difficult to enhance with new features.

Recognizing the potential of YieldSLianGuaice, we quickly pivoted to develop Yield v2. Yield v2 still draws inspiration from MakerDAO but is now fully independent and was launched in October 2021. Yield v2 prioritizes reducing gas costs and enhancing user experience.

The lending process in Yield v2 is heavily influenced by MakerDAO.

All billing, risk management, and collateral checks are consolidated into a single contract called Cauldron. Following MakerDAO’s approach, vault functionality is distributed across Join contracts, with each contract dedicated to a specific asset.

We have improved oracle integration by merging price and interest rate oracles into a common interface. We have reversed MakerDAO’s oracle process so that Cauldron can access the oracles based on collateral checks’ needs. To my knowledge, this is the preferred process for all other applications besides MakerDAO.

Another significant difference from the MakerDAO approach is the introduction of Ladle. This contract serves as the sole intermediary between users and Yield. It has extensive control over vaults and billing, providing significant flexibility for feature development.

In summary, the lending mechanics in Yield v2 work as follows:

• Each asset has its dedicated vault contract.

• A single contract centralizes billing functions. This contract also oversees risk management measures and conducts collateral checks.

• Collateral functionality accesses oracles to determine prices and interest rates.

• Price and interest rate oracles share a unified interface.

• Interest rates are externally generated.

• Users can borrow by issuing a single transaction to a contract.

The Evolution of Compound

The first version of Compound served as a proof of concept, demonstrating the ability to build a money market on Ethereum. Consequently, its design prioritized simplicity. The MoneyMarket.sol contract encapsulated all functions, including lending.

The borrowing process in Compound v1 is simple and effective.

• Vaults, billing, and risk management tasks (such as collateral checks) are consolidated into a single contract.

• The contract retrieves prices from oracles but determines interest rates based on asset utilization.

• Users interact only with this contract, although they must make separate calls to supply collateral and borrow assets.

Compound v2

Compound v2 was launched in May 2019 and ignited the era of liquidity mining, inspiring countless forks. It also serves as a money market, allowing users to deposit and borrow assets.

Based on its whitepaper and structure, it is evident that the main goal of Compound v2 is to use the ERC20 standard to represent lending positions. This ensures composability, allowing users to lend to Compound and then use these interest-bearing positions in other blockchain applications.

Interestingly, the whitepaper does not emphasize the inclusion of rewards in Compound v2’s smart contracts. Due to this omission, the enormous impact of this feature may be unforeseen.

The lending process in Compound v2 tokenizes lending positions

• Each asset has its own funding contract.

• The accounting functions are also separate, with each cToken recording a user’s collateral and debt.

• A single contract (Comptroller) records and enforces risk management parameters, including collateral checks.

• The Comptroller references the price oracle for collateral checks and the interest rate for cTokens.

• The price and interest rate oracles operate through separate interfaces.

• The interest rate is derived from the utilization of assets.

• Users must interact with multiple contracts to borrow.

Compound v3

Compound v3 was released in 2022 and adopts a more conservative risk management strategy, isolating liquidity to pools for each borrowable asset. This design also shows its focus on user-friendliness and gas costs.

Borrowing process in Compound v3 (Comet). Back to basics, back to safety. But with a better user experience.

Due to the reduced number of required calls, the system is more intuitive for developers and users. Additionally, the design of a single contract minimizes calls between contracts to reduce gas costs. The isolated money market is a defense against oracle-based attacks, which is currently a major security concern.

Other notable features mentioned in the article (as stated in the release notes) include:

• A revamped risk management and liquidation engine. This design enhances fund security while being more borrower-friendly.

• Setting restrictions on individual collateral assets across the market to reduce risks.

• Revenue and borrowing interest rate models are now separated, giving governance full control over economic policies.

Interestingly, Compound v3 mirrors the architecture of Compound v1, with a single contract handling all functions for each borrowable asset. Other noteworthy features include:

• Only loanable assets can be borrowed, collateral assets cannot be borrowed.

• In Compound v3, collateral does not generate returns.

Prohibiting borrowing against collateral increases the security of collateral depositors. This reduces the likelihood of governance errors or intentional attacks jeopardizing the collateral.

The removal of collateral supply rewards may be a result of Compound successfully accumulating substantial liquidity in v2. My intuition is that in Compound v2, borrowing limits were either lower or not higher than the assets users lent to the application.

Assuming they will manage similar levels of liquidity in v3, the prohibition of borrowing against collateral can make the application secure, which is one of the core goals of v3.

From an architectural perspective:

• Each money market is an independent contract that includes reserves, bills, and risk management.

• Each money market retains the borrowable assets and all approved collateral asset tokens, distributing the assets throughout the application.

• The price feed is the only external input; borrowing rates are generated internally.

• Traditional functionalities such as supply/withdraw/borrow/repay are cleverly integrated. Now, withdrawing borrowable assets from a money market means borrowing, while supplying borrowable assets means repaying debt or making a loan based on user’s intention.

• It integrates routing contracts to allow multiple operations in a single call.

Aave’s Architectural Evolution

Aave v1 was launched in October 2019, replacing ETHLend. Aave v1 introduced shared liquidity pools instead of ETHLend’s peer-to-peer approach.

Borrowing process in Aave v1 consolidates liquidity submissions for computational efficiency.

Just like in Yield v2, the routing contract controls the business logic. The LendingPoolCore implements bill, risk management, and reserve functionalities. Having the reserves centralized in one contract is a distinguishing point from Compound v2.

Leaving collateral checks in their own contract instead of calling them from the router, although seemingly weak, likely serves a purpose as Aave v2 was released two years after v1.

• The LendingPoolCore contract handles reserves and bills.

• The LendingPoolDataProvider manages collateral checks and interacts with oracles.

• The LendingPool acts as the user entry point and implements the business logic.

• Borrowing rates are internally determined and rely only on price feedback.

Aave v2

Aave v2 was released in December 2021. While it retains similar functionalities to Aave v1, it introduces an improved and simpler architecture compared to Aave v1 and Compound v2. In this version, Aave also introduces aTokens (similar to Compound’s cTokens) and vTokens, which represent tokenized debt.

Aave v2 has a very clean architecture and is fully tokenized

For simplicity, certain features that were limited in Aave v1 have been omitted. Issues in Aave v1, such as the complex representation of accrued interest, have been addressed in Aave v2.

• The LendingPool contract integrates global accounting and risk management features, such as collateral checks. It serves as the primary access point for users.

• aToken represents collateral, similar to a loan position. Users’ collateral is reflected through the aTokens they hold, and the vault functionality is distributed across all aTokens.

• vToken is used to represent debt positions. Users’ debt is represented by the vTokens they hold.

Aave v3

Aave v3 is set to be released in January 2023, with support for multiple chains and additional features. Adding these won’t change the core architecture. This update also improves risk management and gas efficiency.

Despite many advancements, Aave v3 is not fundamentally different from Aave v2 in terms of this research. In fact, this may indicate that the architecture of Aave v2 remains robust in 2023.

Euler’s Architecture Evolution

Euler was launched in December 2022, aiming to provide permissionless functionality and minimal governance for money markets.

One notable design is the diamond pattern. A single contract owns all the storage space for the application. This storage can be accessed through different proxies, with each proxy managing different conceptual elements of the system.

While one contract stores all asset, accounting, and risk management data, there are still eTokens for collateral and borrowing, as well as dTokens for debt, similar to Aave v2. However, these token contracts are merely views of the central storage contract.

• The Storage contract manages accounting variables.

• The BaseLogic contract acts as the vault.

• The RiskManager contract oversees risk management variables and functionalities, including collateral checks.

Analysis of the code suggests that minimizing gas costs is a top priority, resulting in an overall design that eliminates the need for contract-to-contract calls. Security is ensured through rigorous testing and auditing. Only logic spread across modules serves as the implementation of the storage contract, with the storage contract primarily acting as a proxy contract.

This unified design also supports easy upgrades. If changes to storage are not required, modules can be quickly swapped to modify or introduce functionalities.

Euler was hacked 15 months after its release and 6 months after the introduction of an exploited vulnerability through an upgrade.

I don’t think the loss of assets was due to its overall architecture; rather, it was due to insufficient supervision of code updates.

Conclusion

Early Ethereum applications such as MakerDAO, Compound, and Aave have demonstrated the potential of Ethereum’s overcollateralized lending. Once these proof-of-concepts were proven successful, the focus shifted to introducing a range of new features to capture market share. Compound and Aave’s subsequent versions introduced liquidity mining, composability, and pooled liquidity, which flourished particularly in bull markets.

One major development was the introduction of tokenized lending positions by Compound v2, allowing these positions to be recognized as standard assets by other applications. Aave v2 and Euler further expanded on this by implementing tokenized debt positions, with their broader utility still being a topic of discussion.

High gas costs became a major issue during bull markets, prompting changes in user experience pursued by Yield v2, Aave v2, and Euler. Router contracts and overall implementation assist in reducing users’ transaction costs. However, this comes at the cost of more complex and therefore riskier code.

Compound v3 seems to set a precedent by prioritizing security over financial efficiency. It deviates from the traditional liquidity pool model to better safeguard against potential hacking attacks. The rise of Layer 2 networks (where gas costs become increasingly negligible) may impact the design of future mortgage lending applications.

In this article, I provide a comprehensive overview of key mortgage lending applications on Ethereum. The approach I use to analyze each application can also be applied to quickly grasp the intricacies of other lending applications.

When developing blockchain lending applications, always consider the storage of assets, placement of billing records, and risk and collateral evaluation methods. When considering these considerations, utilize the historical changes of previous applications and insights from this overview to inform your decision-making.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!