We specialize in building secure crypto lending platforms. In our practice, we have delivered 12 DeFi projects, including protocols with a combined TVL of over $500M. Losses from lending protocol hacks can reach hundreds of millions of dollars—one mistake in a contract can cost the entire project. Our experience helps avoid the typical errors that lead to exploits.
One major hack was the Euler Finance protocol, which lost $197M. Euler Finance exploit report The vulnerability lay in the donateToReserves function, which allowed accumulating a deficit without checking collateral. The attacker used a flash loan to create a position with a broken health factor and self-liquidated through the donate mechanism. The code had passed several audits, but the error remained undetected. Our solutions have helped clients prevent losses exceeding $50M.
Lending protocols are one of the most complex categories in DeFi. Each function (deposit, borrow, repay, liquidate) interacts with others, and system invariants are non-trivial. Therefore, we pay special attention to formal verification and extensive testing.
Our team offers end-to-end crypto lending platform development—from specification to audit and deployment. Contact us to discuss your project details.
Why are lending protocols particularly vulnerable?
Oracle manipulation and cascading liquidations
A lending protocol relies on a price oracle to calculate the collateral ratio. Compromising the oracle means you can take out a loan against overvalued collateral or avoid liquidation.
Cream Finance lost $130M through oracle manipulation: a thinly liquid token was used as collateral, its price was manipulated via a flash loan in an AMM pool, and the attacker borrowed an amount many times over the actual value.
Protection—multi-layered oracle:
- Chainlink as primary feed with
latestRoundDatastaleness check (>1 hour — pause) - Uniswap v3 TWAP as secondary with a 30-minute window
- Circuit breaker: if the two oracles diverge by more than 5% — new borrows suspended
Cascading liquidations are a separate problem. During a sharp market decline, simultaneous liquidation of thousands of positions pushes the asset price down, triggering further liquidations. Compound v3 solves this through liquidation caps at the protocol level.
Health factor calculation and integer precision
Most errors occur here. Health factor = (collateralValue * collateralFactor) / borrowedValue. When calculated with uint256 without proper scaling, rounding cuts precision.
Concrete example: collateral 1.001 ETH with collateralFactor 0.8 gives 0.8008 ETH coverage. Borrow 0.8 ETH. Health factor should be 1.001. If the calculation is done as (collateral * factor / 1e18) / borrow instead of using mulDiv, precision loss can mark a healthy position as liquidatable.
We use FullMath.mulDiv from Uniswap v3 core for all calculations where precision matters. No division before all multiplications.
Reentrancy in liquidate + transfer chains
The liquidate function typically performs several actions: takes collateral from the borrower, repays debt, pays a bonus to the liquidator. If the collateral token implements ERC-777 or has a custom transfer hook, there is a window for reentrancy between steps.
AAVE v3 uses ReentrancyGuard at the Pool contract level and additionally checks a _status flag in critical paths. For any lending protocol, nonReentrant on deposit, borrow, repay, and liquidate is mandatory.
Learn more about reentrancy: reentrancy attack.
Common mistakes when developing a lending protocol
- Using a single oracle without a fallback
- Incorrect health factor calculation due to rounding
- Lack of partial liquidation for large positions
- Ignoring reentrancy in custom tokens
- Too high collateral factor for volatile assets
How to protect a protocol from cascading liquidations?
Modular structure modeled on Compound v3
Comptroller / RiskManager
├── CToken / CometMarket (per asset)
│ ├── InterestRateModel
│ └── PriceOracle
├── LiquidationEngine
└── GovernanceModule
A separate contract for each supported asset (CToken pattern) vs a single Comet contract with mappings—this is a fundamental architectural decision. The CToken pattern is simpler to audit and isolate risk: a problem in one market does not affect others. A single contract is cheaper to deploy and simpler for users.
| Characteristic | CToken pattern (Compound v2) | Single contract (Comet) |
|---|---|---|
| Audit complexity | Lower: isolated contracts | Higher: complex logic |
| Gas efficiency | Higher deploy, lower transactions | Lower deploy, higher transactions |
| Systemic error risk | Low | Medium |
| Flexibility | High: can add markets independently | Medium: changes affect all markets |
Interest rate model
Kinked interest rate is the standard: low rate at utilization < 80%, sharp rise above. Formula:
- If
U < kink:borrowRate = baseRate + slope1 * U - If
U >= kink:borrowRate = baseRate + slope1 * kink + slope2 * (U - kink)
At 95% utilization, rates can reach 100%+ APR—this mechanism pressures borrowers to return liquidity to the pool.
Parameters (baseRate, slope1, slope2, kink) should be changeable through governance with a timelock. The market changes, and optimal parameters change with it.
Liquidation mechanics
Liquidation bonus (5-10% of collateral) is the reward for liquidators. Too small a bonus—liquidators are not incentivized, the protocol accumulates bad debt. Too large—borrowers lose more than reasonable.
Partial liquidation (repaying only part of the debt) is mandatory. Full liquidation of a large position in one go requires enormous capital from the liquidator. Compound v3 allows liquidation down to a health factor of 1.05.
Flash loan liquidations are the standard pattern. The liquidator takes a flash loan, repays the debt, receives collateral (with a bonus), sells it on a DEX, returns the flash loan plus fee. The protocol must support this—i.e., not block collateral withdrawal in the same transaction.
Supported assets and collateral factors
| Asset | Collateral Factor | Liquidation Threshold | Example (Aave v3) |
|---|---|---|---|
| ETH/WETH | 80% | 82.5% | 80% / 82.5% |
| WBTC | 70% | 75% | 70% / 75% |
| USDC | 85% | 88% | 86% / 88% |
| LINK | 65% | 70% | 65% / 70% |
| Volatile ERC-20 | 40-60% | 50-65% | varies |
Isolation mode (Aave v3)—assets with a debt ceiling, used only as collateral for stablecoins. For new or less liquid assets, this is the right strategy: it reduces systemic risk.
What is included in lending platform development
- Documentation: specification, mathematical model, risk parameters
- Smart contracts in Solidity (Foundry) with modular architecture
- Test suite: unit, fuzz, integration, fork tests
- Oracle integration (Chainlink, Uniswap TWAP)
- User interface (optional)
- External audit by independent experts (typical cost for a complex protocol: $30,000 to $100,000)
- Deployment and monitoring
- Post-release support and updates
Development process
- Specification (3-5 days). Define assets, interest rate models, need for governance and upgradeability.
- Mathematical specifications (2-3 days). Formulas are verified on a Python reference before writing Solidity. This saves a week of debugging in contracts.
- Development (4-6 weeks). Foundry + fuzz tests on all invariants: health factor cannot become negative, total debt does not exceed reserves, liquidation bonus is calculated correctly.
- Fork testing. Simulate flash loan attacks on a mainnet fork. Test cascading liquidations through price manipulation.
- External audit. Mandatory for any protocol with TVL. Preferably two independent auditors.
Timeframe estimates
Minimum viable lending protocol (one asset, basic liquidation)—4-6 weeks. Full platform with multiple markets, governance, upgrades—2-3 months. Audit—an additional 4-8 weeks depending on code size.
Contact us to discuss your project. Get a free consultation and preliminary assessment.