Инженерные заметки Naly: интеграция API Polymarket Gamma для публикаций о рынках прогнозов

КраткоNaly использует API Gamma от Polymarket как детерминированную базу обнаружения и формирования цен для всех рабочих процессов рынков прогнозов, заменяя разрозненные скрейпинги новостей структурированными рыночными сущностями. Каждым циклом она преобразует живые события и рынки в сигналы, готовые к формированию статей для сводок mispricing, превью KBO, пакетов цитирований и последующей проверки результатов, поэтому генерация материала всегда начинается с наблюдаемых публично вероятностей и рыночной структуры, а не с выведенных мнений.

Аннотация

Naly использует данные рынков прогнозов как инфраструктуру, а не как добавку, поэтому редакционные артефакты напрямую связываются с внешним состоянием рынка, которое позже можно проверить. API Gamma дает путь чтения для событий, рынков, тегов и цен без необходимости ключей уровня кошелька. Задача дизайна — сделать этот слой ingest достаточно строгим для надежности и одновременно достаточно гибким для редакционных команд, которым нужна быстрая тематическая разведка.

Место в Naly

Интеграция Polymarket Gamma находится на верхней границе между сырыми рыночными примитивами и публикуемыми редакционными материалами. Это первый шаг более широкой цепочки:

Входной слой: получение событий, рынков, тегов и статусов рынков из Gamma.
Интерпретационный слой: нормализация во внутреннюю схему Naly (event_id, market_id, ID токенов, исходы, вероятности, временные метки, флаги active/closed).
Нарративный слой: подача нормализованных входов в потоки сводок mispricing и черновиков прогнозов KBO.
Слой валидации: хранение состояний resolved/closed для последующей проверки фактов в статьях и ретроспективных scorecards.

По состоянию на 10 июня 2026 года это особенно соответствует активным тактикам, которым нужны надежные, пригодные для цитирования доказательства прогнозирования: прозрачность калибровки, воспроизводимое получение источников и последующие процессы верификации.

Технический механизм

Polymarket определяет три API, где Gamma — это публичный слой discovery для просмотра событий/рынков и метаданных, тогда как данные книги заявок и торговых операций раскрываются через CLOB, а данные пользователя/позиций — через Data API (документацию). Gamma и Data публичны по документации Polymarket, в то время как CLOB имеет приватные торговые поверхности, для которых для операций с заявками требуется аутентификация.

Naly может реализовать надежный ежедневный поток, используя только публичные endpoint-ы:

Поиск активных рыночных кандидатов через GET /events с active=true, closed=falseпагинацией (limit, offset), и необязательными фильтрами сортировки.
Расширение до дочерних рынков через полезную нагрузку уровня события, поскольку события содержат связанные рынки и уменьшают число вызовов API по сравнению с отдельным поиском каждого рынка.
Точное целевое извлечение сущностей с помощью вызовов по slug, когда известное событие или рынок уже определено.
Нормализация цен путем сопоставления outcomes и outcomePrices массивов по индексу в именованные вероятности.
Сохранение артефактов аудита в виде как нормализованных строк, так и сырьевых снапшотов, чтобы каждая статья могла проследить каждую приведенную цифру.
Ограничение последующей генерации по свежести и проверкам схемы: устаревшие или неполные снапшоты помечаются для обновления до использования.

Документация Gamma описывает ровно такую операционную схему: публичные endpoint-ы, такие как /events, /markets, /public-search, /tags, и /series доступны для discovery, а пагинация и фильтрация поддерживаются через limit/offset, tag_id, и связанные фильтры. Также даются прямые рекомендации по трем паттернам получения: поиск по slug, discovery по тегам и перечисление событий для широкого сканирования. Для Naly шаблон event-first наиболее экономичен при построении большого дневного пула кандидатов, потому что каждое событие может раскрывать множество записей рынков.

На практике минимальная запись source-of-truth для Naly должна включать:

ID событий и рынков
рынок question
clobTokenIds (для последующей сверки цены с CLOB при необходимости)
outcomes и outcomePrices
enableOrderBook
active, closed, а также временные поля (временные метки начала/окончания)
временную метку выборки и исходный URL

Хотя Gamma уже может обеспечить сильную вероятностную базу, второй путь уточнения является опциональным: когда Naly нужен более частый внутридневной апдейт, endpoint-ы CLOB, такие как /price, /prices, или /book могут быть объединены позже.

Что говорит литература

Исследования рынков прогнозирования поддерживают этот подход, ориентированный на данные, но вводят ограждения вокруг интерпретации.

Модель рыночных данных на рынках прогнозирования полезна только при корректной калибровке и интерпретации; цены не являются универсальными вероятностями без контекста. Исследование 2026 года по Polymarket и Kalshi выявило системные паттерны калибровки, которые варьируются по домену и горизонтy, включая измеримую недооценку в отдельных областях.
Другое исследование 2026 года с фокусом на жизненный цикл подчеркивает, что осмысленный рыночный анализ требует синхронизированной многослойной инженерии данных: метаданные рынков, торговые события и сигналы резолюции должны иметь явную связь и периодические проверки согласованности, а не быть изолированными извлечениями.
Ранее работа по микроструктуре рынка показывает, что рыночные цены передают информацию трейдеров в потоке непрерывного аукциона, поэтому Naly может трактовать рыночные цены как коллективные прогнозные сигналы, при этом по-прежнему проверяя исходы со временем.
Литература по прогнозированию, сравнивающая рыночные цены с другими методами (например, на основе опросов), показывает, что рынки прогнозирования могут быть очень предиктивными, но только когда сохранена проверка исходов и дисциплина модели.

Практическое следствие для Naly напрямую следует: захватывать всё с provenance, никогда не считать один снэпшот цены финальной правдой и разделять readiness (свежесть данных + целостность) от story quality (редакционного фрейминга).

Компромиссы дизайна

Naly сознательно оптимизирует надежность, а не скорость на уровне ingest.

Gamma-only vs Gamma+CLOB: Gamma дает стабильное discovery и публичный контекст быстро; добавление CLOB повышает глубину микроструктуры, но добавляет сложности с аутентификацией и endpoint-ами.
Ежедневный снапшот vs непрерывный поток: детерминированный запланированный pull проще аудировать и воспроизводить, чем непрерывные потоки, но пропускает подминутные смены режимов.
Event-first pull vs market-first pull: event-first снижает дублирующиеся вызовы и улучшает контекстное покрытие; market-first дает немного меньший размер полезной нагрузки для узких задач.
Wide schema vs strict schema: широкая JSON-first схема ускоряет интеграцию, но повышает риск дрейфа схемы; строгая нормализация ловит дрейф раньше, но увеличивает накладные расходы на миграции.
Generalized fields vs domain-specific fields: использование общих полей повышает переиспользование между статьями; добавление доменно-специфичных расширений (например, окон уверенности для спорта) повышает точность сразу, но может фрагментировать долгосрочное обслуживание.

Учитывая цель Naly по доверительному отношению и удержанию, строгая воспроизводимость и качество цитирования должны иметь приоритет над мгновенной оптимизацией латентности.

Режимы сбоев

Крупнейшие режимы сбоев — операционные, а не алгоритмические.

Отсутствующие данные из-за ошибок пагинации: если limit и offset окна меняются между опросами, могут появляться дубли или пробелы. Митигация: чекпоинтить курсоры пагинации и выполнять идемпотентные upsert-ы.
По умолчанию closed=false утрата исторического контекста: open-market pulls пропускают resolved-элементы, если closed=true не запрошено явно. Митигация: запускать отдельный путь исторического backfill для задач верификации.
Нестабильность slug: URL продукта и человеко-читаемые slug могут смещаться. Митигация: использовать первичные ID внутри системы и хранить slug как вторичный ключ.
Дрейф семантических полей: outcomes/outcomePrices интерпретация может ломаться, если предположения о порядке полей схемы неверны. Митигация: проверять выравнивание массивов и длину при ingest.
Временная недоступность API или троттлинг: публичные endpoint-ы могут падать или возвращать частичные payload-ы. Митигация: повтор с экспоненциальным backoff, poison-queue при повторных сбоях и сохранение предыдущих снапшотов.
Позднее резолюция и устаревшие нарративы: статьи верификации могут публиковаться до того, как расчет закроется чисто. Митигация: хранить статус settlement как часть состояния публикации и обновлять постфактум с неизменяемым журналом корректировок.

С учетом trust-first стратегии Naly конвейер должен работать в режиме fail closed: лучше отложить публикацию, чем выпускать статью с непроверяемым состоянием рынка.

Примечания по реализации

При заявленном runtime-стеке практическая реализация остается прямолинейной:

Использовать серверные обработчики Next.js (next@16.0.7) для размещения endpoint-ов ingest и запланированных jobs.
Сохранять нормализованные строки в Neon через drizzle-orm@^0.44.7 с @neondatabase/serverless@^1.0.2 явными уникальными ограничениями по идентификаторам рынков.
Хранить сырые payload-снапшоты в Vercel Blob (@vercel/blob@^2.0.0) для auditability и постморемного сравнения diff.
Держать генерацию markdown и сборку статьи вне ядра ingest; использовать marked@^17.0.1 для безопасной трансформации и ai@6.0.0-beta.105 плюс @anthropic-ai/claude-agent-sdk@^0.2.15 только после прохождения проверок целостности данных.
Использовать tsx@^4.21.0/typescript@^5.9.3 для воспроизводимых одноразовых повторных прогонов при backfilling исторических окон.

На 10 июня 2026 года архитектура должна приоритизировать три жестких результата: неизменяемость сырого снапшота, детерминированную проекцию во внутреннюю схему и аудитный след, ориентированный на верификацию, от URL исходного API до финальной цитаты статьи.