How to Fork Aave: Build Your Own Lending Protocol

What Is Aave and Why Fork It?

Aave is one of the largest decentralized lending protocols in DeFi, with billions of dollars in total value locked across multiple chains. At its core, Aave allows users to deposit crypto assets to earn interest and borrow assets against their collateral. Interest rates adjust algorithmically based on supply and demand, and the entire system runs on smart contracts without any centralized intermediary.

So why would you want to fork it? There are several compelling reasons builders consider learning how to fork Aave:

• Custom collateral types — support assets that Aave governance hasn't approved, such as real-world asset tokens, LP tokens from specific DEXes, or niche ERC-20 tokens serving a particular community.
• Chain-specific deployments — launch on newer L2s or EVM-compatible chains where Aave hasn't deployed yet, capturing early liquidity.
• Niche market focus — build a lending market tailored to a specific vertical like NFT collateral, gaming assets, or stablecoin-only markets.
• Revenue from interest rate spreads — protocol owners earn a percentage of interest paid by borrowers, creating a sustainable revenue stream.
• Full control over governance — set your own risk parameters, upgrade schedules, and fee structures without needing approval from Aave DAO voters.

Because Aave's smart contracts are open source (licensed under BUSL-1.1 for V3, with older versions under more permissive licenses), anyone can study, fork, and modify the codebase. However, as we'll explore in this guide, the distance between "cloning a repository" and "running a production lending protocol" is enormous.

Aave V2 vs V3: Which Version to Fork?

When you decide to fork Aave, the first decision is which version to base your project on. Both V2 and V3 are battle-tested and have been deployed on mainnet for years, but they differ significantly in complexity and features.

Our recommendation: If you're building a simple lending market and want the easiest path, V2 is more approachable due to its GPL license and simpler architecture. If you need advanced risk management features like isolation mode and eMode, V3 is the way to go — but be aware of the BUSL-1.1 license implications. According to DeFiLlama, there are now over 50 Aave V3 forks deployed across various chains, demonstrating that the complexity is manageable with the right team.

Architecture Overview

Before you touch any code, you need to understand how Aave's contracts fit together. The protocol is modular by design, which makes it powerful but also means there are many moving parts.

Core Contracts

• Pool (LendingPool in V2) — the main entry point for all user interactions: supply, borrow, repay, withdraw, and liquidate. Every transaction flows through this contract.
• PoolAddressesProvider — a registry that stores the addresses of all other protocol contracts. This is the single source of truth for the deployment — if you need to upgrade a component, you update its address here.
• aTokens — ERC-20 tokens that represent a user's deposit. When you supply 100 USDC, you receive 100 aUSDC. These tokens accrue interest in real time — your balance increases every block.
• Debt Tokens — track what users owe. There are two varieties: StableDebtToken (fixed-rate borrowing) and VariableDebtToken (floating-rate borrowing).
• Price Oracle — fetches asset prices from external sources (typically Chainlink). The oracle contract aggregates prices and provides them to the Pool for calculating health factors and collateral values.
• Interest Rate Strategy — each asset has its own interest rate model defined by a contract implementing IInterestRateStrategy. These contracts use a kinked curve: rates are low when utilization is below the optimal threshold and spike sharply above it.

Supporting Infrastructure

• ACL Manager — role-based access control for admin functions (adding assets, pausing the protocol, setting risk parameters).
• Pool Configurator — admin interface for configuring reserves, setting LTV ratios, and enabling/disabling features.
• Liquidation logic — handles undercollateralized position cleanup. In V3, this includes a liquidation bonus that incentivizes third-party liquidators.
• Flash Loan logic — enables uncollateralized single-transaction loans, used by arbitrageurs and composability protocols.

Understanding this architecture is essential because when you fork Aave, you aren't just deploying one contract — you're deploying and correctly wiring together a system of 20+ interrelated contracts.

Step 1 — Clone and Set Up

Start by cloning the Aave V3 core repository and installing dependencies:

# Clone the core protocol contracts
git clone https://github.com/aave/aave-v3-core.git
cd aave-v3-core

# Install dependencies
npm install

# Compile contracts
npx hardhat compile

The repository is organized into several key directories:

aave-v3-core/
  contracts/
    protocol/         # Core protocol (Pool, aTokens, debt tokens)
    misc/             # Helper contracts (WETH gateway, etc.)
    flashloan/        # Flash loan logic
    interfaces/       # All interface definitions
  deploy/             # Deployment scripts
  helpers/            # Deployment helper utilities
  test/               # Test suite
  markets/            # Market configurations per chain

You'll also want the deploy repository, which contains the actual deployment scripts and market configurations:

# Clone the deployment tooling
git clone https://github.com/aave/aave-v3-deploy.git
cd aave-v3-deploy
npm install

Make sure you're running Node.js 16+ and have Hardhat configured properly. The test suite is extensive — run it first to make sure everything compiles and passes before making any changes.

Step 2 — Configure Markets

Market configuration is where you define which assets your lending protocol supports and their risk parameters. In Aave V3, this is done through configuration files in the markets/ directory.

Here's an example of how a reserve configuration looks:

// markets/mychain/reservesConfigs.ts
export const strategyUSDC: IReserveParams = {
  strategy: rateStrategyStableTwo,
  baseLTVAsCollateral: '8000',   // 80% LTV
  liquidationThreshold: '8500',  // 85% liquidation threshold
  liquidationBonus: '10500',     // 5% liquidation bonus
  liquidationProtocolFee: '1000', // 10% of liquidation bonus to protocol
  borrowingEnabled: true,
  stableBorrowRateEnabled: false,
  flashLoanEnabled: true,
  reserveDecimals: '6',
  aTokenImpl: eContractid.AToken,
  reserveFactor: '1000',         // 10% of interest goes to treasury
  supplyCap: '2000000000',       // 2B USDC supply cap
  borrowCap: '2000000000',       // 2B USDC borrow cap
  debtCeiling: '0',
  borrowableIsolation: true,
};

Key parameters you'll need to set for each asset:

• baseLTVAsCollateral — the maximum percentage a user can borrow against this asset. An 80% LTV means depositing $1000 worth allows borrowing up to $800.
• liquidationThreshold — the point at which a position becomes liquidatable. Set this above the LTV to give borrowers a safety buffer.
• liquidationBonus — the discount liquidators receive when closing unhealthy positions. 10500 means a 5% bonus (100% + 5%).
• reserveFactor — the percentage of interest payments that go to the protocol treasury. This is your revenue.
• supplyCap / borrowCap — maximum amounts that can be supplied or borrowed (V3 only). Essential for limiting exposure to volatile or low-liquidity assets.

You also need to define interest rate strategies. These control how borrow rates change based on utilization:

export const rateStrategyStableTwo: IInterestRateStrategyParams = {
  name: 'rateStrategyStableTwo',
  optimalUsageRatio: ethers.utils.parseUnits('0.8', 27).toString(),
  baseVariableBorrowRate: '0',
  variableRateSlope1: ethers.utils.parseUnits('0.04', 27).toString(),
  variableRateSlope2: ethers.utils.parseUnits('0.75', 27).toString(),
  stableRateSlope1: ethers.utils.parseUnits('0.005', 27).toString(),
  stableRateSlope2: ethers.utils.parseUnits('0.75', 27).toString(),
  baseStableRateOffset: ethers.utils.parseUnits('0.01', 27).toString(),
  stableRateExcessOffset: ethers.utils.parseUnits('0.08', 27).toString(),
  optimalStableToTotalDebtRatio: ethers.utils.parseUnits('0.2', 27).toString(),
};

The interest rate curve uses two slopes: slope1 applies below optimal utilization (encouraging borrowing), and slope2 applies above it (discouraging over-utilization). Getting these numbers right is critical for balancing depositor yields with borrower costs.

Step 3 — Set Up Price Oracles

Price oracles are the backbone of any lending protocol. They determine collateral values, health factors, and liquidation triggers. A faulty oracle can drain your entire protocol in minutes.

Aave uses Chainlink price feeds as its primary oracle source. You'll need to configure the oracle contract to point to the correct Chainlink aggregators on your target chain:

// markets/mychain/commons.ts
export const chainlinkAggregatorProxy: Record<string, string> = {
  USDC: '0x50834F3163758fCC1Df9973b6e91f0F0F0434aD3',
  WETH: '0x5f4eC3Df9cbd43714FE2740f5E3616155c5b8419',
  WBTC: '0xF4030086522a5bEEa4988F8cA5B36dbC97BeE88c',
  // Add your asset price feeds here
};

Important considerations for oracle setup:

• Chainlink availability — not all assets have Chainlink feeds on all chains. If your target chain or asset lacks a feed, you'll need a fallback solution.
• Fallback oracle pattern — Aave implements a fallback mechanism where if the primary oracle fails or returns stale data, a backup source is used. You should configure both.
• Heartbeat and deviation thresholds — each Chainlink feed updates at different intervals. Make sure your protocol handles stale prices correctly.
• Base currency — Aave V3 uses USD as the base currency for all price calculations. Ensure all your price feeds return values in the same denomination.

// Example: Setting up the oracle in deployment
const aaveOracle = await deploy('AaveOracle', {
  args: [
    addressesProvider.address,
    [USDC_ADDRESS, WETH_ADDRESS, WBTC_ADDRESS],
    [USDC_ORACLE, WETH_ORACLE, WBTC_ORACLE],
    FALLBACK_ORACLE_ADDRESS,
    USD_ADDRESS,
    ethers.utils.parseUnits('1', 8), // base currency unit
  ],
});

Oracle manipulation is one of the most common attack vectors in DeFi. Using Chainlink mitigates most risks, but you should also implement circuit breakers that pause borrowing if prices move beyond expected thresholds within a short window.

Step 4 — Deploy to Testnet

Once your configurations are in place, it's time to deploy. Aave provides deployment scripts, but they require careful configuration.

First, set up your environment variables:

# .env
PRIVATE_KEY=your_deployer_private_key
ALCHEMY_KEY=your_alchemy_api_key
ETHERSCAN_API_KEY=your_etherscan_key

# For testnet deployment
HARDHAT_NETWORK=sepolia

Run the deployment:

# Deploy core protocol
npx hardhat deploy --network sepolia --tags core

# Initialize reserves (add your configured assets)
npx hardhat deploy --network sepolia --tags init

# Verify contracts on Etherscan
npx hardhat verify-contracts --network sepolia

The deployment process will create and wire together approximately 20-30 contracts depending on how many assets you configure. After deployment, verify that:

• All contracts are correctly linked through the AddressesProvider.
• Oracles return valid prices for each configured asset.
• You can successfully supply and borrow in a test transaction.
• Liquidation works correctly when positions become undercollateralized.
• Interest accrues properly over time (advance blocks in your test).

Expect to spend several days debugging deployment issues. Common problems include incorrect constructor arguments, missing oracle feeds on testnet, and library linking errors.

Step 5 — Build the Frontend

With the contracts deployed, you need a user interface. Aave's official frontend is open source, but it's a complex React application with hundreds of components.

You have three options:

1. Fork the Aave interface — clone aave/interface from GitHub. It's built with React, Next.js, and uses ethers.js for contract interactions. You'll need to update contract addresses, branding, and supported networks. This is the most feature-complete option but requires significant frontend expertise.
2. Build from scratch — use a framework like React or Vue and interact with contracts directly via ethers.js or viem. This gives full control but takes months of development for basic functionality (deposit, borrow, repay, withdraw, health factor display).
3. Use a template — some projects offer pre-built lending frontends that you can configure to point at your deployed contracts.

Key frontend components you'll need:

• Market overview — show all assets with current supply/borrow APYs, total supplied, total borrowed.
• Deposit/Withdraw — approve token spending, call pool.supply() and pool.withdraw().
• Borrow/Repay — display available borrow amount based on collateral, call pool.borrow() and pool.repay().
• Health factor display — calculate and show the user's health factor in real time. Below 1.0 means liquidation risk.
• Wallet connection — integrate with MetaMask, WalletConnect, and other providers.

The frontend alone typically takes 2-4 months of development time for a small team, even when forking the existing Aave interface.

The Hidden Complexity of Aave Forks

Most guides about how to fork Aave stop at deployment. But deploying the contracts is only about 20% of the work. Here's what catches most teams off guard:

Governance Setup

Aave uses a sophisticated governance system with tiered proposal types, time locks, and voting power delegation. If you fork the protocol, you need to decide: do you implement on-chain governance from day one, or start with a multisig? Most forks start with a multisig (like Gnosis Safe) and plan to decentralize later — but "later" often never comes, leaving users trusting a small team with full admin control.

Oracle Reliability

Chainlink feeds are reliable on major chains, but if you deploy on a newer L2 or alt-L1, you may find that feeds are missing, update infrequently, or have wider deviation thresholds. Some Aave forks have been exploited because they used oracle sources that could be manipulated through flash loans or low-liquidity pools.

Liquidation Bot Infrastructure

Your protocol is only as safe as its liquidation infrastructure. If borrowers become undercollateralized and nobody liquidates them, the protocol accrues bad debt. You need:

• At least one reliable liquidation bot running 24/7.
• Sufficient liquidity for liquidators to execute trades.
• Gas price monitoring to ensure liquidations are profitable on-chain.
• Alerting systems for when positions approach liquidation thresholds.

Running this infrastructure costs $500-2000/month in cloud hosting and gas fees, and requires ongoing maintenance.

Security Audits

Any lending protocol handling real user funds must be audited. Even if you only changed a few configuration files, auditors need to verify that your changes don't introduce vulnerabilities. Professional audits from firms like Trail of Bits, OpenZeppelin, or Spearbit cost $100,000-$500,000 depending on scope, and take 4-8 weeks.

Ongoing Maintenance

Post-launch, you'll need to monitor for:

• Oracle failures or stale prices.
• Interest rate model performance (are rates attracting enough depositors?).
• Asset risk changes (did a supported token lose liquidity?).
• Smart contract upgrades when vulnerabilities are discovered in the Aave codebase.
• Frontend hosting and reliability.

Alternative Approaches to Building a Lending Protocol

Forking Aave is one approach, but it's not the only one. Here's how the alternatives compare:

The "simplified lending contracts" approach means writing your own pool contract from scratch with only the features you need: deposit, borrow, repay, withdraw, and liquidate. Without the complexity of flash loans, stable rates, eMode, isolation mode, and portals, the codebase shrinks by 80%, making it far easier to audit and maintain. This is the approach taken by projects like Lenda, which implements an ERC4626-inspired vault with Chainlink oracles and multi-collateral support in a fraction of the code.

List of Notable Aave Forks

Dozens of teams have already forked Aave with varying degrees of success. Here are the most notable ones:

A few important lessons from these forks:

• Security is paramount. Both Radiant and Sturdy suffered exploits that cost millions. In Radiant's case, the exploit targeted the multisig infrastructure rather than the Aave code itself, demonstrating that the attack surface extends far beyond smart contracts.
• Chain choice matters. Forks on chains with deep liquidity (Ethereum, Arbitrum) tend to survive longer than those on smaller chains where liquidity can dry up quickly.
• Token incentives are a double-edged sword. Most forks launch with aggressive token emissions to attract TVL, but this creates mercenary capital that leaves when rewards decrease.
• Some forks have been shut down. Geist Finance wound down operations, proving that even a well-executed fork isn't guaranteed to succeed long-term.

How Much Does It Cost to Fork Aave?

Let's break down the realistic costs of launching an Aave fork from scratch. These numbers are based on actual market rates for Solidity developers, auditors, and infrastructure providers in 2025-2026.

Development Costs

• Smart contract customization: $30,000-$80,000 — modifying Aave's contracts, configuring markets, writing deployment scripts, and building a test suite for your changes.
• Frontend development: $20,000-$60,000 — forking and customizing the Aave interface or building from scratch. Includes wallet integration, responsive design, and transaction handling.
• Liquidation bot: $10,000-$30,000 — custom bot that monitors positions and executes liquidations. Must handle gas price spikes and MEV competition.
• Subgraph/indexer: $5,000-$15,000 — building a Graph Protocol subgraph or custom indexer for historical data and analytics.

Security Costs

• Professional audit: $100,000-$500,000 — a thorough audit from a top firm. Even for a minimal fork with few changes, expect at least $100K.
• Bug bounty program: $50,000-$200,000 — ongoing budget for rewarding vulnerability disclosures.
• Formal verification (optional): $50,000-$150,000 — mathematical proof of contract correctness.

Ongoing Operational Costs

• Cloud infrastructure: $500-$2,000/month — RPC nodes, liquidation bot hosting, monitoring, and alerting.
• Oracle costs: Variable — Chainlink feeds are free to read, but running custom oracle nodes has costs.
• Team maintenance: $10,000-$30,000/month — at minimum, you need 1-2 developers on call for emergencies.

Total Cost Comparison

Full Aave V3 Fork: $200,000-$800,000+ to launch, plus $15,000-$40,000/month to operate.

Simplified Lending Protocol: $50,000-$150,000 to launch, plus $5,000-$15,000/month to operate.

Ready-made Platform like Lenda: Under $1,000, with the smart contracts and frontend already built and tested. This approach trades some customization flexibility for a dramatically lower cost and faster time-to-market.

For teams with limited budgets, understanding how to fork Aave is valuable knowledge, but actually doing it may not be the most practical path. Consider whether a turnkey solution covers your needs before committing six figures to a custom fork.

Frequently Asked Questions