Граббінг даних з агрегаторів DEX (1inch, Jupiter)

Граббинг даних з агрегаторів DEX (1inch, Jupiter)

1inch та Jupiter не просто дають кращу ціну — вони публікують маршрутизаційну логіку через API. Це цінний джерело даних: які пулі використовуються для пари, як розбивається об'єм між протоколами, який price impact при різних розмірах ордера. Для аналітичних систем, MEV-ботів, арбітражних стратегій та дослідницьких інструментів — це сирий матеріал.

API 1inch: що реально доступно

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 запит/секунду, 500k запитів/місяць безплатно. Для інтенсивного скрапінгу — 1inch Dev Portal з Pro планом або використання власного 1inch router через прямі contract calls.

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

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

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

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

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

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

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

Jupiter API (Solana)

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 запитів/хвилину. 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, настроювальна concurrency за джерелом.

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. Алерт при error rate > 10% за 5 хвилин.

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

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

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

Процес роботи

Аналітика (0.5 дня). Список пар та розмірів ордерів для моніторингу, вимоги до частоти оновлення, цілі використання даних (аналітика / торговий сигнал / дослідження).

Розроблення (1-3 дні). Сервіс скрапера (Node.js/TypeScript) + зберігання + базовий дашборд або API для споживання даних.

Орієнтири по строкам

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

Вартість розраховується індивідуально.