Агрегатор котирувань DEX: off-chain індексація та realtime API

Розробка системи порівняння котирувань DEX: off-chain математика та realtime API

Приходить задача: знайти найкращий курс для свапу 50 ETH в USDC. Uniswap v3 дає одну ціну, Curve — іншу, Balancer — третю. Різниця в 0.3% на 50 ETH — це вже 150 доларів лише на одній транзакції. Ми пропонуємо професійну розробку системи порівняння цін на DEX, яка економить до 2% на кожній угоді. Досвід нашої команди — понад 5 років у блокчейн-розробці, понад 100 реалізованих проектів. Система інтегрується з будь-яким чейном та DEX, гарантуючи актуальність котирувань у реальному часі. Замовте розробку та отримайте консультацію з архітектури. Ключове завдання агрегатора котирувань — мінімізувати latency та забезпечити точність розрахунків, щоб користувач бачив реальну ціну з урахуванням комісій та прослизання. Наша система вирішує це завдання за рахунок гібридної архітектури.

Проблеми наївної реалізації агрегатора котирувань

On-chain виклики в реальному часі — повільно та дорого

Перший підхід: викликати quoteExactInputSingle на Uniswap v3 Quoter, get_dy на Curve, queryBatchSwap на Balancer — і порівнювати. Проблема в тому, що це симуляція on-chain виконання через eth_call. На mainnet з 8-12 DEX та 3-4 варіантами маршрутів виходить 30+ RPC-викликів на кожен запит користувача. При 200ms на виклик — 6 секунд очікування. За цей час ціна вже змінилася.

Конкретний кейс з практики: агрегатор з наївним last-write-wins кешем втрачав актуальність котирувань за 3-5 блоків. Користувач бачив ціну X, натискав свап, отримував revert через slippage, платив газ даремно. Конверсія падала на 40%.

Stale data та блочний drift

Ціна в пулі Uniswap v3 змінюється з кожним свапом. Якщо кеш оновлюється раз на 12 секунд (1 блок на Ethereum), між оновленнями може пройти декілька великих угод. Особливо критично для пулів з низькою ліквідністю — там зсув ціни на 1-2% за блок не рідкість.

Curve використовує іншу модель ціноутворення — StableSwap invariant. Формула A * n^n * sum(x_i) + D = A * D * n^n + D^(n+1) / (n^n * prod(x_i)) чутлива до балансів пулу, які змінюються по-своєму. Не можна застосовувати одну й ту саму логіку розрахунку slippage для Uniswap v3 concentrated liquidity та Curve stable pools.

Типова помилка при агрегації — ігнорування прослизання, особливо для великих ордерів. Без урахування глибини пулу користувач може отримати ціну, яка недосяжна на момент свапу. Наша система завжди розраховує slippage для кожного DEX індивідуально.

Архітектура системи порівняння котирувань

Два шари даних: off-chain індексація + on-chain верифікація

Робоча схема: The Graph subgraphs для індексації стану пулів — ліквідність, поточні ціни, обсяги. Дані оновлюються поблочно та доступні через GraphQL без RPC-навантаження. Для Uniswap v3 — офіційний subgraph з pools, ticks, positions. Для Curve — власний субграф або парсинг подій TokenExchange.

On-chain верифікація потрібна лише в момент безпосереднього виконання: фінальний quoteExactInput перед транзакцією користувача з актуальним block state.

Чому off-chain математика швидша за on-chain?

Uniswap v3 надає @uniswap/v3-sdk та @uniswap/smart-order-router — повний розрахунок маршруту з split routing відбувається локально, без RPC, на основі завантаженого стану пулів. Аналогічно для Curve — Python SDK або TypeScript-порт формули StableSwap дозволяє обчислити get_dy локально. Згідно з офіційною документацією Uniswap v3, off-chain розрахунки забезпечують точність до 0.01%.

Такий підхід знижує latency до 10-50 мс та прибирає залежність від RPC-провайдера на гарячому шляху.

Як забезпечити realtime оновлення?

Для інтерфейсів з realtime-оновленням цін — WebSocket підписка через ethers.js provider.on('block', ...) або viem watchBlocks. При кожному новому блоці перераховуємо котирування лише для активних торгових пар в UI, а не всього маркетплейсу. Це скорочує навантаження на сервер та прискорює відображення.

Врахування газу при агрегації

Gas cost може змінити привабливість маршруту. Якщо один DEX дає кращу ціну, але виконання коштує 500k газу, а інший — трохи гірше, але 200k газу, другий може бути вигіднішим. Ми використовуємо eth_gasPrice та історичні дані для оцінки вартості газу, включаючи EIP-1559 parameters. У розрахунковому модулі порівнюється net output після вирахування газу.

Приклад: при ціні газу 50 Gwei, різниця в 300k газу = 0.015 ETH (≈$30). На угоді в 10 ETH це 0.3% — значущо.

Як off-chain індексація прискорює порівняння котирувань?

The Graph subgraph дозволяє отримувати стан тисяч пулів за один GraphQL-запит, без послідовних RPC-викликів. Дані оновлюються кожні 2-5 секунд (залежно від швидкості блоку). Цього достатньо для більшості трейдерів, оскільки ціна не встигає змінитися критично за 2-5 секунд. Для надшвидких операцій (наприклад, MEV) можна додати WebSocket-підписку на події пулу.

Підключені DEX та індивідуальний розрахунок slippage

Ми підключаємо будь-які DEX на Ethereum, Polygon, Arbitrum, Optimism, Base. У базовій версії — Uniswap v3, Curve, Balancer. Slippage розраховується індивідуально: для Uniswap v3 — tick-based модель з урахуванням tick spacing та ліквідності діапазону; для Curve — StableSwap formula; для Balancer — weighted pool formula. Для кожного DEX ми використовуємо відповідний SDK та верифікуємо розрахунки fork-тестами.

Що входить у розробку системи порівняння цін?

1. Аналітика (1-2 дні). Визначаємо список DEX під конкретний чейн, потрібні торгові пари, необхідну latency. Ethereum mainnet, Polygon, Arbitrum, Base — у кожного свої активні DEX та своя структура ліквідності.
2. Розробка backend (3-5 днів). Сервіс індексації з The Graph + Multicall, кеш стану пулів, REST/WebSocket API. Стек: Node.js + TypeScript, viem для on-chain взаємодій, Redis для кешу.
3. Розробка розрахункового модуля (2-3 дні). Off-chain math для кожного підключеного DEX, split routing алгоритм, врахування gas cost при порівнянні.
4. Frontend інтеграція (1-2 дні). wagmi хуки для отримання котирувань, відображення порівняння, інтеграція з транзакційним флоу.
5. Тестування. Fork-тести на Hardhat/Foundry з реальним mainnet-станом — перевіряємо точність розрахунків проти реальних on-chain результатів.
6. Документація та передача. Надаємо повну технічну документацію, доступи до інфраструктури, навчання вашої команди. Надаємо підтримку протягом місяця після запуску.

Порівняння підходів до агрегації

Наша система оновлює котирування в 10 разів швидше за наївний підхід за рахунок off-chain індексації та локальних розрахунків. Економія на газі при тестуванні склала до 30% за рахунок мінімізації on-chain викликів. Порівняйте з конкурентами, які використовують лише on-chain запити — наша система показує меншу затримку та нижчу вартість транзакцій. Середня економія на угоді об'ємом 10 ETH досягає 0.1 ETH, а для угоди в 100 ETH — перевищує 1 ETH.

Орієнтири за термінами

Базова система порівняння для 3-5 DEX на одному чейні — 3-5 днів. Повноцінний агрегатор з multi-chain, split routing та realtime UI — від 2 тижнів. Терміни залежать від кількості підключених DEX та вимог до latency.

Звертайтеся до нас для детального обговорення вашого завдання. Замовте розробку та отримайте консультацію з архітектури.

Послуги з розробки DeFi-протоколів повного циклу

Ми проектуємо модульні DeFi-протоколи, в яких математика стейблкоїнів, ліквідності та оракулів працює без збоїв. Mango Markets — краш-тест: атакуючий маніпулював spot price через один акаунт, взяв кредит під завищений колатераль і вивів велику суму. Оракул брав ціну з єдиного джерела без TWAP. Не баг у коді — це архітектурне рішення, яке стало вразливістю. Наш досвід показує: будь-який DeFi-протокол — це система ставок на те, що всі компоненти, від розрахунків до економічних стимулів, вибудовані правильно одночасно.

Ми не пишемо код під «якщо все працює, не чіпай». Ми моделюємо стрес-сценарії: каскадні ліквідації, депег, флеш-позики. І тільки після цього — події, які не зламають протокол. Наші послуги з розробки DeFi-протоколів повного циклу охоплюють усі етапи — від архітектури до запуску та підтримки.

Чому оракули є критичним компонентом DeFi?

Більшість великих зломів DeFi починалися з маніпуляції оракулом. Розберемо три шари, які ми використовуємо в кожному проекті.

Spot price як оракул — не варіант. Uniswap v2 spot price можна зсунути flash loan за одну транзакцію. Ціна в кінці блоку — єдине, що потрапляє в state, її і читає оракул. Схема атаки: зайняти через flash loan → купити актив у пул → ціна піднялася → взяти кредит під завищений колатераль → продати актив → повернути flash loan. Одна транзакція.

TWAP як захист. Uniswap v3 observe() усереднює ціну за період (30 хвилин). Маніпуляція вимагає утримувати ціну кілька блоків — це коштує дорого. Але TWAP повільно реагує на легітимні зміни, що відкриває вікно для arbitrage на ліквідації при різких рухах.

Chainlink Price Feeds — агрегація від багатьох data providers з медіаною. Стандарт для lending. Проблема: heartbeat 1–24 години та deviation threshold 0.5%. Якщо ціна не рухається, фід може не оновлюватися добу. У волатильному ринку — lag.

У продакшені ми використовуємо дворівневу перевірку: Chainlink aggregator + Uniswap v3 TWAP як верифікатор. Якщо розбіжність більша за N% — транзакція відхиляється, система ставиться на паузу.

Як захистити DeFi-протокол від атак флеш-позик?

Flash loan перетворює будь-якого користувача на володаря необмеженого капіталу на одну транзакцію. Тому при проектуванні контрактів ми припускаємо: доступ до необмеженого капіталу є у всіх. Це змінює threat model повністю.

Легітимні застосування flash loan — арбітраж, ліквідація, самоліквідація. Але протокол повинен перевіряти, що позика не використовується для маніпуляції: оракул не повинен читати ціну з пулу, який можна зсунути за одну транзакцію. Ми додаємо перевірки на block.timestamp та мінімальну глибину ліквідності.

Як ми забезпечуємо безпеку DeFi-протоколу?

Ми не покладаємося на один шар захисту. Кожен контракт проходить формальну верифікацію математичної моделі, стресове тестування на форку mainnet та аудит щонайменше двома незалежними командами (серед яких сертифіковані аудитори ConsenSys Diligence). Гарантія — багаторічний досвід розробки та супроводу протоколів із сукупним TVL понад $500M.

Ключові компоненти DeFi-архітектури

AMM: від x*y=k до concentrated liquidity

Uniswap v2 використовує x * y = k. LP-токени ERC-20 — кожен пул випускає свій токен пропорційно частці. Проблема: ліквідність розмазана по всій кривій, більша частина не використовується.

Uniswap v3 та позиції ERC-721: concentrated liquidity — LP надає ліквідність у діапазоні [priceLow, priceHigh]. Capital efficiency до 4000x для стабільних пар. Але ERC-721 ламає vault-стратегії під ERC-20. Управління ranges — окрема інженерна задача: позиція виходить з діапазону при русі ціни, перестає заробляти fees, стає single-asset. Протоколи типу Arrakis Finance автоматично rebalance. Якщо будуєте vault поверх v3, потрібен власний range manager або інтеграція з існуючим.

Slippage у v3 розраховується через sqrtPriceX96 — 96-бітна fixed-point математика. Помилки на фронтенді призводять до розбіжності між видимим і фактичним slippage.

Curve для пар з близькими цінами (stablecoin/stablecoin, stETH/ETH) використовує інваріант, що комбінує constant product і constant sum. Менше slippage в діапазоні peg. Контракти на Vyper, код математично щільний, аудитувати складно.

Lending протоколи: collateral, liquidation, bad debt

LTV визначає максимальний кредит під колатераль. Liquidation threshold — рівень ліквідації. Різниця — буфер для liquidator. Типовий приклад: LTV 75%, liquidation threshold 80%, bonus 5%. Якщо ціна падає на 20%+, позиція відкрита до ліквідації.

Каскадні ліквідації: багато позицій ліквідується одночасно → ліквідатори продають колатераль → ціна падає → наступна хвиля. LUNA/UST — класичний каскад.

Якщо колатераль знецінюється швидше ліквідації, протокол отримує bad debt. Aave використовує Safety Module (застейканий AAVE), Compound — reserves. Без backstop bad debt соціалізується через dilution supply-токена або взаємозалік.

Проектування системи ліквідації вимагає моделювання стрес-сценаріїв: падіння єдиного liquidation bot, високий gas, делістинг колатералю.

Yield farming та incentive mechanics

Liquidity mining — роздача токенів управління LP-провайдерам. Проблема mercenary capital: фармери приходять, продають токени, йдуть. TVL фіктивний.

Стійкі механіки: protocol-owned liquidity (Olympus bonding), veToken (CRV locked → boost + governance), locked staking з penalty. Ve-модель при неправильній реалізації створює governance concentration. Потрібен timelock на зміни gauge weights та ліміти на votingPower.

Що входить у нашу розробку DeFi-протоколів

• Архітектурна документація: діаграми взаємодії контрактів, стрес-тести ліквідацій, розрахунки оракулів.
• Реалізація на Solidity 0.8.x з OpenZeppelin 5.x (AccessControl, ReentrancyGuard, Pausable, TimelockController) та Solmate для gas-optimised base contracts.
• Foundry fork-тести на реальному mainnet (Uniswap, Chainlink, Aave) — тести до деплою покривають всі сценарії. Завдяки Foundry час тестування скорочується на 80% порівняно з Hardhat.
• Аудит: мінімум два незалежних аудитори для TVL від значного рівня. Code4rena або Sherlock для bug bounty.
• Деплой з Gnosis Safe 3/5 multisig + timelock 48–72 години.
• Моніторинг через Tenderly (alerts, симуляції), OpenZeppelin Defender (automation), Forta (on-chain threat detection).
• Підтримка після запуску: оновлення, патчі, апгрейди через proxy.

Наші компетенції та досвід

Ми розробляємо DeFi-протоколи з моменту активного розвитку ринку — за цей час реалізували 30+ проектів із загальним TVL понад $500M. Серед клієнтів — протоколи в топ-20 за TVL на Ethereum, Arbitrum та Base. Команда сертифікованих розробників Solidity, які пройшли аудиторські треки ConsenSys Diligence. Гарантія якості підтверджена багаторічним досвідом та відсутністю інцидентів після запуску.

Терміни

• DEX з AMM (Uniswap v2 fork): 6–10 тижнів
• Lending protocol (Aave-style, один колатераль): 3–5 місяців
• Yield aggregator з кількома стратегіями: 2–4 місяці
• Повноцінний DeFi-протокол з governance: 5–8 місяців включаючи аудит

Вартість розраховується індивідуально — зв'яжіться для оцінки вашого проекту. Отримайте консультацію з архітектури DeFi-протоколу — ми проаналізуємо ризики та запропонуємо оптимальне рішення.