Development of a Liquidation Protection System
A $500k position in Aave with health factor dropping from 1.8 to 1.05 in 40 minutes during a flash crash. The user is asleep. A liquidator sees a position with health factor 1.02 in the mempool, sends a transaction with liquidationCall, receives a 5% bonus on collateral. $25k goes to the liquidator in a single transaction.
Automatic liquidation protection systems solve exactly this situation: real-time health factor monitoring, automatic collateral replenishment or partial debt repayment before the position becomes vulnerable.
Protection Architecture: Three Approaches
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. A keeper node checks checkUpkeep each block. If health factor drops below a threshold value — performUpkeep is automatically called, which replenishes collateral or repays part of the debt.
Key parameters:
| 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: Gelato/Chainlink Automation cost. At $0.05/execution and monitoring every 30 seconds — $144/month per position. For positions with collateral >$50k this is justified; for smaller ones — not.
Flash Loan-based Rebalancing
If a user lacks free funds to replenish collateral, protection can use a flash loan. Algorithm:
- Take a flash loan from Aave/Balancer in collateral token
- Replenish collateral in the protected protocol
- Borrow debt token against new, higher collateral
- Repay flash loan from borrowed funds
- Net result: position rebalanced, flash loan returned, slight protocol fee retained
This works only if target health factor is achievable with current LTV and market prices. The contract must verify this before execution — otherwise the transaction reverts after gas fee is deducted.
Monitoring via The Graph + Off-chain Service
Off-chain component: a service subscribes to Aave events Borrow, Withdraw, LiquidationCall via WebSocket to a node (Alchemy/Infura). For each event affecting monitored addresses — health factor recalculation through multicall to getAccountData. Upon threshold crossing — protection transaction sent.
Issue with this approach: liveness depends on the off-chain service. If the server goes down — position is unprotected. For production: multiple instances in different regions, monitoring via UptimeRobot/Grafana, circuit breaker at anomalous gas prices.
In Depth: How Liquidation Works in Aave v3
Understanding liquidation mechanics is critical for proper protection setup. In Aave v3, liquidation is possible when:
healthFactor = sum(collateral_i * price_i * liquidationThreshold_i) / totalDebt
healthFactor < 1.0
A liquidator can repay up to 50% of the debt (close factor) in one transaction and receive collateral with liquidation bonus (5–15% depending on asset). For ETH collateral the bonus is 5%, for less liquid assets — higher.
Important nuance: when health factor < 0.95 in Aave v3, bad debt mode activates — a liquidator can take all collateral without full debt repayment. This is a scenario where the protocol incurs losses. The protection system should activate well before this threshold.
Price Manipulation and Oracle Lag
A flash crash on Binance doesn't always immediately reflect in Chainlink price feed — the median from 31 sources updates with delay, deviation threshold is usually 0.5–1%. In this window: real ETH price $1800, oracle still shows $1900. No liquidations. Two blocks later oracle updated — $100 difference in seconds, hundreds of positions become liquidatable simultaneously.
The protection system must account for this lag: if spot price (DEX TWAP) deviates from oracle price by more than 5% — this is a signal for preventive protection, without waiting for oracle update.
Protection Contract: Critical Details
Access Control for Automatic Operations
The protection contract acts on behalf of the user (adds collateral, repays debt). The user must grant permission via approve or use ERC-4337 Account Abstraction, where the protection module is a validating plugin for a smart wallet.
Without AA approach there is risk: the contract has approve on user tokens. If there is a vulnerability in the contract — this is attack surface for drain. All access control undergoes review for privilege escalation.
Slippage in Automatic Swap
If protection requires token swap (sell part of collateral → repay debt), slippage tolerance is critical. Too soft (5%) — sandwich attack consumes additional position. Too tight (0.1%) — transaction reverts during volatility. Optimum: dynamic slippage through Chainlink volatility feed or fixed 0.5% with retry logic.
Workflow
Analytics (2–3 days): audit of target protocol (Aave v3 / Compound v3 / Morpho), identification of available protection vectors, liquidation scenario analysis through 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 boundary health factor values, flash crash scenario simulation.
Deployment and Monitoring (1–2 days): Foundry script, verification, Grafana dashboard setup.
Total: 1–2 weeks depending on number of supported protocols and rebalancing strategy complexity. Cost is calculated individually.