Граббинг данных DeFi-протоколов (TVL, APY, пулы)

Сбор данных DeFi-протоколов часто превращается в хаос из-за разрозненных источников и задержек обновлений. Мы разрабатываем надёжные системы граббинга TVL, APY и пулов, учитывая особенности каждого протокола и инфраструктуры. Наша команда реализует проект под ключ — от аудита источников до внедрения и последующей поддержки, обеспечивая стабильную работу и масштабирование вместе с вашим бизнесом.
Часто задаваемые вопросы

Мы регулярно сталкиваемся с задачей сбора TVL и APY по DeFi-протоколам. На первый взгляд всё просто: вытянуть данные, сложить в базу, отдать через API. Но на практике каждый протокол использует собственную логику расчёта — часть данных лежит on-chain, часть — в субграфах с задержкой, а APY пересчитывается каждый блок. Многие протоколы деплоят несколько версий на разных чейнах с несовместимыми ABI. К тому же RPC-провайдеры ограничивают частоту запросов, а субграфы The Graph могут устаревать (The Graph Protocol). Без продуманной архитектуры граббинга вместо чистых данных вы получаете кашу из пропущенных точек, завышенных TVL из-за манипулированных цен и неверного APY.

Источники данных и их особенности

The Graph: основной источник агрегированных данных

Большинство крупных протоколов имеют официальные субграфы: Uniswap, Curve, Aave, Compound, Balancer, Yearn. The Graph Studio позволяет запрашивать исторические и текущие данные через GraphQL.

Проблемы, с которыми сталкиваемся:

  • Задержка. Субграф обновляется с задержкой 1–10 минут после on-chain событий. Для мониторинга реального времени — не подходит. Для исторических данных и дашбордов — норма.
  • Устаревшие субграфы. Uniswap v2 субграф давно не поддерживается командой, данные могут быть неполными. Для Uniswap v3 официальный субграф периодически отстаёт при высоком объёме.
  • Пагинация. The Graph возвращает максимум 1000 записей за запрос. Для получения всех пулов Uniswap v3 (их >50 000) нужна пагинация через skip или id_gt паттерн.
query GetPools($lastId: String) {
  pools(first: 1000, where: { id_gt: $lastId }, orderBy: id) {
    id
    token0 {
      symbol
      decimals
    }
    token1 {
      symbol
      decimals
    }
    totalValueLockedUSD
    volumeUSD
    feeTier
  }
}
  • Нюанс с TVL в The Graph. Uniswap v3 субграф считает TVL как сумму значений токенов в USD через внутренний price feed. Этот price feed иногда даёт неверные значения для малоликвидных токенов — пул с $500k реального TVL может отображаться как $50M из-за манипулированной цены одного токена. Нужна проверка через внешний источник.

On-chain запросы для точных данных

Для данных, которые важно получить точно и актуально — прямые eth_call к контрактам:

  • Aave v3 TVL: Pool.getReserveData(asset) возвращает aToken.totalSupply() * liquidityIndex. Для каждого актива в каждом рынке.
  • Curve APY: Minter.minted(gauge, user) для CRV эмиссии, gauge.inflation_rate() для текущей ставки. Реальный APY = (crv_per_year * crv_price) / gauge_tvl_usd.
  • Uniswap v3 fee APY: positions.tokensOwed0/1 — накопленные комиссии. Для general pool APY: pool.feeGrowthGlobal0X128 — дельта за период / liquidity.

Multicall3 (0xcA11bde05977b3631167028862bE2a173976CA11) — деплоен на всех мейджорных чейнах, позволяет пакетировать сотни eth_call в одну транзакцию. Вместо 100 отдельных RPC запросов — один batch. Для скрапинга это критично по производительности. Multicall3 в 10 раз эффективнее последовательных eth_call.

DeFi Llama API

https://api.llama.fi — публичный API без ключа для TVL данных по большинству протоколов. Структура данных:

GET /tvl/{protocol} → current TVL
GET /protocol/{protocol} → historical TVL + breakdown
GET /pools → APY по всем пулам (~10k записей)

/pools — золотая жила: там уже посчитан APY для тысяч пулов на всех чейнах. Но DeFi Llama обновляет данные раз в несколько минут — для realtime задач нужен собственный расчёт.

Источник Задержка Точность TVL Стоимость запросов
The Graph 1–10 мин Средняя (риск манипуляции) Бесплатно (1000 запросов/день)
On-chain (eth_call) Реальное время Высокая Gas, RPC лимиты
DeFi Llama несколько мин Средняя Бесплатно, без ключа

Как нормализовать данные из разных протоколов?

Каждый протокол возвращает данные в своём формате. Нормализация — ключевой компонент системы. Мы приводим всё к единой схеме: { protocolId, chainId, poolAddress, tvlUsd, apy, timestamp }. Единая схема позволяет строить cross-protocol сравнения. Для этого используем Node.js скрипты с TypeScript и библиотеку ethers.js.

Архитектура системы граббинга

Слои сбора данных

Scheduler (cron / event-driven)
├── GraphQL Fetcher (The Graph subgraphs)
├── On-chain Fetcher (Multicall3 + ethers.js)
├── HTTP Fetcher (DeFi Llama, CoinGecko)
└── WebSocket Listener (real-time events)
↓
Normalizer (единый формат)
↓
TimescaleDB / PostgreSQL
↓
API (REST/GraphQL)

Normalizer — ключевой компонент. Каждый протокол возвращает данные в своём формате. Нормализация: { protocolId, chainId, poolAddress, tvlUsd, apy, timestamp }. Единая схема позволяет строить cross-protocol сравнения.

Расчёт APY

APY = Annual Percentage Yield с учётом compound. Для большинства DeFi-протоколов данные — это APR (без compound), который нужно пересчитать:

APY = (1 + APR/n)^n - 1, где n — количество compound периодов в год.

Для lending протоколов APR обычно уже с compound (Aave v3 считает через liquidityRate). Для LP позиций — нет: fees начисляются без reinvest.

Компоненты реального APY для Uniswap v3 LP позиции:

  1. Trading fees APR (зависит от volume и position range)
  2. Liquidity mining rewards (если есть incentives)
  3. Минус IL (историческая оценка)

Почему APY без вычета IL вводит в заблуждение?

Честный APY без вычета impermanent loss — показывает завышенную доходность. В реальности при широком диапазоне LP позиции IL может съедать до 80% прибыли. Мы показываем оба числа: fee APY и fee APY минус IL.

Обработка ошибок и rate limiting

Alchemy free tier: 300 CUPS (compute units per second). Один eth_call = 10–40 CU, Multicall3 = 20 CU независимо от количества запросов внутри. Пакетируем максимально.

The Graph: 1000 запросов в день на бесплатном плане. Используем кэш с TTL — большинство данных не нужно обновлять чаще раза в 5 минут.

Retry с exponential backoff на все HTTP запросы. Dead letter queue для failed fetches — не теряем данные при временных сбоях RPC.

Компонент Источник Особенности
Trading fees On-chain / The Graph Зависит от объёма и диапазона
Rewards Merkle drop / incentives Требует мониторинга
IL On-chain price Оценивается исторически

Стек разработки

TypeScript + Node.js для скраперов. PostgreSQL + TimescaleDB для хранения time-series. Redis для кэширования промежуточных данных. Docker Compose для локальной разработки.

ethers.js v6 для on-chain взаимодействий. graphql-request для The Graph запросов. p-limit для контроля параллельности (не давим RPC провайдеры).

Типичные ошибки при граббинге DeFi-данных

  • Использовать только один источник без валидации. TVL из непроверенного субграфа может быть в 10 раз выше реального из-за манипулированных цен.
  • Не учитывать impermanent loss при расчёте APY для LP.
  • Игнорировать rate limits — скрапер падает с ошибками, данные теряются.
  • Хранить все данные в одной таблице без партиционирования — запросы к истории тормозят.

Что входит в работу

  1. Анализ протоколов и источников данных под вашу задачу.
  2. Разработка скрапера с нормализацией и валидацией.
  3. Настройка TimescaleDB с TTL и партиционированием.
  4. REST/GraphQL API с кэшированием.
  5. Документация по структуре данных и endpoint'ам.
  6. Поддержка в течение месяца после сдачи.

Ориентиры по срокам

Граббер для 2–3 протоколов на одном чейне с базовым API — 2–3 дня. Multi-protocol, multi-chain система с исторической базой и нормализацией — 1–2 недели в зависимости от количества источников и требований к точности APY.

Оценим ваш проект и предложим решение под ключ. Свяжитесь с нами, чтобы обсудить детали. Закажите разработку скрапера DeFi-данных.

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

Последние работы

  • Разработка сайта компании B2B ADVANCE
    Разработка сайта компании B2B ADVANCE
    1542
  • Разработка веб-приложения для компании FEEDME
    Разработка веб-приложения для компании FEEDME
    1394
  • Разработка веб-сайта для компании БЕЛФИНГРУПП
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    1081
  • Разработка интернет магазина для компании FURNORO
    Разработка интернет магазина для компании FURNORO
    1369
  • Разработка логотипа компании B2B Advance
    Разработка логотипа компании B2B Advance
    816
  • Разработка веб-приложения для компании Enviok
    Разработка веб-приложения для компании Enviok
    1142