Збір даних з DEX-агрегаторів: 1inch, Jupiter

Збір даних з DEX-агрегаторів: 1inch, Jupiter При побудові аналітики DeFi-ринків ви стикаєтеся з проблемою: як отримати чисті дані про маршрутизацію та ціни з DEX-агрегаторів, не впираючись у їхні rate limits? <cite>[1inch](https://en.wikipedia.org/wiki/1inch)</cite> і <cite>[Jupiter](https://en.w

Напрямки блокчейн-розробки

Часті запитання

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1451
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1309
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    1005
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1270
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    719
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    1011

Збір даних з DEX-агрегаторів: 1inch, Jupiter

При побудові аналітики DeFi-ринків ви стикаєтеся з проблемою: як отримати чисті дані про маршрутизацію та ціни з DEX-агрегаторів, не впираючись у їхні rate limits? 1inch і Jupiter — ключові джерела, але їхні API мають обмеження, а маршрути часто змінюються. Ми розробили скрапер, який збирає дані з обох агрегаторів, нормалізує їх та зберігає в TimescaleDB або ClickHouse. За 7+ років роботи з Web3 (понад 50 проектів з агрегації) ми відпрацювали архітектуру, стійку до перебоїв.

Скрапінг DEX-агрегаторів — це не просто виклик API за розкладом. Це вміння обробляти різні формати відповідей, обходити ліміти, нормалізувати дані з 1inch (EVM) і Jupiter (Solana) в єдину схему та зберігати їх з урахуванням часових міток для подальшої аналітики. У нашій практиці були проекти, де потрібно було збирати дані по 500+ пар з частотою раз на 10 секунд — це потребувало налаштування BullMQ і Redis для координації запитів.

У цій статті розберемо, як парсити маршрути 1inch і Jupiter, обходити rate limits, зберігати дані та будувати на них аналітику. Також ми обговоримо збір MEV-даних, парсинг свопів на EVM-мережах і практичні прийоми скрапінгу DEX-агрегаторів.

Як збирати дані з 1inch API без rate limits?

Swap API vs Fusion API

Swap API (/swap/v6.0/{chain}/swap) — класична агрегація. Запит повертає:

  • tx об'єкт з повними даними транзакції
  • protocols — список протоколів у маршруті з частками
  • toAmount — мінімальна вихідна сума

Для скрапінгу цінових даних без виконання свопу використовуємо /quote endpoint: немає slippage параметра, немає fromAddress, повертає лише котирування. Це не створює навантаження на RPC і не потребує дозволів.

Fusion API (/fusion/v1.0/{chain}/quote/receive) — інша модель: RFQ (request for quote) з участю market maker-ів. Маршрутизація непрозора, протоколи не розкриваються повністю. Для скрапінгу маршрутів — менш корисний.

Rate limits і обходи

1inch Public API: 1 request/second, 500k requests/month безкоштовно. Для інтенсивного скрапінгу — 1inch Dev Portal з Pro планом або використання власного 1inch router через direct contract calls.

Прямий виклик 1inch Aggregation Router через eth_call — отримуємо quote без HTTP запиту і без rate limits. Використовуємо calldata з SDK для симуляції:

const data = routerContract.interface.encodeFunctionData("swap", [ executor, desc, data ]); const result = await provider.call({ to: ROUTER_ADDRESS, data }); 

Але це потребує розуміння внутрішнього формату 1inch — він змінюється між версіями роутера.

Парсинг маршруту

Відповідь /quote містить protocols — масив масивів, що представляє split route:

"protocols": [ [ [{"name": "UNISWAP_V3", "part": 60, "fromTokenAddress": "...", "toTokenAddress": "..."}], [{"name": "CURVE", "part": 40, ...}] ] ] 

Перший рівень — parallel paths (split за об'ємом). Другий рівень — sequential hops всередині шляху. Для побудови графа ліквідності: нормалізуємо імена протоколів, агрегуємо за парами токенів, відстежуємо динаміку part у часі.

Чому Jupiter Price API кращий для аналітики?

V6 Quote API

GET /quote?inputMint=...&outputMint=...&amount=...&slippageBps=50 Відповідь включає routePlan — детальний маршрут через AMM-и Solana:

"routePlan": [ { "swapInfo": { "ammKey": "...", "label": "Orca (Whirlpool)", "inputMint": "...", "outputMint": "...", "inAmount": "1000000", "outAmount": "998432", "feeAmount": "3000", "feeMint": "..." }, "percent": 100 } ] 

Для скрапінгу: ammKey — публічний ключ пулу на Solana. Можна прямо запросити стан пулу через getAccountInfo. label — людиночитане ім'я AMM.

Price API Jupiter

Jupiter надає /price?ids=... endpoint — bulk price query для до 100 токенів за запит. Повертає ціну в USDC з вказанням ліквідності джерела. Це не quotation (немає slippage), а довідкова ціна. Оновлюється кожні 30 секунд.

Для побудови price history: опитуємо /price з потрібними парами кожні 30 секунд, зберігаємо в TimescaleDB або InfluxDB. За день — ~2880 точок на пару.

Rate limits Jupiter: публічний API без ключа — 600 requests/minute. Jupiter API Pro — вище. Гарантія безперервної роботи для production систем — використовуємо власний Jupiter self-hosted або партнерський ключ.

Архітектура скрапера

Структура даних

interface RouteSnapshot { timestamp: number; chain: "ethereum" | "solana" | "arbitrum" | ...; inputToken: string; outputToken: string; inputAmount: bigint; outputAmount: bigint; priceImpact: number; // в % protocols: ProtocolHop[]; source: "1inch" | "jupiter"; } interface ProtocolHop { name: string; poolAddress: string; percentOfRoute: number; inputAmount: bigint; outputAmount: bigint; } 

Черга запитів і retry

Скрапер з декількома парами токенів → паралельні запити → швидке досягнення rate limit. Правильна архітектура: черга з Bull/BullMQ + Redis, configurable concurrency per source.

Retry з exponential backoff для 429 Too Many Requests: delay = Math.min(base * 2^attempt, maxDelay). Для 1inch — base = 1000ms, maxDelay = 30000ms.

Моніторинг health скрапера: prometheus метрики scraper_requests_total{status="success|error"}, scraper_latency_ms. Alert при error rate > 10% за 5 хвилин.

Зберігання та запити

TimescaleDB (PostgreSQL розширення) для часових рядів — оптимізований для WHERE timestamp BETWEEN ... AND ... запитів з агрегацією. Для скрапінгу маршрутів з високою частотою — партиціювання за днями.

ClickHouse як альтернатива для дуже високих обсягів (>10M рядків/день): columnar storage дає 10-100x швидші аналітичні запити за великими часовими діапазонами.

Порівняння сховищ
Характеристика TimescaleDB ClickHouse
Оптимізація часові ряди, JOIN аналітика, агрегації
Max throughput до 1M рядків/день >10M рядків/день
Швидкість запитів висока для точкових висока для агрегатів
Вартість проекту від $1000 від $2000
Пара 1inch chains Jupiter pools Частота
USDC/ETH Ethereum, Arbitrum, Optimism 1 хв
SOL/USDC Orca, Raydium 30 сек
BTC/USDC всі EVM 5 хв

Що входить у роботу

  1. Аналіз ваших цілей та підбір пар/частоти опитування.
  2. Розробка скрапера (Node.js/TypeScript) з буферизацією та retry.
  3. Інтеграція зі сховищем (TimescaleDB / ClickHouse).
  4. Дашборд або API для доступу до даних (Grafana, REST).
  5. Документація по форматах даних і лімітах.
  6. Передача доступів і навчання вашої команди.

Орієнтири за термінами та бюджетом

Скрапер для одного джерела (1inch або Jupiter) зі зберіганням в PostgreSQL — 1-2 дні, від $800. Мультисорсний скрапер з нормалізацією даних, ClickHouse та аналітичним API — 3-5 днів, від $2000. Терміни та вартість обговорюються індивідуально — пишіть, оцінимо проект безкоштовно.

Замовте розробку скрапера під ключ за вашими вимогами — отримайте надійний інструмент для аналітики DeFi. Зв'яжіться з нами — підберемо оптимальне рішення під ваші пари та частоту опитування.