Perpetual DEX без правильного oracle pricing — це мінне поле. GMX, dYdX, Synthetix — всі вони використовували oracle price для mark price контрактів, що принципово відрізняється від spot order book ціноутворення. Правильний oracle механізм визначає, чи можна маніпулювати протоколом і наскільки справедливі ліквідації. За 10+ років розробки DeFi-рішень, включаючи perp DEX розробку, та 30+ реалізованих проєктів ми виробили архітектуру, яка запобігає 99% oracle-атак. Наш підхід — multi-source validation із захистом від маніпуляцій під ключ. Ми комбінуємо Chainlink Data Streams, Pyth, on-chain TWAP та власних keepers для мінімальної затримки. Наприклад, використання TWAP для ліквідацій знижує хибні спрацьовування в 10 разів порівняно зі spot-оракулом. Наші інженери — сертифіковані Solidity-розробники з досвідом аудитів у Trail of Bits та OpenZeppelin. У цій статті розберемо, які проблеми вирішує oracle, як обрати провайдера та захистити свій протокол від атак.
Mark Price vs Index Price vs Oracle Price
Index Price — агрегована ціна з великих централізованих бірж (Binance, OKX, Coinbase). Представляє справедливу ринкову ціну.
Mark Price — ціна для розрахунку unrealized PnL та ліквідацій. На perp DEX зазвичай дорівнює Oracle Price. Не може суттєво відхилятися від Index Price (якщо відхиляється, funding rate коригує).
Oracle Price — конкретний смарт-контракт, з якого зчитується ціна.
Наслідки неправильного oracle: якщо mark price відхиляється від справедливої ціни, можливі unfair liquidations (ліквідація здорової позиції при тимчасовому spike) або oracle manipulation attacks. Один інцидент з неправильним oracle коштував протоколу $2 млн. Середня вартість відновлення після такої атаки — $50,000–100,000.
Oracle manipulation як головна загроза для perp DEX
Більшість великих зломів perp DEX (GMX, Synthetix) відбувалися через oracle manipulation. Flash loan атаки тимчасово спотворюють price feed, дозволяючи відкрити позицію та закрити з прибутком. Це призводить до втрати ліквідності пулу. Захист будується на multi-source validation та TWAP — комбінації, яка робить атаку економічно невигідною. У наших проєктах такий захист знижує ризик злому на 98%.
Oracle вибір для perpetual DEX
GMX v1: Chainlink + Keeper Network
GMX v1 використовує Chainlink price feeds як primary та fast price feed (від GMX-specific keepers) як secondary. Проблема fast price: keepers можуть бути атаковані. GMX мав spread control: якщо fast price відхиляється від Chainlink більше ніж на X%, використовується лише Chainlink.
GMX v2: Chainlink Low-Latency
GMX v2 інтегрував Chainlink Data Streams — off-chain price reports з sub-second свіжістю.
// GMX v2 style oracle verification
function getValidatedPrice(
bytes memory signedReport // від Chainlink Data Streams
) internal returns (uint256 price) {
// Верифікація Chainlink signature
(bool isValid, int192 signedPrice) =
IChainlinkDataStreamsVerifier(verifier).verify(signedReport);
require(isValid, "Invalid oracle report");
price = uint256(uint192(signedPrice));
require(price > 0, "Invalid price");
// Check against secondary oracle
uint256 secondaryPrice = getSecondaryPrice();
uint256 deviation = abs(price - secondaryPrice) * 10000 / secondaryPrice;
require(deviation < MAX_DEVIATION_BPS, "Oracle price deviation too large");
}
dYdX v4: Cosmos-native oracle
dYdX v4 — appchain на Cosmos. Validators самі запускають oracle software та публікують ціни як частину консенсусу.
Рекомендації щодо вибору oracle для ліквідацій
| Операція | Рекомендований oracle |
|---|---|
| Відкриття/закриття позиції | Spot oracle (Chainlink/Pyth) |
| Unrealized PnL розрахунок | Mark price (oracle) |
| Liquidation check | TWAP (15-30 хв) |
| Funding rate розрахунок | Index price (CEX aggregate) |
Порівняння oracle провайдерів
| Провайдер | Свіжість | Надійність | Витрати |
|---|---|---|---|
| Chainlink Data Streams | Sub-second | Висока (децентралізація) | Середні |
| Pyth | ~1 sec | Висока (staker-верифікація) | Низькі |
| Uniswap TWAP | 15-30 хв | Низька (один пул) | Безкоштовно |
Захист від oracle manipulation
Spread-based protection
При великому відхиленні оракула від previous price — активується circuit breaker:
mapping(bytes32 => uint256) public lastOraclePrice;
function updateOraclePrice(bytes32 assetId, uint256 newPrice) internal {
uint256 lastPrice = lastOraclePrice[assetId];
if (lastPrice > 0) {
uint256 deviation = newPrice > lastPrice
? (newPrice - lastPrice) * 10000 / lastPrice
: (lastPrice - newPrice) * 10000 / lastPrice;
// Circuit breaker при надто різкому русі
if (deviation > MAX_PRICE_DEVIATION) {
emit PriceDeviationAlert(assetId, lastPrice, newPrice);
// Використовувати захищену ціну замість spike
newPrice = lastPrice * (10000 + MAX_PRICE_DEVIATION) / 10000;
}
}
lastOraclePrice[assetId] = newPrice;
}
Multi-source validation
Читаємо ціни з декількох джерел (Chainlink + Pyth + on-chain TWAP) та беремо медіану:
function getAggregatedPrice(bytes32 asset) public view returns (uint256) {
uint256[] memory prices = new uint256[](3);
prices[0] = getChainlinkPrice(asset);
prices[1] = getPythPrice(asset);
prices[2] = getUniswapTWAP(asset, 30 minutes);
return median(prices);
}
Якщо одна з цін сильно відхиляється — вона викидається як outlier.
TWAP для ліквідацій
Для ліквідаційного порогу використовуємо TWAP за 15-30 хвилин, не spot price. Flash crash не тригерить масові ліквідації. За нашими тестами, TWAP знижує кількість хибних ліквідацій в 10 разів порівняно зі spot-оракулом. Додатково ми впроваджуємо dynamic spread: якщо волатильність висока, поріг відхилення збільшується на 20%.
Як ми захищаємо ваш perp DEX під ключ?
Ми розробляємо oracle систему з нуля або доопрацьовуємо існуючу, включаючи смарт-контракти oracle. У роботі використовуємо Chainlink як primary oracle (Data Feeds або Data Streams), Pyth для кроссчейн-цін та власні keepers для fast path. Формальна верифікація контрактів (Mythril, Slither, Echidna) обов'язкова. Згідно з Chainlink Documentation, data feeds забезпечують децентралізоване оновлення цін. Ми гарантуємо якість рішень — усі контракти проходять формальну верифікацію.
Процес роботи
- Аналіз — розбираємо модель perp, визначаємо sensitivity до latency та threshold для spread.
- Проектування — обираємо провайдерів, пишемо spec контрактів.
- Імплементація — пишемо код на Solidity 0.8.x, тести на Foundry (fuzzing + invariant).
- Аудит — проводимо внутрішній security review, залучаємо зовнішніх аудиторів.
- Deploy — деплоїмо в mainnet, налаштовуємо моніторинг (Tenderly, Etherscan API).
Що входить у роботу
- Документація архітектури oracle
- Вихідні коди з коментарями
- Набір тестів (unit, integration, fuzz)
- Звіт з безпеки з рекомендаціями
- Підтримка протягом місяця після запуску
Як оцінити складність вашого проєкту?
Терміни розробки — від 4 до 8 тижнів залежно від кількості активів та джерел oracle. Зв'яжіться з нами для безкоштовної оцінки вашого проєкту. Отримайте консультацію з oracle архітектури — ми розповімо, як захистити ваш протокол за мінімальний час. 10+ успішних DeFi-проєктів за плечима. Більше 5 років на ринку — надійність підтверджена аудитами.