Lending applications form the cornerstone of blockchain-based financial activity on Ethereum. Billions of dollars in assets have been loaned through these protocols, making it essential for developers, architects, and researchers to understand their operational mechanics.
Similar to the evolution of programming paradigms, these DeFi applications showcase varied architectural designs reflecting shifting priorities—from security and efficiency to user experience.
This article analyzes the architecture of major lending applications including MakerDAO, Compound, Aave, Euler, and Yield. We highlight key innovations and design patterns that offer valuable lessons for future development in decentralized lending.
How Lending Works in DeFi
Most DeFi lending is over-collateralized. Users can borrow specific assets by providing collateral that exceeds the value of the loan. Unlike traditional loans, many of these arrangements don’t require periodic payments or fixed repayment dates. In essence, you can borrow and never repay.
However, there’s one critical condition: the collateral value must always remain above a predefined threshold.
If the collateral value falls below this threshold, the loan becomes subject to liquidation. During liquidation, a third party repays part or all of the loan in return for a portion of the borrower’s collateral.
All borrowing protocols following this structure require the same foundational components:
- A treasury to hold user collateral and borrowed assets
- An accounting system to track each user's collateral and debt
- A function to determine borrower interest rates
- A mechanism to verify sufficient collateral, often using external price oracles
- A liquidation pathway for under-collateralized loans
- A risk management system to monitor total borrowing, safety metrics, global and per-user borrowing limits, minimum collateral levels, and collateral ratios
- User interfaces for adding/removing collateral, borrowing, and repaying assets
Borrowing and lending can be considered independent functions. While most DeFi lending applications incorporate both, they aren’t always tightly integrated. In protocols like Compound, Aave, and Euler, the interest rates for borrowers and lenders are internally correlated—this enables these applications to function with minimal intervention.
In contrast, MakerDAO and Yield lend assets to borrowers from their own reserves (i.e., the protocol itself). They don’t require users to supply assets for others to borrow.
This analysis focuses primarily on on-chain borrowing, as it is more complex due to collateral requirements. Understanding borrowing patterns often provides better insight into the entire protocol.
The Architectural Journey of MakerDAO
Launched in November 2019, MakerDAO currently holds billions in collateral. Its modular architecture uses separate contracts for each function, making it relatively straightforward to understand and audit.
In MakerDAO, the treasury function is managed by Join contracts. Each approved collateral asset has its own dedicated Join contract. Interestingly, MakerDAO does not own the borrowed asset DAI—it simply mints and burns DAI as needed.
Accounting is handled within the vat.sol contract. When collateral enters or exits the system, the Join contract updates this central ledger. If a user borrows, they interact directly with vat.sol, which updates the user’s debt balance and allows them to mint DAI.
To repay, users burn DAI in the DAI Join contract, which then updates the Vat to reflect the settled loan.
The vat.sol contract also serves as the risk management engine. It maintains global borrowing limits, sets per-user minimum thresholds, and oversees collateral ratios. When a user’s debt or collateral balance changes, vat.sol assesses rates and spot values based on the collateral used and the current DAI-to-collateral price ratio. These values are supplied by other MakerDAO contracts—a design choice that distinguishes it from most other applications.
MakerDAO prioritized security during its design phase—a time when gas costs were secondary, user experience was less critical, and competition was minimal. As a result, it can appear idiosyncratic, costly to use, and difficult to navigate. However, its vast managed assets and flawless operational record underscore its robust design.
MakerDAO Key Takeaways:
- Each asset has its own contract
- Accounting is centralized in a single contract that also records and enforces risk parameters, including collateral checks
- Unlike other applications, oracles update contracts that oversee collateral
- Price and interest rate oracles use different interfaces
- Interest rates are derived externally
- To borrow, users must interact with multiple contracts
Yield Protocol’s Evolutionary Path
Yield v1 was a proof-of-concept for fixed-rate lending using YieldSpace, built on top of MakerDAO’s collateralized debt engine. However, Yield v1 proved expensive to use and challenging to enhance with new features.
Recognizing YieldSpace’s potential, the team quickly pivoted to Yield v2, launched in October 2021. While still inspired by MakerDAO, Yield v2 operates independently and prioritizes reduced gas costs and improved user experience.
All accounting, risk management, and collateral checks are merged into a single contract: the Cauldron. Mirroring MakerDAO’s approach, treasury functions are distributed across Join contracts, each dedicated to a specific asset.
Yield v2 also improved oracle integration by combining price and interest rate oracles into a unified interface. It reversed MakerDAO’s oracle flow so that the Cauldron queries oracles as needed for collateral checks—a process that has become the preferred approach for most applications outside MakerDAO.
Another significant deviation from MakerDAO is the introduction of the Ladle contract. This contract acts as the sole intermediary between users and Yield, wielding broad control over treasury and accounting functions. This design offers considerable flexibility for feature development.
In summary, borrowing in Yield v2 works as follows:
- Each asset has its own dedicated treasury contract
- A single contract centralizes accounting functions while overseeing risk management and enforcing collateral checks
- The collateral function queries oracles for prices and interest rates
- Price and interest rate oracles share a unified interface
- Interest rates are externally generated
- Users can borrow with a single transaction to one contract
Compound’s Architectural Shifts
The first version of Compound was a proof-of-concept demonstrating that money markets could be built on Ethereum. Its design prioritized simplicity: the MoneyMarket.sol contract encapsulated all functionality, including borrowing and lending.
Treasury, accounting, and risk management tasks (including collateral checks) were merged into a single contract. This contract retrieved prices from oracles but determined interest rates based on asset utilization. Users interacted only with this contract, though separate calls were required to supply collateral and borrow assets.
Compound v2
Launched in May 2019, Compound v2 ignited the yield farming era and inspired countless forks. It functioned as a money market, allowing users to deposit and borrow assets.
Based on its whitepaper and structure, Compound v2’s primary goal was using the ERC-20 standard to represent borrowing positions. This ensured composability, allowing users to lend to Compound and then use these interest-bearing positions in other blockchain applications.
Notably, the whitepaper didn’t emphasize that Compound v2 would incorporate rewards into its smart contracts. This omission meant the feature’s enormous impact may have been unforeseen.
In Compound v2:
- Each asset has its own treasury contract
- Accounting functions are separated, with each cToken recording user collateral and debt
- A single contract (Comptroller) records and enforces risk management parameters, including collateral checks
- The Comptroller contract references price oracles and determines cToken interest rates
- Price and interest rate oracles operate through different interfaces
- Interest rates are derived from internal asset utilization
- Users must interact with multiple contracts to borrow
Compound v3
Launched in 2022, Compound v3 adopted a more conservative risk management strategy, isolating liquidity into pools for each borrowable asset. The design also reflects a focus on user-friendliness and gas efficiency.
The system is more intuitive for both developers and users due to reduced call requirements. The single-contract design minimizes inter-contract calls, lowering gas costs. Isolated money markets serve as a defense against oracle-based attacks—a major security concern.
Other notable features include:
- A fully redesigned risk management and liquidation engine that enhances fund security while being more borrower-friendly
- Limits on individual collateral assets across markets to mitigate risk
- Separate interest rate models for revenue and borrowing, giving governance full control over economic policy
Interestingly, Compound v3 mirrors the architecture of Compound v1, with a single contract handling all functions for each borrowable asset. Additional features include:
- Only borrowable assets can be borrowed; collateral assets cannot be borrowed
- Collateral does not generate yield in Compound v3
- Prohibiting the borrowing of collateral enhances safety for depositors, reducing the possibility that governance errors or malicious attacks could compromise collateral
From an architectural perspective:
- Each money market is an independent contract containing treasury, accounting, and risk management
- Each money market holds the borrowable asset and all its approved collateral tokens, distributing assets across the application
- Price feeds are the only external input; borrowing rates are generated internally
- Traditional functions like supply, withdraw, borrow, and repay are seamlessly integrated
- A router contract allows multiple operations to be executed in a single call
👉 Explore advanced lending strategies
Aave’s Progression Through Versions
Aave v1 launched in October 2019, replacing ETHLend. It introduced shared liquidity pools instead of ETHLend's peer-to-peer approach.
Similar to Yield v2, a router contract controlled business logic. LendingPoolCore implemented accounting, risk management, and treasury functions. Centralizing the treasury in one contract differentiated it from Compound v2.
The decision to keep collateral checks in a separate contract, called from the router rather than the accounting contract, might seem less robust. However, since Aave v2 arrived two years after v1, this design likely served its purpose.
In Aave v1:
- The
LendingPoolCorecontract handles treasury and accounting LendingPoolDataProvidermanages collateral checks and interacts with oraclesLendingPoolserves as the user entry point and implements business logic- Borrowing rates are determined internally, relying only on price feeds
Aave v2
Aave v2 was released in December 2021. While retaining similar functionality to v1, it introduced an improved and simpler architecture compared to both Aave v1 and Compound v2. This version also introduced aTokens (similar to Compound's cTokens) and vTokens, which represent tokenized debt.
Aave v2 features a clean architecture with full tokenization:
- The
LendingPoolcontract consolidates global accounting and risk management functions, including collateral checks, serving as the primary user access point - aTokens represent collateral, similar to lending positions—user collateral is embodied through their aToken holdings, with treasury functions distributed across all aTokens
- vTokens represent debt positions—user debt is represented by their vToken holdings
Aave v3
Launched in January 2023, Aave v3 added multi-chain support and other features without altering the core architecture. The update also improved risk management and gas efficiency.
Despite these advancements, Aave v3 isn't fundamentally different from Aave v2 for the purposes of this architectural analysis. This may indicate that Aave v2's architecture remained robust into 2023.
Euler’s Innovative Approach
Euler launched in December 2022 with the goal of providing permissionless functionality for money markets with minimal governance.
Its signature design feature is a diamond-like pattern: a single contract holds all of the application's storage, which can be accessed through different proxies, each managing different conceptual elements of the system.
Although one contract stores all asset, accounting, and risk management data, Euler uses eTokens for collateral and lending, and dTokens for debt—similar to Aave v2. However, these token contracts are merely views into the central storage contract.
- The Storage contract manages accounting variables
- The BaseLogic contract acts as the treasury
- The RiskManager contract oversees risk management variables and functions, including collateral checks
Code analysis shows that minimal gas cost was a top priority, leading to a holistic design that eliminated the need for inter-contract calls. Security was ensured through rigorous testing and auditing. Only logic is distributed across various modules, which serve as implementations for the storage contract—which primarily functions as a proxy contract.
This unified design also supports easy upgrades. If storage changes aren't required, modules can be quickly replaced to modify or introduce functionality.
Euler was hacked 15 months after launch, with the exploit occurring six months after an upgrade introduced the vulnerability. The architecture itself didn't cause the asset loss; rather, insufficient oversight of code updates was responsible.
👉 Discover real-time DeFi analytics
Frequently Asked Questions
What is over-collateralized lending in DeFi?
Over-collateralized lending requires borrowers to deposit collateral worth more than the loan value. This protects lenders against price volatility since the collateral can be liquidated if its value falls below a certain threshold relative to the loan amount.
How do lending protocols determine interest rates?
Protocols use varying methods: some derive rates internally based on asset utilization (Compound, Aave), while others use externally supplied rates (MakerDAO, Yield). The approach impacts how responsive rates are to market conditions.
What is liquidation in DeFi lending?
Liquidation occurs when a borrower's collateral value drops below the required threshold. Other participants can then repay portions of the loan in exchange for discounted collateral, helping to ensure the protocol remains solvent.
Why did Compound v3 stop allowing collateral to earn yield?
This change enhanced safety for depositors by reducing the risk that governance errors or attacks could compromise collateral. The existing liquidity from Compound v2 likely made this transition feasible without significantly affecting protocol functionality.
How do tokenized positions work in lending protocols?
Tokenized positions (like cTokens in Compound or aTokens in Aave) represent user deposits as ERC-20 tokens. These tokens accumulate interest and can be transferred, traded, or used as collateral in other DeFi applications, enhancing composability.
Are newer lending protocols necessarily better?
Not necessarily. While newer protocols often improve gas efficiency and user experience, established protocols like MakerDAO have proven extremely secure over time. The choice depends on specific needs: security, efficiency, or particular features.
Conclusion
Early Ethereum applications like MakerDAO, Compound, and Aave demonstrated the potential of over-collateralized lending on blockchain networks. Once these proof-of-concept implementations proved successful, the focus shifted to introducing new features to capture market share. Subsequent versions of Compound and Aave introduced yield farming, composability, and pooled liquidity—techniques that flourished particularly during bull market conditions.
A significant development was Compound v2's introduction of tokenized lending positions, which allowed these positions to be recognized as standard assets by other applications. Aave v2 and Euler went further by implementing tokenized debt positions, though their broader utility remains a topic of debate.
High gas costs became a major concern during bull markets, prompting user experience improvements as seen in Yield v2, Aave v2, and Euler. Router contracts and monolithic implementations helped reduce user transaction costs, albeit at the expense of more complex—and therefore riskier—code.
Compound v3 appears to have set a precedent by prioritizing security over financial efficiency. It departed from traditional liquidity pool models to better guard against potential hacks. The rise of L2 networks, where gas costs become increasingly negligible, will likely influence the design of future collateralized borrowing applications.
When developing blockchain lending applications, always consider where assets are stored, where accounting records are maintained, and how risk and collateral are assessed. Let the historical changes in previous applications and the insights in this overview inform your decisions.