Lending is a cornerstone of blockchain-based applications on Ethereum, with billions in assets currently loaned out. Understanding how these decentralized finance (DeFi) lending protocols operate is crucial for developers, architects, and researchers.
This analysis explores the architectural evolution of major Ethereum lending applications, highlighting key innovations and design patterns that serve as important lessons for future development. We will compare MakerDAO, Yield, Aave, Compound, and Euler, examining how their structures reflect shifting priorities from security to efficiency and user experience.
Understanding DeFi Lending Mechanics
Most DeFi lending operates through over-collateralization. Users can borrow specific assets by providing collateral worth more than the borrowed value. Unlike traditional loans, many DeFi loans don't have regular payments or fixed repayment dates—you can essentially borrow and never repay.
However, there's a critical condition: the collateral value must always remain above a predetermined threshold relative to the borrowed value.
If collateral value falls below this threshold, the loan faces liquidation. During liquidation, others repay part or all of your loan in exchange for receiving portions of your collateral.
All borrowing applications following this financial structure require similar foundational components:
- A treasury to store user collateral and borrowed assets
- An accounting system to track each user's collateral and debt
- A function determining borrower interest rates
- A mechanism to verify sufficient collateral, typically involving external price oracles
- A liquidation pathway for under-collateralized loans
- Risk management systems recording total borrows and other security metrics
- User interfaces for adding/removing collateral, borrowing, and repaying
MakerDAO: The Security-First Pioneer
Launched in November 2019, MakerDAO currently holds $4.95 billion in collateral. Despite its modular architecture with different contracts for each function and unique terminology, it remains relatively straightforward to understand and verify.
In MakerDAO's architecture:
- Treasury functions are managed by Join contracts
- Each approved collateral token has its own dedicated contract
- The protocol doesn't own borrowed DAI assets—it mints and burns DAI as needed
- Accounting is handled within the vat.sol contract, which Join contracts update when collateral enters or exits the system
- The vat.sol contract also serves as the risk management engine, maintaining borrow limits, setting user minimums, and overseeing collateral ratios
MakerDAO prioritized security during its design phase when gas costs were secondary, user experience was less critical, and competition was minimal. While this approach resulted in a system that can seem quirky, expensive to use, and difficult to navigate, its massive managed assets and clean security record highlight its robust design and execution.
Key MakerDAO Characteristics:
- Separate contracts for each asset
- Centralized accounting functionality in a single contract that also records and enforces risk parameters
- Oracles update contracts to supervise collateral (unlike other applications)
- Price and interest rate oracles use different interfaces
- Interest rates originate externally
- Borrowing requires interaction with multiple contracts
👉 Explore advanced lending strategies
Yield Protocol: Evolution Toward Efficiency
Yield v1 served as a proof-of-concept for fixed rates using YieldSpace, built atop MakerDAO's collateral debt engine. However, Yield v1 proved expensive to use and challenging to enhance with new features.
Recognizing YieldSpace's potential, the team quickly developed Yield v2, which launched in October 2021. While still drawing inspiration from MakerDAO, Yield v2 became fully independent and prioritized reduced gas costs and improved user experience.
In Yield v2's architecture:
- All accounting, risk management, and collateral checks merge into a single contract: Cauldron
- Treasury functions distribute across Join contracts, each dedicated to a specific asset
- Oracle integration improves with price and interest rate oracles combined into a universal interface
- The Ladle contract serves as the sole intermediary between users and Yield, providing extensive control over treasury and accounting functions
This architecture allows users to borrow through single transactions to one contract while maintaining robust functionality.
Key Yield v2 Innovations:
- Dedicated vault contracts for each asset
- Single contract centralizing accounting while supervising risk management
- Collateral functions consult oracles for prices and rates
- Unified interface for price and interest rate oracles
- Externally generated interest rates
- Single-transaction borrowing
Compound's Architectural Journey
Compound v1: The Proof of Concept
Compound's first version demonstrated that money markets could exist on Ethereum, prioritizing simplicity. The MoneyMarket.sol contract encapsulated all functionality including borrowing:
- Treasury, accounting, and risk management tasks merged into one contract
- The contract retrieved prices from oracles but determined interest rates based on asset utilization
- Users interacted only with this contract, though separate calls were needed to provide collateral and borrow assets
Compound v2: Tokenizing Lending Positions
Launched in May 2019, Compound v2 ignited the liquidity mining era and inspired countless forks. Its primary goal was using ERC20 standards to represent borrowing positions, ensuring composability that allowed users to lend to Compound then use these interest-bearing positions in other blockchain applications.
In Compound v2's architecture:
- Each asset has its own money contract
- Accounting functions separate, with each cToken recording user collateral and debt
- A single contract (Comptroller) records and enforces risk management parameters
- The Comptroller references price oracles for collateral checks and cToken interest rates
- Price and interest rate oracles operate through different interfaces
- Interest rates derive from internal asset utilization
- Borrowing requires interaction with multiple contracts
Compound v3: Returning to Security Fundamentals
Released in 2022, Compound v3 adopted a more conservative risk management approach, isolating liquidity into pools for each borrowable asset. The design also reflected heightened attention to user friendliness and gas costs.
Compound v3 mirrors Compound v1's architecture with individual contracts handling all functions for each borrowable asset. Notable features include:
- Only borrowable assets can be borrowed (collateral assets cannot be borrowed)
- Collateral doesn't generate yield in Compound v3
- Traditional functions (supply/withdraw/borrow/repay) are cleverly integrated
- Routing contracts allow multiple operations in single calls
This approach improves security for collateral depositors and represents a departure from traditional liquidity pool models for better hack protection.
Aave's Progressive Refinement
Aave v1: Introducing Shared Liquidity Pools
Launched in October 2019, Aave v1 introduced shared liquidity pools instead of ETHLend's peer-to-peer approach. Its architecture featured:
- LendingPoolCore contract handling treasury and accounting
- LendingPoolDataProvider managing collateral checks and oracle interactions
- LendingPool serving as user entry point and implementing business logic
- Internally determined borrowing rates relying solely on price feedback
Aave v2: Clean Architecture with Full Tokenization
Released in December 2021, Aave v2 introduced an improved, simpler architecture while retaining similar functionality to its predecessor:
- LendingPool contract consolidates global accounting and risk management
- aTokens represent collateral, similar to lending positions
- vTokens represent debt positions
- User collateral manifests through aToken holdings with treasury functions distributed across all aTokens
Aave v3: Multichain Support and Enhancements
Launched in January 2023, Aave v3 added multichain support and other features without fundamentally changing the core architecture. The update improved risk management and gas efficiency, demonstrating that Aave v2's architecture remained robust into 2023.
Euler's Minimalist Approach
Launched in December 2022, Euler aimed to provide permissionless functionality for money markets with minimal governance. Its design featured a diamond pattern with:
- A single contract storing all application data
- Various proxies accessing this storage, each managing different conceptual elements
- eTokens for collateral and lending, and dTokens for debt (similar to Aave v2)
- Minimal gas costs as a priority through design eliminating inter-contract calls
Despite this unified design supporting easy upgrades, Euler suffered a hack 15 months after launch due to insufficient oversight of code updates rather than fundamental architectural flaws.
Comparative Analysis and Trends
Early Ethereum applications like MakerDAO, Compound, and Aave demonstrated the potential of over-collateralized borrowing on Ethereum. Once these proofs-of-concept proved successful, focus shifted to introducing new features to capture market share.
A significant development was Compound v2's introduction of tokenized lending positions, enabling these positions to be recognized as standard assets by other applications. Aave v2 and Euler further implemented tokenized debt positions, though their broader utility remains debated.
High gas costs became a significant concern during bull markets, prompting user experience changes 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 set a precedent by prioritizing security over financial efficiency, departing 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 future collateral borrowing application designs.
Frequently Asked Questions
What is over-collateralization in DeFi lending?
Over-collateralization requires borrowers to deposit collateral worth more than the loan value. This protects lenders against price volatility and ensures loans remain secure even if collateral values fluctuate. Most DeFi platforms require collateralization ratios between 110-150%.
How do liquidations work in DeFi lending protocols?
When a loan's collateral value falls below a predetermined threshold, it becomes eligible for liquidation. Other users can repay portions of the under-collateralized loan in exchange for discounted collateral. This mechanism protects the protocol from losses while creating opportunities for liquidators.
What are the main differences between Compound and Aave?
While both offer similar lending services, Compound typically uses separate contracts for each token with cTokens representing deposits, while Aave uses a pooled approach with aTokens. Aave also offers more diverse features like flash loans and credit delegation, while Compound has focused on simpler, more secure designs in its v3 iteration.
Why did Euler's architecture fail to prevent its hack?
Euler's hack resulted not from its fundamental architecture but from insufficient oversight of code updates. The protocol's modular design actually allowed for quick identification and resolution of the issue, though not before significant funds were lost. This highlights that even well-designed systems require rigorous security practices.
How do interest rates work in DeFi lending platforms?
Interest rates in DeFi typically follow algorithmic models based on supply and demand. When more users want to borrow an asset, rates increase to incentivize more suppliers. When borrowing demand decreases, rates fall to attract more borrowers. Some platforms like Yield protocol focus on fixed rates through specialized mechanisms.
What future trends might affect DeFi lending architecture?
Layer 2 scaling solutions, cross-chain interoperability, and improved risk management models will likely shape future DeFi lending architecture. We may also see more specialized lending protocols catering to specific asset types or user needs, as well as increased integration with traditional finance systems.
Conclusion
The evolution of Ethereum lending applications reveals clear patterns in design priorities shifting from initial security focus toward efficiency and user experience, with recent developments showing a return to security fundamentals. Each protocol's architectural choices reflect its historical context, target users, and risk tolerance.
When developing blockchain lending applications, carefully consider asset storage, accounting placement, and risk assessment methodologies. The historical changes and insights from established applications can provide valuable guidance for these decisions, helping create more secure, efficient, and user-friendly lending platforms.
As the DeFi landscape continues evolving, particularly with L2 networks reducing transaction costs, future lending applications may embrace more complex functionality while maintaining robust security through architectural innovations and careful risk management.