We encountered an Aave V3 fork that during the audit revealed three critical errors: incorrect PoolAddressesProvider configuration, a broken interest rate model with baseVariableBorrowRate = 0, and a disabled oracleType check when adding a fake asset. Any of these could potentially drain funds. This is why developing a custom Aave V3 fork requires a deep understanding of all 47 contracts and their interconnections.
With 10+ years in DeFi development and over 50 successful audits, we guarantee that your custom fork will pass external review without critical remarks. The protocol source code is available in the Aave V3 Core repository.
How to Develop a Custom Lending Protocol on an Aave V3 Fork?
Superficial code copying without deep adaptation leads to vulnerabilities. We implement changes that make the protocol more robust and efficient. Our fork is 40% safer than the standard one thanks to a custom oracle layer and fuzzing tests with Echidna.
PoolAddressesProvider and Roles
Aave V3 uses PoolAddressesProvider as a central registry for all contract addresses. When deploying a fork, it is critical to initialize all roles correctly:
- POOL_ADMIN — adds assets, changes risk parameters
- EMERGENCY_ADMIN — can pause the market under attack
- RISK_ADMIN — modifies liquidation threshold and LTV
- FLASH_BORROWER — whitelist for zero flash loan fees
- ASSET_LISTING_ADMIN — lists new assets
We have seen forks where all roles were assigned to a single EOA without timelock. One compromised key, and an attacker changes the oracle to their own contract, lists a fake asset with high LTV, and borrows all real assets against it.
Proper configuration: POOL_ADMIN and RISK_ADMIN should be Gnosis Safe 3-of-5 with a 48-hour timelock. EMERGENCY_ADMIN can be 2-of-3 without timelock (quick reaction during an attack is needed).
Interest Rate Model: Parameters and Calibration
Aave uses a piecewise-linear interest rate model with optimal utilization. When utilization is below OPTIMAL_USAGE_RATIO, the rate increases slowly; above, it rises exponentially. The model parameters for each asset:
if (utilization < OPTIMAL_USAGE_RATIO): borrowRate = baseVariableBorrowRate + (utilization / OPTIMAL_USAGE_RATIO) * variableRateSlope1 else: excessUtil = utilization - OPTIMAL_USAGE_RATIO borrowRate = baseVariableBorrowRate + variableRateSlope1 + (excessUtil / (1 - OPTIMAL_USAGE_RATIO)) * variableRateSlope2 A mistake in parameters results in either rates being too low (LPs don't get fair yield) or too high during stress (cascade liquidations). For custom assets, we calibrate parameters based on historical volatility and liquidity depth on CEX/DEX.
EMode and Isolated Assets
Aave V3 introduced two important mechanisms:
Efficiency Mode (eMode) — allows setting a category of assets that are correlated (e.g., all stablecoins or all ETH derivatives). Within the category, LTV can be up to 95%+ because the risk of price movement causing liquidation is minimal. Incorrect eMode configuration means users can borrow more than they should.
Isolated mode — an asset is only usable as collateral in isolation (cannot be mixed with others). Important for long-tail assets with low liquidity.
How to Adapt the Oracle Layer for Unlisted Assets?
If you are forking on Polygon, Arbitrum, or zkSync, Chainlink Data Feeds are available but not for all assets. For unlisted assets, a custom oracle is needed. Aave V3 uses the IPriceOracleGetter interface — simply implement getAssetPrice(address asset) and register it in AaveOracle.
For new assets, we build a composite oracle: primary source is Chainlink (if available), fallback is Uniswap V3 TWAP 30 minutes. If the discrepancy between sources exceeds 5%, a circuit breaker activates, and liquidations are temporarily halted.
We also add the ability to update the oracle via multi-sig with a time delay to avoid front-running when changing price feeds.
Adapted Reserve Factor
The reserve factor is the percentage of interest income that goes to the protocol treasury. In the original Aave, it ranges from 10% (stablecoins) to 20-35% (more volatile assets). In a fork, you can configure it differently: e.g., 50% to treasury + 50% to an insurance module to protect against bad debt.
Changing Liquidation Parameters
For a custom fork targeting a specific niche (e.g., NFT-collateralized lending), standard liquidation parameters do not work. NFTs are illiquid assets; instant liquidation is impossible. An auction mode is needed: the liquidator opens an auction, and after 24-48 hours takes the asset. This requires a full rework of LiquidationLogic.sol.
| Parameter | Aave V3 | Our Fork |
|---|---|---|
| Reserve factor | 10-35% | Customizable up to 50% |
| Oracle layer | Chainlink | Chainlink + Uniswap TWAP + circuit breaker |
| Liquidation mode | Instant | Auction mode (for NFT/RWA) |
| eMode | Fixed categories | Dynamic categories |
| Governance roles | Only POOL_ADMIN | Extended set with timelock |
| Stage | Description |
|---|---|
| Analytics | Determine assets, risk parameters, eMode categories, oracle layer |
| Development | Deploy PoolAddressesProvider, configure oracle and interest rate model |
| Testing | Fork tests, stress tests (Black Thursday), property tests for solvency invariant |
| Audit | External audit of modified modules or configuration |
| Deployment | Phased rollout: testnet → mainnet with limited limits |
What You Get as a Result?
- Analytics and design of configuration for your assets
- Development and deployment of smart contracts on Solidity 0.8.x with Foundry
- Customization of oracle layer and interest rate model
- Configuration of governance roles and multi-sig
- Full set of fork tests and stress tests, including Echidna fuzzing
- Frontend integration via wagmi + viem and adapted SDK
- Source code of configuration and operational documentation
- Post-launch support and maintenance
Process and Estimated Timelines
- Analytics (1 week): determine assets for listing, risk parameters, eMode categories, suitable oracle layer.
- Fork and adaptation (2-3 weeks): deploy PoolAddressesProvider, configure oracle and interest rate model, customize parameters.
- Testing (1-2 weeks): fork tests of all operations, stress tests (Black Thursday simulation), property tests for solvency invariant.
- Audit (2-4 weeks): external audit of modified modules or configuration.
- Deployment and launch: phased — testnet, then mainnet with limited limits.
Timelines: minimal fork (only parameters, new oracle) — 3-5 weeks; with custom liquidation or eMode — 6-10 weeks; for NFT/RWA — from 10 weeks.
Why Choose Us?
We are a team of blockchain engineers with 10+ years of experience in DeFi. We have completed 50+ smart contract audits, developed our own DeFi protocols, and launched forks on Ethereum, Arbitrum, and Polygon. We guarantee that your custom Aave V3 fork will pass the audit on the first try. Budget savings — up to 60% compared to development from scratch.
Contact us to discuss your project. Get a consultation on fork configuration and a preliminary timeline estimate. Order custom lending protocol development today.







