Development of DeFi Liquidation Protection Systems
With over 5 years of experience in DeFi and 15+ delivered projects, we develop automated liquidation protection systems that prevent losses up to $500k per position. A $500k position in Aave, health factor drops from 1.8 to 1.05 in 40 minutes during a flash crash. The user is asleep. A liquidator sees the position with health factor 1.02 in the mempool, sends a liquidationCall transaction, gets a 5% bonus on collateral — $25k gone in a single transaction. We develop systems that eliminate such scenarios.
Our team has extensive experience in DeFi and has delivered over 15 protection projects. We ensure the system triggers before the health factor falls below the liquidation threshold. Contact us for a consultation — we will assess your position and propose a turnkey solution.
Automated protection monitors health factor in real time and tops up collateral or repays debt before the position becomes vulnerable. Savings from preventing liquidation can reach 90% of collateral value compared to manual management. On average, clients save between $10,000 and $500,000 per position when the system triggers in time.
How does the liquidation protection system work?
We use three approaches, each with its own trade-offs:
On-chain automation via Gelato or Chainlink Automation
The most reliable approach for critical positions. A smart contract registers a task in Gelato Network or Chainlink Automation. The keeper node checks checkUpkeep every block. If health factor drops below the threshold, performUpkeep is automatically called, which tops up collateral or repays part of the debt. Compared to off-chain monitoring, the on-chain approach is 3 times more reliable in response time, as it triggers in the same block rather than with polling delays.
| Parameter | Description | Typical Value |
|---|---|---|
triggerThreshold |
Health factor for trigger | 1.3–1.5 |
targetThreshold |
Health factor after protection | 1.8–2.0 |
maxGasPrice |
Maximum gas price for execution | 100–200 gwei |
cooldownPeriod |
Pause between executions | 10–30 minutes |
Bottleneck: cost of Gelato/Chainlink Automation. Each execution incurs a small fixed fee, and with monitoring every 30 seconds, monthly costs can be around $150 per position. For positions with collateral over $50k this is justified; for smaller ones, it is not.
Flash loan-based rebalancing
If the user has no free funds to top up collateral, protection can use a flash loan. Algorithm:
- Take a flash loan from Aave/Balancer in the collateral token
- Top up collateral in the protected protocol
- Borrow the debt token against the new, higher collateral
- Repay the flash loan from the borrowed funds
- Net result: position rebalanced, flash loan repaid, a small protocol fee deducted
This only works if the target health factor is achievable with current LTV and market prices. The contract must check this before execution — otherwise, the transaction reverts after spending gas fees.
Monitoring via The Graph + off-chain service
Off-chain component: a service subscribes to Aave events (Borrow, Withdraw, LiquidationCall) through a WebSocket node (Alchemy/Infura). On each event affecting tracked addresses — recalculate health factor via multicall to getAccountData. When the threshold is crossed — send a protective transaction.
| Approach | Reliability | Cost | Complexity |
|---|---|---|---|
| On-chain (Gelato) | High (live on blockchain) | Medium | Medium |
| Flash loan | Medium (depends on liquidity) | Low (protocol fee) | High |
| Off-chain | Low (depends on server) | Low | Medium |
Problem with this approach: liveness depends on the off-chain service. If the server goes down, the position is unprotected. For production: multiple instances in different regions, monitoring via UptimeRobot/Grafana, a circuit breaker for anomalous gas prices.
Why is it important to set triggers before liquidation?
Understanding the liquidation mechanism is critical for correctly configuring protection. In Aave v3, liquidation is possible when:
healthFactor = sum(collateral_i * price_i * liquidationThreshold_i) / totalDebt
healthFactor < 1.0
Source: Aave V3 Documentation
A liquidator can repay up to 50% of the debt (close factor) in one transaction and receive collateral with a liquidation bonus (5–15% depending on the asset). For ETH collateral, the bonus is 5%; for less liquid assets, it is higher.
Important nuance: when health factor < 0.95 in Aave v3, bad debt mode is activated — the liquidator can take all collateral without fully repaying the debt. This is a scenario where the protocol incurs losses. The protection system must trigger well before this threshold.
Technical details of Aave v3 liquidation
Liquidation in Aave v3 uses the function liquidationCall(address collateralAsset, address debtAsset, address user, uint256 debtToCover, bool receiveAToken). On success, the liquidator receives the collateral with a bonus. The close factor determines the maximum debt that can be repaid — typically 0.5 (50%).
Price manipulation and oracle lag
A flash crash on Binance is not always immediately reflected in the Chainlink price feed — the median from 31 sources updates with a delay, deviation threshold usually 0.5–1%. In this window: real ETH price $1800, oracle still shows $1900. No liquidation. After 2 blocks, the oracle updates — $100 difference in seconds, hundreds of positions become liquidable simultaneously.
The protection system must account for this lag: if the spot price (DEX TWAP) deviates from the oracle price by more than 5%, this is a signal for preventive protection, without waiting for the oracle update.
Protection contract: critical details
Access control for automated operations
The protection contract acts on behalf of the user (adds collateral, repays debt). The user must grant it permission via approve or use ERC-4337 Account Abstraction, where the protection module is a validating plugin for a smart wallet.
Without the AA approach, there is a risk: the contract has approve on the user's tokens. If the contract has a vulnerability, it becomes an attack surface for drain. All access control undergoes review for privilege escalation. All contracts are audited and security guaranteed.
Slippage during automatic swap
If protection requires a token swap (sell part of collateral -> repay debt), slippage tolerance is critical. Too loose (5%) — a sandwich attack eats an additional part of the position. Too tight (0.1%) — the transaction reverts during volatility. Optimum: dynamic slippage via Chainlink volatility feed or fixed 0.5% with retry logic.
What is included in development
- Documentation: architectural diagram, logic description, parameter specification
- Access: source code of the contract, repository with commit history
- Training: workshop on configuring monitoring and triggers
- Support: 2 weeks post-deploy maintenance, bug fixes
Process of work
Analytics (2–3 days): audit of the target protocol (Aave v3 / Compound v3 / Morpho), identification of available protection vectors, analysis of liquidation scenarios via fork simulation.
Smart contract development (4–6 days): protection logic, flash loan integration, access control, events for monitoring.
Off-chain monitoring (3–4 days): health factor tracking service, integration with Gelato/Chainlink Automation, alerting.
Testing (3–4 days): fork tests on Ethereum mainnet with real positions, fuzz tests on edge health factor values, simulation of flash crash scenarios.
Deployment and monitoring (1–2 days): Foundry script, verification, Grafana dashboard setup.
Total: 1–2 weeks depending on the number of supported protocols and complexity of rebalancing strategy. Cost is calculated individually. Get a consultation — we will assess your project and propose the optimal solution.
Order development of a protection system to secure your funds from unexpected liquidations.