Розробка системи ліквідацій для perpetual DEX
Flash crash на 50% за пару хвилин — і якщо ліквідаційний модуль не встигає обробити позиції, протокол отримує bad debt. Одна популярна perpetual біржа минулого року зіткнулася з цим, коли обсяги зросли на порядок, а keeper-мережа не впоралася. У таких сценаріях правильно спроектована система ліквідацій з інсентивами для ліквідаторів тримає удар: ліквідатор отримує частку комісії, але тільки при швидкому виконанні. Погана архітектура або пропускає позиції, або генерує необслуговуваний борг для LP. Ми проектуємо рішення, що витримують екстремальні рухи ринку. Зв'яжіться з нами для аудиту вашого протоколу.
Наші інженери мають 5+ років досвіду в DeFi розробці, реалізували понад 15 рішень для ліквідацій на Ethereum, Arbitrum та Polygon. Гарантуємо коректну роботу навіть при різких стрибках ціни.
Як обчислюється ліквідаційний поріг?
На perpetual DEX (Wikipedia) трейдер відкриває позицію з leverage: 10x long ETH, внісши 1000 USDC колатераль, позиція = 10,000 USDC notional. При падінні ETH на 9% unrealized loss становить 900 USDC, колатераль зменшується до 100 USDC. Margin ratio = 100/10,000 = 1%. Якщо це нижче maintenance margin (зазвичай 0.5-1%), позиція підлягає примусовому закриттю.
Формула margin ratio: marginRatio = (collateral + unrealized_pnl) / notional_value. Протокол повинен ліквідувати позицію до того, як collateral + unrealized_pnl < 0 — інакше виникає bad debt.
Чому gap risk — головна загроза?
Gap (різкий стрибок ціни, наприклад при виході новин) перескакує через кілька рівнів ліквідації за один тік. Позиція може одразу піти в negative equity без можливості проміжної ліквідації. Розробники dYdX вказують у документації до v4, що gap risk — основна причина bad debt.
GMX v2 та dYdX v4 застосовують кілька механізмів для пом'якшення gap risk:
- Insurance fund — резерв з частини trading fees
- ADL (Auto-Deleveraging) — якщо insurance fund не покриває, примусово закриваються прибуткові позиції протилежної сторони
- Max open interest limits — обмеження сукупного OI по активу знижує потенційний bad debt
Порівняння підходів: keeper vs on-chain ліквідація
| Параметр | Keeper-based | On-chain автоматична |
|---|---|---|
| Швидкість реакції | Залежить від gas та конкуренції | Миттєво при кожному блоці |
| Складність | Середня (інфраструктура оффчейн) | Висока (газ, складність) |
| Контроль протоколу | Непрямий (через incentives) | Прямий |
| Ризик MEV | Високий | Низький |
| Приклад | GMX, dYdX | Synthetix (минулі версії) |
Keeper-based підхід знижує газові витрати на ліквідацію в 2-3 рази порівняно з on-chain автоматичним. Це підтверджено на практиці в наших проектах.
Архітектура системи ліквідацій
On-chain компонент
Контракт зберігає позиції та постійно оновлює mark price через оракул. Ліквідація проходить у два кроки:
1. Перевірка ліквідованості (view function):
function isLiquidatable(uint256 positionId) public view returns (bool) {
Position memory pos = positions[positionId];
uint256 markPrice = oracle.getMarkPrice(pos.indexToken);
int256 unrealizedPnl = calculatePnl(pos, markPrice);
int256 equity = int256(pos.collateral) + unrealizedPnl;
// Вираховуємо накопичений funding fee
int256 pendingFunding = calculateFundingFee(pos);
equity -= pendingFunding;
uint256 notional = pos.size; // size = notional value
// Нижче maintenance margin threshold
return equity < int256(notional * MAINTENANCE_MARGIN_BPS / 10000);
}
2. Виконання ліквідації:
function liquidate(uint256 positionId, address recipient) external nonReentrant {
require(isLiquidatable(positionId), "Not liquidatable");
Position memory pos = positions[positionId];
uint256 markPrice = oracle.getMarkPrice(pos.indexToken);
// Розраховуємо залишок колатералю після збитків
int256 remainingCollateral = calculateRemainingCollateral(pos, markPrice);
uint256 liquidationFee = pos.collateral * LIQUIDATION_FEE_BPS / 10000;
// Виплата keeper'у
uint256 keeperFee = liquidationFee * KEEPER_SHARE / 100;
token.transfer(recipient, keeperFee);
// Залишок в insurance fund або протокол
if (remainingCollateral > 0) {
uint256 toInsurance = uint256(remainingCollateral) - keeperFee;
insuranceFund.deposit(toInsurance);
} else {
// Bad debt — списуємо з insurance fund
insuranceFund.cover(uint256(-remainingCollateral));
}
_closePosition(positionId);
emit PositionLiquidated(positionId, msg.sender, keeperFee, block.timestamp);
}
Keeper система
Keeper — зовнішній учасник, що моніторить позиції та викликає liquidate(). Інсентив — keeper fee, що створює конкурентний ринок ліквідаторів.
Приклад конфігу keeper-бота на TypeScript з viem
class LiquidationKeeper {
private positionCache: Map<bigint, Position> = new Map();
async monitorPositions(): Promise<void> {
contract.on('PositionUpdated', (positionId, position) => {
this.positionCache.set(positionId, position);
});
provider.on('block', async (blockNumber) => {
const markPrice = await oracle.getMarkPrice(INDEX_TOKEN);
const liquidatable = [...this.positionCache.entries()]
.filter(([_, pos]) => this.isLiquidatable(pos, markPrice))
.sort((a, b) => this.prioritize(a, b, markPrice)); // Найвигідніші першими
for (const [positionId] of liquidatable) {
await this.attemptLiquidation(positionId);
}
});
}
private prioritize(a: [bigint, Position], b: [bigint, Position], price: bigint): number {
return Number(b[1].collateral - a[1].collateral);
}
}
Оракул для mark price
Ключовий елемент: mark price не повинен маніпулюватися flash loan'ами. dYdX v4 використовує Pyth oracle з aggregated median з кількох джерел. GMX v2 використовує Chainlink (офіційна документація) + custom keeper oracle з верифікацією підпису.
Вимоги до оракула:
- Freshness check: ціна не старша N секунд (зазвичай 30-60)
- Deviation check: нова ціна не більше ніж на X% відрізняється від попередньої (circuit breaker)
- Multi-source aggregation: медіана з 3+ джерел
function getMarkPrice(address token) external view returns (uint256) {
PriceData memory data = priceData[token];
require(block.timestamp - data.timestamp <= STALENESS_THRESHOLD, "Stale price");
require(data.numSources >= MIN_SOURCES, "Insufficient sources");
return data.medianPrice;
}
Що відбувається при нестачі страхового фонду? (ADL)
Auto-Deleveraging — остання лінія захисту. Якщо insurance fund вичерпано, протокол примусово закриває прибуткові позиції за mark price (без slippage). Порядок закриття: спочатку позиції з найбільшим profit та leverage — як найбільш ризиковані для системи.
ADL — болючий механізм для трейдерів. Важно:
- Чітко розкривати ризик ADL в документації
- Показувати ADL indicator на UI (як на Binance futures)
- Обмежувати OI, щоб мінімізувати необхідність ADL
Що входить в розробку системи під ключ
| Етап | Тривалість | Результат |
|---|---|---|
| Аналіз ризиків та моделювання | 3-5 днів | Параметри maintenance margin, fee, розмір insurance fund |
| Розробка смарт-контрактів | 2-4 тижні | Контракти ліквідації, insurance fund, oracle adapter |
| Інтеграція keeper-бота | 1-2 тижні | Off-chain інфраструктура на TypeScript |
| Fork-тестування | 1 тиждень | Симуляція стрес-сценаріїв (flash crash та крах стейблкоіна) |
| Аудит | 2-3 тижні | Звіт незалежного аудитора |
| Деплой та моніторинг | 1 тиждень | Документація, скрипти, дашборд |
Повний цикл займає 8-12 тижнів. Вартість розраховується індивідуально.
Стек
Solidity + Foundry — ліквідаційні контракти, оракул, insurance fund. TypeScript + viem — keeper-бот, моніторинг. Chainlink + Pyth — price feeds. Gelato Network — fallback для виклику keeper-функцій. Foundry fork tests — симуляція на mainnet fork.
Як ми гарантуємо надійність
Спираємось на 5-річний досвід у Web3 та десятки успішних аудитів. Впроваджуємо формальну верифікацію для критичних контрактів. Надаємо гарантію на код протягом 6 місяців після деплою.
Отримайте консультацію: опишіть свій протокол, і ми оцінимо ризики та запропонуємо архітектуру.