Aave is a pooled, over-collateralized lending protocol where depositors receive interest-bearing aTokens and borrowers take variable-rate loans against collateral, protected by liquidations and a layered risk framework. Building something "like Aave" means understanding why each of those layers exists, most of which were added after real incidents.
This page dissects Aave's design as a reference. For a protocol-agnostic build guide covering interest rate math, oracles and pooled versus isolated markets, start with building a DeFi lending and borrowing platform.
A short history and why it matters
Aave began in 2017 as ETHLend, a peer-to-peer lending marketplace that struggled to match lenders with borrowers. It relaunched as Aave with pooled liquidity in early 2020, released v2 later that year and v3 in 2022, initially on other networks and then on Ethereum. Each version responded to problems in the previous one: peer-to-peer matching was too slow, and pooled risk proved too broad without isolation tools. Aave also launched its own stablecoin, GHO, in 2023. Aave Labs has published a v4 design built around a hub-and-spoke liquidity architecture; check the official repositories and documentation for what is deployed today rather than relying on announcements.
The lesson for a new protocol: start with the mature design, not the first one.
Core components
| Component | Role | Design note |
|---|---|---|
| Pool | Entry point for supply, borrow, repay, withdraw, liquidate, flash loans | Upgradeable via governance-controlled proxy |
| aTokens | Receipt for deposits; balance grows with interest | Scaled balances times a liquidity index give the current balance |
| Variable debt tokens | Non-transferable record of debt; grows with borrow interest | Prevents moving debt to unsuspecting addresses |
| Interest rate strategy | Utilization-based kinked curve per asset | Parameters set by governance on risk providers' advice |
| Oracle | Asset prices, mostly from Chainlink feeds with fallbacks | Custom adapters for correlated and pegged assets |
| Pool configurator and ACL manager | Parameter changes and role-based permissions | Separates risk admin, emergency admin and pool admin roles |
| Treasury and reserve factor | Share of interest kept by the protocol | Funds the DAO and can absorb deficits |
| Safety module | Staked backstop that can be slashed to cover shortfalls | Mechanics have been redesigned over time |
How aTokens accrue interest without loops
Each reserve keeps a liquidity index that grows as interest accrues. A user's stored value is a scaled balance: deposit amount divided by the index at deposit time. Their current balance is the scaled balance times the current index. Debt tokens work the same way with a variable borrow index. The protocol updates two numbers per reserve on each interaction, never iterating over users. The same accumulator idea appears in staking contracts and vaults.
Risk features worth copying
Supply and borrow caps
Caps limit how much of an asset can be supplied as collateral or borrowed. They bound damage from a manipulated or collapsing asset to a known amount. In late 2022 a trader used Aave v2 to attempt a large short on CRV, a strategy that left the protocol with a modest amount of bad debt when liquidations could not keep pace. Caps and stricter parameters for volatile assets are the structural answer.
Isolation mode
Newly listed or riskier assets can be supplied as collateral only in isolation: a user using them cannot use other collateral at the same time, can borrow only approved stablecoins, and total borrowing against the asset is limited by a debt ceiling. This lets a pooled protocol list long-tail assets without exposing the entire pool.
Efficiency mode (E-Mode)
Assets whose prices move together, such as stablecoins or ETH and its liquid staking derivatives, can be grouped into categories with higher LTV and liquidation thresholds. Borrowing ETH against wstETH at a high LTV is reasonable because the two rarely diverge, though they can during stress. E-Mode is one of Aave's main capital-efficiency advantages and also its main correlated-risk exposure, so oracle choice for these assets is critical.
Siloed borrowing
Assets with risky oracles or behavior can be borrowable only on their own: a user who borrows a siloed asset cannot borrow anything else in the same position.
Deprecating features
Aave once offered "stable" interest rates, which were rebalanced under certain conditions. The feature proved complex and was disabled after a vulnerability report in 2023, then removed. Not every feature of a mature protocol is one to copy.
Liquidations in Aave's model
A position becomes liquidatable when its health factor drops below 1. Liquidators repay part of the debt and receive collateral plus a per-asset liquidation bonus. The close factor limits how much debt can be repaid in a single call, with later v3 releases allowing full liquidation of deeply unhealthy or very small positions to avoid leaving uneconomic dust. Liquidators can receive collateral as the underlying asset or as aTokens, and can fund liquidations with flash loans, which makes the liquidation market highly competitive.
Flash loans
Aave popularized flash loans: borrow any amount of available liquidity, use it within the same transaction, and repay with a small premium. They enable collateral swaps, self-liquidations and arbitrage, and also finance attacks on protocols that read manipulable prices. If you add flash loans to your protocol, check every function for state that could be inconsistent mid-loan and protect governance and oracles against flash-borrowed balances.
Governance and risk management
Aave is governed by AAVE holders through a DAO that approves proposals and executes them via timelocked executors. Day-to-day parameter work, like adjusting caps and rates, is delegated to independent risk service providers whose recommendations governance adopts, plus tightly scoped stewards for faster changes. A new protocol rarely has this apparatus, so it must start with conservative parameters, a short asset list and an emergency guardian that can pause but not move funds.
Forking Aave: a realistic plan
- Check the license of the exact version you plan to deploy. Aave's releases have used different licenses, including business source terms for some code; get legal confirmation.
- Pick a market niche: a chain where Aave is absent, a specific asset ecosystem, or a regulated or permissioned market (Aave has run a permissioned market for institutions in the past, which shows the code can be adapted to allowlists).
- Define the asset list and parameters from on-chain liquidity data: how much of each collateral could be sold in a crash without excessive slippage.
- Set up oracles with staleness checks, sequencer-uptime checks on rollups and specific adapters for pegged assets.
- Configure roles: multisig and timelock for pool admin, a limited emergency admin, and no single-key owner.
- Run liquidation bots and publish integration docs for third-party liquidators.
- Audit your changes, even small ones. Many lending forks were exploited because a minor modification or a new asset broke an assumption in otherwise audited code.
- Launch with caps, publish risk dashboards and raise limits as liquidity grows.
Mistakes lending forks keep making
- Listing illiquid tokens with high LTVs, then being drained by price manipulation.
- Using a DEX spot price as an oracle.
- Launching new markets empty, exposing rounding and exchange-rate attacks.
- Copying parameters from Aave on Ethereum to a chain with a fraction of the liquidity.
- Leaving upgrade powers with a deployer key.
For audit planning, see the smart contract audit guide; for NFT-collateralized credit, which uses quite different mechanics, see NFT lending platform development; and for the stablecoin side of Aave's design, see decentralized stablecoin development.
Cost and timeline
As a reasoned estimate, deploying an Aave v3 fork on a new EVM chain with a small asset list, a branded front end, liquidation bots and monitoring takes a team of three to five engineers two to four months, plus an audit of all changes and an independent risk assessment of parameters. Ongoing costs include oracle infrastructure, risk monitoring and governance operations; these never end. Substantive modifications to accounting, a new interest model or a stablecoin module turn it into a protocol build measured in many months.
Frequently asked questions
Can I legally fork Aave?
It depends on the version's license. Some Aave code has been released under business source terms that restrict commercial use without permission for a period. Read the license file of the exact release and get legal advice before deploying.
What are aTokens?
Receipt tokens for deposits. Their balance increases over time as interest accrues, calculated from a scaled balance and a reserve-wide liquidity index. They can be transferred, used in other protocols or redeemed for the underlying asset if liquidity is available.
What is E-Mode?
Efficiency mode groups correlated assets, such as stablecoins or ETH and liquid staking tokens, and allows higher borrowing limits between them. It improves capital efficiency but concentrates risk if the correlation breaks.
How does Aave protect against bad debt?
Through conservative collateral parameters, supply and borrow caps, isolation and siloed modes, liquidation incentives, reserves and a staked safety backstop. None of these eliminates bad debt; together they make it rare and bounded.
Do I need a governance token to run an Aave-like protocol?
No. A new protocol can start with a multisig and timelock controlling parameters. A token can come later, if ever, once there is something meaningful to govern.
How is an Aave-style protocol different from Compound?
Both are pooled lending protocols. Compound III moved to a model where each market has a single borrowable asset, while Aave kept multi-asset borrowing and added isolation, siloed borrowing and E-Mode to manage risk inside one pool.