How To Compare DeFi Borrowing Architectures on Ethereum?
November 4, 2025
6 mins read
This article explores the evolving architectures of leading DeFi platforms, offering insights into the diverse strategies used to address security, efficiency, and user experience. It delves into key components of DeFi borrowing, such as...
Borrowing plays a pivotal role in Ethereum-based decentralized finance (DeFi) applications. This article explores the evolving architectures of leading DeFi platforms, offering insights into the diverse strategies used to address security, efficiency, and user experience. It delves into key components of DeFi borrowing, such as overcollateralization, liquidation, and the fundamental building blocks for these applications. The focus is on analyzing the architectural evolution of platforms like MakerDAO, Compound, Aave, Euler, and Yield.
I: Understanding Borrowing in DeFi
Overcollateralization in DeFi Borrowing
Most DeFi borrowing practices are characterized by overcollateralization. This means that users can only borrow a specific asset if they provide collateral that exceeds the value of the loan. Unlike conventional loans, these DeFi loans typically lack regular repayments or fixed end dates, allowing borrowers to defer repayment indefinitely. However, there is a crucial catch: the value of the collateral must always exceed the loan value by a predetermined margin. If the collateral's value falls below this threshold, the loan is subject to liquidation. During liquidation, a third party repays a portion or the entirety of the loan, receiving a commensurate share of the collateral in return.
Liquidation in DeFi Borrowing
The process of liquidation, inherent to DeFi borrowing, involves several key components:
-
A treasury to hold user collateral and borrowed assets.
-
An accounting system to track individual users' collateral and debt.
-
Mechanisms to determine interest rates for borrowers.
-
A verification system to assess loan collateralization, often utilizing external price oracles.
-
A path for liquidating undercollateralized loans.
-
Robust risk management systems, recording vital metrics like global and per-user borrowing limits, collateral minimums, and specific over-collateralization ratios.
-
A user-friendly interface for users to manage collateral, borrow assets, and make repayments.
Key Building Blocks for DeFi Borrowing Applications
These components serve as the foundational building blocks for DeFi borrowing applications. They can be arranged and implemented in various ways, depending on the platform's unique architecture. The subsequent sections will delve into the architectural nuances of MakerDAO, Compound, Aave, Euler, and Yield, sheddin
g light on how these components are configured within each system.
II: Architectural Evolution of MakerDAO
MakerDAO's Background
MakerDAO, a pioneering figure in the Ethereum landscape, entered its current form in November 2019 and currently holds a staggering $4.95 billion in collateral. Despite its extensive modular architecture and distinctive contract-based design, MakerDAO's structure remains both comprehensible and verifiable.
The Modular Architecture of MakerDAO
MakerDAO's architecture is composed of several critical components:
-
Treasury Management: The treasury function is managed by the Join contracts, with a dedicated contract for each approved collateral asset.
-
Accounting and Debt Tracking: Accounting functions are centralized within the vat.sol contract. Joins update this contract as collateral enters or exits the system. Borrowers interact with vat.sol when they mint DAI or repay it.
-
Risk Management: The vat.sol contract serves as the risk management engine, overseeing global borrowing limits, per-user thresholds, and collateralization ratios.
Unique Features of MakerDAO
MakerDAO distinguishes itself through its distinctive features:
-
Price and Interest Rate Oracles: Unlike most other DeFi platforms, MakerDAO employs oracles to update the contract and oversee collateralization, thus ensuring the integrity of the system.
-
Borrowing and Repayment Process: To borrow or repay, users must interact with multiple contracts, a method unique to MakerDAO.
III: Architectural Evolution of Compound Finance
The Evolution of Compound: v1, v2, and v3
The first version of Compound served as a Proof of Concept, emphasizing simplicity in its design. MoneyMarket.sol encapsulated all functions, including lending.
Compound v2, launched in May 2019, aimed to promote the use of ERC20 standards for lending positions, fostering composability within the DeFi ecosystem.
Compound v3, released in 2022, shifted focus towards safety by segregating liquidity into separate pools for each borrowable asset. The redesign sought to reduce gas costs and enhance user experience.
Simplicity and Tokenized Lending Positions
Compound v1's architecture emphasized simplicity, condensing treasury, accounting, and risk management functions into one contract. Users interact solely with this contract, but they must make separate calls to supply collateral and borrow assets.
Compound v2 introduced tokenized lending positions, enabling users to employ interest-bearing positions in other blockchain applications.
Compound v3 prioritized safety, deviating from traditional liquidity pool models to better protect against potential hacks.
Architectural Features of Compound
Compound's architecture is marked by several key elements:
-
Individual treasury contracts for each asset, ensuring maximal distribution of the treasury function.
-
Consolidation of accounting functions into a single contract.
-
A Comptroller contract overseeing risk management parameters.
-
Distinct interfaces for price and interest rate oracles.
-
Borrowing and lending interest rates generated internally.
-
Users must interact with multiple contracts to borrow.
IV: Architectural Evolution of Aave
Aave's Transition from ETHLend
Aave, launched in October 2019, marked a transition from its predecessor, ETHLend's peer-to-peer approach to a shared liquidity pool model. This shift enabled users to lend and borrow assets within a single, communal pool.
Aave v1: Shared Liquidity Pool
Aave v1 established a shared liquidity pool with distinct architectural features:
-
Accounting and Treasury: The LendingPoolCore contract managed accounting and treasury functions, serving as the core of the system.
-
Collateralization Checks: Unlike some other DeFi platforms, Aave v1 employed a dedicated contract, LendingPoolDataProvider, for collateralization checks, which was called from the router contract.
Aave v2: Simplicity and Tokenization
Aave v2, introduced in December 2021, simplified its architecture and introduced tokenized assets and debt positions:
- Introduction of aTokens and vTokens: Aave v2 brought forth aTokens, representing collateral, and vTokens, which represented tokenized debt positions. These additions provided a novel approach to managing collateral and debt.
Aave v3: Multi-Chain Support
Aave v3, released in January 2023, expanded its capabilities with support for multiple chains. While retaining features similar to Aave v2, it introduced improved risk management and enhanced gas efficiency.
V: Architectural Evolution of Euler
Introduction to Euler
Euler, introduced in December 2022, aimed to provide money markets with permissionless features and minimal governance. Its architecture adopted a unique diamond-like pattern, different from other DeFi platforms.
The Diamond-Like Pattern and Monolithic Design
Euler's distinctive design centered on a single contract, termed the "Storage," which stored all assets, accounting data, and risk management metrics. This monolithic approach eliminated the need for inter-contract calls, optimizing gas efficiency and simplifying transactions. Users accessed distinct proxies, each managing specific elements of the system.
Security and Flexibility in Euler
Security was a paramount concern in Euler's design. Rigorous testing and auditing assured the platform's safety. The modular implementation enabled easy upgrades, as modules could be replaced swiftly to introduce new features without altering the storage contract.
Euler's design emphasized gas efficiency, but it encountered a security breach fifteen months after its release. The breach did not seem related to its monolithic architecture but rather due to insufficient oversight of code updates.
Conclusion
In summary, understanding the storage of assets, the placement of accounting records, and methods for risk and collateral evaluation are essential when developing a blockchain borrowing application. Drawing from the historical insights provided by earlier platforms and the architectural evolution outlined in this overview can serve as a valuable guide for future developers entering the DeFi landscape.
Experience verifiable data in action - Join the zkDatabase live demo!
Book a Demo
