Разработка системы расчета funding rate для perpetual DEX
Perpetual futures — крупнейший по объёму инструмент в крипто. Binance обрабатывает $20-50 миллиардов notional в день только по BTC perp. Механизм funding rate — то, что удерживает perpetual цену близко к spot. Без него perp мог бы торговаться с постоянным 50% premium над spot, делая хеджирование бессмысленным. На CEX это решено централизованно. На децентрализованном perp DEX — нужна полностью on-chain система, устойчивая к манипуляциям.
Механика funding rate: что именно мы рассчитываем
Классическая формула (Bitmex style)
Базовая формула funding rate, используемая большинством CEX:
Funding Rate = clamp(Premium Index + clamp(IR - Premium Index, -0.05%, 0.05%), -0.075%, 0.075%)
где:
- Premium Index = (Mark Price - Index Price) / Index Price
- IR (Interest Rate) = обычно фиксированный 0.01% per 8h в крипто
- clamp ограничивает значение диапазоном
Mark Price — weighted average price с учётом volume на нескольких площадках. Index Price — spot цена из оракула (Chainlink / Pyth).
Когда Mark Price > Index Price (perp торгуется с premium) — funding rate положительный, longs платят shorts. Рынок incentivized открывать shorts и закрывать longs, давя на perp цену вниз к spot.
Проблема манипуляции Mark Price
На on-chain perp DEX Mark Price нельзя просто взять как last trade price — это тривиально манипулируемо через flash loan или wash trading в маленьком пуле. Атакующий делает серию крупных trades перед снимком funding rate → завышает Mark Price → funding rate в его пользу.
Защита через TWAP (Time-Weighted Average Price). Mark Price рассчитывается как средневзвешенная цена за период (обычно 1-8 часов):
function getMarkPrice() public view returns (uint256) {
uint256 twapPrice = 0;
uint256 totalWeight = 0;
for (uint i = 0; i < observations.length; i++) {
uint256 weight = observations[i].timestamp - (i > 0 ? observations[i-1].timestamp : periodStart);
twapPrice += observations[i].price * weight;
totalWeight += weight;
}
return totalWeight > 0 ? twapPrice / totalWeight : currentPrice;
}
Уniswap V3 использует аналогичный подход с observe() функцией, которая возвращает cumulative tick value. Длинный TWAP period (8h) делает манипуляцию дорогой: нужно удерживать искусственную цену на протяжении всего периода.
Pyth Network vs Chainlink для Index Price
На-chain perp DEX требует низкой latency для Index Price. Chainlink обновляется при отклонении >0.5% или каждые heartbeat (1h на основных парах) — слишком медленно при быстром рынке. Pyth предоставляет price updates каждые 400ms через pull-based модель.
Pyth pull oracle — контракт не хранит цену постоянно, вместо этого пользователь или keeper передаёт VAA (Verifiable Action Approval) в каждой транзакции:
function updateAndGetPrice(bytes[] calldata priceUpdateData) external payable returns (PythStructs.Price memory) {
uint fee = pyth.getUpdateFee(priceUpdateData);
pyth.updatePriceFeeds{value: fee}(priceUpdateData);
return pyth.getPriceUnsafe(priceId); // или getPrice для staleness check
}
Трейдоф: каждая транзакция несёт небольшой gas overhead на обновление цены. Для perp DEX это приемлемо — важнее точность.
Начисление funding rate on-chain
Continuous vs discrete начисление
CEX начисляют funding rate дискретно — каждые 8 часов. Для on-chain протокола есть два подхода:
Discrete (snapshot): Keeper вызывает settleFunding() раз в 8 часов. Все позиции обновляются в одной транзакции. Проблема: при большом количестве позиций — gas limit exceeded. Решение: paginated settlement или lazy settlement (начисление при следующем взаимодействии пользователя с позицией).
Continuous (per-block accumulation): Используется в dYdX v3 и Synthetix. Вместо settlement раз в период — fundingIndex растёт непрерывно с каждым блоком. При открытии позиции запоминается entryFundingIndex. При закрытии — (currentFundingIndex - entryFundingIndex) * positionSize = funding payment.
mapping(address => uint256) public positionEntryFundingIndex;
uint256 public globalFundingIndex;
function calculateFundingPayment(address trader) public view returns (int256) {
return int256(positionSize[trader]) *
int256(globalFundingIndex - positionEntryFundingIndex[trader]) / 1e18;
}
Continuous подход элегантнее и масштабируется на любое количество позиций без pagination. Главное: globalFundingIndex должен обновляться регулярно (Chainlink Automation или собственный keeper).
Реализация с учётом знаковых позиций
Long позиции и short позиции платят/получают funding в противоположных направлениях. Стандартный подход: хранить signed position size (положительный для long, отрицательный для short), funding payment автоматически меняет знак:
// Положительный funding rate → longs платят, shorts получают
// Отрицательный funding rate → shorts платят, longs получают
int256 fundingPayment = signedPositionSize * int256(fundingRateDelta) / 1e18;
// Если signedPositionSize > 0 (long) и fundingRate > 0 → payment < 0 (платим)
// Если signedPositionSize < 0 (short) и fundingRate > 0 → payment > 0 (получаем)
Funding rate bounds и extreme markets
При экстремальном рыночном дисбалансе (99% участников — longs) funding rate без ограничений может стать astronomically high. Shorts получали бы огромные выплаты, но никто не хочет быть short при сильном bull trend.
Нужны boundaries:
-
maxFundingRateper period — предотвращает экстремальные выплаты - Graduated rate: при малом imbalance — низкая rate, при большом — растёт нелинейно
GMX v2 использует adaptive funding rate: чем больше open interest дисбаланс, тем быстрее меняется funding rate. Это мягче, чем hard cap, и эффективнее corrects imbalance.
Keeper инфраструктура
Funding rate система требует регулярного on-chain обновления. Варианты:
Chainlink Automation. Надёжно, decentralized, но latency не гарантирована при сетевой нагрузке.
Gelato Network. Аналог Chainlink Automation, дополнительные опции для conditional triggers.
Собственный keeper. Полный контроль над latency, но требует инфраструктуры. Для critical financial protocol — рекомендуем собственный keeper с Chainlink как fallback.
// Keeper logic
async function updateFunding() {
const lastUpdate = await contract.lastFundingUpdate();
if (Date.now() / 1000 - lastUpdate > FUNDING_INTERVAL) {
const markPrice = await getMarkPriceTWAP();
const indexPrice = await pythOracle.getPrice(PRICE_ID);
await contract.updateFundingRate(markPrice, indexPrice);
}
}
setInterval(updateFunding, 60_000); // проверка каждую минуту
Процесс разработки
Аналитика (2-3 дня). Выбор формулы (Bitmex style, adaptive, bounded), oracle стратегии, settlement модели (discrete/continuous).
Разработка (3-5 дней). FundingRateEngine контракт: TWAP расчёт Mark Price, интеграция Pyth/Chainlink для Index Price, continuous funding index, settlement логика.
Тестирование (2-3 дня). Fork-тесты с симуляцией разных рыночных условий: extreme bull (99% long OI), flash crash, rapid funding rate changes. Fuzz-тесты на invariant: funding payments должны балансировать (сумма платежей longs = сумма получений shorts при нулевом insurance fund).
Keeper деплой. Chainlink Automation setup или собственный keeper сервис.
Ориентиры по срокам
Базовая система с discrete settlement и Chainlink oracle — 3-4 дня. Continuous funding с Pyth, adaptive bounds и keeper инфраструктурой — 1-2 недели. Стоимость рассчитывается индивидуально.